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#73734: [PATCH] Fix tmm menu layout Date: Thu, 10 Oct 2024 21:29:48 +0300 Message-ID: <868quv24mb.fsf@gnu.org> References: <87cyk812uv.fsf@ledu-giraud.fr> <86iku00wbz.fsf@gnu.org> <878quv96sk.fsf@ledu-giraud.fr> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="314"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, 73734@debbugs.gnu.org To: Manuel Giraud Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 10 20:31:10 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 1syxwL-000AON-8u for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Oct 2024 20:31:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syxw5-0000tJ-AC; Thu, 10 Oct 2024 14:30:53 -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 1syxw3-0000su-33 for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 14:30:51 -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 1syxw2-0001j0-QR for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 14:30:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=a8e3PcNRRhQtC5vrLkf4/ZCWLdMkuP4KbYEj7CtSznM=; b=PDZGbNglx2Wb7OKJIQ2HvkM3rQwdV1A/2xOLJdZ8OFEiL0RHU+NiKaz8EdR5K/xlftl0ZI2h+2E80JNuzwbakyWttSyfbvcuhdn2CTuwAQQlw7Wl3e6Tu5e1XehGgdzeG+FdmOWcZ56Ubs6LpCrahlaGGn4Bg0YgaSLshDmGnT5rocZle+gGd4iYMzMeQa9RPi05EnCoiyxmh/xIuVrUKwwvPnCcs5tOw8B9MwxvfpZ0QIoB23Y9WEUGivZHxTzJnZuVB9ubL0CQXMBRLfhFnb1Fwf8bVVivL1rM/pB9b6+4/YQnDtwrRKaSvhOBWdHGVZsClapkMf+EHa3HFZi1tA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1syxwE-0001Gu-Cn for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 14:31:02 -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, 10 Oct 2024 18:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73734 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 73734-submit@debbugs.gnu.org id=B73734.17285850484867 (code B ref 73734); Thu, 10 Oct 2024 18:31:02 +0000 Original-Received: (at 73734) by debbugs.gnu.org; 10 Oct 2024 18:30:48 +0000 Original-Received: from localhost ([127.0.0.1]:60538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syxw0-0001GR-4S for submit@debbugs.gnu.org; Thu, 10 Oct 2024 14:30:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syxvx-0001GA-Vm for 73734@debbugs.gnu.org; Thu, 10 Oct 2024 14:30:46 -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 1syxvd-0001cW-Ta; Thu, 10 Oct 2024 14:30:26 -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=a8e3PcNRRhQtC5vrLkf4/ZCWLdMkuP4KbYEj7CtSznM=; b=oItfepaO/lgI HjkeD/kshPQYuNJ58yBOYGu1xCOJf7QOrK2E9Ik2AX0zErAY3wj8kQNqlwlRv1ayaxuqe2sZ0lJ2L fDfqxJ3LvEbZzJ6zm9FcfLuktJIx+OwqSKnXhF3tOZjYG+1IU+piN8wVI9SOdxe70WR3z3iue4VHZ kQq4j01WvhyOCdjJsp+mm5jSWgrI2Z9T4Brzkt5Tk17iXN01ve+OH3r5GDBN65zwTbmoRYgOZFOG+ kYeRoojk+0nPYFBxafSFYGvpkiw6Pnl30c9zTsUb7Scn7zZUdW4kY8Iv2Le5p8u0TAwfkfm2JT/0A iU95fuOarSVncgqbL2LQvw==; In-Reply-To: <878quv96sk.fsf@ledu-giraud.fr> (message from Manuel Giraud on Thu, 10 Oct 2024 20:00:59 +0200) 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:293304 Archived-At: > From: Manuel Giraud > Cc: martin rudalics , 73734@debbugs.gnu.org > Date: Thu, 10 Oct 2024 20:00:59 +0200 > > > What is the "selection character" in this image? > > On the image below, "n" is what I called the selection character for > "Next Marked" while "* c" is the keybinding for "Change Marks...". The > proximity of those two makes this hard to read IMO. Ah, I see now what you meant. But if this is the problem, then changing the column width is not a reliable solution, because you cannot know in advance what will be the width of the SPC glyph in a font people use. I suggest to use 'display' properties instead, for example '(space . (:width N)), where N is the number of canonical columns we want the space to take on display. > >> This patch tries to solves this issue. > > > > Can you tell how? All I see is a different value for colwidth. I > > guess I'm missing something. > > Yes but this different colwidth would leave more space between a > keybinding and the "selection character" of the next column. But, I > have to say that it would be hard to prove that it will work for every > possible settings. Yes, I think using the 'display' property will be more reliable. > >> Here, how I justify the modification of `colwidth': > >> > >> - I don't think we need the "(min 30)" part since, if the frame is > >> wide enough, we always get a colwidth of 30. > >> > >> - I don't think "(window-width)" is what we need since, by > >> default, the *Completions* buffer will use the full frame width. > > > > Martin, is that guaranteed? > > > > And even if it is, what's the harm in keeping window-width? > > I don't think that a full frame width *Completions* buffer is > guaranteed: it is only what I see with "emacs -Q". > > Keeping window-width in this calculation seems a bit strange because, by > default, it has nothing to do with the *Completions* buffer window > width. Which window's width does this return in this case?