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: Wed, 7 Mar 2018 08:15:39 -0500 Message-ID: <420d531c-5d0f-8576-cc69-08d6232dae03@gmail.com> 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> <83ina9q6nq.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 1520428438 25024 195.159.176.226 (7 Mar 2018 13:13:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Mar 2018 13:13:58 +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 Wed Mar 07 14:13:53 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 1etYt7-0004wB-Cy for ged-emacs-devel@m.gmane.org; Wed, 07 Mar 2018 14:13:45 +0100 Original-Received: from localhost ([::1]:33415 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etYvA-0004Kw-3r for ged-emacs-devel@m.gmane.org; Wed, 07 Mar 2018 08:15:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etYv1-0004Kf-T7 for emacs-devel@gnu.org; Wed, 07 Mar 2018 08:15:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etYv0-0000Lc-Ne for emacs-devel@gnu.org; Wed, 07 Mar 2018 08:15:43 -0500 Original-Received: from mail-qt0-x236.google.com ([2607:f8b0:400d:c0d::236]:43851) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1etYv0-0000LT-J0; Wed, 07 Mar 2018 08:15:42 -0500 Original-Received: by mail-qt0-x236.google.com with SMTP id d26so2506531qtk.10; Wed, 07 Mar 2018 05:15:42 -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=isNL0Ov8tm5y1ze0CXOpYjw0DY3eHpD7U0E+Xhv7UvM=; b=VlM7RbsOsD95SxciExu/Q+2Q6I1hMYIMDmWobGlohXZz6uKNRbh6y6kWBGHLpr+JoK NfpQF8ErbIC8jg/pFDjAw6e2a2XZFCbTcp9JEDOg906sWKadfXzc65Vitg+AtgHrNX56 PzoT22i2HuuBaJGK4bIwUal8Jim4Np2yPw1miJSS2n2kBTHcf2ATEwXsA35N8Hi5+ZDZ Li58xgMpgTifaVeC24qdEuXGfyYx7jiuKDQ/JeyBhA8Xj2JZV/Y7V1Co/il4TbFGZbbN uFRkbqvxFBlMJf1cMNSAdYu3SHczyn0Vjq0A2URwPQY2dvBPbc239HnAsaT57v1EXWsK oLYQ== 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=isNL0Ov8tm5y1ze0CXOpYjw0DY3eHpD7U0E+Xhv7UvM=; b=eISZroQcE0r47hTx6mFqlb3PhyE4E5+h4R0GtKFRy436IvSutH2rp5EHgLNAnSkcbU FWki/np9pfayI1+bJ+7ozmetVmTegq0xwAFjuic/6EvK+hTVI0xGswGHHe5+HAxBMapQ Mt9BLGTCMq3nO7nkNLrji4hzLYN3HhqAhM2dn9Sp8KxYLZT1bD/nEeXFJa5kNlgpqI6V H+KlIL4fow2kkOlsZ8mvR/SExZAkcLoolPt8xE9Nn3fq4ebY96bzNoR8auzaoUgewk9P ekL536julC7CmK8kLGGupGQOscHvWANKiMlXc2znlim8tW2sBE7Ybg6OtOsNmtmO/6e2 BtDA== X-Gm-Message-State: AElRT7FnmPgaMgYkl3Xa9uwtaxyyIaz7Xkr70baLkOxRbfAf30LMdw5b HuuUEbC6Md7xVQtc530AxroEQFWf X-Google-Smtp-Source: AG47ELsUq+G+w2NnR/NP1Enhh8pcfeSCwrMfWkn8AdKDdlXSxQKdV3wJr4GVw86TBszWuvRmQ6whvA== X-Received: by 10.200.97.74 with SMTP id d10mr34115266qtm.16.1520428541887; Wed, 07 Mar 2018 05:15:41 -0800 (PST) Original-Received: from ?IPv6:2601:184:4180:66e7:a5fa:8a0b:647e:f011? ([2601:184:4180:66e7:a5fa:8a0b:647e:f011]) by smtp.gmail.com with ESMTPSA id l10sm12575328qta.60.2018.03.07.05.15.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 05:15:41 -0800 (PST) In-Reply-To: <83ina9q6nq.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:400d:c0d::236 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:223406 Archived-At: On 2018-03-06 15:40, Eli Zaretskii wrote: >> 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. Yes and no: it might be offscreen. But posn-at-point is a useful suggestion, thanks :) > 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 don't think I need that part. >> 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. Thanks, I'll look into this. >> 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. That code was just a rough draft, so it's plenty of corner cases that I didn't think about yet. That's all :) >>>> 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 meant build a prefix string (which the code I sent called the "spine") to use instead of leading spaces. The ghost characters that you noticed are the value of the spine on that line. >>> 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. Ah, yes, I see. That's not what the code I offered does at all, I think. >>> , 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. Wait, never do what? >>> 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. The feature I'm offering is like font-locking, not like reindenting: it changes the display of existing buffer elements in a way that doesn't modify the underlying text. Given this, it makes more sense to me to run it automatically (rather than on demand) Clément.