Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Wed, May 22 2019, Richard Stallman wrote:

>   > I'm only suggesting to give people
>   > (particularly those new to Emacs) the freedom to choose a 
>   > more
>   > literal syntax that fits with the aesthetics of the 
>   > surrounding
>   > code.
>
> We must not do that.  That would lead to such usage creeping 
> into Lisp
> code.
>
> I don't believe this syntax would help people learn Lisp.  If 
> you have
> some hard evidence, that might convince me, but I think you are
> simply speculating.
>
> It seems impossible that changes in Emacs Lisp would convince 
> people
> to start editing with Emacs.

Well call Ripley's because here I am presenting my hard evidence 
by way of recounting that this was exactly my experience in 
learning Emacs Lisp.

I worked my way through the Emacs Lisp Intro manual, then started 
thumbing through the Elisp manual piecemeal. When I reached the 
backquote section, my reaction was "why doesn't this syntax match 
the Elisp syntax I've already learnt?" followed by "this must be 
for programmers to add bits of more complex languages like C, and 
D and E" (because I had no idea what C looked like). So I put it 
in the too-hard basket and just did my best without it.

So yes, making the backquote line noise make more sense would have 
its benefits.

This may make me sound like an outlier, but in releasing Elisp 
packages aimed at non-programmers, I've come into contact with 
many Emacs users with little or no familiarity with code.

In the recent mailing list thread (cited in my first email), both 
Eli and Stefan urged people to request features in Emacs when they 
found the existing Emacs capabilities insufficient:

Eli:

> But requesting a feature in addition to that does two things: 
> (a) it alerts others, including Emacs developers, to the need; 
> and (b) it announces load and clear that the package maintainer 
> is not really happy with the current solution. Without such a 
> request, no one will even know that there's a problem here 
> waiting for a volunteer.

Stefan:

> All Eli is saying is: when the Emacs infrastructure isn't as 
> good as
> you'd like for your package, please report it as a bug (no need 
> to do
> anything more than that).  That doesn't mean we'll necessarily 
> fix those
> bugs (sometimes they're hard to fix, or simply nobody is 
> interested in
> fixing them), but it helps to know about them, and can guide
> future redesigns.

This is all I'm doing. And what I'm suggesting is not without 
precedent; I've already cited the rx library, but for something 
more prevalent:

   (if COND nil ELSE)
   ->
   (unless COND THEN)

Clearly the macro unless was introduced to make Elisp more 
readable and more aesthetically pleasing; Emacs seemed to have 
survived the resultant waves of confusion and bloody factioning.

A few replies have continued with an equivocation of "change" and 
"addition". I am *not* suggesting a change to the existing syntax, 
I'm suggesting an addition. If you have an apple, and I give you 
an orange, the addition of this orange does not change your apple 
-- you still have your apple! Your life with your apple may 
continue on unabated, and my preference for oranges does not in 
any way affect your ability to eat apples. I think what 
programmers tend to believe is that if they prefer apples, then 
everyone should eat apples.