From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 13 Mar 2021 14:39:28 -0500 Message-ID: References: <87wnvkixrv.fsf@miha-pc> <874kinakv2.fsf@miha-pc> <87sg6690vc.fsf@miha-pc> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32636"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: jakanakaevangeli , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 13 20:40:44 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lLA7w-0008OG-30 for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Mar 2021 20:40:44 +0100 Original-Received: from localhost ([::1]:46658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lLA7v-0001DG-2a for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Mar 2021 14:40:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLA6t-0000eg-II for emacs-devel@gnu.org; Sat, 13 Mar 2021 14:39:39 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14347) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLA6q-0002RV-Py for emacs-devel@gnu.org; Sat, 13 Mar 2021 14:39:38 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 456D680229; Sat, 13 Mar 2021 14:39:35 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7D51980712; Sat, 13 Mar 2021 14:39:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1615664369; bh=OXrvbB2ZwzbdI8EN3EPBoTQW+foCjk820nusTmKr+Po=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NozUOdu5QRw/SiPe2BiswuuXnoqb4chZ5ZbYm7srLV8NwG3kAb1zYKaLtjn/pZhJL fkOt5jspoZ0UwJ1lNBFd3N2hyDhmVkyOyGVdmp3RFL+dkoIWH80io8oPM885L6pT2s OLx0eaqEIWSmrv+U6rMUG1hG0j6UYJWLY1Rk2of7xYOeSN/qDUAykk8DMRzeUQnKC2 EBwFJvxVK4DWveXJfzdI44TzIgLYJr5LbMi6PZRGidduqb0fr48E4xcRGJbd8oKBnr LWW/qJBs4J53os8dWC0jONhKAiAyLB8en3aY6VIlEeXYhKIy0Koxf1SsHgJRmemkxM /wOqKAyWM6bow== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3C6E3120211; Sat, 13 Mar 2021 14:39:29 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Sat, 13 Mar 2021 18:23:33 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266441 Archived-At: Hi Alan, > I would be grateful indeed if either of you (or indeed, anybody else), > would apply the patch and try it out, or indeed comment on it. Thanks! I'm not very familiar with this part of Emacs's code, but here are some things I noticed: > @@ -4416,7 +4416,8 @@ record-window-buffer > window (assq-delete-all buffer (window-prev-buffers window)))) > > ;; Don't record insignificant buffers. > - (unless (eq (aref (buffer-name buffer) 0) ?\s) > + (when (or (not (eq (aref (buffer-name buffer) 0) ?\s)) > + (string-match "^ \\*Minibuf" (buffer-name buffer))) I think you want to use `minibufferp` here (and if not, then please add a comment explaining why). > @@ -4348,7 +4348,7 @@ extern void clear_regexp_cache (void); > > extern Lisp_Object Vminibuffer_list; > extern Lisp_Object last_minibuf_string; > -extern void move_minibuffer_onto_frame (void); > +extern void move_minibuffers_onto_frame (struct frame *, int); Please use the `bool` type for booleans. > +/* Get the next live buffer entry from a w->prev_buffer, setting the pertinent > + variables of `zip_minibuffer_stacks'. The parameter P is either "d" for > + the destination structures, or "s" for the source structures. When the > + ->prev_buffers list is exhausted, set di/si to -1. */ > +#define NEXT_BUFFER_ENTRY(p) \ > + do \ > + { \ > + if (NILP (p##_bufs)) \ > + { \ > + p##b = Qnil; \ > + p##_ent = Qnil; \ > + } \ > + else \ > + { \ > + p##_ent = Fcar (p##_bufs); \ > + p##b = Fcar (p##_ent); \ > + p##_bufs = Fcdr (p##_bufs); \ > + } \ > + if (!NILP (p##b)) \ > + p##i = this_minibuffer_depth (p##b); \ > + else \ > + p##i = -1; \ > + } while (p##i == 0) Any chance we could make that into a function taking an argument `p` that's a reference to a struct { Lisp_Object bufs; Lisp_Object b; Lisp_Object ent; int depth; } ? I know we already use such longish macros in various places, but I'd rather we use fewer of them rather than adding more of them, because they're a pain to debug (and I find they make the code harder to read; e.g. here we see a call to `NEXT_BUFFER_ENTRY` we can't know which variables will be accessed/modified without looking at the definition of the macro). > +/* Move the ordered "stack" of minibuffers from SOURCE_WINDOW to > + DEST_WINDOW, interleaving those minibuffers with any in DEST_WINDOW > + to produce an ordered combination. The ordering is by minibuffer > + depth. A stack of minibuffers consists of the minibuffer currently > + in DEST/SOURCE_WINDOW together with any recorded in the > + ->prev_buffers field of the struct window. */ This is actually the "merge" part of a merge sort, so we could use `sort_list` or even just the `merge` function used by `sort_list`. [ Tho maybe it is simpler and more robust (in case ELisp code can access (and hence modify) those lists) to leave those lists not sorted, and instead look for the deepest buffer in `minibuffer_unwind` rather than just picking the next. ] > +/* If `minibuffer_follows_selected_frame' is t, or we're about to > + delete a frame which potentially "contains" minibuffers, move them > + from the old frame to the selected frame. This function is > + intended to be called from `do_switch_frame' in frame.c. OF is the > + old frame, FOR_DELETION is self explanatory. */ Actually, I suspect that the "self explanatory" part will not be true when my daughter ends up having to fix that code 10 years from now. [ Tho, it currently looks quite unlikely :-( ] Stefan