From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Variable-width font indentation Date: Thu, 8 Mar 2018 14:55:20 -0500 Message-ID: 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> <83sh9ao086.fsf@gnu.org> 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 1520538882 30178 195.159.176.226 (8 Mar 2018 19:54:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2018 19:54:42 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 08 20:54:37 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 1eu1cb-0007ki-2j for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 20:54:37 +0100 Original-Received: from localhost ([::1]:41521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eu1eb-0001nr-Uh for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 14:56:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eu1dR-000122-NQ for emacs-devel@gnu.org; Thu, 08 Mar 2018 14:55:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eu1dN-0004UP-3p for emacs-devel@gnu.org; Thu, 08 Mar 2018 14:55:29 -0500 Original-Received: from mail-io0-x232.google.com ([2607:f8b0:4001:c06::232]:38643) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eu1dM-0004Ty-Q1; Thu, 08 Mar 2018 14:55:24 -0500 Original-Received: by mail-io0-x232.google.com with SMTP id g21so988973ioj.5; Thu, 08 Mar 2018 11:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YSLyT/XgteUGtqHwiUh0eDoVtJ/3u6vyFoaMBP3+AsM=; b=AFfFBEXPI6AZZ6o9eX9vb8lfA5OGAygnwKOomruzE9Z3CUFANlAyMtHuf87LJNUXhQ gXxFpYNU/LhgHf7KLdNCjUWnKYPOVMQmsXAvFFaX4hkzg4hO6KtggEtnAR4zCVHeJDLg wTok/Neby6VFKei4gpl5PVDcMQ7O/0mTet5LUqnPHBCbR0QGesXQ8OHazN1MfIpOs6Pk kNgwi1hbi+8Nxf/arS39NLHdBJ4xS/sPNm0KqW+3MX6Or0yquxHqU/LL9HUX/i+HG0q0 AJdln7cn/R0A21pZ0OyCP/N2mu14E3abB73dvfDzGmqUX6dNPFCksomV5pJPArhEQcsu thuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YSLyT/XgteUGtqHwiUh0eDoVtJ/3u6vyFoaMBP3+AsM=; b=tvaDoX1Cexqnj2S8AITX57QjYFlDQ2a4EZzwi1l3D4DvFioRvW15NupPt+jeV1MgyR jRtGco4NunFk3Vqp8WVkbx5mfmhKwMtifDgd5hw0svhpgqo1l5no7rLkfEJtRMHPJqgx 7FMLostT5nllU1Y/4LspGwSOyQ35+jNaQFHF9fYIgWbtpnmRXeepdqOzKti6g/qwee8C tLnD5XMqgtiQ5+4NWkAA5GBwvTniYj+3Vuy0PDqJ9cig3XSl2ZygVeXB6uKn84F2E46H BTyKS/hE4KxnrKEt8c9XvrlEDoy8DHz5hI5hUhd2m/1nBZbAxMmhC6ayUpPOub2szVfG EzxA== X-Gm-Message-State: APf1xPDahSQ67M4500AU330/h4mPerATN+NeGflLkJT2cr7BrKoopboD 42cbdnLZt6nnOUdNBdmyJFVLYcAc X-Google-Smtp-Source: AG47ELuShyQUWAyE5o3mkOyUYl5GOpRZpmykIhDtjrENZ5kSDda0VvE4eVD1Q12i5wDz4kzx0WQScA== X-Received: by 10.107.158.12 with SMTP id h12mr32294397ioe.54.1520538923892; Thu, 08 Mar 2018 11:55:23 -0800 (PST) Original-Received: from [18.26.2.123] (26-2-123.dynamic.csail.mit.edu. [18.26.2.123]) by smtp.gmail.com with ESMTPSA id j2sm14064491iob.43.2018.03.08.11.55.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 11:55:23 -0800 (PST) In-Reply-To: <83sh9ao086.fsf@gnu.org> Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::232 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:223512 Archived-At: On 2018-03-08 14:07, Eli Zaretskii wrote: >> 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. Maybe :) I don't know how good it would look, in practice, but it's easy to experiment. Paul's algorithm is not too bad in that sense: these two examples align pixel-perfectly. >> 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. Hmm, indeed. So which problems did you have in mind when you said the following? > But leading whitespace will certainly be aligned, something that is > not universally true today. >> 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 >> 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. OK. I tend to think of indentation even in text modes as being somewhat previous-lines dependent (wrapped paragraphs align relative to bullet points, for example), but I agree that it isn't as much as in programming modes.