[Top][All Lists]

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

Re: [Nano-devel] [PATCH] enable searching (^W) in a help text (^G)

From: Benno Schulenberg
Subject: Re: [Nano-devel] [PATCH] enable searching (^W) in a help text (^G)
Date: Thu, 24 Nov 2016 19:55:31 +0100

On Thu, Nov 24, 2016, at 17:49, Rishabh Dave wrote:
> On Mon, Nov 21, 2016 at 9:57 PM, Benno Schulenberg
> <address@hidden> wrote:
> > Those two functions are nearly identical.  If you make sure
> > that title == NULL when not in MHELP, you could have done
> > without the first function by making a tiny tweak to the
> > second.
> Didn't get you... Are you talking about the following change in the
> total_refresh()?
> titlebar(currmenu == MFINDINHELP ? title : NULL);

Why so difficult?  Just write:


> I previously avoided it as it makes a variable global

Code duplication is worse.

> and the update/s in topwin is visible (you could see title in
> topwin change in quick successions).

And your method avoids this?  If yes, then walk me through it:
where and when does it get written, and where and when rewritten?

> Is having top 2 help functions, one for each with and without
> multibuffer disabled, is bad option?

Ehhh...  You want to have a searchable help when multibuffer is
available, and have the old non-searchable help when it's not?
Out of the question.  When we make searchable help, it will be
always searchable, or entirely unavailable.

> > Basing off your previous patch, you needed to change just
> > five lines to achieve text rewrapping upon a window resize.
> > See attached patch.
> Oh...  It is much better this way.

But it's not good enough yet: the explanations of the shortcuts
don't get wrapped to the width of the window.

> By the way, what is the effect is achieved by this change?

Ehm...  When referring to something, put your text /after/ it,
so that it is somewhat obvious what "this" refers to.

> -       if (has_valid_path(realname)) {
> +       if (currmenu != MHELP && has_valid_path(realname)) {
> Is it only an optimization -- avoiding considerations of locking
> for help text? I couldn't figure.

Well, /try/ it: revert that change and see what happens when
you look at a help text and resize the window:
"File /tmp/nano.X4ca9F is being edited...; continue?".
That is not good.  So we need to avoid locking for the temporary
help files.  Also, locking for those files should not be needed:
they should be unique, and other users can't open them.


-- - Same, same, but different...

reply via email to

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