From: "Paul W. Rankin" <hello@paulwrankin.com>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: Improving aesthetics & readability of backquote
Date: Wed, 22 May 2019 12:46:49 +1000 [thread overview]
Message-ID: <m2h89nmciu.fsf@paulwrankin.com> (raw)
In-Reply-To: <E1hTBEP-0002CT-B0@fencepost.gnu.org>
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.
next prev parent reply other threads:[~2019-05-22 2:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 3:03 Improving aesthetics & readability of backquote Paul W. Rankin
2019-05-20 3:38 ` Stefan Monnier
2019-05-22 15:44 ` Stefan Monnier
2019-05-20 8:52 ` Alan Mackenzie
2019-05-20 13:25 ` Paul W. Rankin
2019-05-20 14:02 ` Alan Mackenzie
2019-05-20 14:26 ` Paul W. Rankin
2019-05-20 16:08 ` Ken Olum
2019-05-20 23:19 ` Richard Stallman
2019-05-21 2:06 ` Paul W. Rankin
2019-05-21 2:22 ` Noam Postavsky
2019-05-21 2:39 ` Paul W. Rankin
2019-05-21 20:19 ` Richard Stallman
2019-05-22 2:46 ` Paul W. Rankin [this message]
2019-05-22 7:56 ` Eli Zaretskii
2019-05-22 8:55 ` Paul W. Rankin
2019-05-22 15:57 ` Michael Heerdegen
2019-05-22 16:13 ` 조성빈
2019-05-22 16:13 ` Michael Heerdegen
2019-05-22 22:40 ` Richard Stallman
2019-05-20 8:59 ` Lars Ingebrigtsen
2019-05-20 13:35 ` Paul W. Rankin
2019-05-20 13:47 ` Basil L. Contovounesios
2019-05-20 14:18 ` Paul W. Rankin
2019-05-20 14:48 ` Basil L. Contovounesios
2019-05-20 15:25 ` Lars Ingebrigtsen
2019-05-20 23:21 ` Richard Stallman
2019-05-21 2:34 ` Paul W. Rankin
2019-05-22 16:14 ` Sam Steingold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2h89nmciu.fsf@paulwrankin.com \
--to=hello@paulwrankin.com \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).