() Michael Heerdegen () 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