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

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:
>> Pixel-granular alignment would probably be ignored, `face' properties
>> would be either ignored, or just kept as-is in the rendered string.
>
> Keeping the faces makes sense if they are automatically generated, but
> not if they are put by explicit Lisp code, since then you just get
> whatever the code put.

There's no easy way to compare faces, save for rendering to some
external format like images or html. So yeah, this mechanism by itself
would be unsuitable for testing i.e. syntax highlighting. If you recall,
I gave some examples of text properties that *could* be tested with it.

I'll admit that `before-string', `display', etc, are not used too much
by packages everywhere, but they do get used, and other packages
sometimes have to interoperate with those that do. (*) (**)

>> A human has to write these tests, and then come back later, be able to
>> read and modify them. Try doing that efficiently with screen grabs.
>
> UI testing people do that all the time: you compare the grab with some
> baseline.

I'm not saying it can't be done with grabs.

http://en.wikipedia.org/wiki/Efficiency

And if you're suggesting just comparing screenshots, even font rendering
is very different across platforms, and it's affected by many settings,
so each such reference image would be platform- and settings-specific.
Good luck writing a portable test suite.

>> The only means of building interface widgets exposed to Elisp are text
>> properties, AFAIK. They do include some graphical-only features, but
>> those aren't used as often as one might expect.
>
> Try looking at Customize, and you will see a different story.

Customize is just one package.

By "often", I meant the percentage of packages that do, compared to the
total amount, not "number of interactions by users per hour".

But Customize still works with -nw, right? It might be helpful to test
just how it looks in non-graphical terminal, and verify any additional
features separately.

(*) Two examples:

- `outlne-minor-mode' hides a portion of buffer text, our overlay covers
  it (https://github.com/company-mode/company-mode/issues/16), we'd like
  to make sure the rectangle is still still drawn in the right shape.

- `org-indent-mode' uses `line-prefix' and `wrap-prefix' text
  properties, and they seep into strings we collect from the buffer
  before drawing over them
  (https://github.com/company-mode/company-mode/issues/24).
  We'd like to make sure the lines still look fine, even when there are
  such text properties inside the overlay's `before-string'.

I ended up removing `line-prefix' from all collected lines, prepending
the values physically to the strings that get collected, but it's not
fun that I need to look up the property value at the beginning of the
line and act on it, instead of just asking "gimme the line like it
looks!" (actually, I should search the whole line, but that's more work,
so I'm not doing that until someone else asks). I don't handle
`wrap-prefix' here at all because it's one more special case, and
luckily, org-mode buffers truncate lines by default.

Another thing I found lacking is a version of `current-column' that's
aware of those text properties.

(**) Another feature that would render better to strings is visual line
folding (when truncation is off). For example, the candidates popup in
Company needs to work with visual lines, not physical ones, so writing a
test that ensures that popup overlay took the requires lines and painted
over them, without jumping over folded lines, woult be useful.

Although, in this case, the harder part is setting up the test data the
right way to make sure the line does get wrapped where it should.