[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving 'pcase' documentation
|
From: |
Michael Heerdegen |
|
Subject: |
Re: Improving 'pcase' documentation |
|
Date: |
Tue, 21 Nov 2023 17:30:19 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Jim Porter <jporterbugs@gmail.com> writes:
> 1. Mention backquote patterns earlier in the 'pcase' docstring.
Good idea. The current documentation tries to keep the first parts
simple, but this is also a bit demotivating and artificial (readers may
wonders what this is all good for until they see the whole picture).
> 2. Add a simpler conceptual summary for backquote patterns. I think
> you could get pretty far by describing them as "running the usual
> backquoting in reverse". That is, instead of building a list where you
> splice values *in*, you're destructuring a list where you cut values
> *out*.
Yes. I came to the conclusion that it is important to outline the
design idea and the concept behind `pcase' more. I guess this would
make the documentation a lot more accessible.
> 5. Mention 'pcase' in the Lisp Intro manual? A beginner's guide to
> 'pcase' could make sense in the Lisp Intro, and while we wouldn't have
> to cover everything, it would at minimum alert readers to the fact
> that it exists, and the basics of how 'pcase' works.
A clear "no" from my side. Beginners should concentrate on basics.
> 6. Improve editing support. I'm not sure how feasible this is, but it
> would be nice if Emacs understood 'pcase' better when editing. For
> example, font-lock support on the various macro forms; Emacs already
> font-locks the 'or' pattern, but only because 'or' is font-locked
> normally. It would be nice if the same applied to 'pred', 'guard',
> etc. Similarly, ElDoc and Help (C-h f) could do the right thing inside
> 'pcase', providing us with the appropriate documentation. (I also
> think it'd be nice to font-lock anything that looks like ",SYMBOL",
> even outside of 'pcase', but maybe others would find that annoying.)
I would find the ElDoc part most useful by far.
Thanks so far,
Michael.