From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.bugs Subject: bug#28771: 26.0.60; A couple space display property feature requests Date: Tue, 10 Oct 2017 15:27:03 -0600 Message-ID: <87bmled788.fsf@gmail.com> References: <87fuarc0px.fsf@gmail.com> <83efqbqz1n.fsf@gnu.org> <87tvz6dh26.fsf@gmail.com> <83k202q0k8.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1507670898 6850 195.159.176.226 (10 Oct 2017 21:28:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Oct 2017 21:28:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) Cc: 28771@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 10 23:28:12 2017 Return-path: Envelope-to: geb-bug-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 1e224Q-0000eO-2r for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Oct 2017 23:28:10 +0200 Original-Received: from localhost ([::1]:37226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e224X-0000Uq-8e for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Oct 2017 17:28:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e224N-0000T9-9o for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2017 17:28:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e224I-0006QL-9Z for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2017 17:28:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52332) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e224I-0006QF-59 for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2017 17:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e224H-0000ll-Pe for bug-gnu-emacs@gnu.org; Tue, 10 Oct 2017 17:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Oct 2017 21:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28771 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28771-submit@debbugs.gnu.org id=B28771.15076708452910 (code B ref 28771); Tue, 10 Oct 2017 21:28:01 +0000 Original-Received: (at 28771) by debbugs.gnu.org; 10 Oct 2017 21:27:25 +0000 Original-Received: from localhost ([127.0.0.1]:32780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e223g-0000ks-O5 for submit@debbugs.gnu.org; Tue, 10 Oct 2017 17:27:25 -0400 Original-Received: from mail-io0-f180.google.com ([209.85.223.180]:56103) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e223f-0000ke-Ba for 28771@debbugs.gnu.org; Tue, 10 Oct 2017 17:27:23 -0400 Original-Received: by mail-io0-f180.google.com with SMTP id z187so248170ioz.12 for <28771@debbugs.gnu.org>; Tue, 10 Oct 2017 14:27:23 -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=xEZ4YVfzj2EiKDW2KmK50r5oKo2JMEfdgP4NZgGG580=; b=rO7aBigEgDVHcORnsMeT4+0uMhlIb60cr64/0ujHoRc/op8syM/d0n3skjBLAWhcjb qAwZLa0/yXS7QATwu76shVp7A5l/7XOe1FXvDpZ0pQmdxiptvY5pF/sJaS3ky8vfAvSr rwoitYWcZwbYGeIz7IGGiV0zqYjC7LTYlhQAUUDKkvCvWJn1X2F4komrdrCm5eepCQR2 /cJWMV2gwKSU20II4/iBgZQKEtAWd8ykL/WRPHTQFWE6S5ohchZh3rnRTHF5NvlZ/q7V AkgbeJzM3EgFa4TDI/qrRQRUQGJIrPTUjviio3IBnH3Dpi34WMg3LFEtamM58Y5RA1A/ MBAw== 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=xEZ4YVfzj2EiKDW2KmK50r5oKo2JMEfdgP4NZgGG580=; b=nUZgQ/5MYoRIozTCssFWJzYqb1/5d5Elah4E+S4JKLoLDo4s7ypodM+xeB/0f84vpu Rej+diIvXv3GdfcicPzw7+ECea1MFADtd+g3vRtfxc8LE5JfX0uLBEcpssw8isGQp3/y DBdAoWZksYtbqGO3wR2iFptUkT6TRrhcc+Cicbnx/yUThIKlRvsHRMsJ8263bvCcjskM K1tzmmdQbnkBqJrbVP6p/Pj7nimaTPhfLVvlZGBoC1ZOJcJoZhnk3Yf1PHMyUKnydwS6 dsNHR7Dwp6StpJ69D+qeCBzfd/X+qYbaIQ1XtGPWlwAYA58zSHL0eq6JRdteLDFyT5Tz 59Xw== X-Gm-Message-State: AMCzsaWmXgVUnCAqkYxpiyJCuZ4SlR/fA+zX/6F9vRdOQmQtHE9qYnXc gF3tyX/w7cnlB2lZP8Bq90wQ8Q== X-Google-Smtp-Source: AOwi7QBy3PuSQq+GmXHljDFD/cQTCYErCBpFUWm3Tuuer6Ywh4T1pUngRBBjUvcYrp5VOeh6qPhE3A== X-Received: by 10.107.142.208 with SMTP id q199mr15469028iod.186.1507670837538; Tue, 10 Oct 2017 14:27:17 -0700 (PDT) Original-Received: from lylat (S010664777d9cebe3.ss.shawcable.net. [70.64.85.59]) by smtp.gmail.com with ESMTPSA id y6sm5404660ioy.54.2017.10.10.14.27.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 10 Oct 2017 14:27:16 -0700 (PDT) In-Reply-To: <83k202q0k8.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Oct 2017 22:12:39 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138199 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: 28771@debbugs.gnu.org >> Date: Tue, 10 Oct 2017 11:54:41 -0600 >> >> 1. There is currently no robust way to specify a pixel width to the >> center or left/right edge of the text area in the 'space' display spec. > > There's some kind of miscommunication here. For starters, what do you > mean by "text area"? For me, "text area" is the area of the window > inside the fringes, see the definition in "(elisp)Frame Layout". But > you must mean something else, because with my interpretation, > specifying pixel width of the text area makes no sense: it is > determined by the window dimensions. I'm using whatever "(elisp) Pixel Specification" uses. In this case, I believe it's the start of either column 0 or the line-prefix (see the gnu-emacs-help thread on that point). To get an idea evaluate: (setq header-line-format (concat (propertize " " 'display '(space :align-to 0)) "test")) The start of "test" is what I mean by the "left" of the "text-area". The point here is that :align-to has access to some pixel positions using `left', `center', and `right'; the diff above allows :width to return a stretch space as wide as that position. >> This is because there's no way to tell what's before the left edge of >> the text area. If there's a left-side scroll-bar, then its width >> should be included; but if it's on the right, its width shouldn't be. > > This is only true for a header-line and mode-line, right? Because the > rest of the window lines don't change their alignment when the scroll > bar switches sides, as their pixel count starts where the left fringe > ends, whether or not there's a scroll bar to the left of the fringe. I believe so. I haven't really played around with these specs outside of the header-line. >> As for an example, try this in a graphical emacs -Q: >> >> (setq header-line-format >> (propertize >> (concat (propertize " " >> 'display >> '(space :align-to 0)) >> "Test" >> (propertize " " >> 'display >> '(space :width (+ left-fringe left-margin)))) >> 'face 'highlight)) >> >> >> By default, the spaces before and after test are equally sized. > > Again, there's some misunderstanding here, because this example shows > "Text" in the header-line flushed all the way to the left, with only > one space before "Test", to account for the left fringe (if I turn off > fringe-mode, that space disappears). That's not what you are > describing, so I guess the example needs some change? So you don't see the space after "Test"? Make sure the background of the 'highlight face is different than the 'header-line background to see the space clearly. I mentioned `emacs -Q' since the face background should be different there. Any face with a different background suffices. For clarification, what you should see is 1 space before and 1 space after "Test", each the same pixel width as the left fringe. What should happen is that if you toggle the fringes/margins, then the spaces shrink and grow accordingly, with the exception of faulty scroll-bar width calculation. Using '(space :width left) does not have this faulty calculation. The point is that the before/after stretch whitespace must have equal lengths at all times, regardless of fringe/margin/line-number/scroll-bar statuses. > And again, this is limited to header-line, right? I believe so (and the mode-line). >> 2. Suppose you want to align a string to the right edge of the window. > > What is "the right edge of the window" in this context? The very ends of the window shown in the art in "(elisp) Window Sizes" (i.e., past RD). Specifically, whatever is returned by WINDOW_LEFT_PIXEL_EDGE and WINDOW_RIGHT_PIXEL_EDGE is what I'm referring to. >> That's my use-case at the moment. > > If you are talking only about header lines, maybe the solution (if we > need one) doesn't have to be such a general one. Are there similar > problems with other lines in a window? Maybe it doesn't, but since the general case is simple enough to implement, why not do it? I think it fits in with the existing code well enough. I don't know of any similar problems, but I don't use these :align-to/:width outside of the header-line. >> Is there currently no display spec that allows for appending/prepending >> (or would it be hard to add)? > > Appending/prepending what and to what kind of text/object? Sorry, > maybe it's too late, but I have trouble following your > descriptions :-( Sorry, I should have been more clear -- appending/prepending a pixel-specified space string to an arbitrary string. Essentially a (concat string ).