bug#31311: 27.0; doc of `pcase'

[Thien-Thi Nguyen]

() Michael Heerdegen <michael_heerdegen@web.de>
() Wed, 16 May 2018 17:18:14 +0200

   Personally I would prefer to have KEYWORD, INTEGER and STRING
   in one line, like

   KEYWORD, INTEGER, STRING
            shorthand for \\='KEYWORD, \\='INTEGER,
            and \\='STRING

   so that we have as least different cases as possible in the
   item list.

Yeah, that does seem a bit more pleasant.  To achieve that,
however, we would need to use ‘@table @asis’ and then manually
add @code around everything, so that the commas are not included
in @code.  Hmmm, energy seeping away...

   It's ok for me.  I'll have a look at the complete change when
   the details are done.

As of commit 7c68d9f8c7, "the details are done", but for:

   > commit 5b775cf3fc there is an Issue.  WDYT?

   Yes, the code seems a bit half-baked.  I don't recall why
   these cases are so problematic that they are handled this
   way.  I think Stefan will know.

and the other remaining Issue (commit 455f990ce), excerpt here:

 +@c Issue: Should this be split off into its own node/subsection?
 +@subheading Backquote-Style Patterns
 +@cindex backquote-style patterns

IMHO, ‘pcase’ is so complex (compared to most other Emacs Lisp
control structures), it deserves to be promoted to @‘section’,
between ‘Conditionals’ and ‘Constructs for Combining Conditions’.

What do people think?

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502

signature.asc
Description: PGP signature