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

[Tomas Mudrunka]

I beleive nano can get some improvements while still being lightweight.

Another idea i have in this field:
I would love to be able to specify pair of input/output filters instead 
of file name. eg.:

nano --read "cat file.txt" --write "tee file.txt"

So it would use the read command to load the file into the memory and 
pipe the file contents in the write command upon save.

Or specify some filters to process files when reading writing. For 
example.:

To convert binary to hexdump upon read and back to binary upon write:

nano --read-filter "xxd" --write-filter "xxd -r" file.bin

To have encrypted textfile for personal notes which will be decrypted 
and encrypted automaticaly by nano upon access using GPG. While this is 
not perfect security-wise, it would be secure enough for my use case.

nano --read-filter "gpg --no-use-agent --decrypt" --write-filter "gpg 
--symmetric -a --no-use-agent" file.gpg

It is similar idea as  "smudge/clean" filters available in git.

What do you think about such file access filters? It makes lot of sense 
to me, because it will make it easy to add interresting functionality 
without changing the nano too much.


Cheers
    Tom


Dne 2021-01-04 12:40, Benno Schulenberg napsal:
> Op 02-01-2021 om 23:17 schreef Marco Diego Aurélio Mesquita:
> > 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...
>
> That all sounds like IDE stuff -- Integrated Development Environment.
> That is not the target area of nano.
>
> > 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
>
> With LINE you mean the text of the current line?
>
> > LINE_NUMBER
> > ROW_NUMBER
>
> How would the row number on the screen of nano's cursor be relevant to
> an external program?
>
> > 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,
>
> These are all alien ways of thinking to me.  It would not occur to me
> to call 'git diff' from within nano.  Calling a tool from within nano
> is meant to insert the output of that tool into the current buffer (or
> into a new buffer).  Why would I want to read the output of 'git diff'
> into nano?  Maybe only if I were writing a book about git or something.
>
> So the external tools you would make for yourself would all take some
> action and show some stuff, and then would return zero characters to
> nano, so that nano would say "0 lines read"?
>
> Please provide an example script that would show a 'git diff' of the
> current buffer.  (Assume that DOCUMENT_PATH is set to "README".)
>
> >   - etc...
>
> (If you give examples, you should not say "etc", since "et cetera" is
> not an example.)
>
> Benno

--
S pozdravem
Best regards
     Tomáš Mudruňka - SPOJE.NET s.r.o.