Re: edit.m and EDITOR

[Mike Miller]

On Tue, Apr 10, 2012 at 09:17:07PM -0400, John W. Eaton wrote:
> On 10-Apr-2012, Michael Goffioul wrote:
> 
> | On Tue, Apr 10, 2012 at 10:04 PM, Jordi Gutiérrez Hermoso
> | <address@hidden> wrote:
> | > 2012/4/10 Ben Abbott <address@hidden>:
> | >> On Apr 10, 2012, at 4:26 PM, Jordi Gutiérrez Hermoso wrote:
> | >
> | >>> The problem I'm trying to solve is that EDITOR and edit shouldn't be
> | >>> storing separate variables for the EDITOR command. How do you
> | >>> recommend to solve this instead?
> | >>
> | >>
> | >> I'd forgotten about this conflict.
> | >>
> | >> Should we be using preferences instead ?
> | >>
> | >> i.e. addpref, ispref, setpref, getpref, rmpref
> | >
> | > I don't see how those solve this problem... we already have a way to
> | > set the preference, the EDITOR function-variable does this. The
> | > problem is that I don't know how to fix the two copies of the EDITOR
> | > variable in EDITOR and edit.m without breaking part of edit.m's
> | > interface.
> | 
> | What about leaving FUNCTION.EDITOR empty and computing it dynamically
> | (as cstrcat(EDITOR, " %s")) when needed? If it's not empty, it means
> | it has been set through "edit('editor', ...)", and you use it instead
> | of the dynamic version. So the EDITOR variable will still continue to
> | be used, unless it has been overridden at the edit.m level. OTOH,
> | changing the editor through edit.m will not change the actual EDITOR
> | value.
> 
> Is there some reason not to have edit change the EDITOR value?  I'm
> not sure what would be more surprising
> 
>   * having "edit EDITOR vi" also set EDITOR to "vi"
> 
>   * having "edit get EDITOR" possibly return something different from
>     EDITOR
> 
> Should we deprecate the internal EDITOR variable?  We could initialize
> the editor used by edit and other functions that need an editor
> (edit_history, others?) to the value of EDITOR from the environment
> instead of from the internal EDITOR variable.

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 :)

-- 
mike