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 17:39:44 +0200 Message-ID: <83zi3io9tr.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> 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 1520523479 23263 195.159.176.226 (8 Mar 2018 15:37:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2018 15:37:59 +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 16:37:55 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 1etxcB-0005y4-85 for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 16:37:55 +0100 Original-Received: from localhost ([::1]:39769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etxeE-0008Ly-11 for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 10:40:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etxe7-0008Lj-SC for emacs-devel@gnu.org; Thu, 08 Mar 2018 10:39:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etxe6-0004bC-US for emacs-devel@gnu.org; Thu, 08 Mar 2018 10:39:55 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etxe1-0004ZF-UF; Thu, 08 Mar 2018 10:39:49 -0500 Original-Received: from [176.228.60.248] (port=3914 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1etxe1-0002D9-C3; Thu, 08 Mar 2018 10:39:49 -0500 In-reply-to: <42d0c18b-8d14-bfe2-8f09-112787e8b0b4@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Wed, 7 Mar 2018 15:32:53 -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:223505 Archived-At: > Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu > From: Clément Pit-Claudel > Date: Wed, 7 Mar 2018 15:32:53 -0500 > > >> But changing tab-width doesn't change the contents of the buffer, whereas what you're advocating for does, right? > > > > No, it doesn't. I'm advocating a way of changing the width of > > whitespace characters on display to account for variable-pitch font, > > not any change in the buffer. > > OK, understood. So for example if I have this snippet: > > 01234567 > -------- > 0 |x = (y + > 1 | z) > > …then on line 1 the indentation function would put display properties on each of the 5 spaces leading to `z` to align it with the `y`. Correct? 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. > >> * 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. > >> * What happens in indentation-sensitive languages (Python, F#, Haskell, etc)? > > > > Same as today (the buffer contents will not change from what it is > > today). > > I meant to ask what the code would look like, not what the buffer contents would change to. Hopefully, the buffer will look like users of those languages expect it to look. > >> * What happens in comments? > > > > Nothing special. > > Same question: what do the contents look like (what text properties do you apply on leading spaces in comments?) I hope we will be able to manage without display properties at all. > For example, if I have this in a C buffer: > > /* FIXME: > - long > text > here > - more text */ > > what will this look like in variable-pitch mode? Hopefully, very similar, although we won't be able to guarantee column-wise alignment for arbitrary text. But leading whitespace will certainly be aligned, something that is not universally true today. > >> * Do I need to call M-x indent-region every time I switch between variable-pitch and fixed-pitch? > > > > 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. > As another concrete example, consider this snippet: > > (do-stuff a > b > c) > > won't you need to recompute the width of each leading space every time you change fonts? Hopefully, no. At least not for approximate alignment. > >> * If I close and reopen a file in variable-pitch mode, do I need to re-run M-x indent-region? > > I don't understand this part either: ow will you determine how to scale each space without calling the indentation function? Hopefully, by calculating some representative metrics of the font.