>> Personally, I am a little surprised that centi-second differences in
>> startup time are of concern to users for that change,
>I'm not looking at the absolute numbers, I only look at percentages.
>If startup time can be reduced by thirty or forty percent, then that is
>worth it, depending on the amount of code it takes. Nano is dead-slow
>compared to things like 'ne' and 'le' -- their snappiness is enviable.
Well I believe that is mostly because of how they handle files.
IIRC, ne, le, vim, and perhaps Emacs don't load the entire file.
The bottlenecks in Nano I presume would be
1. Reading large files, as nano's current structure requires reading the entire file.
2. Linked lists: Jumping around memory like that is terrible in a cache based world. Vectors, or at least hybrid lists, are usually better.
3. Rendering. I don't think that nano's coloring rules are very efficient; ideally we would use ncurses's extended chars and use its native scrolling feature. Old curses and slang can f*** themselves.
4. Regex: not a big fan of gnulib's regex parser, it is not very fast. Ideally we should use pcre-jit or rure. Additionally, **every syntax definition** requires regex. Even keywords.
An ideal restructure of nano would try to use memory mapping if possible with a malloc+fread fallback.
Send Nano-devel mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/nano-devel
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Nano-devel digest..."
Today's Topics:
1. Re: [PATCH] bindings: at a Yes-No prompt, accept also ^N and
^Q for "No" (Benno Schulenberg)
2. Re: [PATCH 1/2] new thing: a tools menu that groups together
some larger functions (Benno Schulenberg)
3. Re: [PATCH 3/3] files: check for an empty FIFO before
blocking on it (Benno Schulenberg)
4. Re: [PATCH 3/3] files: check for an empty FIFO before
blocking on it (Brand Huntsman)
5. Re: patch #9772: Add color name definition to the nanorc
configuration (color schemes) (Benno Schulenberg)
---------- Forwarded message ----------
From: Benno Schulenberg <address@hidden>
To: address@hidden
Cc:
Bcc:
Date: Wed, 15 May 2019 19:55:05 +0200
Subject: Re: [Nano-devel] [PATCH] bindings: at a Yes-No prompt, accept also ^N and ^Q for "No"
Op 14-05-19 om 03:11 schreef Brand Huntsman:
> On Mon, 13 May 2019 19:48:36 +0200 Benno Schulenberg <address@hidden>
> wrote:
>> When wanting to exit after having modified a buffer by mistake, I don't want
>> to politely answer a question by typing precisely an unmodified N, I want to
>> give a command: ^N, meaning *No!*. Or seen another way: I don't want to be
>> obliged to let go of the Ctrl key before typing N.
>
> What about those who don't want to let go of Ctrl to type an unmodified Y? It
> doesn't make sense to support one but not the other.
Yeah, could do that. Didn't think of it, because my way of exiting nano is
either ^S ^X (previously ^O ^M ^X), or ^X N, so the only time I type something
after a ^X is when it is "No". But indeed, maybe there are people who were
and still are in the habit of typing ^X Y <Enter> to save the buffer and exit.
I will add the ^Y in a separate commit.
Benno
---------- Forwarded message ----------
From: Benno Schulenberg <address@hidden>
To: address@hidden
Cc:
Bcc:
Date: Wed, 15 May 2019 20:15:00 +0200
Subject: Re: [Nano-devel] [PATCH 1/2] new thing: a tools menu that groups together some larger functions
Op 14-05-19 om 04:14 schreef Brand Huntsman:
> The ^T bind is not available without ENABLE_SPELLER.
>
> #ifdef ENABLE_SPELLER - add_to_sclist(MMAIN, "^T", 0, do_spell, 0); +
> add_to_sclist(MMAIN, "^T", 0, offer_tools, 0); #endif
Thanks. Didn't notice that.
> There is no function name to rebind the tools menu in nanorc.
I didn't think that far ahead. Will add it in a separate commit.
> The "Choose a tool" should probably be left aligned. Your eye is drawn to the
> left side for other menus and this one has nothing there.
This is actually on purpose. I had it left aligned at first with trailing dots,
but didn't like it: it still looked too much like a prompt. Now it looks like
a header, a title, which means that the real stuff will be underneath it. But
indeed, when the help lines are hidden...
> Maybe the nohelp M-X toggle could be bound by default in the tools menu (and
> maybe other prompts so you don't have close prompt, enable help and re-open
> prompt).
That is good idea. But it will have to be a "blind" binding: I don't want
to show M-X in every menu and every help text.
> And "Choose a tool... press M-X for list" could be used if help bar is
> hidden.
Don't like that much. People shouldn't switch off the help lines when
they don't know nano fully yet, and for those that do know, the "press
something for list" is superfluous. But true, this is something new,
and the experienced users will not switch the help lines just because
they upgraded to a newer nano.
Benno
---------- Forwarded message ----------
From: Benno Schulenberg <address@hidden>
To: address@hidden
Cc:
Bcc:
Date: Wed, 15 May 2019 20:45:49 +0200
Subject: Re: [Nano-devel] [PATCH 3/3] files: check for an empty FIFO before blocking on it
Op 14-05-19 om 07:59 schreef Brand Huntsman:
> The open() in open_file() blocks if an empty FIFO is opened, causing nano to
> hang.
Strange... I remember seeing a "Reading File" message while it was waiting
for data to appear. But obviously I must be misremembering that.
> This patch opens the FIFO in non-blocking mode, polls it for data and
> re-opens it in blocking mode if data found. Just start the writing process
> first, and then open nano.
I want it to be possible to open nano before the writing process has started.
When a FIFO is used, the result shouldn't depend on the particular order of
starting things.
> It would also be nice if a "Writing to FIFO..." message was displayed before
> writing to one.
Yes, that is a good idea. And "Reading from FIFO..." could be shown before
the open() is called.
> It would provide a little feedback as to why nano hangs if the FIFO is no
> longer listening.
Or not yet listening.
Benno
---------- Forwarded message ----------
From: Brand Huntsman <address@hidden>
To: address@hidden
Cc:
Bcc:
Date: Wed, 15 May 2019 19:36:53 -0600
Subject: Re: [Nano-devel] [PATCH 3/3] files: check for an empty FIFO before blocking on it
On Wed, 15 May 2019 20:45:49 +0200
Benno Schulenberg <address@hidden> wrote:
> > This patch opens the FIFO in non-blocking mode, polls it for data
> > and re-opens it in blocking mode if data found. Just start the
> > writing process first, and then open nano.
>
> I want it to be possible to open nano before the writing process has
> started. When a FIFO is used, the result shouldn't depend on the
> particular order of starting things.
What about this new patch? It allows nano to be started before the FIFO has data without hanging nano when someone accidentally opens a FIFO. The filename should probably be displayed in the prompt, but I'm out of time today. I originally set the filename early so it would appear in the titlebar, but that can't be done when inserting into an existing buffer.
Also, after reading a FIFO into a new buffer, the cursor remains at top of buffer. But the cursor moves to bottom of data when inserting a FIFO into an existing buffer. I assume it treats the FIFO as a file and opening normal files set cursor to top. Normal files save the cursor position when closing, but FIFOs don't. A FIFO could be used to open an encrypted file, and position history would be nice for that. Should FIFOs support position history or should they move cursor to bottom like reading from stdin does?
terminal 1: mkfifo fifo ; nano fifo
terminal 2: echo 1 >> fifo
terminal 1: ^R to insert fifo into buffer
terminal 2: echo 2 >> fifo
---------- Forwarded message ----------
From: Benno Schulenberg <address@hidden>
To: address@hidden
Cc:
Bcc:
Date: Thu, 16 May 2019 15:22:55 +0200
Subject: Re: [Nano-devel] patch #9772: Add color name definition to the nanorc configuration (color schemes)
Op 14-05-19 om 12:48 schreef Justin F:
> This is a better solution (to my mind) than the current situation where,
> if you don't like the colour scheme forced on you by the supplied
> syntaxes, you have to copy those syntaxes. Yes, it's a bit of a faff to
> write out these rules, but it's better than to have your syntax
> definitions drift from those used by the ones supplied by Nano.
The syntaxes supplied by nano were originally just meant as examples,
for the user to modify and extend to their taste, as you can still see
from the comment in several of those files. But some distros started
to install and enable those syntaxes by default, and thus they have
become the de facto standard, I guess.
> I certainly know that my own definitions are significantly different from
> those supplied with Nano either to fix deficiencies,
If you have improvements to nano's syntaxes that might be useful to
others too, please post patches.
> All feature change makes things slower, but I wouldn't consider this to be
> too relevant to the editor itself.
True, the impact is not large. But it is also the indirection that
puts me off. Something like 'color green "someregex"' is direct and
simple. But 'color comment "someregex"' requires straining on my part
to keep realizing that 'comment' here is the indirect name of a color.
I don't like it.
> Personally, I am a little surprised that centi-second differences in
> startup time are of concern to users for that change,
I'm not looking at the absolute numbers, I only look at percentages.
If startup time can be reduced by thirty or forty percent, then that is
worth it, depending on the amount of code it takes. Nano is dead-slow
compared to things like 'ne' and 'le' -- their snappiness is enviable.
Benno
_______________________________________________
Nano-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/nano-devel