Menu
▾
▴
vimplugin-devel
|
From: Nageshwar M <wha...@gm...> - 2007-10-13 14:40:33
|
Hi, I read this message on the sf and here is the reason why we implemented that way. Starting the Gvim instance is taking a lot of time for connection initialization. If the user wants to edit a file quickly, he has to wait for the whole procedure. Instead of that he can quickly open the file in the existing vim window as another buffer. So we have given that option. There is another advanced functionality to think about. That is, if there are two opened gvim windows and when we right click the file to open, then we will get "open in new window", "open in 1st gvim", "open in 2nd gvim" like that (similar to context menu provided by vim on windows). This removes the redundant code and also gives the user an advanced editing environment. If everybody accepts the above idea, then we can continue working on that part. -- Best Regards, Nageshwar M. |
|
From: Dave T. <dav...@gm...> - 2007-10-14 13:38:51
|
The two classes aren't about 'opening in an external window' or 'open embedded in vim'. That option is indeed as you suggested controlled by a setting in the preferences page. The two classes are there for either: 1) VimEditor class: This class will try to open the file using the default Vim instance. If this instance doesn't exist it will be created. Using this class multiple files can be opened in one vim instance. 2) VimEditorNewWindow class: This class will always open a file in a new Vim instance which will only contain the one file. Using the second class we can easily embed vim into eclipse since each tab will contain its own vim instance. Using the first class gives better performance but doesn't embed into eclipse properly at the moment. If we use the first class we couldn't use Eclipses tabs, but we would be using Vim's tabs. Best Regards, David Terei. P.S My email system had a heart attack on the weekend, also not helped by a misplaced 'rm -r' call by myself. At the moment I'm trying to get it all fixed up again, hence why I've haven't replied to a fair few emails. On 10/14/07, Nageshwar M <wha...@gm...> wrote: > > Hi, > > I read this message on the sf and here is the reason why we > implemented that way. Starting the Gvim instance is taking a lot of > time for connection initialization. If the user wants to edit a file > quickly, he has to wait for the whole procedure. Instead of that he > can quickly open the file in the existing vim window as another > buffer. So we have given that option. There is another advanced > functionality to think about. That is, if there are two opened gvim > windows and when we right click the file to open, then we will get > "open in new window", "open in 1st gvim", "open in 2nd gvim" like that > (similar to context menu provided by vim on windows). This removes the > redundant code and also gives the user an advanced editing > environment. If everybody accepts the above idea, then we can continue > working on that part. > > -- > Best Regards, > Nageshwar M. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > vimplugin-devel mailing list > vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimplugin-devel > |
|
From: Sebastian M. <seb...@un...> - 2007-10-14 20:59:09
|
Am Sun, 14 Oct 2007 23:38:55 +1000 schrieb "Dave Terei" <dav...@gm...>: > The two classes aren't about 'opening in an external window' or 'open > embedded in vim'. That option is indeed as you suggested controlled > by a setting in the preferences page. > > The two classes are there for either: > > 1) VimEditor class: This class will try to open the file using the > default Vim instance. If this instance doesn't exist it will be > created. Using this class multiple files can be opened in one vim > instance. > > 2) VimEditorNewWindow class: This class will always open a file in a > new Vim instance which will only contain the one file. > OK, I understand now. And it's explained well in the docs ... I got only distracted by the name which suggests something else. How about VimEditorNewInstance instead? > Using the second class we can easily embed vim into eclipse since > each tab will contain its own vim instance. Using the first class > gives better performance but doesn't embed into eclipse properly at > the moment. If we use the first class we couldn't use Eclipses tabs, > but we would be using Vim's tabs. Could't we embed the _same_ gvim using "--socketid" in the different eclipse-editor-tabs all the time? Then when the eclipse tab is changed, or a new editor is opened, we only create a new buffer in vim, select that buffer and we are done. The user should not notice what is going on behind the scenes (unless he did :buffers or similar). When Embedding is unchecked, we could use tabs instead. That would give a cleaner design (one editor class instead of three, where two of them are two-liners), a cleaner userinterface (only one vim-editor in the menu) and at last give a better performance (only one gvim running) .. Getting technical: Is there an obvious way to send "normal" vim commands to vim? e.g. ":buf <bufid>" Seb. |
|
From: Nageshwar <nag...@st...> - 2007-10-15 03:56:27
|
Hi Sebastian, > > Could't we embed the _same_ gvim using "--socketid" in the different > eclipse-editor-tabs all the time? Then when the eclipse tab is > changed, or a new editor is opened, we only create a new buffer in > vim, select that buffer and we are done. The user should not notice > what is going on behind the scenes (unless he did :buffers or > similar). When Embedding is unchecked, we could use tabs instead. > We followed the same idea for standalone vim instance. But I didn't check whether that is working or not. I don't think that the "embedding same window multiple times" will work. Each window contains only a single parent. As far as I know, the vim instance will appear in the latest eclipse editor. I searched the same on the net but couldn't find any relevant results. Anyway once please check it. Just enable the embed vim option and open files in standalone vim. > That would give a cleaner design (one editor class instead of three, > where two of them are two-liners), a cleaner userinterface (only one > vim-editor in the menu) and at last give a better performance (only > one gvim running) .. > If it doesn't work, we have to modify the protocol and add a new command to dynamically embed the window. But we can't do that since we are using netbeans protocol implementation on vim. > Getting technical: Is there an obvious way to send "normal" vim > commands to vim? e.g. ":buf <bufid>" > This command is there in the protocol. Command is "setDot". We used it when we get the focus on the eclipse editor tab. -- Best Regards, Nageshwar M. |
Thanks for helping keep SourceForge clean.
X