External F4 (or Ctrl-F4) editor

[elkie]

For many years I use FAR manager console application for Windows. I believe you know it. It is the number one program for me in Windows just because I love the console. For several reasons I switched to Mac now, and I am sad that there is almost nothing similar to FAR under Mac OS X.

It is not a secret that there are 3 most famous file managers for Mac OS: XF..., D.O., and muCommander. I tested them all, and as for me, muCommander is really the best, without variants. It is much more closer to traditional NC or FAR, I feel myself in muCommander just like in home.
Actually, there is only one thing I really-really miss in muCommander - good (really good - see FAR's editor for example) text editor. I want to just press F4 and edit ANY text file with ANY extension of ANY type for ANY reason (html, txt, php, conf, css, inc, etc.). I don't want to use OS's defaults, I want my file manager to manage it.

As I read this forum, the most wanted new feature is exactly F4 (or alternative combination, such as Ctrl-F4) default _external_ editor. Why don't you want to make such an easy improvment? Just one additional setting in preferences, and many users who used FAR or NC for years will be very happy. This feature (or any nice workaround) will be just great!

[Nicolas]

Hey there,

Thanks for the nice feedback - is muCommander really that popular? I never realised :)

Here's something that will make you like it even more: your post triggered a long discussion between the lead developers, and we came to the conclusion that not only should we make the editor configurable, but we should also go the extra mile and make this sort of configuration generic to the system and we should do it soon.

I hate giving dates, it makes me feel like I'm in the office, but this should make it to v0.8 beta 3 which we're hoping to release soonish - this is probably the last feature we'll add, and then it's just a matter of waiting for translations.

Do you love us or what? :)

Nicolas

[elkie]

Thank you for your reply, Nicolas.

Thanks for the nice feedback - is muCommander really that popular? I never realised

It is as popular as 2-panels file manager idea is popular under Mac OS at all. For unknown reason NC-like file managers are not popular under Mac OS. I can not work without "2-panels application". Internet says about 3 NC-like managers for Mac OS, almost every user's message about file manager mentions them all.

Let's be realists: for Windows muCommander of course has no chances. But for Mac OS it is simply the best.

Here's something that will make you like it even more: your post triggered a long discussion between the lead developers, and we came to the conclusion that not only should we make the editor configurable, but we should also go the extra mile and make this sort of configuration generic to the system and we should do it soon.

I am really sorry, but I didn't understand what exactly you meant. Maybe my English is too bad for that.

Do you mean you want to make a system (i.e. OS) associate all file types with a single editor, or what?

I just may suggest to make user-defined shortcuts for launching any application with filename as a parameter. Then a user will be able to add any application (text editor as well, or even several different text editors for different hotkeys) to work with all files.
Update: if you think this feature will not be very popular, just make it "hidden", i.e. do not add it to GUI preferences and make it configurable with XML preference files... Please mind the hotkeys, menu "Open with" without hotkeys support is just not enough.

[Nicolas]

Mmm... let me make myself clearer. One feature we're working on and that should make its way into the nightly build fairly soon is the possibility for users (so, you) to create custom muCommander commands with parameters.

Sounds a bit arcane, but see it that way: there is a mucommander command which opens the current file with the default editor. It'll soon accept parameters which will be used as a command to open a file.
For example: open -a Emacs $f
Since all mucommander actions can be bound to a keyboard shortcut, you'll be able to do pretty much whatever you want, something like f4 -> default editor, shift-f4 -> emacs, ctrl-f4 -> preview, apple-f4 -> photoshop, ...

Was that pretty much what you had in mind?

[elkie]

Was that pretty much what you had in mind?

Yes, that's a really wise and powerful solution. This really moves muCommander forward to the ideal.

Please also pay attention to a very strange bug I discovered in my environment:
http://www.mucommander.com/forums/viewtopic.php?t=417
I really can't understand where it's coming from, but unfortunately it will be impossible to work with muCommander if this bug is not solved somehow...

[viskwal]

Hi Nicolas,

I'm running the latest nightly build and I just tried what you explained here :
<action class="open -a TextMate.app $f" keystroke="F4"/>

but it doesn't seem to work. Is there anyplace we can download some documentation to see which switches work and how they can be configured... this looks like a great feature...

muCommander is fast becomming an awesome application on Os X (long time Windows Commander addict... and NC before that)

cheers,
Peter

[hritcu]

I agree that this is a great feature to have in muCommander, I find myself too often dragging and dropping files to Smultron instead of just pressing F4.

[Nicolas]

Viskwal: it's not working yet, that's why :)

This has become one of the most demanded features since release 0.8 beta 3, so we're definitely looking into this. We've come up with a few smart ideas of dealing with it, I just need to find the time to implement them now. I'll keep you posted.

Nicolas

[Nicolas]

