Re: Render a buffer or string to a simpler string?

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 26 May 2013 07:38:30 +0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > We lack such a feature currently.  Display rendering is a C-level
> > operation, whose result is not a string, but an array of structures
> > called "glyphs" which are passed to the terminal back end for drawing
> > on the screen.  So you need primitives (which don't exist) to produce
> > Lisp strings out of those glyphs.
> 
> That's what I figured, but had to ask anyway. Thanks for the reply.

Btw, the general problem you described -- "render to a string" -- is
not necessarily solvable even in principle.  E.g., how do you express
in a string variable fonts and other face attributes that don't change
the text, only how it is displayed? what about pixel-granular
alignment we do with :align-to and similar display properties? what to
do with images and sounds? etc. etc.

> >> To put it differently, the goal is to make the buffer look a certain way,
> >> so I'd like to be able to check that it does look that way.
> >
> > That's hard to do automatically, unless you use external software that
> > grabs screen portions.  Rendering is just one of the aspects, there's
> > also alignment, decorations, remnants from previous redisplay cycles,
> > etc.
> 
> I think it's a shame, because out of all (?) text editors, Emacs is the
> best positioned to enable human-readable UI tests, because of how often
> people use text properties to do visuals.

I don't understand this reasoning at all.  Why do you think Emacs is
best positioned for this?  And what have human-readable UI tests to do
with this; I thought you were talking about _automated_ tests?

> Testing UI look in graphical applications has to involve screen grabs,
> at least on some level.

When Emacs runs on a graphical terminal, it acts as a graphical
application.