From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28771: 26.0.60; A couple space display property feature requests Date: Wed, 11 Oct 2017 15:59:54 +0300 Message-ID: <83r2u9on5h.fsf@gnu.org> References: <87fuarc0px.fsf@gmail.com> <83efqbqz1n.fsf@gnu.org> <87tvz6dh26.fsf@gmail.com> <83k202q0k8.fsf@gnu.org> <87bmled788.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507726893 15436 195.159.176.226 (11 Oct 2017 13:01:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Oct 2017 13:01:33 +0000 (UTC) Cc: 28771@debbugs.gnu.org To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 11 15:01:27 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 1e2GdT-0002ZP-Hu for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Oct 2017 15:01:19 +0200 Original-Received: from localhost ([::1]:40919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2Gda-0000En-LR for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Oct 2017 09:01:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2GdF-0008V8-20 for bug-gnu-emacs@gnu.org; Wed, 11 Oct 2017 09:01:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2GdB-0006N1-Tx for bug-gnu-emacs@gnu.org; Wed, 11 Oct 2017 09:01:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e2GdB-0006Mx-Qe for bug-gnu-emacs@gnu.org; Wed, 11 Oct 2017 09:01:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e2GdB-0004cs-JU for bug-gnu-emacs@gnu.org; Wed, 11 Oct 2017 09:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Oct 2017 13:01: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.150772683517737 (code B ref 28771); Wed, 11 Oct 2017 13:01:01 +0000 Original-Received: (at 28771) by debbugs.gnu.org; 11 Oct 2017 13:00:35 +0000 Original-Received: from localhost ([127.0.0.1]:33158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2Gck-0004c1-VJ for submit@debbugs.gnu.org; Wed, 11 Oct 2017 09:00:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2Gcj-0004bo-CI for 28771@debbugs.gnu.org; Wed, 11 Oct 2017 09:00:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2GcY-000661-Cj for 28771@debbugs.gnu.org; Wed, 11 Oct 2017 09:00:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2GcY-00065m-99; Wed, 11 Oct 2017 09:00:22 -0400 Original-Received: from [176.228.60.248] (port=4418 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e2GcW-0007RH-2e; Wed, 11 Oct 2017 09:00:21 -0400 In-reply-to: <87bmled788.fsf@gmail.com> (message from Alex on Tue, 10 Oct 2017 15:27:03 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:138217 Archived-At: > From: Alex > Cc: 28771@debbugs.gnu.org > Date: Tue, 10 Oct 2017 15:27:03 -0600 > > 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". Actually, my understanding is that 'left' is the number of pixels from the left edge of the window to the start of "Test". IOW, it's a pixel width, not a position. Right? > For clarification, what you should see is 1 space before and 1 space > after "Test", each the same pixel width as the left fringe. Actually, by "space" you mean space displayed with 'highlight' face, right? Because there's a lot of "other" space in the header-line, but you don't mean that space. That's what tripped me originally. > 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). So what is the purpose of having the header-line or mode-line text move relative to buffer text when some window decorations are enabled/disabled or moved from left to right? IOW, why did you need the "space" on both sides of "Test" to be of the same pixel width, independently of the scroll-bar position? Right now, "Test" moves together with buffer text, and so is always aligned with it, no matter which side is the scroll bar on. Why is that not TRT? > >> 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). Again, why do you need that? Also, why cannot you use the existing functions that return dimensions of the window and its decorations? > > 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. It fits with the code, but not with the conceptual framework. The :align-to spec starts counting pixels at the left edge of the text area, whereas with the new symbols you introduce it will start at a different point. That's confusing. > Sorry, I should have been more clear -- appending/prepending a > pixel-specified space string to an arbitrary string. Essentially a > (concat string ). The only way to generate a stretch of whitespace is to use a 'space' display spec. So no, we don't have that. The display engine cannot display a glyph of a character with prepended or appended space, because we ask the font back-end to produce the glyph metrics for us, and those metrics come from the font. That is why we must produce stretch glyphs separately.