Cream (for Vim)

On Fri, 2006-04-28 at 13:09 -0300, BG - Ben Armstrong wrote:
>
> This is a strange problem that probably only affects me, but it's a
> really annoying one that is made worse by the fact that I'm beta
> testing vim 7 + cream 0.36.
>
> When I start Cream, passing it a command to execute via --remote
> "+commandname", if there are errors in the cream initialization
> (which there are currently in the experimental version: the
> Cream_tabpages_init error) they are output to the messages window
> followed by a prompt to "Press ENTER or type command to continue".
> Unfortunately, cream hasn't finished its initialization yet at this
> point, keyboard focus is not on the messages window, and there is no
> way to make keyboard focus go to the messages window, so I can't
> press ENTER to unblock the initialization.  At this point I have to
> kill Cream and start all over again.

It's odd that you can't focus the command line, not even Ctrl+C
terminates the broken error?

> Thus, my way of starting cream from the commandline, passing it the
> initial file to open & still have the Cream-specific open hooks
> applied fails:
>
> cream --remote "+call Cream_file_open(\"file.txt\")" "<C-U>"

Nice hack!

> My only workaround is to start Cream without any arguments, press
> ENTER to the messages dialog, and *then* invoke Open the klunky
> old-fashioned way, via the menu.
>
> Any idea how we could fix this?

The bug fix in the previous list mail should at least avoid the error.

> By the way, I went looking in sf.net's CVS for the latest goodies
> upcoming in beta2.  Nothing there.  Is it broken these days?  There
> are no changes in CVS newer than 7 weeks ago!  I'd love to have the
> fix to Cream_tabpages_init, as that would make this problem go away
> for the time being.

SF's CVS has been broken for months to anonymous users. Here's a
snapshot of the current code for both Windows and GNU/Linux:

  http://cream.sf.net/cream-0.36beta2-2006-04-28.tar.gz



-- 
Steve Hall  [ digitect mindspring com ]
:: Cream... something good to put in your Vim!
::   http://cream.sourceforge.net

On Fri, 2006-04-28 at 20:32 -0400, Steve Hall wrote:
> It's odd that you can't focus the command line, not even Ctrl+C
> terminates the broken error?

That's right.  I just get a white X cursor but can't even Ctrl+C.

> The bug fix in the previous list mail should at least avoid the error.

Thanks.  I'll give that a whirl.

> SF's CVS has been broken for months to anonymous users. Here's a
> snapshot of the current code for both Windows and GNU/Linux:
> 
>   http://cream.sf.net/cream-0.36beta2-2006-04-28.tar.gz

Grr.  Well, thanks for the snapshot.

I'm "synrg" on sf.net if I'm worthy to be added to the project. :)

Ben

On Mon, 2006-05-01 at 11:10 -0300, BG - Ben Armstrong wrote:
> > The bug fix in the previous list mail should at least avoid the error.
> 
> Thanks.  I'll give that a whirl.

Well.  Here I am, one "whirl" later ...

The error doesn't happen anymore with the beta2-2006-04-29 snapshot, but
now my file doesn't open at all and the only clue that anything went
wrong is "E749: empty buffer" in messages.

Ben

On Mon, 2006-05-01 at 11:26 -0300, BG - Ben Armstrong wrote:
>
> Well.  Here I am, one "whirl" later ...
>
> The error doesn't happen anymore with the beta2-2006-04-29 snapshot,
> but now my file doesn't open at all and the only clue that anything
> went wrong is "E749: empty buffer" in messages.

How about this:

  cream --remote-send "<C-o>:call Cream_file_open(\"/path/file\")<CR>"

I think this syntax is a little smoother, although the file must exist
to work. So, if we change the second test in Cream_file_open() to:

    if filereadable(myfile) == 0
        let n = confirm(
            \ "File \"" . myfile . "\"\n" .
            \ "does not exist, create it?\n" .
            \ "\n", "&Ok\n&Cancel", 1, "Info")
        if n != 1
            return
        endif
    endif

the user can confirm to create it (or see the bad filename).

What do you do if you're trying to open multiple files? It might be
good for somebody to modify the cream shell script to pass multiple
arguments this way, although it might be a little complicated parsing
wildcards and passing in each name.


-- 
Steve Hall  [ digitect mindspring com ]

