help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using :align-to with non-spaces


From: Eli Zaretskii
Subject: Re: Using :align-to with non-spaces
Date: Wed, 11 Oct 2017 13:38:30 +0300

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]