all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Using :align-to with non-spaces
Date: Wed, 11 Oct 2017 13:38:30 +0300	[thread overview]
Message-ID: <83zi8ynf4p.fsf@gnu.org> (raw)
In-Reply-To: <871smacy80.fsf@gmail.com> (message from Alex on Tue, 10 Oct 2017 18:41:35 -0600)

> From: Alex <agrambot@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 10 Oct 2017 18:41:35 -0600
> 
> > 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.

What for?  If these are needed for doing layout in Lisp, then I'd
prefer to consider changes whereby the layout is completely done by
the display engine, if that is possible in the relevant use cases.

> 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.

How is that different from using line-number-display-width in the
display spec?

> >> > 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 meant this:

  http://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00385.html

and Martin's response to it.

> > 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"?

How can we know whether this will cause breakage all over the place?

> > 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).

You are arguing for extending the display engine with features that
are apparently intended to help Lisp programs do layout on the Lisp
level.  I'm saying that I'd be more happy if we could push _all_ of
the layout job in those cases into the display engine.  If possible,
of course.  E.g., if you want to be able to center the text of a
header-line in the window, why not ask the display engine do that for
you?



  reply	other threads:[~2017-10-11 10:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-09  5:22 Using :align-to with non-spaces Alex
2017-10-10  6:40 ` Eli Zaretskii
2017-10-10 18:09   ` Alex
2017-10-10 18:27     ` Eli Zaretskii
2017-10-10 19:18       ` Alex
2017-10-10 20:01         ` Eli Zaretskii
2017-10-11  0:41           ` Alex
2017-10-11 10:38             ` Eli Zaretskii [this message]
2017-10-12  0:47               ` Stefan Monnier
2017-10-12  7:10                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zi8ynf4p.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.