On Mon, 2006-05-01 at 20:11 -0400, Steve Hall wrote:
> On Mon, 2006-05-01 at 11:26 -0300, BG - Ben Armstrong wrote:
> >
> > Well.  Here I am, one "whirl" later ...
> >
> > The error doesn't happen anymore with the beta2-2006-04-29 snapshot,
> > but now my file doesn't open at all and the only clue that anything
> > went wrong is "E749: empty buffer" in messages.
> 
> How about this:
> 
>   cream --remote-send "<C-o>:call Cream_file_open(\"/path/file\")<CR>"

Tried it.  Didn't work for me.  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.  By specifying --remote-silent, I suppress the warning
when the server doesn't exist yet.  I cannot use --remote-send because
it will make no attempt to create the server if it doesn't yet exist:

E247: no registered server named "GVIM": Send failed.

> I think this syntax is a little smoother, although the file must exist
> to work. So, if we change the second test in Cream_file_open() to:
> 
>     if filereadable(myfile) == 0
>         let n = confirm(
>             \ "File \"" . myfile . "\"\n" .
>             \ "does not exist, create it?\n" .
>             \ "\n", "&Ok\n&Cancel", 1, "Info")
>         if n != 1
>             return
>         endif
>     endif

Good idea.  But this doesn't quite work.  I get:

Warning!

File is not writable (read-only, permissions, etc.). Open anyway?

I think you now need to move the writable check into the "else" of the
readable check, since if the file isn't readable and we don't create it,
there is no file to edit, and if we do create it, then surely it is
writable (or else the touch would have failed).  At least, that's what
works for me.

> What do you do if you're trying to open multiple files? It might be
> good for somebody to modify the cream shell script to pass multiple
> arguments this way, although it might be a little complicated parsing
> wildcards and passing in each name.

At present I'm not concerned about the multiple file open case, although
I agree some people might want this.

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)

Ben

On Tue, 2006-05-02 at 08:34 -0300, BG - Ben Armstrong wrote:
> On Mon, 2006-05-01 at 20:11 -0400, Steve Hall wrote:
> > I think this syntax is a little smoother, although the file must exist
> > to work. So, if we change the second test in Cream_file_open() to:
> > 
> >     if filereadable(myfile) == 0
> >         let n = confirm(
> >             \ "File \"" . myfile . "\"\n" .
> >             \ "does not exist, create it?\n" .
> >             \ "\n", "&Ok\n&Cancel", 1, "Info")
> >         if n != 1
> >             return
> >         endif
> >     endif

Speaking of creating new files, Cream's "New" like many other editors
only creates a new buffer & does not associate a filename.  The file
doesn't come into existence until the first save.  However, when saving
a file, the open hook isn't called, so our "interlock" file
(basename.jou) isn't created, and the other checks that would have
otherwise failed a "bad" open are defeated.

So it seems we need a save hook, one which is run immediately prior to
the save to check the "sanity" of the file save request and fail it if
need be (e.g. in case the user asks to overwrite a production file that,
while writable by the user, should never be directly overwritten from
the editor).

We've lived without this so far, so it's not a high priority to fix.  We
all just know not to do things that would damage the integrity of our
production files.  However, as the number of users here grows, I can see
this becoming an issue of more urgency: the first time a user forgets
and a valuable file is lost, requiring a restore from backup, I imagine
we'll want to revisit it.

Ben

