Re: patch for new feature: placeholders in execute command

Dear Benno,

thank you for taking the time to go through my long message and your 
reply :)

In fact, I didn't know I could use the {writeout} command as you 
provided in your example.
That makes the patch I submitted totally redundant! I am sorry, I tried 
hard to achieve that
behavior you provided in your bind command, but I never managed.

Just to make clear why I think this is useful (subjectively), I am 
replying to your comments below,
if you are interested to read.

Thank you for your time and suggestions, and thanks for your work.
I hope I will be able to contribute to nano in some other way in the future.

Best,
Luca


*** Replies to comments:

> But... why would one want to insert the documentation for some Python
> module into a Python file itself?  It doesn't make sense to me.  You
> will have to give a more concrete example of something that is likely
> to be useful to a fair number of nano users.  (Also, nano doesn't have
> a syntax for R, so mentioning that as an example is a bit strange.)

Indeed, this is useless, and it is not what I was thinking.  That is my 
fault, I should have explained the use case better.
What I meant is not to insert the documentation in the current document, 
but to show the doc in an external terminal,
that is opened "on the fly". I typically spawn a new terminal and type 
the command that brings the documentation;
I think it is just more convenient to highlight a word in nano, and have 
a keypress do that for me. But I was missing the
  filetype, so that I have not been able so far to invoke the correct 
documentation program (like pydoc for Python).
If I am correct, I would use Shift+K in vim to do something similar.
(As per the R example, it is just an example I am familiar with; but it 
really doesn't matter).

> Oh no...  I have no interest in making it easier for nano to interact
> with "artificial intelligence".

Yes, I totally agree. I was not suggesting that. It is something I use 
myself (e.g. pipe text to ollama and paste the output
in current document), but it does not require anything from nano, 
really. Having filetype, filename and pwd will make it
easier to implement any external script to do any sort of manipulation 
on the text. Another example I use: I am frequently
filtering text using shell scripts and I use a shell program that 
conveniently prompts all available filters and allows me to
choose one with fzf. Currently, the script shows all possible filters; 
now, with your suggestion, I am able to only prompt the
filters that are relevant for the current programming language syntax, 
parsing the filetype.


> (One remark about the implementation: why two passes when one pass will do?
> It will require a few re-allocations of the target string, but that hardly
> matters: they will seldom happen.)

Ah... I really didn't know what is the best thing to do here. I could 
pre-allocate a string and re-allocate as needed in
one pass. I went with just allocate once, using the exact length without 
re-allocations. To do this I need to
know the correct length of the parsed string, and that is why I have the 
first pass. But I am no expert, and I didn't know
that it is better to re-allocate. I learnt something new, thank you :)


> And second: nano is a simple editor, it is not
> meant for doing advanced stuff.

I do understand this, and this is exactly what I love about nano. Still, 
I think that nano interacting so naturally with
the shell and external scripts makes it suitable for moderately advanced 
use cases like connecting it with a REPL via tmux
or using it for forward and backward search for tex files (two things I 
actually use). Being able to access filetype, filename and pwd,
just makes everything easier. But nano already has this feature, has you 
showed me.