GNU bug report logs - #47454
plist-put should have a version which accepts multiple properties

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47454 in the body.
You can then email your comments to 47454 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: scame <laszlomail <at> protonmail.com>
To: "scame via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: plist-put should have a version which accepts multiple properties
Date: Sun, 28 Mar 2021 17:34:45 +0000

Modifying plists could be much easier if multiple properties
were also accepted.

E.g. (plist-put PLIST PROP VAL ... )

or (plist-put PLIST (PROP VAL ....) )


Others also find this problematic:

https://emacs.stackexchange.com/questions/39473/how-to-modify-multiple-keys-in-a-plist

and the suggessted solutions are clumsy:

  (setq org-format-latex-options (plist-put org-format-latex-options :scale 1.5))
  (setq org-format-latex-options (plist-put org-format-latex-options :foreground 'auto))

or

  (setq org-format-latex-options
      (plist-put (plist-put org-format-latex-options
                            :scale 1.5)
                 :foreground 'auto))


Making plist-put smarter to accept multiple values or adding an
other function which accepts them (e.g. plist-put-multiple)
could make using plists much more convenient.

Message #8 received at 47454 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: scame <laszlomail <at> protonmail.com>
Cc: 47454 <at> debbugs.gnu.org
Subject: Re: bug#47454: plist-put should have a version which accepts
 multiple properties
Date: Tue, 18 May 2021 18:13:45 +0200

scame <laszlomail <at> protonmail.com> writes:

> Modifying plists could be much easier if multiple properties
> were also accepted.
>
> E.g. (plist-put PLIST PROP VAL ... )
>
> or (plist-put PLIST (PROP VAL ....) )
>
> Others also find this problematic:
>
> https://emacs.stackexchange.com/questions/39473/how-to-modify-multiple-keys-in-a-plist
>
> and the suggessted solutions are clumsy:
>
>   (setq org-format-latex-options (plist-put org-format-latex-options :scale 1.5))
>   (setq org-format-latex-options (plist-put org-format-latex-options :foreground 'auto))

Well...  pretty much any key/value storage function works like this --
for instance, you can't put more than one key/value into a hash table
with puthash.  puthash does have the advantage that you don't have to
setq the variable, so it's somewhat less verbose.

(setf (seq-elt plist ...))

may help with that, though.

In any case, I don't think extending plist-put (or adding a new function
to take a list would be that useful, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #15 received at 47454 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47454 <at> debbugs.gnu.org
Subject: Re: bug#47454: plist-put should have a version which accepts
 multiple properties
Date: Tue, 15 Jun 2021 00:53:54 +0300

> (setf (seq-elt plist ...))
>
> may help with that, though.

BTW, often after pulling from master and recompiling,
Emacs fails to start with such errors:

Debugger entered--Lisp error: (error "(setf seq-elt) is already defined as something else than a generic function")
  error("%s is already defined as something else than a generic function" \(setf\ seq-elt\))
  cl-generic-ensure-function(\(setf\ seq-elt\))
  cl-generic-define-method(\(setf\ seq-elt\) nil (store (sequence array) n) nil #f(compiled-function (store sequence n) #<bytecode -0x1d67862086490644>))
  byte-code(...)
  require(seq)
  byte-cod...)
  require(gnus-util)
  byte-code(...)
  require(nnheader)
  byte-code(...)
  require(gnus)

This requires bootstrap that fixes it.
But I wonder if maybe there is some deeply hidden problem with setf and seq-elt?

Message #18 received at 47454 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47454 <at> debbugs.gnu.org
Subject: Re: bug#47454: plist-put should have a version which accepts
 multiple properties
Date: Tue, 15 Jun 2021 08:48:25 -0400

Juri Linkov [2021-06-15 00:53:54] wrote:

>> (setf (seq-elt plist ...))
>>
>> may help with that, though.
>
> BTW, often after pulling from master and recompiling,
> Emacs fails to start with such errors:
>
> Debugger entered--Lisp error: (error "(setf seq-elt) is already defined as
> something else than a generic function")
>   error("%s is already defined as something else than a generic function" \(setf\ seq-elt\))
>   cl-generic-ensure-function(\(setf\ seq-elt\))
>   cl-generic-define-method(\(setf\ seq-elt\) nil (store (sequence array) n)
> nil #f(compiled-function (store sequence n)

Hmm....

When you see that, could you show us the value of:

    (symbol-function '\(setf\ seq-elt\))


-- Stefan

Message #21 received at 47454 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 47454 <at> debbugs.gnu.org
Subject: Re: bug#47454: plist-put should have a version which accepts
 multiple properties
Date: Wed, 16 Jun 2021 12:55:49 -0400

forcemerge 47454 49053
close 47454 49053
thanks

Stefan Monnier [2021-06-15 08:48:25] wrote:

> Juri Linkov [2021-06-15 00:53:54] wrote:
>
>>> (setf (seq-elt plist ...))
>>>
>>> may help with that, though.
>>
>> BTW, often after pulling from master and recompiling,
>> Emacs fails to start with such errors:
>>
>> Debugger entered--Lisp error: (error "(setf seq-elt) is already defined as
>> something else than a generic function")
>>   error("%s is already defined as something else than a generic function" \(setf\ seq-elt\))
>>   cl-generic-ensure-function(\(setf\ seq-elt\))
>>   cl-generic-define-method(\(setf\ seq-elt\) nil (store (sequence array) n)
>> nil #f(compiled-function (store sequence n)
>
> Hmm....
>
> When you see that, could you show us the value of:
>
>     (symbol-function '\(setf\ seq-elt\))

I installed the patch below which apparently fixes this problem


        Stefan


diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
index 31aa0cb4f9..544704be38 100644
--- a/lisp/emacs-lisp/cl-generic.el
+++ b/lisp/emacs-lisp/cl-generic.el
@@ -568,17 +568,17 @@ cl-generic-define-method
               (cons method mt)
             ;; Keep the ordering; important for methods with :extra qualifiers.
             (mapcar (lambda (x) (if (eq x (car me)) method x)) mt)))
-    (let ((sym (cl--generic-name generic))) ; Actual name (for aliases).
+    (let ((sym (cl--generic-name generic)) ; Actual name (for aliases).
+          ;; FIXME: Try to avoid re-constructing a new function if the old one
+          ;; is still valid (e.g. still empty method cache)?
+          (gfun (cl--generic-make-function generic)))
       (unless (symbol-function sym)
         (defalias sym 'dummy))   ;Record definition into load-history.
       (cl-pushnew `(cl-defmethod . ,(cl--generic-load-hist-format
                                      (cl--generic-name generic)
                                      qualifiers specializers))
                   current-load-list :test #'equal)
-      ;; FIXME: Try to avoid re-constructing a new function if the old one
-      ;; is still valid (e.g. still empty method cache)?
-      (let ((gfun (cl--generic-make-function generic))
-            ;; Prevent `defalias' from recording this as the definition site of
+      (let (;; Prevent `defalias' from recording this as the definition site of
             ;; the generic function.
             current-load-list
             ;; BEWARE!  Don't purify this function definition, since that leads

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.