From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#69983: Use category for display-buffer-alist Date: Fri, 19 Apr 2024 09:24:10 +0300 Organization: LINKOV.NET Message-ID: <861q71rhtk.fsf@mail.linkov.net> References: <86h6gv7e0z.fsf@mail.linkov.net> <86a5m3jboy.fsf@mail.linkov.net> <86v84rvwpa.fsf@gnu.org> <867ch7gfa4.fsf@mail.linkov.net> <86bk6iwftq.fsf@gnu.org> <86il0pd8da.fsf@mail.linkov.net> <864jc9wk5r.fsf@gnu.org> <861q7dgla3.fsf@mail.linkov.net> <86il0pulum.fsf@gnu.org> <86cyqwjtpr.fsf@mail.linkov.net> <86y19ktkj2.fsf@gnu.org> <86h6g7m773.fsf@mail.linkov.net> <86sezrrrgh.fsf@gnu.org> <86il0m7ceo.fsf@mail.linkov.net> <86a5lysah3.fsf@gnu.org> <86o7ad2j84.fsf@mail.linkov.net> <86mspxnkyt.fsf@gnu.org> <86bk6c5ke3.fsf@mail.linkov.net> <864jbyeo9y.fsf@gnu.org> <86jzkusidd.fsf@mail.linkov.net> <86h6fyd06g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8550"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: rudalics@gmx.at, 69983@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 19 08:26:12 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rxhhM-00025B-3r for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Apr 2024 08:26:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxhh1-0004qf-Uv; Fri, 19 Apr 2024 02:25:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rxhgz-0004qW-Om for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 02:25:49 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rxhgz-0006jB-D8 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 02:25:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxhhC-0005ai-Rx for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 02:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Apr 2024 06:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69983 X-GNU-PR-Package: emacs Original-Received: via spool by 69983-submit@debbugs.gnu.org id=B69983.171350794221345 (code B ref 69983); Fri, 19 Apr 2024 06:26:02 +0000 Original-Received: (at 69983) by debbugs.gnu.org; 19 Apr 2024 06:25:42 +0000 Original-Received: from localhost ([127.0.0.1]:57018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxhgr-0005YC-Hr for submit@debbugs.gnu.org; Fri, 19 Apr 2024 02:25:41 -0400 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:46789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxhgp-0005Y5-Bq for 69983@debbugs.gnu.org; Fri, 19 Apr 2024 02:25:39 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 29997E0003; Fri, 19 Apr 2024 06:25:17 +0000 (UTC) In-Reply-To: <86h6fyd06g.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 18 Apr 2024 20:56:39 +0300") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283633 Archived-At: >> >> >> > If we want to enable user control of displaying warnings, we will have >> >> >> > to add an option for that, because currently that cannot be >> >> >> > controlled. display-buffer-alist is inappropriate for such control, >> >> >> > since in some cases warnings are not displayed in pop-up windows. >> >> >> >> >> >> Could you show an example when warnings are not displayed in pop-up windows. >> >> > >> >> > The two calls to 'message' there. >> >> >> >> These calls are irrelevant. It makes no sense to add an option >> >> to display text "at the bottom of 'message'". >> > >> > Of course. But what if some user would like to display the warnings >> > in the echo-area? Don't we want to allow such customization? If we >> > do, then display-buffer machinery is not relevant, exactly as it is >> > not relevant for those two calls. >> >> This proves that a new option is not needed. QED. >> >> >> >> > Thanks, but what do you mean by "at the bottom"? Can you describe >> >> >> > that place more precisely? >> >> >> >> >> >> Here is an example: >> >> > >> >> > I understand what this means in the simple cases, but not necessarily >> >> > what happens in more complex cases. >> >> >> >> This case is not simple. It demonstrates the problem >> >> in horizontally split windows. >> >> >> >> > This is why I asked for a detailed definition of "at bottom". >> >> >> >> The detailed definition is in the documentation of >> >> 'display-buffer-at-bottom'. >> > >> > I agree that "display at bottom" is a useful feature, but why should >> > we decide that users could have no control of that, either? E.g., >> > another reasonable MO is to split the selected window vertically and >> > show the warning in the lower window. >> >> This is easy to customize with a category in display-buffer-alist. >> >> > So I think display-warning should have a variable to customize its >> > display, and limiting that only to what display-buffer can produce >> > doesn't support all the optional behaviors people could reasonably >> > want. Moreover, display-buffer is IMO overly-complex for this simple >> > job; a simple variable with several distinct values would do. >> >> Adding dozens of new variables that replace display-buffer-alist >> makes no sense. > > So we disagree. I stand by my opinion, and will object to making > display-buffer-alist the way of customizing display-warning. This is not about customizing display-warning. This is about customizing the display of the warning buffer. When other functions such as 'lwarn' and 'warn' display the warning buffer the only way to customize the display of the warning buffer is display-buffer-alist.