Thread: [cream] Extra buffer created when file opened with cream --remote-send
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: Ben A. <BAr...@dy...> - 2007-08-21 12:05:22
|
Hi, I started debugging my Cream wrapper script over a year ago when I was first testing Vim 7.1. At that time, I ran into some problems which I posted about here, and got a bit of help, but never managed to finish fixing it. This week, I returned to the problem. I need to tell Cream to open a new file using --remote-send because otherwise if I specify a file to open on the command line, my open hook doesn't get executed. When the wrapper detects that Cream is not yet running, it produces this command: >ruby cream.rb test.rb START C:\Vim\vim71\gvim.exe --servername CREAM "+let $CREAM_FILE_OPEN=\"C:/test.rb\"" "<C-U>" The "<C-U>" prevents Vim from opening a file when it starts up. In cream-user.vim, I have a test for $CREAM_FILE_OPEN after all other settings are loaded. If it is set, the file is opened using Cream_file_open(). This works. When Cream is already running, the wrapper produces this command: >ruby cream.rb test.rb START C:\Vim\vim71\gvim.exe --servername CREAM --remote-send "<C-O>:call Cream_file_open(\"C:/test.rb\")<CR>" The wrapper is sending exactly the keystrokes I would type to open a file without using the menu. When I hand type in Cream the keystrokes specified as the argument to --remote-send, the file open works without creating an extra buffer. But when I send the keystrokes via --remote-send, an empty (Untitled) buffer is created in addition to a new buffer for the newly opened file. If I have tabbed documents turned off, I am positioned in the extra buffer, so I have to switch to the new file buffer before I can start editing. If I have tabbed documents turned on, the tab for the empty buffer is created between the previous tab and the new tab, and the focus is on the file I told cream to open, which is slightly less annoying, but still problematic. I can't begin to imagine what's going on here. Any hints for debugging? Thanks, Ben |
From: Steve H. <dig...@da...> - 2007-08-22 03:33:29
|
On Tue, 2007-08-21 at 09:05 -0300, Ben Armstrong wrote: > > I need to tell Cream to open a new file using --remote-send because > otherwise if I specify a file to open on the command line, my open > hook doesn't get executed. When the wrapper detects that Cream is > not yet running, it produces this command: > > >ruby cream.rb test.rb > > START C:\Vim\vim71\gvim.exe --servername CREAM "+let > $CREAM_FILE_OPEN=\"C:/test.rb\"" "<C-U>" > > The "<C-U>" prevents Vim from opening a file when it starts up. As opposed to turning off Preferences > Last File Restore? > In cream-user.vim, I have a test for $CREAM_FILE_OPEN after all > other settings are loaded. If it is set, the file is opened using > Cream_file_open(). This works. > > When Cream is already running, the wrapper produces this command: > > >ruby cream.rb test.rb > > START C:\Vim\vim71\gvim.exe --servername CREAM --remote-send > "<C-O>:call Cream_file_open(\"C:/test.rb\")<CR>" > > The wrapper is sending exactly the keystrokes I would type to open a > file without using the menu. When I hand type in Cream the > keystrokes specified as the argument to --remote-send, the file open > works without creating an extra buffer. But when I send the > keystrokes via --remote-send, an empty (Untitled) buffer is created > in addition to a new buffer for the newly opened file. I think this may be Vim working in the background. All sorts of unamed buffers are created in practice, Cream can usually delete them or avoid creating new ones via various autocmds. But when you pass an argument in from an outside application, Vim acts before Cream and we get a slightly dis-organized environment. Window > Tabs > Refresh Tabs should usually fix this. Also, see if you can verify if the actual buffer count/name is different or it is just the position within a buffer/window/tab: :buffers! > If I have tabbed documents turned off, I am positioned in the extra > buffer, so I have to switch to the new file buffer before I can > start editing. If I have tabbed documents turned on, the tab for the > empty buffer is created between the previous tab and the new tab, > and the focus is on the file I told cream to open, which is slightly > less annoying, but still problematic. I can't begin to imagine > what's going on here. Any hints for debugging? The code for all this is in cream-lib-win-tab-buf.vim, but you want to make sure you understand what is happening in cream-autocmd. When moving between tabs or windows, the logic is pretty simple, but when a buffer is created or deleted, Cream has to go through a lot of hoops to make sure everything has been managed. -- Steve Hall [ digitect dancingpaper com ] :: Cream... usability for Vim :: http://cream.sourceforge.net |
From: Ben A. <BAr...@dy...> - 2007-08-22 10:43:44
|
Steve Hall wrote: > As opposed to turning off Preferences > Last File Restore? > Hm. No, that's not what I meant. But I see now it's totally unnecessary. A prior version of the wrapper used --remote, and that required a filename. The <C-U> was necessary to escape out. Such hackery is no longer needed in my current version. > I think this may be Vim working in the background. All sorts of unamed > buffers are created in practice, Cream can usually delete them or > avoid creating new ones via various autocmds. But when you pass an > argument in from an outside application, Vim acts before Cream and we > get a slightly dis-organized environment. Window > Tabs > Refresh Tabs > should usually fix this. That does nothing in my case. > Also, see if you can verify if the actual > buffer count/name is different or it is just the position within a > buffer/window/tab: > > :buffers! > OK. It is definitely a different buffer. > The code for all this is in cream-lib-win-tab-buf.vim, but you want to > make sure you understand what is happening in cream-autocmd. When > moving between tabs or windows, the logic is pretty simple, but when a > buffer is created or deleted, Cream has to go through a lot of hoops > to make sure everything has been managed. > Thanks. I'll see if I can figure it out. Ben |
From: Ben A. <BAr...@dy...> - 2007-08-23 11:21:25
|
Ben Armstrong wrote: >> I think this may be Vim working in the background. All sorts of unamed >> buffers are created in practice, Cream can usually delete them or >> avoid creating new ones via various autocmds. But when you pass an >> argument in from an outside application, Vim acts before Cream and we >> get a slightly dis-organized environment. Window > Tabs > Refresh Tabs >> should usually fix this. >> > > That does nothing in my case. > In fact, this morning when I was trying to debug Peter's report to me that while he sees the first and second tabs, opening a third file does not create a third tab, but merely replaces the one on top, I tried "Refresh Tabs" after the third open to see what would happen. Lo and behold, two empty "Untitled" tabs appeared! So I guess these extra buffers are being created all the time. We just don't normally see them. You may recall that in our cream-user.vim we have an 'after open' hook set up to create a lockfile for selected files being edited. When I comment out in the hook the call to "Cream_touch()" so that the lockfile isn't created, both problems go away! So I need some ideas about how we can still create the lock file without causing these problems. Any clues? Ben |
From: Ben A. <BAr...@dy...> - 2007-08-23 11:52:42
|
Ben Armstrong wrote: > You may recall that in our cream-user.vim we have an 'after open' hook > set up to create a lockfile for selected files being edited. When I > comment out in the hook the call to "Cream_touch()" so that the lockfile > isn't created, both problems go away! So I need some ideas about how we > can still create the lock file without causing these problems. Any clues? > Here is a simple, reproducible test case that I believe doesn't require any of my hooks and that shows Cream_touch() is broken. 1. With an empty buffer, ^O:call Cream_touch("test.tmp"). Then "refresh tabs". No extra tabs appear. 2. Open a file. Do another ^O:call Cream_touch("test.tmp"). Then "refresh tabs". An extra "Untitled" tab appears. I tried just changing the bwipeout to a "call Cream_bwipeout()" in Cream_touch(), but that didn't help. I don't really know what I'm doing here. :) Ben |