On Tue, 2006-05-02 at 23:40 -0400, Steve Hall wrote:
Even when you had a GVIM server running? What was the error? Is this
from bash or something else?
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.
> 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?
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 ...

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?
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 am running a ruby wrapper that does a system() command to start cream.
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?
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.

And if we later create the file, how could it be read-only immediately after creating it?  So this check becomes superfluous anyway.
> 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.
Never mind about it for now. :)  The wrapper is probably the way to do it:

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.

Ben