From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.help Subject: Re: Using :align-to with non-spaces Date: Tue, 10 Oct 2017 18:41:35 -0600 Message-ID: <871smacy80.fsf@gmail.com> References: <87zi90yjws.fsf@gmail.com> <83fuarqzd9.fsf@gnu.org> <87mv4ydgcu.fsf@gmail.com> <83lgkiq2nu.fsf@gnu.org> <87fuaqdd6n.fsf@gmail.com> <83bmlepya4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1507682538 8521 195.159.176.226 (11 Oct 2017 00:42:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Oct 2017 00:42:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Oct 11 02:42:13 2017 Return-path: Envelope-to: geh-help-gnu-emacs@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 1e2568-0000ud-CE for geh-help-gnu-emacs@m.gmane.org; Wed, 11 Oct 2017 02:42:08 +0200 Original-Received: from localhost ([::1]:37986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e256F-0002Rz-Og for geh-help-gnu-emacs@m.gmane.org; Tue, 10 Oct 2017 20:42:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e255n-0002Rc-UZ for help-gnu-emacs@gnu.org; Tue, 10 Oct 2017 20:41:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e255j-0003KZ-Kp for help-gnu-emacs@gnu.org; Tue, 10 Oct 2017 20:41:47 -0400 Original-Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]:51509) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e255j-0003K1-G9; Tue, 10 Oct 2017 20:41:43 -0400 Original-Received: by mail-it0-x22d.google.com with SMTP id o135so854669itb.0; Tue, 10 Oct 2017 17:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=f7x+N6x+9kk4mygTOfuMVAttzpaHQvl+5AkvH9Q0XQU=; b=nRxiFmZOwMImYzQBkI8MzfByaTei5cSdZOdw90304iZ6fmIfwg0Ed31rTrbm1jMGr6 aSzde3Um6ppNT6z/GxKkiOoUKtCk6B7aMsRblnkM7z5mx9Kyn1W7PaiNkIVKUW8JOxwE 2WH9GlVFfab5w1O4Oqr9GrWYMcIBtWWSiRNIzKtXA/eiM91C+PRKrxYEovMYaM2ElIuQ wuphYUiREaD0wfL8HIJ2BVANLC/yiOwMiATdRmnFV5wZhDzXbmzxcOau9RNAPJkvwvzI BXKnVqHdy7EcIO+wr2y+k6vvnRXO6rMpz+mGos7lX8gm0xKW3QITv/gdqad+5DG5egcG 1G/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=f7x+N6x+9kk4mygTOfuMVAttzpaHQvl+5AkvH9Q0XQU=; b=ox42twPhSqgHRWrwE3fCLZjyMkiL7URy5vgh25ss4FbhVWFjxdXm5La5VsEBFaenvX rFwQ/pjH2qZrtVNwHNKcVpSsbhriXp7PJuibRNVfoAy+qQTcv2FirVuW+KZ5W9OVI2OU C7bTr7BAzbjNTMZFu0tvMICSXJ8O5O+RS/CCJiu0ZmB28AlkGdomP3bbqW1WvTJiufrq 2zdpFmxwJPD4P5npgOGXFRSQi9+3AKMwkKnNgMCLbJrigVP7uEJlB3hALESLVMnJqQTD ICUYtDleffN6ThlDjDC7GyxBW6Y2x8WIWi2swGUOfUWEmyYKDPPtcOIxkekTEaG5ARHN CIZw== X-Gm-Message-State: AMCzsaU4xZRfJEAOwB0eW6OtTb8I8QzqKJQjB+9Yd3WM2PE8vXFqNtDs I5gW+YoY/bKZIGKwEqZ7FkVIdw== X-Google-Smtp-Source: AOwi7QDKXgJNUJ/6GXYf+prUAuEVKrhaqcMcdcf8sYGwNtDbEOG+2dj3mGm54MAucjCwGowDYjj4SQ== X-Received: by 10.36.177.9 with SMTP id o9mr21475640itf.44.1507682500898; Tue, 10 Oct 2017 17:41:40 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id s5sm5247615its.1.2017.10.10.17.41.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 10 Oct 2017 17:41:39 -0700 (PDT) In-Reply-To: <83bmlepya4.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Oct 2017 23:01:55 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22d X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:114546 Archived-At: Eli Zaretskii writes: >> Right, I misspoke. What would be nice is to have the above 'align-to >> display property prepend a stretch space that ends at an :align-to >> expression. > > Then the stretch would have no buffer/string position on it, and the > code which processes glyphs would become more complex. IMO, the gain > is too small to justify the complexity. Sure, it's not worth it if the solution is complex. >> I would consider it not recognizing {line,wrap}-prefix to be a bug as >> well (either in behaviour or documentation). > > Everything in the text area counts: images, stretches, line numbers, > etc. This was always so, since Emacs 21. Hmm, then I think that "(elisp) Pixel Specification" should include more elements to account for these. >> > The "text area" is everything inside the fringes/display margins >> > (whichever comes last), so it includes the space used for the >> > line-number display. >> >> >From a user perspective, I don't think the prefix/line-numbers should be >> considered as part of the text area. At the very least, not the >> line-numbers. > > That's your linum-mode experience talking ;-) It takes time to get > used to a different view of this. I suppose so. Still, I think that if it's not considered as part of the "text area", then there should be some notion of `text area modulo prefix/line-numbers' that :align-to/:width (and other parts of display, perhaps) could use. Then, I believe the default offset in "(elisp) Pixel Specification" should be changed to the start of this construct (i.e., column 0). I believe it would be a more user-friendly default. >> > The solution I can suggest is to use the value returned by >> > line-number-display-width. >> >> Right, but shouldn't it be recomputed at the same times that the other >> element's widths are (i.e., toggling display-line-numbers should >> automatically change the display width of relevant :align-to/:width >> spaces)? > > We discussed that briefly on emacs-devel, and decided not to, mainly > due to the line/wrap-prefix precedent. I still don't see any reason > to revise that decision, the few problems that are caused for that > were solved relatively easily. What do you mean by "that"? I don't recall a discussion on this; the closest I could find was: https://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00525.html I think we misunderstand each other here (see below). >> So even if `left' doesn't mean column 0 (I find this poor behaviour, >> though), then one can use `(:align-to (+ left prefix)' or something of >> the sort to always mean column 0, even if there are >> prefixes/line-numbers displayed. > > I think you underestimate the number of different "things" that could > precede the leftmost text character. We have so many display features > that can put stuff to the left of the leftmost character that we will > have hard time deciding what should and shouldn't be considered > 'prefix'. It is easier to write a function that computes their > summary width, if that's what you need. Wouldn't anything between the left fringe and column 0 be considered "prefix"? Any "thing" that is in this area and applies to all lines should be accounted for in "(elisp) Pixel Specification", IMO. > More generally, doing layout in Lisp (which is what I think you are > trying) isn't easy, and was never supposed to be. It is better to > extend the display engine to do layout for you, if that makes sense. There appears to be some miscommunication here; I thought I was arguing to extend the display engine (i.e., adding new values for `space' display specifications).