[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving aesthetics & readability of backquote

From: Paul W. Rankin
Subject: Re: Improving aesthetics & readability of backquote
Date: Wed, 22 May 2019 12:46:49 +1000
User-agent: mu4e 1.2.0; emacs 26.2

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

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:


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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]