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 12:09:53 -0600 Message-ID: <87mv4ydgcu.fsf@gmail.com> References: <87zi90yjws.fsf@gmail.com> <83fuarqzd9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1507659082 13393 195.159.176.226 (10 Oct 2017 18:11:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Oct 2017 18:11:22 +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 Tue Oct 10 20:11:17 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 1e1yzs-0002P6-3E for geh-help-gnu-emacs@m.gmane.org; Tue, 10 Oct 2017 20:11:16 +0200 Original-Received: from localhost ([::1]:36528 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1yzw-0005kA-8K for geh-help-gnu-emacs@m.gmane.org; Tue, 10 Oct 2017 14:11:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1yyg-0005Bb-7B for help-gnu-emacs@gnu.org; Tue, 10 Oct 2017 14:10:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1yyb-0000Ft-56 for help-gnu-emacs@gnu.org; Tue, 10 Oct 2017 14:10:02 -0400 Original-Received: from mail-it0-x236.google.com ([2607:f8b0:4001:c0b::236]:47858) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e1yya-0000Fg-V4; Tue, 10 Oct 2017 14:09:57 -0400 Original-Received: by mail-it0-x236.google.com with SMTP id p138so3620911itp.2; Tue, 10 Oct 2017 11:09:56 -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:content-transfer-encoding; bh=IZEO2AKBk/EUmpAQ1+0tPB3CzWbE8qGJTLy8pimAFeI=; b=VBGtr7rcWGGtk6+xITRUa3ZoyKmkkdByqXizY8iu/uw4vgh57JRoYzwZHIcmIsn6xK CitKRHJgAz4z0nD4nUj4IMfdUU4l1NfzU+DZ4ykK7i8zF9RWtqgF1lrF6btuPkr5VJsl mJcjZIlO1Vn8WNxbsfd8g6jYJ+XvUSFxPgNBrP89O0nBYgrjrNvPf1lun8+QCyJhumzC jcernBe95QYrVBc2LCIJyiiy3Vsv8OW44krI9dfHb64klsPmazZC9gBSOnxGm9Lry+Pv LggSc39fI1BhMLx0+c3ToWzJ0/L44j1DmChMczmP5VV4zQgrVq/XQln/dbg+WPU1kTWj N9Xg== 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:content-transfer-encoding; bh=IZEO2AKBk/EUmpAQ1+0tPB3CzWbE8qGJTLy8pimAFeI=; b=EzhtbtUTzO6qPIMAqxg+vjXqhYjCCIEMmTekt4F/Ej5w1AYaRCxvmtIeHBJQD9DanE D4PhjZLCH2exsUiTnUWYqTMi/uyEMIIonXYqoMmx6yfzBya5/8sst9LNfxJkP3XvKbDj bhrCIcN0AwJe0ldleqyzNSlQpDCiPU/XelhYWnGVr2KvONHDSlaL3kDho8iKbXLHlgss Kh7+k5v5A4EM1BIz33/NivHL4in7kT4K6Ij89kcJiXqe0b9nNU0kjoezl+ZvntLf3LdP YBToEKH0eG00waGyUIxTxQvqotpLbKrymo1EsApP7+wcH8c1J3upali24P8CMNeCEK6F ZlyQ== X-Gm-Message-State: AMCzsaVffRoatKSfZ54GN+1Kv+4S4jT3fuh5kTkDX+MdulHVr/azpDSg imEx0kvFCP46DzVAm6sZRMmSSQ== X-Google-Smtp-Source: AOwi7QAtrTGiS5UYpgkGVfDZvrj2edcUPhnxuVv7Y65zpuo8Ypnowp5hhsmBtBH8P0tUQeMi+TnEiw== X-Received: by 10.36.182.5 with SMTP id g5mr18329117itf.35.1507658995920; Tue, 10 Oct 2017 11:09:55 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id o137sm5148424iod.59.2017.10.10.11.09.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 10 Oct 2017 11:09:54 -0700 (PDT) In-Reply-To: <83fuarqzd9.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Oct 2017 09:40:50 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::236 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:114541 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: eliz@gnu.org >> Date: Sun, 08 Oct 2017 23:22:59 -0600 >>=20 >> (setq header-line-format >> (concat (propertize " " >> 'display >> '(space . (:align-to 0))) >> "test")) >>=20 >> (setq header-line-format >> (propertize "test" >> 'display >> '(space . (:align-to 0)))) >>=20 >> It's not a big deal, but it's makes things look cleaner, especially when >> the string in question is also being propertized. > > The 'space' display property is of the "replacing" kind, i.e. it > completely replaces the text which has that property. So implementing > what you want would need a new property at least. Or maybe you could > use the '(space-width FACTOR)' display spec instead, and prepending a > single SPC character that precedes the string characters? (This > assumes the string itself doesn't have embedded SPC characters; if it > does, put this display property only on the initial SPC character.) I guess I replied to this part in Bug#28771 (sorry for fragmenting the discussion). > FWIW, having a 'space' display property on some whitespace character > sounds very intuitive to me, since this feature was supposed to be > used to display white space subject to pixel-level resolution > considerations of a GUI frame. It does to me as well, but it would be nice to have similar functionality to :align-to in arbitrary strings. Something like the following, that would align the string similar to :align-to does a space: (propertize "test" 'display '(align-to EXPR)) where EXPR can be the same as in :align-to. >> P.S. I noticed that the above does not take into account the space taken >> by `display-line-numbers'. > > That's because it isn't clear whether it should be done for every > header-line. For example, the Info mode will certainly not want > that. So this has to be done by the Lisp program, because only it > knows whether the text in the header line should be aligned with the > rest of buffer text. I don't understand. The Info mode header isn't aligned at all (for example, toggling fringe and linum-mode (for the margin) doesn't change the position of the info header). Only headers with an `:align-to num' property would be affected. Here is what the manual says about :align-to: For example, =E2=80=98:align-to 0=E2=80=99 in a header-line aligns with = the first text column in the text area. I would consider "the first text column" to be column 0, so the current behaviour is incorrect. If line-number display is treated specially, then there should also be a `line-number' element for the :align-to and :width specs.