Re: [RFC] improve nano's interface toward external tools

[Saagar Jha]

Saagar Jha

> On Jan 4, 2021, at 05:06, Benno Schulenberg <bensberg@telfort.nl> wrote:

> Nano never looked at other editors.  For the longest of times nano's only
> goal was to be a copy of Pico -- with a few improvements here and there.
> This has changed only since version 4.0, two years ago.

I noticed, hence why this is why the first time I’m bringing this up :) Nano 
doesn’t have to look *like* other editors, but I see no harm in it looking *at* 
other editors. There’s no shame in stealing or adapting good features from 
other editors that would fit well in nano.

> The linter required a horrible amount of code.  I wish Chris had never
> added it.  But I didn't have the heart to kill it.

Well, I for one am glad it’s stuck around. Plus, if we consider the “factor it 
out into an extension” if we added an extension point for running a command on 
the buffer and displaying a message in the status bar from the output of that 
script we could rip out some of the error parsing (“just make your script 
follow what we want!”). And this might answer the questions you asked Marco, 
because it’d let people do things like what the current status of the git 
repository is, or how many words are in the current file, or the output of a 
build command (as I have currently been using it). I feel like we’ve gotten a 
couple of requests already of some sort of customizable status bar, and I think 
this would solve a lot of that too because it lets you put controllable text 
there.

> "One" maybe, but I certainly can't imagine that: for every keystroke run
> code to try and find the things that could complete the current fragment
> and present them onscreen...  What a horrible waste of CPU cycles!  For me
> the attraction of nano is not just its small binary size but also that it
> uses the CPU sparingly.

Believe me, I value these things too, otherwise I’d be using an IDE or Visual 
Studio Code and not nano ;) There are some machines I use nano on that hardly 
have a megabyte of space and where NANO_TINY is enabled–no need for 
autocomplete there. But when I’m on a machine that is already spending millions 
of cycles a second to take the output of nano and send it through a terminal to 
render on the screen, I feel like I can be just a little bit more generous for 
quality-of-life features.

> Sure, sounds good.  If you have a specific idea for an extension point
> and can give two different examples of how this point could be used by
> an external script, then let's hear it.

Well, one is where you can write scripts whose output shows up in the status 
bar as I described, with the various usecases I described. Revisiting the 
“scripts can set preferences” example, we had the one about detecting 
indentation width, but another one could be a script that looks for a local 
“.nanorc” file in the repository I am currently working in and changing nano’s 
settings to match that (as you may have already seen many projects with 
“.editorconfig” files already–whereas this feature is usually built into other 
editors, this can be completely pulled out into a third-party plugin here).

> Benno
>