From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#62606: [PATCH] function to align mode-line elements to right Date: Fri, 09 Jun 2023 12:03:02 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28009"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62606@debbugs.gnu.org To: hugo@heagren.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 09 18:04:21 2023 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 1q7eb6-00072u-Ao for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Jun 2023 18:04:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7ear-0008UA-LJ; Fri, 09 Jun 2023 12:04:05 -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 1q7eap-0008Tu-2G for bug-gnu-emacs@gnu.org; Fri, 09 Jun 2023 12:04:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q7eao-0007CD-9H for bug-gnu-emacs@gnu.org; Fri, 09 Jun 2023 12:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7ean-0000Vt-R5 for bug-gnu-emacs@gnu.org; Fri, 09 Jun 2023 12:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Jun 2023 16:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62606 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 62606-submit@debbugs.gnu.org id=B62606.16863265941918 (code B ref 62606); Fri, 09 Jun 2023 16:04:01 +0000 Original-Received: (at 62606) by debbugs.gnu.org; 9 Jun 2023 16:03:14 +0000 Original-Received: from localhost ([127.0.0.1]:60195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ea1-0000Us-Gq for submit@debbugs.gnu.org; Fri, 09 Jun 2023 12:03:13 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7eZz-0000Ua-VF for 62606@debbugs.gnu.org; Fri, 09 Jun 2023 12:03:12 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CA9A2442908; Fri, 9 Jun 2023 12:03:05 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 02931442903; Fri, 9 Jun 2023 12:03:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686326584; bh=LoxBt43Vay/CCFgoxIUFZ3N9YqxKkAXfPXF4C6FiFIo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TuIR7ca6ViMQXgU3s9TbJDI0G5FXcftvZwdRa8ZsYpL0+qvjLche+4qUr4n666HYs 8YDEuvkU9YLe9LxalkNOVJL+uYWCwv6KQ+3fLcoV/+YisNFVtknc1FuCQLaqVoNcvs 5Um9vXZIr8YKFVnDeIPXd/sLCqu/r2/TxiAWSj3GSMVgw72UPvwME3sYazuhiHfiR9 szEI9WDmU3rfespqrDa4zp2yJ/PHKDtXMJHZ0CZ1b/KVlBskT+dKL3E6NtNplZe4wR xfTDbIXX0YgmuYMg3pzZPaH07ARjdId6SI2jC+zWbg6Vpv/3uPgT/KM9mjo31rkXcn PLCrlMRkNw8qA== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AB9421205D9; Fri, 9 Jun 2023 12:03:03 -0400 (EDT) In-Reply-To: (hugo@heagren.com's message of "Sat, 01 Apr 2023 23:27:31 +0100") 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:263173 Archived-At: > Let's hear from others. Stefan, Lars, any thoughts? Does anyone else > have any comments about this proposed feature? FWIW, my mode-lines always tend to overflow to the right, so I wouldn't be able to use that functionality, but I have no doubt that it would be welcome by several users, based on some of the mode-lines I've seen elsewhere. Also, the code is fairly simple and self-contained, so I don't see a good reason not to include that. Some comments about the code below: > +(defcustom mode-line-right-align-edge 'window > + "Where function `mode-line-format-right-align' should align to. > + > +Must be set to a symbol. Acceptable values are: > +- window: align to extreme right of window, regardless of margins > + or fringes > +- right-fringe: align to right-fringe > +- right-margin: align to right-margin > +- right: synonym for right-margin (supported because this is how the > + display property understands this, see info node `(elisp)Specified > + Space'.)" I think symbols like `right-fringe` should be enclosed in `...' in docstrings. Also, I see no reason to encourage the use of an alias, so I'd drop either `right-margin` or `right` from the doc (especially since it doesn't really come for free in the code). As a user I'd wonder if "align to right-fringe" means to align to the beginning (i.e. left side) or end (i.e. right side) of the right fringe. [ And now I wonder: can Emacs have R2L modelines? If so, what should happen in those? ] > +(defun mode-line-format-right-align () > + "Right-align all following mode-line constructs. > + > +When the symbol `mode-line-format-right-align' appears in > +`mode-line-format', return a string of one space, with a display > +property to make it appear long enough to align anything after > +that symbol to the right of the rendered mode line. Exactly how > +far to the right is controlled by `mode-line-right-align-edge'. > + > +It is important that the symbol `mode-line-format-right-align' be > +included in `mode-line-format' (and not another similar construct > +such as `(:eval (mode-line-format-right-align)'). This is because > +the symbol `mode-line-format-right-align' is processed by > +`format-mode-line' as a variable." AFAICT, this function is internal to the implementation of the `mode-line-format-right-align` mode-line spec. So maybe it should use "--" in its name. > + (let* ((rest (cdr (memq 'mode-line-format-right-align > + mode-line-format))) This is the ugly part of the implementation: the `mode-line-format-right-align` has to "find itself". I wonder if/how we could get rid of this wrinkle. Maybe instead of a `mode-line-format` of the form: (..LEFT.. mode-line-format-right-align ..RIGHT..) an alternative is to use (..LEFT.. (:eval (mode-line-format-right-align ..RIGHT..))) I wonder if it would work as well (I'm worried that it means that `..RIGHT..` is not processed directly by the C code by goes through the `format-mode-line` ELisp function to turn it into an ELisp string first and that could affect the result). It would have the advantage that it doesn't process `..RIGHT..` twice, and it should also be usable in `header-line-format` and friends. It's not great tho :-( Stefan