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: Tue, 6 Mar 2018 15:11:29 -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> <8b94336f-1bb4-84ab-263b-af5ba40bfca4@cs.ucla.edu> <673d6612-f0d4-5d34-c6ee-a276dbba3068@cs.ucla.edu> <087fdedd-a7c5-f7f6-f3a5-b1700fb6e516@gmail.com> <834lltrwja.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 1520367142 22102 195.159.176.226 (6 Mar 2018 20:12:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 20:12:22 +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 Tue Mar 06 21:12:18 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 1etIwB-00024M-E6 for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 21:11:51 +0100 Original-Received: from localhost ([::1]:57905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etIyE-0002eP-5s for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 15:13:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etIvw-0000zn-EU for emacs-devel@gnu.org; Tue, 06 Mar 2018 15:11:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etIvt-0004YE-9g for emacs-devel@gnu.org; Tue, 06 Mar 2018 15:11:36 -0500 Original-Received: from mail-it0-x22c.google.com ([2607:f8b0:4001:c0b::22c]:53120) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1etIvt-0004Xz-4Y; Tue, 06 Mar 2018 15:11:33 -0500 Original-Received: by mail-it0-x22c.google.com with SMTP id k135so406607ite.2; Tue, 06 Mar 2018 12:11:33 -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=4QEhOiyHgIELmHQi1Boj2RgJCfb2/iQg6B3Y4E8q2cY=; b=KY3v3Atei5HRajthGPHAqxRVXDQbg3qjvCLJoFeSKaMrttsjZr54canzNqbsEksLZq XYbT5yWCsyl89/CsjZaoDqENEY68YMvbIVzPgNoUuxrRu54c9DXCyiKgmSQ4g3rU9vbG s/pvicRpj+ZKsA4JrZ3mJq83jeVYMG+X/HLn0PsVsfqSNLxl6vvg17SewxkKiPLuxVTp SxdkjIzUgbCOCrYdltVIEBxbDWtuIR2FAlPNO4p84KlLc6hmfWU1EsohtUFuRYSqTXAc QibDjWusCEHGoEiKLgyxL5AZUw9paU0Bft5/ruguMx6ZKhoxzQLgoZB3TwXP6K2G6he5 bgyA== 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=4QEhOiyHgIELmHQi1Boj2RgJCfb2/iQg6B3Y4E8q2cY=; b=L8m1C+ivRJVcxL5W/oN1SqWeHCzXfb/Cgm0T78ht+1Ie5+2gvLRXo58nBvmbxIfpul tZSB44VJD5VixBiTiAYnjVI18BOSODvnPNwlAzDpQbW1uJB67woQhexSPlzdLrqMibRn QkdQoVB7VAo854ogJ24uvI6RJFPbLyhE4FQX47hEIDX29W/mEi29VKwB5CFrrq3UFT/5 JiwIbKlaZiUx95xqHRZaj9W268+E+pwr9a9QoeZrkKOOBdfjzqoI/Q43zbSfGlJHrzEW e0bFDGFHQm5ihQY/vb2k+kvwUWMRPxJF91nHlWgIhbwPxUulIdxyMja4lbP6R8ezORoe qCNg== X-Gm-Message-State: AElRT7HCRYP2BQK1E+rxLS6Jxu0usviNPSlP1eANwRM3RP7HrpCeDt6+ Jn9WV/pvlwepcneQYkl9AhYpBJfg X-Google-Smtp-Source: AG47ELvnWB5ceQbYFXzB0S2Ru+HHPTgjWJLCf8GKVmoHOc42w+bFBj2AUQegryM7CsM1IgqiOR13DA== X-Received: by 10.36.70.72 with SMTP id j69mr7319766itb.32.1520367092353; Tue, 06 Mar 2018 12:11:32 -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 o187sm10221131iof.66.2018.03.06.12.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 12:11:31 -0800 (PST) In-Reply-To: <834lltrwja.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:c0b::22c 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:223365 Archived-At: On 2018-03-06 11:36, Eli Zaretskii wrote: >> From: Clément Pit-Claudel Date: Mon, 5 Mar >> 2018 20:40:14 -0500 >> >> The following code gives a preview of what the algorithm that we've >> been discussing produces: > > Thanks, but I still don't see why we couldn't simply "adjust" the > width of white space using the 'space' display property. Because "I'm not aware of a way to get a specified space whose width equals that of a particular string, without measuring the string beforehand. Is there a way?" :) IOW, I'm all for it, but I don't know how. > Your implementation has a few issues. First, if you move the cursor > vertically at column zero, do you see "ghost" characters displayed > at cursor position? Hiding characters by displaying them with > foreground color identical to the background color has its limits > ;-) That's a feature :) (Just to be clear: that was the easy way to get a feel for what the algorithm that Paul and I were discussing would produce; I'd have used space properties if I had known a way to get a space of the same with as these ghost characters). And there are many other issues, of course: we don't want to apply the display property to more than one stretch of space, and the code doesn't deal properly with tabs vs spaces, etc. > Also, with this implementation, the braces in the 'if' and 'else' > blocks no longer align. E.g., try to indent this snippet: > > foo () { if (something) { do (anything); } else { do > (something-else); } } > > I think this misalignment will be annoying. Indeed, this was discussed in this thread; Paul thinks it's not an issue; I'm not convinced (I tend to agree with you) :) >> I do agree that it doesn't look too bad, and presumably a C >> implementation of the algorithm above would be very fast, since it >> could build the "spine" above during redisplay. > > Indenting during redisplay is a bad idea, because it will disable > almost every redisplay optimization. I think we're using "indenting" to mean different things. (Just to be clear: the process I'm describing doesn't call indent-line-function, nor any of the indentation machinery) > I actually don't understand why you worry about performance: the > function you wrote is the morel equivalent of C-\ C-\ is toggle-input-method on my machine; is that what you meant? > , and that one is not fast with the current implementation. We never > modify indentation of non-current lines anyway, we expect the user to > type TAB or some electric character to reindent a line, and we expect > them to use C-\ to reindent more than one line. Automatic adjustment > of indentation might be a good feature, but it would be a separate > feature. I never meant to adjust indentation (that is, to change the contents of the buffer): just to display existing leading spaces differently based on the contents of previous line. > In any case, I'd suggest to reindent via buffer-modification hooks, > not as part of redisplay. Right, and that's why I worry about performance. Clément.