On Tue, 2006-05-02 at 08:34 -0300, BG - Ben Armstrong wrote:
> On Mon, 2006-05-01 at 20:11 -0400, Steve Hall wrote:
> >
> > How about this:
> >
> >   cream --remote-send "<C-o>:call
> >     Cream_file_open(\"/path/file\")<CR>"
>
> Tried it. Didn't work for me. 

Even when you had a GVIM server running? What was the error? Is this
from bash or something else?

> 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?

> By specifying --remote-silent, I suppress the warning when the
> server doesn't exist yet.

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 cannot use --remote-send because it will make no attempt to create
> the server if it doesn't yet exist:
>
> E247: no registered server named "GVIM": Send failed.

Right, I forgot. It's too late for me, dunno how to solve this.

> > I think this syntax is a little smoother, although the file must
> > exist to work. So, if we change the second test in
> > Cream_file_open() to:
> >
> >     if filereadable(myfile) == 0
> >         let n = confirm(
> >             \ "File \"" . myfile . "\"\n" .
> >             \ "does not exist, create it?\n" .
> >             \ "\n", "&Ok\n&Cancel", 1, "Info")
> >         if n != 1
> >             return
> >         endif
> >     endif
>
> Good idea.  But this doesn't quite work.  I get:
>
> Warning!
>
> File is not writable (read-only, permissions, etc.). Open anyway?
>
> I think you now need to move the writable check into the "else" of
> the readable check, since if the file isn't readable and we don't
> create it, there is no file to edit, and if we do create it, then
> surely it is writable (or else the touch would have failed). At
> least, that's what works for me.

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?

> > What do you do if you're trying to open multiple files? It might
> > be good for somebody to modify the cream shell script to pass
> > multiple arguments this way, although it might be a little
> > complicated parsing wildcards and passing in each name.
>
> At present I'm not concerned about the multiple file open case,
> although I agree some people might want this.
>
> 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.


-- 
Steve Hall  [ digitect mindspring com ]
:: Cream... something good to put in your Vim!
::   http://cream.sourceforge.net

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

On Wed, 2006-05-03 at 08:20 -0300, BG - Ben Armstrong wrote:

> 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.

This is unspeakably horrible:

cream --remote-silent "+call Cream_close()|call
Cream_file_open(\"/path/file\")<CR>" "~/.cream_nofile"

This temporarily creates a buffer for ~/.cream_nofile (using Vim's open,
not Cream's) and then Cream promptly closes it, opening the file we
really want instead.

It seems the new vim uses inputsave() before opening (using "drop") the
filename(s) passed to --remote.  Thus, no matter what I do to try to
hack around that filename, Vim always restores the input afterwards,
defeating my attempts to do without an input file.

I'm quite discouraged.

Ben

On Wed, 2006-05-03 at 10:08 -0300, BG - Ben Armstrong wrote:
> It seems the new vim uses inputsave() before opening (using "drop")
> the filename(s) passed to --remote.  Thus, no matter what I do to try
> to hack around that filename, Vim always restores the input
> afterwards, defeating my attempts to do without an input file.
> 
> I'm quite discouraged.

I have given up on trying to make this work with the vim server.

This seems to work (currently in cream-user.conf ... don't know where it
belongs):

if $CREAM_FILE_OPEN != ""
   autocmd VimEnter * call Cream_file_open($CREAM_FILE_OPEN)
endif

and then:

CREAM_FILE_OPEN="/path/file" cream

Is there any flaw in this approach?

Ben

On Wed, 2006-05-03 at 08:20 -0300, BG - Ben Armstrong wrote:
> On Tue, 2006-05-02 at 23:40 -0400, Steve Hall wrote:
> >
> > 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.

Ah, I just understood what you meant, the two tests must be one:

    endif
    if filewritable(myfile) == 0

to

    elseif filewritable(myfile) == 0

> And if we later create the file, how could it be read-only
> immediately after creating it? So this check becomes superfluous
> anyway.

In your case, but there is the possibility that the file exists, is
readable, but is read-only.

> > > 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.

Just wait until you also have to deal with tabs in that mix. :) 

It is conceivable that Cream could handle a few special arguments for
situations like these. But it would depend on a thorough review of the
autocommands, right now they are firing off all over the place and I'm
now completely at their mercy.


-- 
Steve Hall  [ digitect mindspring com ]
:: Cream... something good to put in your Vim!
::   http://cream.sourceforge.net

On Wed, 2006-05-03 at 11:27 -0300, BG - Ben Armstrong wrote:
> On Wed, 2006-05-03 at 10:08 -0300, BG - Ben Armstrong wrote:
> >
> > It seems the new vim uses inputsave() before opening (using
> > "drop") the filename(s) passed to --remote. Thus, no matter what I
> > do to try to hack around that filename, Vim always restores the
> > input afterwards, defeating my attempts to do without an input
> > file.
> >
> > I'm quite discouraged.

:help starting is quite large isn't it? But check this out:

  There can be no option arguments after the "--" argument.

I think this explains why you're loosing everything following the
--remote {arg} command, Vim is interpreting them all as filenames.

> I have given up on trying to make this work with the vim server.
>
> This seems to work (currently in cream-user.conf ... don't know
> where it belongs):
>
> if $CREAM_FILE_OPEN != ""
>    autocmd VimEnter * call Cream_file_open($CREAM_FILE_OPEN)
> endif
>
> and then:
>
>   CREAM_FILE_OPEN="/path/file" cream
>
> Is there any flaw in this approach?

No, this is effective. Change the test to

  if exists("$CREAM_FILE_OPEN")

though, to avoid error with an uninitialized global.

I also think of cream-conf as a better place for initializations since
it is sourced first (cream-user is last), this would ensure the other
Cream autocommands see and consider your open file.


-- 
Steve Hall  [ digitect mindspring com ]
:: Cream... something good to put in your Vim!
::   http://cream.sourceforge.net