Alright, custom viewer / editor have made their way to the nightly build. Haven't had the time to write a proper UI for it yet, so bear with me, it's a bit hackish.

First, start the latest nightly build, then quit it. Yes, I know, that sounds a bit strange, but that's to make sure muCommander writes the latest version of the configuration files.

You then need to locate and edit your preferences.xml file following the instructions found here: http://www.mucommander.com/forums/viewtopic.php?t=443

If everything went well, you should be able to find the following elements:

Code: Select all

    <viewer>
        <use_custom>false</use_custom>
    </viewer>
    <editor>
        <use_custom>false</use_custom>
    </editor>


Modify this so it looks like:

Code: Select all

    <viewer>
        <use_custom>true</use_custom>
        <custom_command>open -a Preview $f</custom_command>
    </viewer>
    <editor>
        <use_custom>true</use_custom>
        <custom_command>open -a Emacs $f</custom_command>
    </editor>


You can of course put whatever command you want in the custom_command elements.

Editing commands should be fairly straightforward. You can use the following special tokens:
- $f: will be replaced by the selected file's full path.
- $p: will be replaced by the selected file's parent.
- $n: will be replaced by the selected file's name.
- $j: will be replaced by the JVM's current directory.

If you want to keep using the internal viewer / editor, just set use_custom to false.

Note that while muCommander let's you view / edit file that are located on remote servers, most softwares do not know how to deal with protocols such as sftp or ftp . For this reason, the file will be copied locally in your temp directory and deleted when you exit muCommander.
What this means is:
- if it's a big file, the viewer / editor will take a while before starting.
- editing remote files really doesn't make much sense, as the modifications will only be applied locally.

If you still want to have the ability to edit remote files, well, I'm afraid you're stuck with the internal editor. Luckily, you can bind your custom editor to one shortcut and the internal one to another: edit the action_keymap.xml file located in your preferences folder and add the following lines:

Code: Select all

  <action class="com.mucommander.ui.action.InternalEditAction"          keystroke="shift F4"/>
  <action class="com.mucommander.ui.action.InternalViewAction"          keystroke="shift F3"/>


The internal editor is now bound to shift F4 and the internal viewer to shift F3.

Hope this helped. If any of it is a bit obscure, let me know and I'll try to clarify things.

Nicolas

[hritcu]

Tried this and it works great. Thank you again guys

[Nicolas]

No worries, it was actually quite fun to write: I had never realised how usefull the various API we designed for muCommander were, and getting the whole thing up and running in under 2 hours was quite a rush :)

Let us know if you find any problem or can think of improvements, though.

Nicolas

[alejandroscandroli]

Guys, this is absolutely great.
Now I can run my jedit directly from muCommander. EXCELLENT!!!
Thank you VERY VERY much.

Alejandro.

[Nicolas]

Glad you liked it :)

Nicolas

[viskwal]

Hi Nicolas,

I just tried it and it is absolutly fantastic.
mucommander also seems to look better with each nightly build.

Great job on the F4 editor, however I have to ask : is there a specific reason why you don't re-upload a file edited through FTP ?

I know it's considered very bad practice to edit live pages, but I do it all the time, mostly due to tight deadlines and clients who want everything yesterday.

I do have a local MAMP installation running though, to edit locally and after everything has been tested I upload, but this is not always possible.

I currently use YummyFTP in tandem with TextMate.
YummyFTP works in the same way in that it downloads the file in a temp dir, but when it is edited and saved in TextMate, it uploads the edited file back to the server and overwrites the original.
This is a very handy feature to have, and would be nice if mucommander could work in the same manner (maybe configurable for those who don't want this).

Anyway, I also have another FTP bookmark request, but I'll post that in a new thread.

[Nicolas]

Hey there,

Well, there actually is a sound reason for not re-uploading the file after it's been edited: when using external tools, we don't know when the file is finished being edited.
We cannot rely and the process being finished because, well, there's no guarantee that the editor is ever going to be closed.
Typically, my external editor is set to Emacs. I always have an instance of Emacs running, and editing a file just creates a new 'window' in that instance. Once I'm done editing, I close the file's window, not Emacs. The process is not killed.
If you're running mac os x, it's even trickier: I open emacs with 'open -a Emacs %f'. This process quits almost instantaneously and spawns a new one (emacs itself), one that muCommander is not aware of.

We thought of a workaround, namely monitoring the file's last modification date - whenever that changes, it means we must upload the newer version. This, however, would turn muCommander in a huge memory hogg: just because a file has been changed doesn't mean that the user is not working with it anymore, he might very well do more modifcations afterwards. So whenever a file is edited that way, we need to monitor it *until muCommander is closed*. I personally never kill muCommander unless I have to reboot.

So yeah, we thought about doing what you suggest, but haven't yet been able to come up with a good algrithm to spot when the file should be uploaded. Any suggestion is welcome, though :)

Nicolas