octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: edit.m: use current working directory, remove HOME


From: Ben Abbott
Subject: Re: edit.m: use current working directory, remove HOME
Date: Tue, 24 Apr 2012 11:42:16 -0400

On Apr 24, 2012, at 11:33 AM, Mike Miller wrote:

> On Tue, Apr 24, 2012 at 10:32 AM, Ben Abbott <address@hidden> wrote:
>> 
>> On Apr 24, 2012, at 9:47 AM, Mike Miller wrote:
>> 
>>> On Tue, Apr 24, 2012 at 8:58 AM, Ben Abbott <address@hidden> wrote:
>>>> On Apr 22, 2012, at 5:49 PM, Mike Miller wrote:
>>>> 
>>>>> I have prepared a new patch to make the edit command consistent wrt
>>>>> where files are edited, please take a look at the attached and tell me
>>>>> what you think.  The HOME variable is now no longer needed, a warning is
>>>>> issued if the user tries to get or set HOME.  The current directory is
>>>>> now used wherever HOME was used before, primarily when editing a system
>>>>> m-file with no write privileges.
>>>>> 
>>>>> --
>>>>> mike
>>>>> <edit-home.patch>
>>>> 
>>>> I had a thought. Would it be preferred to allow the HOME variable in 
>>>> edit.m to be set to a function handle, or a string. That would accommodate 
>>>> both those who prefer
>>>> 
>>>>        address@hidden
>>>> 
>>>> ... or ...
>>>> 
>>>>        HOME="~/octave";
>>> 
>>> Sure, I don't have a problem with supporting function handles in
>>> principle, but isn't address@hidden effectively overkill for HOME="."?
>> 
>> Ok.
>> 
>>>> Might the same be done for EDITOR ?
>>>> 
>>>>        address@hidden;
>>>> 
>>>> ... or ...
>>>> 
>>>>        EDITOR="gvim";
>>> 
>>> If EDITOR could be a function handle, it should probably take the name
>>> of the file to edit as its argument, right?  That would be analogous
>>> to the "%s" placeholder that the EDITOR setting currently requires.
>>> In that case the the EDITOR() function wouldn't work, but a new
>>> function could be made to be the default using @EDITOR.
>> 
>> I'm not sure I'm following.
>> 
>> Are you proposing a rewrite of the EDITOR function ?
>> 
>> How would it interact with edit.m and the built-in edit_history() ?
> 
> No, not at all, just pointing out the difference between
> 
>    $ env EDITOR=  octave -qf
>    octave:1> EDITOR
>    ans = emacs
>    octave:2> edit get EDITOR
>    ans = emacs %s
> 
> as in one of the prior edit vs. EDITOR threads.  In edit.m, the EDITOR
> setting has a required argument, currently in the form of a sprintf
> replacement.  I interpreted your suggestion into something like:
> 
>    if (is_function_handle (FUNCTION.EDITOR))
>        cmd = FUNCTION.EDITOR (filename);
>    else
>        cmd = sprintf (FUNCTION.EDITOR, filename);
>    endif
> 
> -- 
> mike

Ok. I was thinking the format specifier should be removed from the EDITOR 
string (I think one of your changesets does that, correct ?), and @EDITOR would 
work as it does now (i.e. a function that returns a string).

        cmd = sprintf ("%s %s", FUNCTION.EDITOR, filename)

This would work for either 

       FUNCTION.EDITOR address@hidden;

... or ...

       FUNCTION.EDITOR ="gvim";

Ben



reply via email to

[Prev in Thread] Current Thread [Next in Thread]