Re: [PATCH] Add shell-quasiquote.

[taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> (Sorry if anyone gets dupes, I horked my VM and it improperly handled
> Taylan's display name, which caused bounces from at least two MTAs.)
>
> Taylan Ulrich Bayırlı/Kammer writes:
>
>  > The collective "opinion" here seems to be that it's a good idea to
>  > reject perfectly working code with well-defined semantics for made up
>  > reasons.
>
> The reasons aren't made-up.  Duplication of needed functionality is
> excessive complexity.  Introduction of unneeded functionality is
> excessive complexity.  Excessive complexity makes it harder to learn
> Emacs Lisp and/or harder to understand new code.  Compare the horrible
> hash that is Emacs Lisp with a cleaner language like Guile[1], and
> the costs become clear.  As an exercise, try getting shell-quasiquote
> into Guile and see if you fare better there.  (Maybe you already have,
> in which case just say so, and what the result was. ;-)[2]

There is no duplication of work because the two functions have differing
semantics.  I already pointed this out.

I don't see shell-quasiquote fitting into Guile very well (there aren't
all the different kinds of shell-command functions).  Guile also doesn't
have a direct analogue to ELPA.

> Nor is it obvious to me that shell-quasiquote is "perfectly working".
> Shell quoting is a very fragile thing.  If something is quoted that
> shouldn't be quoted, that is a bug.  Sure, you provide ",,", but
> that's punting the problem back to the user.  Whether it's better to
> punt on quoting or unquoting a given construct is a question of
> balance -- calling it "perfect" is a judgment that depends on the
> application and on the user.  You have every right to say that for
> yourself, but not for Emacs, not even in your intended application.
> Different arguments apply to whether `shqq' *always* quotes enough to
> prevent code injection.

It's documented precisely what shqq does, and it does that correctly.
(If not, please point it out.)

If anyone finds the semantics of shqq to be "overall wonky" (because it
lies in a funny place between `shell-command' and `call-process' so to
say, in terms of the semantics of the generated command) that would be a
different topic, which nobody brought up yet, and they brought up all
sorts of stuff.  Ironically, it would be a criticism I could actually
understand.

> None of that means `shqq' won't turn out to be right thing for many
> Emacs applications in the end.  But your argument so far reduces to
> "it won't hurt and it works for me".  That is inappropriate on both
> counts when requesting maintenance and distribution by the Emacs
> Project (which is what inclusion in GNU ELPA means, even if you are
> offering to do the maintenance yourself -- you could spend that time
> on other services to the project).
>
> If upon consideration you don't like that much better, then you should
> find an alternative way to contribute, or an alternative community to
> contribute to.  But you seem to misunderstand what the needs of the
> Emacs Project are, and how that affects the community's evaluation of
> your proposed contribution.  With a better understanding you may be
> more willing to contribute on the community's terms (and make no
> mistake, every community has its own terms).

Thanks for the friendliness but I wasted an absurd amount of time and
nerves on this trivial topic (a one-line function).  One could still
accept my patch to shell-quote-argument so that I can use that, or one
could accept the variant using the one-line alternative with correct
semantics, and I've explained in painfully excruciating detail why
either is necessary, but so far people were unwilling to accept that.
I'm not going to work on a third way unless someone has a very, very
good reason.

This tells me that this development community (or at least certain
people in it) don't want my contribution for inexplicable reasons, in
particular not technical reasons.  I do not see any possible sensible
definition of "the needs of the Emacs Project" that would lead to the
behavior I've seen from certain people here, so I disagree absolutely
that it could possibly be a misunderstanding on my side.


Moreover, I've been warned about emacs-devel by multiple people before,
and about a certain member of it in particular, and I did not believe it
could possibly be this bad.  Lest you think this is an isolated case.
Maybe the previous victims were less outspoken so the majority of the
community still doesn't see that there's a serious problem.

Taylan