unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: andreas.roehler@online.de, esperanto@cumego.com, emacs-devel@gnu.org
Subject: Re: burden of maintainance
Date: Fri, 02 Oct 2015 21:16:58 +0200	[thread overview]
Message-ID: <87y4flrsgl.fsf@gnu.org> (raw)
In-Reply-To: <837fn55ds7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Oct 2015 21:24:56 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> > We are mis-communicating again: I meant features which display
>> > something or involve interactive keyboard input.
>> 
>> Emacs is in a better position here than most other tools because it
>> has keyboard macros and can easily inspect the things it displays,
>> e.g., the text properties or overlays at point.
>
> We may be mis-communicating here.  Because I cannot see how examining
> text properties or overlays can test whether their display on screen
> is correct.  What am I missing?  Can you show an example of what you
> had in mind?

No, if something is actually displayed correctly cannot be tested like
so.  What I had in mind were things like testing if fontification works
properly by checking if the 'face property is set to some expected face
when point is one some keyword.

> If we are talking about testing the display engine, it should be
> possible and relatively easy to provide Lisp access to the "glyph
> matrices", which are data structures the display engine builds that
> describe what _should_ be on the screen.  You can see one specialized
> example of that in the function bidi-resolved-levels which I wrote for
> testing the bidirectional display.
>
> But doing the above is only half the way.  The other half is the
> terminal-specific back-end, either X, w32, NS, or TTY, which actually
> converts the glyph matrices to draw commands and delivers the results
> to the glass.  To test that, we need some way of "sniffing" the
> results of this drawing, which requires terminal-specific
> infrastructure.
>
> We then need some "language" to describe the expected results to be
> displayed on the screen.  For TTY, this is almost trivial, but for
> sophisticated GUI display features it's more complicated (think of
> fonts, stretches of white space, composed characters, fringe bitmaps,
> tool-bar icons, tooltips, etc.).  We also need a way of describing the
> results of cursor movement.
>
> When all of these are implemented, then yes, writing display tests
> should be relatively easy.  But today all this infrastructure doesn't
> exist.  We don't even have its detailed design.

That's obviously not what I've head in mind.  But I don't think that's
an area where we need a special focus on tests.  At least I have the
feeling that there are only few bugs wrt. the display engine.

>> I can think of something like "ERT keyboard-macro tests" where you
>> would basically record a keyboard macro and during that, you have
>> some way to add some assertions before resuming recording.  The whole
>> recorded thing could then be stored as an ERT test.
>
> For testing keyboard input, we need more than that.  For example,
> consider the simple feature of input history -- you'd need a way to
> inject M-p, M-n, etc., and a way of recording the text that is
> displayed as result and returned to the caller.
>
> And please don't forget that keyboard input is only one kind of events
> supported by Emacs.  There are others, starting with mouse.  We'd need
> ways to simulate or trigger all of them.

Yes, eventually.  But it would at least be a first step.  And this
hypothetical recorder could also be exposed to the user for creating
replayable recipes for bugs they report.  Where a tester would add
assertions, the user would just write what he's expecting, and whoever
fixes the bug could easily turn the string into assertions, and voila,
there's the regression test for the bug.

Bye,
Tassilo



  parent reply	other threads:[~2015-10-02 19:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01  8:10 burden of maintainance Andreas Röhler
2015-10-01 16:03 ` Eli Zaretskii
2015-10-01 18:46   ` Andreas Röhler
2015-10-01 19:09     ` Eli Zaretskii
2015-10-01 20:18       ` Andreas Röhler
2015-10-01 20:27         ` Eli Zaretskii
2015-10-02 13:54       ` Przemysław Wojnowski
2015-10-02 14:15         ` Eli Zaretskii
2015-10-02 17:18           ` Tassilo Horn
2015-10-02 18:24             ` Eli Zaretskii
2015-10-02 18:47               ` joakim
2015-10-02 19:16               ` Tassilo Horn [this message]
2015-10-02 20:53                 ` Eli Zaretskii
2015-10-02 19:28               ` Chad Brown
2015-10-02  7:51   ` Helmut Eller
2015-10-02  8:47     ` Eli Zaretskii
2015-10-02  8:56       ` Helmut Eller
2015-10-02  8:59         ` Eli Zaretskii
2015-10-02 11:46         ` Michael Albinus
2015-10-02 11:58   ` Phillip Lord
2015-10-02 13:14     ` Artur Malabarba
2015-10-02 13:36     ` Eli Zaretskii
2015-10-02 15:00       ` Andreas Röhler
2015-10-02 15:16         ` Eli Zaretskii
2015-10-02 17:19           ` Andreas Röhler
2015-10-02 18:08             ` Eli Zaretskii
2015-10-02 18:54               ` Andreas Röhler
2015-10-02 20:39                 ` Tassilo Horn
2015-10-03  6:53                   ` Andreas Röhler
2015-10-03  7:31                     ` Tassilo Horn
2015-10-03  1:38             ` Richard Stallman
2015-10-03  0:38       ` Eric Ludlam
2015-10-02 23:24     ` Xue Fuqiao
2015-10-03  6:42       ` Przemysław Wojnowski
2015-10-03  7:00         ` Xue Fuqiao
2015-10-03  7:15         ` Eli Zaretskii
2015-10-01 16:34 ` Przemysław Wojnowski
2015-10-02 11:25   ` Phillip Lord
2015-10-02 12:27     ` Michael Albinus
2015-10-02 14:53       ` Phillip Lord
2015-10-02 16:56         ` Michael Albinus
2015-10-03  1:35     ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87y4flrsgl.fsf@gnu.org \
    --to=tsdh@gnu.org \
    --cc=andreas.roehler@online.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=esperanto@cumego.com \
    /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 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).