Re: Improving 'pcase' documentation

[Michael Heerdegen <michael_heerdegen@web.de>]

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.