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

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

Expand Messages
  • Nazri Ramliy
    This is a reply of an almost 3-year old thread (but still relevant :) ... Attached is a toy patch that implements something similar to the above. It add the
    Message 1 of 2 , Feb 18, 2013
    • 0 Attachment
      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)


      Nazri

      --
      --
      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.
    • Charles Campbell
      ... Hello! My synchk plugin may also address a related area; although not by creating a screenshot list
      Message 2 of 2 , Feb 25, 2013
      • 0 Attachment
        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)
        >
        Hello!

        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.

        Regards,
        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.