bug#71081: 30.0.50; shell-command-on-region outputs boilerplate text on Windows

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, 71081@debbugs.gnu.org, matt@excalamus.com
> Date: Wed, 22 May 2024 14:26:47 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The easiest way of solving this conundrum is to create a temporary
> > batch file, insert all the commands into it, with the first line being
> >
> >   @echo off
> >
> > and then submit the name of that batch file to the Windows shell as
> > the sole command-line argument after shell-command-switch.  So my
> > recommendation is to do just that, on Windows.
> 
> May it be something you also want to do for `shell-command-on-region'?

No, because in general the region is some text we want to give a
program as input.  The usual "program" in these cases is not the
shell, but some program that gets the text and processes it in some
way.

So in most "usual" uses of shell-command-on-region, going through a
batch file is an unnecessary overhead.

> At the end, the current Emacs behaviour is unexpected from the user
> perspective

Only if the user is not aware of cmd.exe's different (some say
idiosyncratic) behavior wrt commands you pipe into its stdin, and wrt
command lines that include newlines.  If the user _is_ aware of that,
the behavior is very expected.

> even though it is a result of the cmd.exe behaviour. If there is a
> workable workaround, `shell-command-on-region' and Org mode may as
> well use it; preferably implemented on Emacs side to not duplicate
> the code.

I use Emacs for 30 years, and it's the first time I hear about such a
strange use of shell-command-on-region.  When I will have finished
wondering whatever gave Org developers this crazy idea, my next
question would be whether indeed this strange way of using
shell-command-on-region is a reason good enough for coding something
in core.  I tend to think no.  I think if Org needs that, Org should
solve it for itself.  It isn't very hard, is it?  When we hear about
enough clients for this strange feature, we might consider providing a
general solution.