Re: [RFC] Improve external tools

[Saagar Jha]

Personally, I value nano very much for its lightweight simplicity. The fact 
that its code fits into less than two dozen files, that the binary is less than 
500 KB in size, that is basically the most ubiquitous editor not specified on 
POSIX are massive positives in my book. That being said, the editor landscape 
is changing and I feel that nano should take this into account as it continues 
to gain features. In the hands of a capable user nano is probably much more 
powerful than the average person might give it credit for–with linters and 
formatters and buffers it is actually pretty decent to work in for moderately 
complex projects–but there are still places where it seems like it is missing 
some things that other editors have had for quite a long time. To be clear, if 
nano ever became Visual Studio Code I would probably drop it immediately, but I 
don’t think that means we can’t look at what other editors are doing and think 
of ways of getting some of those niceties into nano.

Extensions points, in general, seem perfect for me for an editor like nano. 
Some of the things I mentioned already serve as those and they are pretty 
powerful for the amount of code that went into them–I mean, putting 
“extendsyntax rust linter rustc --error-format=short” in my nanorc and invoking 
a compiler built yesterday for a language that didn’t even have a stable 
release when the compiler binary I’m using was created is certainly pretty 
awesome. One could imagine nano adding the ability to autocomplete and then 
someone writing a couple dozen lines of Python on their own and giving the 
editor access to all of LSP. Or we could do a robust version of indentation 
detection (which I just realized I was working on and forgot to take another 
look at…oops) by allowing ways to programmatically alter settings and letting a 
script run wild on the current buffer and changing the tabgives to whatever 
would make sense. The beauty of this approach is that the amount of code that 
would actually have to go into nano is non-trivial but not huge, and then you 
can literally start offloading features to people who are interested in it, 
without having to go through the process each time of “Should this be in nano? 
Do I even have a command line flag that I can assign to it?!” And you strike 
that great balance with the people who want the simplest, stripped down nano 
but also allowing for people to trick it out and use it as their replacement 
IDE. (I fall in both camps regularly, so I am particularly interested in this 
scenario.)

I guess this got a bit rambly, but I just wanted to confirm that there are 
other people that feel this way. I think there is a lot of things that nano 
could be great at and yet still be nano at heart. I’d be glad to help wherever 
possible if we would like to talk extensibility, whatever form it might come in.

Regards,
Saagar Jha

> On Jan 2, 2021, at 14:17, Marco Diego Aurélio Mesquita 
> <marcodiegomesquita@gmail.com> wrote:
> 
> I'd like nano interaction with external tools to be more powerful. The
> external tools plugins for gedit allows some interesting features like
> enabling different behavior for different file types, interface
> directly with git, using zenity to get user input, preview with
> another tool, make, build, compile, run, etc...
> 
> Considering nano macros and external tools, I thought about how to get
> most of the described features with minimal changes to gnu nano. Part
> of the power of gedit external tools plugin come from the environment
> variables that gedit passes when the external program/script is run. I
> think we can mimic that and gain some very interesting features in
> nano.
> 
> The minimal set of environment variables that can be passed to enable
> these features, that I came up with, were (names are
> self-explanatory):
> 
> DOCUMENT_PATH
> LINE
> LINE_NUMBER
> ROW_NUMBER
> 
> These can be achieved with very small changes to gnu nano source code
> and would enable much more advanced interactions with external tools.
> It would allow me, for example, to (I think):
>  - compile and preview a latex project,
>  - check for compile warnings on cursor's current line,
>  - run make for the current project and launch it on another terminal window,
>  - run git diff on the current file and easily show what was changed
> since last commit,
>  - run git add or checkout on current file,
>  - etc...
> 
> Also, it is something I'm willing to and think I'm capable of
> implementing myself.
> 
> Please tell me I'm not the only one interested in these features.
>