From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: valign.el Date: Mon, 30 Nov 2020 16:02:31 +0100 Message-ID: <383293557e4b409a79d2060eb03120d3@condition-alpha.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33933"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Pankaj Jangid , Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 30 16:04:26 2020 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 1kjkj4-0008j7-1w for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 16:04:26 +0100 Original-Received: from localhost ([::1]:49470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjkj3-0005Rg-12 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 10:04:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33044) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjkhN-0004AJ-Db for emacs-devel@gnu.org; Mon, 30 Nov 2020 10:02:41 -0500 Original-Received: from smtprelay07.ispgateway.de ([134.119.228.97]:18865) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjkhL-00035z-DC for emacs-devel@gnu.org; Mon, 30 Nov 2020 10:02:41 -0500 Original-Received: from [46.244.205.121] (helo=condition-alpha.com) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kjkhD-0007qf-SY; Mon, 30 Nov 2020 16:02:31 +0100 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=134.119.228.97; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay07.ispgateway.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:260066 Archived-At: Pankaj Jangid writes: > [...] > *One:* > > A few days back I was tinkering with the ``Gnus Summary Line Format'' > and I was thinking if it is possible to align the lines containing > non-english multi-byte characters with the other lines containing ASCII > names. > > Value of my `gnus-summary-line-format' is > > "%4P %U%R%z %-16&user-date; %(%[%4L(%4k):%*%-23,23f%]%) %B%s > > I have reserved 23 characters for name but it misaligns when there are > multi-byte characters in it. > [...] :+1: Same issue here with notmuch-search. But it seems unlikely that this package will solve our issue, since the docs talk about aligning stuff in tables only. To do what this package offers, you will need to do "edge detection" on the surrounding material in order to know which parts of the surrounding text to stretch. This seems somewhat feasible in tables, because the "edges" are readily marked up, and equally where "surrounding material" ends.