[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
- edit.m: use current working directory, remove HOME, Mike Miller, 2012/04/22
- Re: edit.m: use current working directory, remove HOME, Ben Abbott, 2012/04/24
- Re: edit.m: use current working directory, remove HOME, Mike Miller, 2012/04/24
- Re: edit.m: use current working directory, remove HOME, Mike Miller, 2012/04/27
- Re: edit.m: use current working directory, remove HOME, Ben Abbott, 2012/04/27
- Re: edit.m: use current working directory, remove HOME, Mike Miller, 2012/04/27