From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Variable-width font indentation Date: Thu, 08 Mar 2018 21:07:05 +0200 Message-ID: <83sh9ao086.fsf@gnu.org> References: <87inaiss6l.fsf@web.de> <6FCF6ACA-4F29-4B6B-BE9D-D7130C6E9495@gnu.org> <87fu5moe4c.fsf@web.de> <877eqyocro.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> <83lgf3przh.fsf@gnu.org> <42d0c18b-8d14-bfe2-8f09-112787e8b0b4@gmail.com> <83zi3io9tr.fsf@gnu.org> <859ec725-acc3-22e4-ca26-28108c3e5e26@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1520536543 26899 195.159.176.226 (8 Mar 2018 19:15:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2018 19:15:43 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 08 20:15:39 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 1eu10t-0006uN-8E for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 20:15:39 +0100 Original-Received: from localhost ([::1]:41124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eu12w-0003BD-2K for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 14:17:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eu0sm-0003li-1A for emacs-devel@gnu.org; Thu, 08 Mar 2018 14:07:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eu0sl-0004B7-1l for emacs-devel@gnu.org; Thu, 08 Mar 2018 14:07:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eu0sg-00049E-6E; Thu, 08 Mar 2018 14:07:10 -0500 Original-Received: from [176.228.60.248] (port=4049 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eu0sf-00035y-MZ; Thu, 08 Mar 2018 14:07:10 -0500 In-reply-to: <859ec725-acc3-22e4-ca26-28108c3e5e26@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Thu, 8 Mar 2018 11:30:51 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:223511 Archived-At: > Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu > From: Clément Pit-Claudel > Date: Thu, 8 Mar 2018 11:30:51 -0500 > > > Not necessarily display properties, maybe some (most? all?) of the > > effect could be achieved by modifying the display width of a space and > > a tab according to some buffer-local variable, by the display code > > itself, similarly to how we render tab characters now. > > Hmm, interesting. How would that work? For example, if I have these two snippets: > > i = (y + > z) > > w = (y + > z) > > with monospace fonts 'i' and 'w' have the same width, but with variable-pitch fonts they don't and if you assign a constant width to each space the 'y' and 'z' will line up in at most one of the two examples, right? Maybe we could find a middle ground, whereby each one of the examples will approximately align. If that can be done, and the result is acceptable, then the problem of recording the text properties in the file and/or reindenting when the file is revisited goes away. > >>>> * What happens in major modes that don't provide indentation support? > >>> > >>> The same as what happens today: the default functions are invoked. > >> > >> I don't understand this part. Concretely, what will the snippet above look like if it's shown in a prog-mode buffer, in a variable-pitch font? Will the indentation just be off? > > > > When a major mode doesn't provide an indentation function, indent.el > > uses the default function, so I'm not sure what problem you see here. > > I don't know what the default function is, or how it could help us determine proper alignment :/ Looking in indent.el, my reading of the code is that the default function is indent-rigidly. > I've been using the following for that purpose for a long time: > > (font-lock-add-keywords nil `(("^[[:space:]]+" 0 '(face fixed-pitch) append)) 'append) Is it really needed? With most font back-ends, a tab is displayed as a stretch glyph whose width is an integral multiple of the width of the space glyph for the same font. So they should align even without the fixed-pitch font trick. > >>> Not necessarily, not if the idea of controlling the SPC width is > >>> workable. If it is, then the mode will simply set the value of two > >>> buffer-local variables, calculating them from the font in use. > >> > >> That I don't understand. Which two values are you thinking of? > > > > tab-width and (the hypothetical) space-width. Actually, only the > > latter, since tab-width must be its integral multiple. > > OK, I see. This won't help with cases like the following, right? > > int main(int argv, > char** argc) It might get reasonably close, though. Maybe this will be good enough. > OK. I think I follow you at this point, although now I'm not sure anymore what role indentation functions will play. A few emails ago you mentioned teaching indentation functions about variable-pitch, but the solution you're offering now doesn't seem to require that anymore, does it? That's more relevant for text-derived modes, where indentation levels are rigid and not determined by previous lines. There we could do a better job, I hope.