Maybe I have not been really clear and got lost in details in my first mail. To put it straight:
1: Do we want to be able to handle files opened by or dragged from nautilus over a remote connection? 2: Do we want to implement some options to make gvim behave more like gedit in the way it treat multiple files (tabs, all in one instance). It's about adding some options, not making that the default. I think it's *not* *much* *coding* to get it. If you use gnome and nautilus you may value this kind of behaviour. Il giorno mer, 21/03/2007 alle 07.35 +0100, A.J.Mechelynck ha scritto: > Andrea Ratto wrote: > > I think we are missing some easy integration with gnome desktop. Here is > > how I got to think so: > > > > I was working with some files on a remote folder using nautilus and > > noticed I could open remote text files with gedit transparently; but > > that did not work with gvim. > > I knew vim can handle editing over ssh, and I would really value > > clicking on a remote file and have it opened in gvim instead of gedit. > > > > To cut a long story short I ended up in making this small script > > under /usr/local/bin > > > > #!/bin/bash > > > > if [[ $# = 0 || $# = 1 && $1 = "-f" ]]; then > > /usr/bin/gvim $1 > > else > > /usr/bin/gvim --remote-tab `echo $@ | sed 's/-f//' | sed 's/ssh: > > \/\/\(\w\+\)@\(\w\+\)\//scp:\/\/[EMAIL PROTECTED]/\//gi'` > > fi > > > > And now gvim behaves just like gedit! > > I can open files from nautilus in the existing gvim session and open > > files from a ssh folder. I like this behaviour and I think that very > > little work is necessary to implement such features in the official > > gvim, at least in the one with gnome support. > > > > Basically what we need to get this quikly is: > > > > 1: have netrw handle links like ssh:[EMAIL PROTECTED]/folder/file just like > > it > > handles scp:[EMAIL PROTECTED]//folder/file. May require similar changes for > > other protocols as well. > > 2: allow --remote-tab with no argument to open a blank gvim session > > instead of failing > > what about --remote-tab-silent ? It's better because does not produce useless output, but still works the same way. Thanks for pointing it out, my example script should use that, but the way it works it's not going to change. > > 3: change the exec line of the gvim.desktop from "gvim -f %U" to "gvim > > -f -p --remote-tab %F" > > IIUC, that's not a change in Vim. It may be a change in the Vim package in > your Linux distro if it installs that Vim shortcut. The "make install" from > the "official" Vim installation (as downloaded straight from ftp.vim.org ) > installs no keyboard shortcut. It's a menu entry not a keyboard shortcut. It sets the code to be run when you open a file by clicking on it or when you click the gvim icon. > But IMHO those --remote-tab and -p parameters > shouldn't be there by default. I don't know the difference between %U and %F. %U does one invocation per file opened, like gvim fileone; gvim filetwo ... %F does one invocation with all files as arguments like gvim fileone filetwo ... > > > > Even better: we could add some internal options like ":set remotetabs" > > and ":set openintabs" so that this behavior can be set on a per user > > basis. This would be elegant and could work with "gvim -f %F" exec > > command in the .dekstop file. > > I'm skeptical about the usefulness of such additional options. Could you use gedit for a while, with multiple files? This may explain the point better. > > > > I'd like to know your opinions about this. > > > > PS: it also seems that --remote-tab does play well with gnome > > startup-notification when a session is already opened, but this is just > > a cosmetic bug. > > The fact that it does indeed play well is a cosmetic bug ??? There's > something > there that I don't quite grasp. After opening in a remote tab from gnome the cursor is set to the "busy" state even after the file is fully loaded. I don't want to insist on this right now since it's probably easy to fix and it's just cosmetic. > > Best regards, > Tony. Thanks Tony.
