Loading ...
Sorry, an error occurred while loading the content.

Re: WYSIWYG-ish vim screen testing (was Re: Looking for test coordinator)

Expand Messages
  • Charles Campbell
    ... Hello! My synchk plugin may also address a related area; although not by creating a screenshot list
    Message 1 of 2 , Feb 25, 2013
      Nazri Ramliy wrote:
      > This is a reply of an almost 3-year old thread (but still relevant :)
      > On Fri, Jul 30, 2010 at 4:19 AM, Bram Moolenaar <Bram@...> wrote:
      >> Nazri Ramliy wrote:
      >>> What if we had some helper command that dumps how the
      >>> current screen look like so that it can be compared with
      >>> some "expected_dump.txt"?
      >>> Something along the lines of:
      >>> FILE *fd = fopen("dump.txt", "w");
      >>> int r, c;
      >>> for (r = 0; r < screen_Rows; r++)
      >>> for (c = 0; c < screen_Columns; c++)
      >>> fputc(ScreenLines[r * screen_Columns + c], fd);
      >>> fputc('\n', fd);
      >>> fclose(fd);
      >>> [snipped]
      >> Using the lowest level information about the screen is a good idea. We
      >> don't test the communication with the terminal then, but that's a
      >> separate issue, and there have been very few problems in that area the
      >> last few years.
      >> We can use the remote facility from one Vim to control another Vim.
      >> Basically:
      >> Start Vim: :!vim --servername VIMTEST -u {test vimrc}
      >> Send command: :call remote_send("VIMTEST", ":edit file\<CR>")
      >> Evaluate effect: :echo remote_expr("VIMTEST", screen_char(0, 0))
      >> The only thing missing is the function to obtain the properties of a
      >> screen character, such as screen_char(). That's easy to implement.
      >> This only works when compiled with the remote server feature, thus it
      >> won't work to test a small version. Not a real problem.
      >> We can't get output at the command line this way. Accessing the message
      >> history should help, but it doesn't store all the output. Perhaps a
      >> testing mode can be enabled to store all output on the command line and
      >> a function to obtain it.
      >> A few more generic things would be needed, such as a check that there
      >> was no error message.
      >> Perhaps someone can give this a start to test the conceal feature? That
      >> would be an excellent example of what we should be able to test this
      >> way.
      > Attached is a toy patch that implements something similar to the above. It
      > add the following two functions to vimL and four test files (test91.in-
      > test94.in) that uses them to test the 'number', 'relativenumber' and folding
      > feature:
      > -- 8< --
      > screen([{size} [, {col}]]) *screen()*
      > Return a List of the on-screen text (ascii only) drawn by vim.
      > Each item in the list holds one screen line. The first element
      > of the List contains the topmost line. {size} limits the
      > length of each line returned. If not provided, {size} defaults
      > to 'columns'. {col} is the column offset from which each
      > line starts. The first column is 1.
      > screenattr({row} , {col}) *screenattr()*
      > Return a Dict containing the character attributes for the
      > character at row {row} and column {col}. Topmost row is 1
      > and leftmost column is 1.
      > -- >8 --
      > screen() doesn't know how to return multibyte/unicode stuff yet
      > (because I don't know how to do it at the moment).
      > screenattr() was just implemented a few minutes ago as I'm writing
      > this hence there's no test that uses it yet.
      > You can bet that the patch has a handful of bugs :)
      > I'm posting the patch just to get them out the door to see if it is
      > going in the right direction.
      > Have a look at test92.in and screen.vim to see how the patch
      > simplifies testing vim's line drawing regardless of terminal size (as
      > long as they're of reasonable size like 80x20 and not silly ones like
      > 5x5 - those can be handled gracefully later)

      My synchk plugin may also address a related area; although not by
      creating a screenshot list
      (http://www.drchip.org/astronaut/vim/index.html#SYNCHK). From its
      document page:

      The synchk.vim plugin helps syntax highlighting plugin writers to
      maintain their syntax highlighting plugin. Typical use involves
      manually inspecting a test file to insure that its being highlighted
      correctly; once that is so, run |:MakeSynChk| on it. This operation
      will save information on the current syntax highlighting;
      subsequently, one may run |:SynChk| to verify that the highlighting
      has not changed.

      The |:MakeSynChk| command computes a hash value for each line in the
      current file, saving it to synchk/file_suffix.synchk. The hash
      involves synIDattr(synID(line("."),col("."),1),"name"); this is
      (see |synIDattr|, |synID|, |line()|, and |col()|)
      the name of the syntax item under the cursor. The syntax name of
      each character in a line are converted to numbers and hashed together.
      Every line of the current file is thus converted into a hashed value;
      the hashed value is saved.

      Similarly, the |:SynChk| command also computes hash values for every
      line in the current file; however, instead of saving the hashed value,
      it compares it to the previously saved hash value. If the two differ,
      then syntax highlighting is considered to have failed.

      Thus, |:Synchk| is sensitive to syntax highlighting changes on a
      line by line basis, and can be used to locate unexpected changes in
      syntax highlighting. Of course, "failures" may be intentional.

      C Campbell

      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    Your message has been successfully submitted and would be delivered to recipients shortly.