Re: edit.m and EDITOR

[Michael Goffioul]

On Wed, Apr 11, 2012 at 2:19 PM, John W. Eaton <address@hidden> wrote:
> On 11-Apr-2012, Michael Goffioul wrote:
>
> | On Wed, Apr 11, 2012 at 1:31 PM, John W. Eaton <address@hidden> wrote:
> | > On 11-Apr-2012, Mike Miller wrote:
> | >
> | > | Maybe I'm way off here, but I'll throw in anyway.  I do see a difference
> | > | between EDITOR and edit's FUNCTION.EDITOR.  In the context of the edit
> | > | command, people seem to want to fork an editor in the background, edit
> | > | code while you still have access to the Octave shell.  Indeed, as I
> | > | recently learned, the default edit "mode" is now "async".
> | > |
> | > | For edit_history, the EDITOR is called synchronously a la Unix "fc".  It
> | > | must be that way for the results to be useful.  For me, that means I
> | > | want it to happen in the same terminal.
> | > |
> | > | Maybe these are still the same for most people, but for me:
> | > |
> | > |   octave:1> getenv("EDITOR"), EDITOR, edit get EDITOR
> | > |   ans = vim
> | > |   ans = vim
> | > |   ans = gvim %s
> | > |
> | > | If these do collapse to one setting, I'm sure I'll be ok :)
> | >
> | > OK, I didn't realize that the value of EDITOR in the edit function was
> | > not just the name of the editor program, but also could contain some
> | > format specification.  Ugh.  I don't see a good solution that won't
> | > break backward compatibility in some way.
> |
> | Well, remember that the initial confusion comes from the fact that the
> | edit.m help says it's using EDITOR by default. But that's not entirely
> | true, because of FUNCTION.EDITOR being persistent. So whenever edit.m
> | is loaded by octave (whatever the reason), FUNCTION.EDITOR is "fixed"
> | to "[EDITOR, ' %s']" and any later change of EDITOR variable is
> | ignored by edit.m.
> |
> | I suggested to solve that confusion by leaving FUNCTION.EDITOR empty
> | instead of initializing it to "[EDITOR, ' %s']". Then in the rest of
> | edit.m, if FUNCTION.EDITOR is not empty, use it, otherwise use
> | "[EDITOR, ' %s']". That way, EDITOR variable will always be honored by
> | edit.m, except if the editor has been explicitly overridden by calling
> | "edit('EDITOR', ...)".
>
> Although that still leaves some possibility for confusion (the editors
> used by edit and edit_history can be unexpectedly different, for
> example), it seems like the best solution to me.

I wouldn't say "unexpectedly". They would be different if you
explicitly asked so by calling "edit('EDITOR', ...)". AFAIK, edit.m
doesn't say that changing the editor in edit.m will change it in the
entire octave. If you want to change the default editor for
everything, then change EDITOR.

OTOH what I think is currently unexpected is that even if you change
EDITOR, edit.m and edit_history may end up using different editors,
depending on whether edit.m has been loaded by octave before changing
EDITOR variable.

Maybe it's also a matter of clarifying the help strings in edit.m and EDITOR.

Michael.