From: pillule <pillule@riseup.net>
To: martin rudalics <rudalics@gmx.at>
Cc: pillule <pillule@riseup.net>, 48367@debbugs.gnu.org
Subject: bug#48367: 28.0.50; quit-restore-window may jam
Date: Wed, 12 May 2021 14:10:27 +0000 [thread overview]
Message-ID: <87sg2s3uwc.fsf@host.localdomain> (raw)
In-Reply-To: <6a45ac55-4727-adca-009c-f4634619c21b@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
martin rudalics <rudalics@gmx.at> writes:
>> Is that OK to call a cl-lib function in the second patch even
>> if this library is not required in window.el ?
>
> No. I only re-compiled and did not build. Please try to avoid
> it since
> otherwise we get a
>
> In end of data:
> ../../lisp/window.el:5039:29: Warning: the function
> ‘cl-find-if-not’ is not
> known to be defined.
>
> warning.
Here an alternative version using subr.el instead :
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: quit-restore-patch-with-subr.el.patch --]
[-- Type: text/x-diff, Size: 1335 bytes --]
From 5c18c2b416b8fb6ef50dee6acc863130847eec03 Mon Sep 17 00:00:00 2001
From: Trust me I am a doctor <pillule@riseup.net>
Date: Wed, 12 May 2021 10:34:40 +0000
Subject: [PATCH] Clarifying code of quit-restore-window
Still (bug #48367)
This portion may be expressed more succinctly with an higher function.
---
lisp/window.el | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/lisp/window.el b/lisp/window.el
index 24b5df3396..914467aba0 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5036,14 +5036,10 @@ nil means to not handle the buffer in a particular way. This
(setq window (window-normalize-window window t))
(let* ((buffer (window-buffer window))
(quit-restore (window-parameter window 'quit-restore))
- (prev-buffer
- (let* ((prev-buffers (window-prev-buffers window))
- (prev-buffer (caar prev-buffers)))
- (and (or (not (eq prev-buffer buffer))
- (and (cdr prev-buffers)
- (not (eq (setq prev-buffer (cadr prev-buffers))
- buffer))))
- prev-buffer)))
+ (prev-buffer (catch 'prev-buffer
+ (dolist (buf (window-prev-buffers window))
+ (unless (eq (car buf) buffer)
+ (throw 'prev-buffer (car buf))))))
quad entry)
(cond
((and (not prev-buffer)
--
2.20.1
[-- Attachment #3: Type: text/plain, Size: 175 bytes --]
> They are trivial and we don't need an assignment for them. But
> signing
> the agreement is always a good idea.
Ok, it's on its way.
Thank you for the guidance.
--
next prev parent reply other threads:[~2021-05-12 14:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 20:26 bug#48367: 28.0.50; quit-restore-buffer may jam pillule
2021-05-12 8:47 ` martin rudalics
2021-05-12 11:25 ` bug#48367: 28.0.50; quit-restore-window " pillule
2021-05-12 12:32 ` martin rudalics
2021-05-12 14:10 ` pillule [this message]
2021-05-12 16:40 ` martin rudalics
2021-05-15 8:56 ` martin rudalics
2021-05-15 10:34 ` pillule
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sg2s3uwc.fsf@host.localdomain \
--to=pillule@riseup.net \
--cc=48367@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).