Re: edit.m and EDITOR

[John W. Eaton]

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.

jwe