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 15:32:53 -0500 Message-ID: <42d0c18b-8d14-bfe2-8f09-112787e8b0b4@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> <838tb5rxoe.fsf@gnu.org> <83lgf5q73p.fsf@gnu.org> <4742f0ae-86b5-48f9-4601-4dbba9e6380d@gmail.com> <83bmfzreaq.fsf@gnu.org> <83lgf3przh.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 1520454710 18309 195.159.176.226 (7 Mar 2018 20:31:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Mar 2018 20:31:50 +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 21:31:46 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 1etfis-0002z0-G2 for ged-emacs-devel@m.gmane.org; Wed, 07 Mar 2018 21:31:38 +0100 Original-Received: from localhost ([::1]:35486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etfkt-0005VU-9z for ged-emacs-devel@m.gmane.org; Wed, 07 Mar 2018 15:33:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etfkD-0005TM-3B for emacs-devel@gnu.org; Wed, 07 Mar 2018 15:33:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etfk8-0007jD-Ck for emacs-devel@gnu.org; Wed, 07 Mar 2018 15:33:01 -0500 Original-Received: from mail-io0-x22b.google.com ([2607:f8b0:4001:c06::22b]:33626) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1etfk8-0007iR-7Q; Wed, 07 Mar 2018 15:32:56 -0500 Original-Received: by mail-io0-x22b.google.com with SMTP id f1so4521247iob.0; Wed, 07 Mar 2018 12:32:56 -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=zv2Qd4XFyvxB/L3pfzC5YcY46tSC71+MqqdVqU18+0Q=; b=MwEoftGIgBuoYRbkOVlWI8ePAZdhOv/+DtV3Z4ARheMfzt9UlIqBk4ttSl/T02NxDj bXUIaKjiuKB1y4omY/pneaRr2+TOQ5HjxwlI+bIzgY8X7zh8Onift3flVXN8PrV0nSlI rrKdGsrc5OSQivOFcemH/LXw+5aLpVvTTETGc/zBDBKNAjf9bGMVTc2phYo3Tstl8OOs Nkxhwh0F8O4IQF4FUQL4Zi3VRMaO+zMOQgrSyxBw5rjLObUJ9jdcwy0hlbzpMwYr5i40 aqa9dzogvPnignfwXVdKLF+NWpPYHQA5UuYxdVL7E6MAzQMkqEAboZUAxf2ovcb/Bipo lDaA== 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=zv2Qd4XFyvxB/L3pfzC5YcY46tSC71+MqqdVqU18+0Q=; b=NryWVcfEn8rU3NcxorYf4UHos5RBxb22klwKllwi3d5R85ooVhoO3g8XtfmPAY24MQ M95A6joFCbWaWe98zv44uiX/X/gwpCjURgFZBBzqtlGvFr8Iw3QYDx/JNLL32dwnt0Jf r8aZz6C/W8Uv8QY97ua/VfUt2UYKyJi74Swp6HhydkvvjDns2XXqs6uH7O3WbyDSYFtV RaUcfIW79M8BV6rD61UFqwiptDxG7cExleV7xx3GNPlvvFMm5s0XxpatkHuRmbSqPHIm nOI9hzoE7pNCcFUn/KsZMRpaI59pKWWIDvoshczS+dRQ6Vb5t0jwGlIx5F7YFBYuCTA0 NHDQ== X-Gm-Message-State: APf1xPBcSk+n/+b25yuVYEl9xsbZZhfkl29dYJDXnHITLPtnUSSdOEl/ 7eqXqkIFPTzH69/yI6SJ4cw= X-Google-Smtp-Source: AG47ELvP8QQnjs3VlzAQ4zg9+q3WaJPTsNt25k5JoYw5gxfbSmnKg6usGhWKawYHpfJmDfsFF+WgCg== X-Received: by 10.107.132.18 with SMTP id g18mr28110968iod.46.1520454775531; Wed, 07 Mar 2018 12:32:55 -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 f69sm13097812iod.2.2018.03.07.12.32.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 12:32:54 -0800 (PST) In-Reply-To: <83lgf3przh.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::22b 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:223429 Archived-At: On 2018-03-07 15:09, Eli Zaretskii wrote: >> Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu >> From: Clément Pit-Claudel >> Date: Wed, 7 Mar 2018 13:27:35 -0500 >> >>> Not AFAIU, no. It is an implementation of a different indentation >>> method. I don't see why we should want to go that way, since there's >>> nothing wrong with the existing algorithm, except for handling of >>> variable-pitch fonts. >> >> Can you clarify what you call an indentation method? I think that's the source of my confusion. >> I wouldn't call what I wrote an indentation method. Maybe I'm not understanding you because of that? > > I feel that we are somehow bogged down in a miscommunication from > which I see no way out... I think we're making progress, actually :) At least, I'm understanding things better. > An "indentation method" is a method used to determine the indentation > of a line and to insert whitespace in order to achieve that > indentation. Understood. Then what I'm offering isn't an indentation method: it doesn't insert whitespace. But what I'm offering is indeed an imperfect heuristic to determine the indentation of a line. >> But changing tab-width doesn't change the contents of the buffer, whereas what you're advocating for does, right? > > No, it doesn't. I'm advocating a way of changing the width of > whitespace characters on display to account for variable-pitch font, > not any change in the buffer. OK, understood. So for example if I have this snippet: 01234567 -------- 0 |x = (y + 1 | z) …then on line 1 the indentation function would put display properties on each of the 5 spaces leading to `z` to align it with the `y`. Correct? That's also what I do, only I compute the width of the spaces without calling the indentation function. >> If it is correct, then it solves a problem that's different from the one I was thinking in, which is to display existing code with a variable pitch font, without the indentation function. > > We cannot possibly DTRT with indentation without an indentation > function. Well, no, we can't DTRT every time without an indentation function. But we can do fairly good, or at least it looks like that to me given the snippet I posted earlier. (But note that I said the same thing at first, responding to Paul that his technique couldn't work.) >> * What happens in major modes that don't provide indentation support? > > The same as what happens today: the default functions are invoked. I don't understand this part. Concretely, what will the snippet above look like if it's shown in a prog-mode buffer, in a variable-pitch font? Will the indentation just be off? >> * What happens in indentation-sensitive languages (Python, F#, Haskell, etc)? > > Same as today (the buffer contents will not change from what it is > today). I meant to ask what the code would look like, not what the buffer contents would change to. >> * What happens in comments? > > Nothing special. Same question: what do the contents look like (what text properties do you apply on leading spaces in comments?) For example, if I have this in a C buffer: /* FIXME: - long text here - more text */ what will this look like in variable-pitch mode? >> * Do I need to call M-x indent-region every time I switch between variable-pitch and fixed-pitch? > > Not necessarily, not if the idea of controlling the SPC width is > workable. If it is, then the mode will simply set the value of two > buffer-local variables, calculating them from the font in use. That I don't understand. Which two values are you thinking of? As another concrete example, consider this snippet: (do-stuff a b c) won't you need to recompute the width of each leading space every time you change fonts? >> * If I close and reopen a file in variable-pitch mode, do I need to re-run M-x indent-region? I don't understand this part either: ow will you determine how to scale each space without calling the indentation function? >> * In variable-pitch mode, what gets saved to disk after I run M-x indent-region? > > Same as what we have now. OK.