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: Thu, 8 Mar 2018 11:30:51 -0500 Message-ID: <859ec725-acc3-22e4-ca26-28108c3e5e26@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> <42d0c18b-8d14-bfe2-8f09-112787e8b0b4@gmail.com> <83zi3io9tr.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 1520526544 32447 195.159.176.226 (8 Mar 2018 16:29:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Mar 2018 16:29:04 +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 Thu Mar 08 17:29:00 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 1etyPc-0008KY-1w for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 17:29:00 +0100 Original-Received: from localhost ([::1]:40062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etyRe-000286-Tj for ged-emacs-devel@m.gmane.org; Thu, 08 Mar 2018 11:31:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etyRY-00027L-4Z for emacs-devel@gnu.org; Thu, 08 Mar 2018 11:31:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etyRR-0002yB-Uy for emacs-devel@gnu.org; Thu, 08 Mar 2018 11:31:00 -0500 Original-Received: from mail-io0-x22e.google.com ([2607:f8b0:4001:c06::22e]:42829) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1etyRR-0002xp-Ns; Thu, 08 Mar 2018 11:30:53 -0500 Original-Received: by mail-io0-x22e.google.com with SMTP id u84so279957iod.9; Thu, 08 Mar 2018 08:30:53 -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=PbhbikIPvMTwppVz2U67CdXR/z9K1X+CFWdrnruzrRU=; b=b7Zl9QC27Q88R04eez+Q442kGuqtcCg9QsrJCPIZDjyWzNxLIc72in7E/bRgPPZ2wx tK2Xrlhc8rEHKiC3JFQZvfvVp0F0HgCwTVXGwf9Ys6OeTbDf+GiQyKbZdKDOFGZ7vwLm 7rp/7O+//vB3m4eZmNLeoP9ix7KmNcEJA/ZFpb1qmjru4/cRhvBTYpuWtMIYsx1T8pp7 O5nmeQUFfm9Xs/Awhv/FEgvhMF7Nun5xpZ8sCxy8jnTfU16qs72dtWm8DbBhFqPVq9dR 9oKebnUU0MmLv9uD8fc6zbSpfwVD98uEBQUGeoj5cvrsCAfA7SDWkj97PUshNtVtCNH+ ljgw== 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=PbhbikIPvMTwppVz2U67CdXR/z9K1X+CFWdrnruzrRU=; b=D7YvsuoqYINpmQt3S+g+PMN9fipgK4kmE69C08PrHFZtUT8oUFGkYN5w37XOFIJdjh jz6HS92QpFUtwQ6sssAT7qiJTPHImlX/RwXBnro3tk6ZNr40baqkl7OpFCZjrsWw5B/1 E4NISN3Zg9LxFSTPSitavBPImGvgTxj4cDvyZ51KeFUs0WpGBs5GbyJb2Z8NsUQp4uW4 gkrfP/HVBJpRv3XQMoTb+FccTCpAKf2svI1QuXa5OurNjHdnUnqU/RaZaBmZPe433c2D kwxc3+MlpONts+tmD5B0p4qt5V/9mMvLLtX3QRkkWUc/nbSGfk0xAwzyPxWcl8QLoTkM Jumw== X-Gm-Message-State: AElRT7FeOCaMcWrNdQi9nqNQkUQ6UXeZqBmaySaD+6QW4juyQnFRUu4l E+qgEGDZm8N1g3Bfg5jJ8nM= X-Google-Smtp-Source: AG47ELuzUekEuD1j/X3JAGHh/UFPD3t04yqBQh738uQQV4gZ9Ttds9QDtmoZK2Grw7pUvj5DusLW5Q== X-Received: by 10.107.82.1 with SMTP id g1mr33291295iob.203.1520526652943; Thu, 08 Mar 2018 08:30:52 -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 x82sm14716093iod.23.2018.03.08.08.30.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 08:30:52 -0800 (PST) In-Reply-To: <83zi3io9tr.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::22e 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:223508 Archived-At: On 2018-03-08 10:39, Eli Zaretskii wrote: >> From: Clément Pit-Claudel 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? > > Not necessarily display properties, maybe some (most? all?) of the > effect could be achieved by modifying the display width of a space and > a tab according to some buffer-local variable, by the display code > itself, similarly to how we render tab characters now. Hmm, interesting. How would that work? For example, if I have these two snippets: i = (y + z) w = (y + z) with monospace fonts 'i' and 'w' have the same width, but with variable-pitch fonts they don't and if you assign a constant width to each space the 'y' and 'z' will line up in at most one of the two examples, right? >>>> * 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? > > When a major mode doesn't provide an indentation function, indent.el > uses the default function, so I'm not sure what problem you see here. I don't know what the default function is, or how it could help us determine proper alignment :/ I thought from earlier emails that you'd use existing indentation functions to determine proper indentation. >> 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? > > Hopefully, very similar, although we won't be able to guarantee > column-wise alignment for arbitrary text. But leading whitespace will > certainly be aligned, something that is not universally true today. Ah, that I understand :) I've been using the following for that purpose for a long time: (font-lock-add-keywords nil `(("^[[:space:]]+" 0 '(face fixed-pitch) append)) 'append) >>>> * 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? > > tab-width and (the hypothetical) space-width. Actually, only the > latter, since tab-width must be its integral multiple. OK, I see. This won't help with cases like the following, right? int main(int argv, char** argc) >> 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? > > Hopefully, no. At least not for approximate alignment. OK. I don't understand how that part works yet. The solution you propose doesn't get alignment right if I have the following ELisp code, right? (progn (wwwwwwww a b c) (iiiiiiii a b c)) >>>> * 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? > > Hopefully, by calculating some representative metrics of the font. OK. I think I follow you at this point, although now I'm not sure anymore what role indentation functions will play. A few emails ago you mentioned teaching indentation functions about variable-pitch, but the solution you're offering now doesn't seem to require that anymore, does it? Clément.