unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Is a `max-width' spec feasible?
@ 2021-11-26 16:25 Lars Ingebrigtsen
  2021-11-26 17:07 ` Stefan Monnier
  0 siblings, 1 reply; 3+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-26 16:25 UTC (permalink / raw)
  To: emacs-devel

I haven't looked at this at all, so I'm just throwing this out there so
I don't forget (before going out):  Would a `max-width' display spec be
feasible?

That is, it's like `min-width', but if we've reached an it->current_x
that's wider than the spec, then we throw out all glyphs we've already
prepared, back to the desired width?

This would make a variable pitch table trivial to implement -- you'd
just insert a bunch of strings with both min-width and max-width, and
the display engine would do all the stretching/chopping for you.

If the strings were very long, this would be massively inefficient, of
course, but let's assume that we're not doing that.

Or...  we could just skip rendering the glyphs if we're going to surpass
the desired current_x?  Yes, that sounds more efficient?

OK, gotta run.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Is a `max-width' spec feasible?
  2021-11-26 16:25 Is a `max-width' spec feasible? Lars Ingebrigtsen
@ 2021-11-26 17:07 ` Stefan Monnier
  2021-11-27 14:18   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2021-11-26 17:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

> I haven't looked at this at all, so I'm just throwing this out there so
> I don't forget (before going out):  Would a `max-width' display spec be
> feasible?

I'm not the right person to answer.  But I'd welcome this
functionality, indeed.

> That is, it's like `min-width', but if we've reached an it->current_x
> that's wider than the spec, then we throw out all glyphs we've already
> prepared, back to the desired width?

Side note: `truncate-string-to-width` doesn't just throw away the
excess but also inserts an ellipsis to announce the truncation, so if we
add such a `max-width` it'd be desirable to make it display an ellipsis
as well when truncating text.


        Stefan




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Is a `max-width' spec feasible?
  2021-11-26 17:07 ` Stefan Monnier
@ 2021-11-27 14:18   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 3+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-27 14:18 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Side note: `truncate-string-to-width` doesn't just throw away the
> excess but also inserts an ellipsis to announce the truncation, so if we
> add such a `max-width` it'd be desirable to make it display an ellipsis
> as well when truncating text.

Yup.  That does complicate the thing quite a bit, because we'd want to
allow customising that, and the width of the ellipsis is very different
on different displays, etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-11-27 14:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-26 16:25 Is a `max-width' spec feasible? Lars Ingebrigtsen
2021-11-26 17:07 ` Stefan Monnier
2021-11-27 14:18   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).