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 11:30:53 -0600 Message-ID: <86d10bg7n6.fsf@stephe-leake.org> References: <87inaiss6l.fsf@web.de> <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> <86h8pofiwm.fsf_-_@stephe-leake.org> <83bmfwux4d.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1520702979 28827 195.159.176.226 (10 Mar 2018 17:29:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Mar 2018 17:29:39 +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 18:29:35 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 1euiJJ-0007NC-VW for ged-emacs-devel@m.gmane.org; Sat, 10 Mar 2018 18:29:34 +0100 Original-Received: from localhost ([::1]:51482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euiLK-0001Ge-Ty for ged-emacs-devel@m.gmane.org; Sat, 10 Mar 2018 12:31:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euiKh-0001GE-DM for emacs-devel@gnu.org; Sat, 10 Mar 2018 12:31:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euiKd-0002jM-Ei for emacs-devel@gnu.org; Sat, 10 Mar 2018 12:30:59 -0500 Original-Received: from smtp137.ord.emailsrvr.com ([173.203.6.137]:42173) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1euiKd-0002ir-0k for emacs-devel@gnu.org; Sat, 10 Mar 2018 12:30:55 -0500 Original-Received: from smtp26.relay.ord1a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 4985320110 for ; Sat, 10 Mar 2018 12:30:54 -0500 (EST) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp26.relay.ord1a.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 10BF1200D3 for ; Sat, 10 Mar 2018 12:30:53 -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:587 (trex/5.7.12); Sat, 10 Mar 2018 12:30:54 -0500 In-Reply-To: <83bmfwux4d.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Mar 2018 10:56:50 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 173.203.6.137 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:223586 Archived-At: Eli Zaretskii writes: >> From: Stephen Leake >> Date: Sat, 10 Mar 2018 02:12:57 -0600 >> >> Trace => Verbosity > 1, >> Put_Parse_Table => Verbosity > 0, >> Ignore_Unused_Tokens => Verbosity > 1, >> Ignore_Unknown_Conflicts => 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). > > Whatever we do to adapt indentation to variable-pitch fonts, we _must_ > still begin by inserting spaces so that the same text looks aligned > with fixed-pitch fonts. Otherwise, we will be unable to let other > people view our code/documents in other editors which use fixed-pitch > fonts, or even in Emacs with fixed-pitch fonts. > > The features that align text when variable-pitch fonts are in use must > work _on_top_ of the "basic" alignment that just uses spaces and tabs > as we do today. Right. >> 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 =>" above). >> >> I could try doing this. What is the best approach to implementing an >> align-region-local tab setting? > > Any local change in whitespace width would need to use 'display' text > properties, such as '(space :width (N))'. Ok; that doesn't need an explicit tab. > The problem with that is that you cannot easily record this when you > save the file, so these properties will have to be recomputed anew > each time the file is visited. Right. For example, that happens now in info files; formatting is applied to the links via text properties. > Which will take us down the path of font-lock and JIT lock, something > that I'd like to avoid. That's how align.el works now. We could modify it to only set the text properties if the fixed-width spaces are correct, or when in a read-only buffer, or in variable-pitch-mode. On the other hand, the ada-mode currently in GELPA computes indentation and faces from a parse of the source text. It works very well, as long as the source is syntactically correct. I'm working on implementing error recovery in the parser; it works fairly well at the moment, and I'm still improving it. It should be possible to compute alignments from the parse as well; that would elminate some of the minor bugs in current ada-mode alignment. That would still require a parse when visiting the file. > We could also record that in a separate file, but I'm not sure such > meta-data approach will be acceptable. Computing the align properties from the source has to be fast enough to be acceptable while editing (as align.el is now), so it will be acceptable on visiting. -- -- Stephe