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: Tue, 06 Mar 2018 18:36:25 +0200 Message-ID: <834lltrwja.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> <8b94336f-1bb4-84ab-263b-af5ba40bfca4@cs.ucla.edu> <673d6612-f0d4-5d34-c6ee-a276dbba3068@cs.ucla.edu> <087fdedd-a7c5-f7f6-f3a5-b1700fb6e516@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 1520354218 11282 195.159.176.226 (6 Mar 2018 16:36:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 16:36:58 +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 Tue Mar 06 17:36:54 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 1etFZt-0000CF-9y for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 17:36:37 +0100 Original-Received: from localhost ([::1]:56824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etFbv-0001EG-V0 for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 11:38:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etFZw-0000UW-Rb for emacs-devel@gnu.org; Tue, 06 Mar 2018 11:36:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etFZr-00040t-VG for emacs-devel@gnu.org; Tue, 06 Mar 2018 11:36:40 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etFZr-00040l-Rt; Tue, 06 Mar 2018 11:36:35 -0500 Original-Received: from [176.228.60.248] (port=1907 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1etFZr-0003bv-7m; Tue, 06 Mar 2018 11:36:35 -0500 In-reply-to: <087fdedd-a7c5-f7f6-f3a5-b1700fb6e516@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Mon, 5 Mar 2018 20:40:14 -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:223341 Archived-At: > 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. 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 ;-) 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. > 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 actually don't understand why you worry about performance: the function you wrote is the morel equivalent of C-\, 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. In any case, I'd suggest to reindent via buffer-modification hooks, not as part of redisplay.