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: Allow controlling the effect of visibility on buffer switching Date: Sat, 29 Jan 2022 19:31:06 -0500 Message-ID: References: <87a6fi3lrl.fsf@gmail.com> <83a6fihbeb.fsf@gnu.org> <877dam38zr.fsf@gmail.com> <8335lah77y.fsf@gnu.org> <87mtjf0ypz.fsf@gmail.com> <87y22yhogr.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15623"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Thuna , Eli Zaretskii , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 30 01:33:41 2022 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 1nDyA1-0003sT-Az for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jan 2022 01:33:41 +0100 Original-Received: from localhost ([::1]:43504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nDy9z-00079X-Qq for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Jan 2022 19:33:39 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nDy7f-0006G9-Hk for emacs-devel@gnu.org; Sat, 29 Jan 2022 19:31:15 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19116) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nDy7d-0004jz-3b; Sat, 29 Jan 2022 19:31:14 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8683480533; Sat, 29 Jan 2022 19:31:10 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B6B8E80342; Sat, 29 Jan 2022 19:31:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1643502668; bh=CLuXjiQFEenSfA+XQZ6q0kpNgXbNZ786rDrZ68oO/bI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YH1BEYGBnrMSmFcmFw0EmHi0NOZq/8GKaq7HjaAj7XtvfVgiudKs7QTlhUdxUTQVa wgPR1htXnz+VsVLbYI144Y9PqDiU5UIqo7PkqoN4JHRz4tPEAJRUD5KF/OhvOJzjb5 cHP26E2uoP5Ak07zQ7ntQqdsmKQCvl0sDh1/y+5MWEhm2l0mn8Hfcjd1GZLcQMhAib Ug1QdQzkoLT7aVtl6rV+JUrlIG5l6zJCK6eTGuGldfVxhhUDdxqEzUZ+zGQiNGfsM8 h94nN8suoCKwvqDqUhtKuaYGuaMH5glnGZHksFIPMCrBzL5PtsMI9/pVuk8v9NefZM V8iqtUfhOBG6A== Original-Received: from ceviche (76-10-138-212.dsl.teksavvy.com [76.10.138.212]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4ABB21209EE; Sat, 29 Jan 2022 19:31:08 -0500 (EST) In-Reply-To: <87y22yhogr.fsf@yahoo.com> (Po Lu's message of "Sat, 29 Jan 2022 17:37:40 +0800") 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:285577 Archived-At: Po Lu [2022-01-29 17:37:40] wrote: > Thuna writes: >> It is extremely unlikely for someone to know what their last non-visible >> buffer is, especially after accounting for other frames and windows. > > I find it sufficient to take a quick glance at the frame I'm currently > working on. Further more, multiple frame workflows are reasonably rare, > and even more so the workflows where some frames aren't visible at any > given time. FWIW, I also dislike the current behavior: I can't remember the last time that I used `C-x b`s default and was glad that it wasn't one of the already displayed buffers: for my use cases, `C-x b`s default is only ever right when the last buffer is not visible. > And please don't change the behaviour of `switch-to-buffer' in such a > drastic manner. People are used to it as it is. I think this discussion would benefit from a more constructive argument than habit. Can you describe use cases where `C-x b`s current default is indeed the one the user wants yet it is not the last buffer (because the last buffer is already visible elsewhere)? My analysis of the situation is the following: - Users in group A arrange to (almost always) have one one window displaying a given buffer. In that case, they probably won't want to `C-x b` to an already visible buffer (which suggests the current code is right for them) *BUT* it also means that the "last buffer" is most likely not visible either (since it would mean that this last buffer was (back then) visible in two windows). So for those users, either behavior will usually give the same result. - Users in group B OTOH do take advantage of Emacs's (maybe not unique, but somewhat unusual) ability to display the same buffer is several windows at the same time. For them it's just as likely they'll want to use `C-x b` to display an already displayed buffer as any other. For these users, the current behavior may be harmful since it just makes it harder for them to predict what `C-x b`s default will be. Stefan