From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69983: Use category for display-buffer-alist Date: Thu, 18 Apr 2024 17:30:49 +0300 Message-ID: <864jbyeo9y.fsf@gnu.org> References: <86h6gv7e0z.fsf@mail.linkov.net> <86wmpdu0fa.fsf@mail.linkov.net> <86h6gf69jd.fsf@mail.linkov.net> <86sezyjpsn.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31151"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, 69983@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 18 16:32:41 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 1rxSoa-0007oL-JA for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Apr 2024 16:32:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxSoH-0004Ao-LT; Thu, 18 Apr 2024 10:32:21 -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 1rxSnr-00046h-Ji for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 10:32:06 -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 1rxSnn-0002tl-0J for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 10:31:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxSo0-0001Gf-Ct for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 10:32:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Apr 2024 14:32:04 +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.17134506741416 (code B ref 69983); Thu, 18 Apr 2024 14:32:04 +0000 Original-Received: (at 69983) by debbugs.gnu.org; 18 Apr 2024 14:31:14 +0000 Original-Received: from localhost ([127.0.0.1]:52772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxSnC-0000La-1s for submit@debbugs.gnu.org; Thu, 18 Apr 2024 10:31:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxSnA-00006R-M5 for 69983@debbugs.gnu.org; Thu, 18 Apr 2024 10:31:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rxSmq-0002eA-WE; Thu, 18 Apr 2024 10:30:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=t1afo7fm4aAYv4SXTF4z6Df/PqLjQa5fnJp9MzU5MvI=; b=KtHSr+b9ayLt BWw7dLqNPWrh4Ma0Xd+A06JtY5RwFgNYYBcC9Ie9hgL5nV+DkIXGpNanfffqvfD23TgKaBSXVXWfB w9alay/X0Fo5qohPtBfxG5JNIToj3qaxhbInt1eAe85JYNqmwJRxXONHRXkgzaLKkyGtrwDaGbR/+ ZhNhm6Zr9zwxHM0hUXAL7Kj+GU/Tng0gm7A5Y2by+E6cO4TMM+1+XgtDbxtq82+FM8BNHfNABqLVb NvHPcyZhgGeGu9Me9BYOfr8EOkBmDnCLlos1byhAZmi2D3SQfSHdAmPoApO2Glm1POjOrvAlRuI9e zR7MND/LO8R2N6rPFgrt9w==; In-Reply-To: <86bk6c5ke3.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 14 Apr 2024 19:04:13 +0300) 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:283568 Archived-At: > From: Juri Linkov > Cc: rudalics@gmx.at, 69983@debbugs.gnu.org > Date: Sun, 14 Apr 2024 19:04:13 +0300 > > >> > 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. > >> > 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. 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.