map.el: pcase plist keyword-only binding improvement

[Adam Porter]

Hi,

One of the features I find very useful in dash.el's `-let' macro is its
ability to bind plist values to variables of the same names as the keys.
With map.el's `pcase' support, Emacs's `pcase' and `pcase-let' can do
this as well, but in a less convenient way, because it requires writing
both the keyword and the variable name.

However, with a simple change to one of map'el's functions, it can
support keyword-only plist binding as well.

Example usage before change:

#+BEGIN_SRC elisp
  (let ((pl '(:one 1 :two 2)))
    (pcase pl
      ((map :one (:two two))
       (list one two))))  ;;=> nil

  (pcase-let* (((map :one (:two two))
                '(:one 1 :two 2)))
    (list one two)) ;;=> (void-variable one)
#+END_SRC

Changed function:

#+BEGIN_SRC elisp
  (defun map--make-pcase-bindings (args)
    "Return a list of pcase bindings from ARGS to the elements of a map."
    (seq-map (lambda (elt)
               (cond ((consp elt)
                      `(app (pcase--flip map-elt ,(car elt)) ,(cadr elt)))
                     ((keywordp elt)
                      ;; New clause for keyword-only elements.
                      (let ((var (intern (substring (symbol-name elt) 1))))
                        `(app (pcase--flip map-elt ,elt) ,var)))
                     (t
                      `(app (pcase--flip map-elt ',elt) ,elt))))
             args))
#+END_SRC

Example usage after change:

#+BEGIN_SRC elisp
  (let ((pl '(:one 1 :two 2)))
    (pcase pl
      ((map :one (:two two))
       (list one two)))) ;;=> (1 2)

  (pcase-let* (((map :one (:two two))
                '(:one 1 :two 2)))
    (list one two)) ;;=> (1 2)
#+END_SRC

Assuming that this change is acceptable, I would like to prepare a
patch, which would probably need to include NEWS and documentation
changes.  However, since the change is to map.el rather than pcase.el,
and since map.el is also available on ELPA, I'm not sure how to proceed
with those parts, where to make the appropriate documentation changes,
etc.

Please let me know if this proposal is acceptable and how I should
proceed.

Thanks,
Adam