bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54100: 29.0.50; Allow project-buffers to ignore some buffers


From: Dmitry Gutov
Subject: bug#54100: 29.0.50; Allow project-buffers to ignore some buffers
Date: Fri, 25 Feb 2022 04:33:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 24.02.2022 09:18, Manuel Uberti via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
Find attached yet a better approach to avoid repetition.

The patch looks good except for this part:

          (predicate
-          (lambda (buffer)
-            ;; BUFFER is an entry (BUF-NAME . BUF-OBJ) of Vbuffer_alist.
-            (memq (cdr buffer) buffers))))
+          (or predicate
+              (lambda (buffer)
+ ;; BUFFER is an entry (BUF-NAME . BUF-OBJ) of Vbuffer_alist.
+                (memq (cdr buffer) buffers)))))

Doesn't this mean that it won't do the (memq ... buffers) check and thus ignore the result of the (project-buffers pr) call?

Instead, it could be a lambda like

          (lambda (buffer)
            ;; BUFFER is an entry (BUF-NAME . BUF-OBJ) of Vbuffer_alist.
            (and (memq (cdr buffer) buffers)
                 (funcall predicate buffer)))

Does that make sense?

(I would also try to shorten the new defcustom's docstring by referring to the existing one, but I can make that change myself.)

Note that the above mention problem about multiple conditions remains, though. Help appreciated. :)

As described in the docstring:

  If any of these conditions are satisfied ...

So when you use this value

  '(mu-project-buffer-p
    (not (derived-mode . comint-mode)))

it means "either satisfies my-project-buffer-p or not derived from comint-mode". Whereas you probably wanted to combine them with "and":

  (setq-default project-switch-to-buffer-conditions
                '(and mu-project-buffer-p
                      (not (derived-mode . comint-mode))))

And IDK, maybe the "and" top-level combination would work better for project-switch-to-buffer-conditions. It might trip up a user who's customizing both vars, though.

Or if you wanted to stay on "or" but make it easier for certain usage pattern, you could call the var 'project-ignore-buffer-conditions' (or "hide" or etc), and change its use appropriately. Then the value could contain

  '((not mu-project-buffer-p)
    (derived-mode . comint-mode))

...and (not mu-project-buffer-p) could obviously be rewritten in a negated way in the function's definition.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]