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 22:40:41 +0200 Message-ID: <83ina9q6nq.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> <834lltrwja.fsf@gnu.org> 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 1520369893 21118 195.159.176.226 (6 Mar 2018 20:58:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 20:58:13 +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 21:58:09 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 1etJed-0002a5-4B for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 21:57:47 +0100 Original-Received: from localhost ([::1]:58140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etJgf-0000rf-Re for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 15:59:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etJOJ-0001kI-TH for emacs-devel@gnu.org; Tue, 06 Mar 2018 15:40:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etJOF-0001U9-7J for emacs-devel@gnu.org; Tue, 06 Mar 2018 15:40:55 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etJOF-0001Tz-3o; Tue, 06 Mar 2018 15:40:51 -0500 Original-Received: from [176.228.60.248] (port=2127 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1etJOE-0001E4-Gd; Tue, 06 Mar 2018 15:40:50 -0500 In-reply-to: (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Tue, 6 Mar 2018 15:11:29 -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:223375 Archived-At: > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Tue, 6 Mar 2018 15:11:29 -0500 > > > 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?" :) The "string" you refer to is already in the buffer on display, right? If so, you can simply use the likes of posn-at-point to measure portions of text in pixel units. Then translate that into floating-point "column" numbers by dividing by width of some suitable character (it could be SPC, but that is a bad idea with some fonts, so maybe something else, like 'e'). > I'd have used space properties if I had known a way to get a space of the same with as these ghost characters). See above. And there's font-get-glyphs. > 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. Please elaborate, because I don't understand those issues well enough to see if and how they can be resolved. > >> 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) Then what _do_ you mean by "building the spine during redisplay"? > > 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? Sorry, I meant M-C-\, of course. > > , 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. We never do that with the existing indentation machinery, either. > > 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. Then don't automatically reindent, let the user initiate that.