nano-devel
[Top][All Lists]
Advanced

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

Re: Possible new feature: use 'openfile' to open new buffer


From: Benno Schulenberg
Subject: Re: Possible new feature: use 'openfile' to open new buffer
Date: Thu, 21 May 2020 11:57:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

Op 19-05-2020 om 20:40 schreef Marco Diego Aurélio Mesquita:
> On 5/19/20, Benno Schulenberg <address@hidden> wrote:
>> No, what I meant is: when --multibuffer and 'set multibuffer' are not
>> used, then every invocation of ^R ('insert') will insert the read file
>> into the current buffer, *even* when on the previous invocation M-F was
>> toggled on.  And inversely, when --multibuffer or 'set multibuffer' ARE
>> used, then every invocation of ^R will read a file into a new buffer,
>> even when on the previous invocation M-F was toggled OFF.
>
> Sounds like a much simpler approach. Indeed, this would achieve what I
> need without a new bindable function.

But it would be a change in behavior.  We've done that before with
^W, and had one complaint from someone who used different versions
of nano and found it annoying that the Backward flag was persistent
in some versions and volatile in others.  Probably ^R is used less
often than ^W (I hardly ever use ^R, neither to insert nor to open),
but the effect of the flag is quite large.  So... I'm hesitant.
But for you, as a frequent user of ^R, this change would be fine?

> By not having persistence on the MULTIBUFFER flag,

Not "flag" but "toggle".  The flag and option (--multibuffer and
'set multibuffer') DO become persistent.

> +     bool was_multibuffer = ISSET(MULTIBUFFER);

Should be wrapped in #ifdef ENABLE_MULTIBUFFER.
Same for the later fragment.

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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