Re: [PATCH] DRY browser.c implementation for to_first_file

Benno Schulenberg <[email protected]> Wed, 23 Apr 2025 11:49:26 +0200

Newsgroups	gmane.editors.nano.devel
Message-ID	<[email protected]>

Op 22-04-2025 om 20:36 schreef Peter Michaux:
> The functions to_first_file and to_last_file appear to exist only for the 
> MWHEREISFILE menu. It seems a bit unexpected that these functions are in the 
> MWHEREISFILE menu as they are not text search related functions and they are 
> already in the MBROWSER menu

The ^W^Y and ^W^V keystrokes exist in the file browser for historical reasons.
So they will stay.

Sure, the corresponding functions can also be accessed with a single keystroke
(M-\ and M-/), but these are not visible in the help lines on a default terminal
-- they get shown only when the terminal is at least 120 columns wide.  So it is
mildly useful to show them in the Where-Is-File menu.

Furthermore, ^W^Y and ^W^V are available also in the main editor window (as
"blind" bindings), so for symmetry they should be available in the file browser
too.

> If the two functions are to be in both menus, then it seems like a DRY 
> implementation would be an improvement. A suggested patch is attached.

That does not improve anything.  The existing comments say why those functions
_must_ be there.  When adding M-\ and M-/ to the comments the necessity is lost.

> At a later date, the 
> browser code could be refactored without the static variables `filelist`, 
> `list_length`, etc at the top of the browser.c. Instead, a struct representing 
> the browser's current state could be passed between functions.]

What good would that do?  What is there against static variables?


Benno

OpenPGP_signature.asc (application/pgp-signature, 840 B)