From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Variable-width font alignment Date: Sat, 10 Mar 2018 02:12:57 -0600 Message-ID: <86h8pofiwm.fsf_-_@stephe-leake.org> References: <87inaiss6l.fsf@web.de> <83zi3uz4nb.fsf@gnu.org> <0b1dd3fa-e0b0-ed20-a256-dd92d1c1826f@dancol.org> <8bc3c4c7-dfc7-987a-95e7-bd309e2326c6@cs.ucla.edu> <03118DC0-39DA-4AB5-980E-A33809B9A5EE@raeburn.org> <83vaeas8uz.fsf@gnu.org> <83lgf6s3aa.fsf@gnu.org> <838tb5rxoe.fsf@gnu.org> <83lgf5q73p.fsf@gnu.org> <4742f0ae-86b5-48f9-4601-4dbba9e6380d@gmail.com> <83bmfzreaq.fsf@gnu.org> <838tb2ptpw.fsf@gnu.org> <2ca6f8cf-96f6-9caf-d72b-739a8f9cc28d@cs.ucla.edu> <83lgf1odfl.fsf@gnu.org> <83y3j1usn8.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1520669504 8403 195.159.176.226 (10 Mar 2018 08:11:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Mar 2018 08:11:44 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 10 09:11:40 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euZbN-000247-KG for ged-emacs-devel@m.gmane.org; Sat, 10 Mar 2018 09:11:37 +0100 Original-Received: from localhost ([::1]:49562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euZdQ-0006zC-F6 for ged-emacs-devel@m.gmane.org; Sat, 10 Mar 2018 03:13:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euZco-0006yv-1A for emacs-devel@gnu.org; Sat, 10 Mar 2018 03:13:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euZck-0003mT-1L for emacs-devel@gnu.org; Sat, 10 Mar 2018 03:13:05 -0500 Original-Received: from smtp97.ord1d.emailsrvr.com ([184.106.54.97]:56126) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1euZcj-0003mN-T8 for emacs-devel@gnu.org; Sat, 10 Mar 2018 03:13:01 -0500 Original-Received: from smtp13.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 22993C007E for ; Sat, 10 Mar 2018 03:13:01 -0500 (EST) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp13.relay.ord1d.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id E19E9C0066 for ; Sat, 10 Mar 2018 03:13:00 -0500 (EST) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 (76-218-37-33.lightspeed.kscymo.sbcglobal.net [76.218.37.33]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Sat, 10 Mar 2018 03:13:01 -0500 In-Reply-To: <83y3j1usn8.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Mar 2018 18:21:15 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 184.106.54.97 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223573 Archived-At: Eli Zaretskii writes: >> From: Cl=C3=A9ment Pit-Claudel >> Date: Fri, 9 Mar 2018 11:05:13 -0500 >>=20 >> On 2018-03-09 03:34, Eli Zaretskii wrote: >> > Do people think adding a per-buffer space-width variable would be a >> > good step in this direction? It should be easy to add, I think. >>=20 >> It does sound convenient. Will it apply only to leading whitespace, >> or also to inter-word whitespace? > > I'd say it should apply everywhere. It would be confusing to have SPC > take a different number of pixels depending on where it is. Right. Unless we need something else to fix the intra-line align function - ie align '=3D>' in=20 Trace =3D> Verbosity > 1, Put_Parse_Table =3D> Verbosity > 0, Ignore_Unused_Tokens =3D> Verbosity > 1, Ignore_Unknown_Conflicts =3D> Verbosity > 1); It seems to me that implementing this in a variable width font requires some sort of align-region-local tab setting, which is a change to current align algorithms (which just insert spaces). I use this feature extensively in Ada code, so I would not switch to variable width font without it. One step in align.el `align-areas' computes an `align-column'. In variable-pitch-mode, we could convert that into a tab setting by computing the pixel column of that character column in the line with the least whitespace/longest text ("Ignore_Unknown_Conflicts =3D>" above). I could try doing this. What is the best approach to implementing an align-region-local tab setting? --=20 -- Stephe