On Tue, 2006-05-02 at 23:40 -0400, Steve Hall wrote:
Didn't try it with a GVIM server running because, as I said, I need to use the self-starting --remote (or --remote-silent) so once I realized --remote-send was the wrong command, I pursued it no further.
Even when you had a GVIM server running? What was the error? Is this
from bash or something else?
My trailing <C-u> was in place of the filename that I was supopsed to pass to vim. It used to clear the command to load the file. But this apparently broke in vim7. Anyway, I checked the vim man page and found that you can specify "-" to load a file from stdin, which is what I though I needed ...
> The actual command that works for me
> now is:
> cream --remote-silent "+call Cream_file_open(\"/path/file\")" -
> By specifying "-", I no longer need the <C-U> hack, which apparently
> broke in vim7.
Is this trying to dump stdin via Ex mode? My <C-o> and <CR> assume a
call from insert mode, what did your trailing <C-u> do?
Uh-oh. OK, I see now the "-" which I hadn't noticed before. So this clearly doesn't work. I'll have to play with it some more to come up with a correct workaround, as mine only seems to work by accident.
I get a buffer named "-" and a buffer named "file\")"! Can't seem to
figure out a way around, I wonder if this is a shell limitation?
I am running a ruby wrapper that does a system() command to start cream.
It doesn't exist at that point. *Prompting* to create isn't the same as creating. So if we go on to see if the file is not read-only, then of course the check will fail. That's why it must be moved into the else, as I said.
Actually, the writable check is a different block just below the code
above, it didn't change. There are three in file_open():
1. Verify not directory
2. Verify exists, prompt to create if not (above)
3. Verify not read-only
You're now seeing the third, not sure why unless it is already opened
by another server?
And if we later create the file, how could it be read-only immediately after creating it? So this check becomes superfluous anyway.
Never mind about it for now. :) The wrapper is probably the way to do it:
> Before solving the multiple file open in a general way, I'm more
> concerned about allowing these scenarios:
> 1. open a single file read-only
> 2. pass two files to be diffed, opening both read-only
> 3. pass two files to be diffed, opening the first read-only (the
> original) and the second read-write (the working copy)
Arguments and wrappers and global variables, oh my! With too little
sleep, I can't even get my head around this to imagine.
cream.rb -r file
creamdiff.rb -r file1 -r file2
creamdiff.rb -r file1 file2
Each of these would call the appropriate combination of Cream_file_open_readonly and Cream_file_open, split windows & activate diff mode in each. But meanwhile, I'll be content with just having users do all of this the long way, through the GUI.