unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Jim Porter <jporterbugs@gmail.com>,  emacs-devel@gnu.org
Subject: Re: Improving 'pcase' documentation
Date: Mon, 25 Dec 2023 13:33:47 -0500	[thread overview]
Message-ID: <jwvbkaejfzz.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CADwFkm=aZB29-Jc_WGBWj+SdwrQJ1KRCqvJUPgaqR=JpWDLVGA@mail.gmail.com> (Stefan Kangas's message of "Mon, 25 Dec 2023 06:44:37 -0800")

>> 1. Mention backquote patterns earlier in the 'pcase' docstring. While
>> backquote patterns are in the docstring, they're pasted after the main
>> body and not listed in the part that says, "PATTERN can take one of the
>> forms: ...". Since backquote patterns aren't immediately obvious and are
>> hard to search for, they could probably stand to get mentioned earlier.
>> (Likewise, we could do the same for the 'rx' pattern in 'pcase'.) I'm
>> not sure the best way to go about this when using 'pcase-defmacro', but
>> even just manually adding it to the main 'pcase' docstring might improve
>> matters.

I'd rather not do that.  The docstring is a reference, not a manual.
But what we could do maybe is to make it more clear that the patterns
presented first (i.e. those that in pcase's main docstring) are
"internal" (and used mostly to define higher-level patterns) and somehow
encourage people to "jump further" to see the actual higher-level
patterns.

And then arrange the ordering of those higher-level patterns so
backquote comes first (which seems to be the case here, but maybe it's
a lucky accident).

>> 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*.

This "general principle" to make patterns look like calls to the
corresponding constructors should be mentioned somewhere, indeed (along
ith a caveat that it's only true for some patterns).

3-6 all sound very good.


        Stefan




  reply	other threads:[~2023-12-25 18:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-19 20:14 Improving 'pcase' documentation Jim Porter
2023-11-20 13:54 ` Dmitry Gutov
2023-11-21 16:30 ` Michael Heerdegen
2023-12-25 14:44 ` Stefan Kangas
2023-12-25 18:33   ` Stefan Monnier [this message]
2023-12-27  4:54   ` Richard Stallman

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=jwvbkaejfzz.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=jporterbugs@gmail.com \
    --cc=stefankangas@gmail.com \
    /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).