Nikolay Pavlov wrote:

> Some notes which I think are not clear from my rather lengthy (and
> probably too angry) post:
> 1. Point 1 and 2 are just something that is worth writing VimL library
> for. Would not suggest to solve them in C.
> 2. Have not wrote that, but I expect point 5 to be fixed in the
> future, after feature is stabilized.
> 3. Points 3 (where screen state should be kept) and 4 (in what format)
> are actual complains about suboptimal design.

[and more in an earlier first message]

Keep in mind that this screen dump feature is like creating a screenshot
in a .png file.  Nobody is expected to edit the output, you should use
the term_dumpwrite() function to create them and term_dumpload() to view

In my experience making a screenshot is quick and efficient, you just
need to make sure to get to the right state before making the
screenshot.  Dealing with test failures should be a lot easier visually
than trying to look at a text description of the expected output (and
adjusting the text, instead of accepting the new file if it looks OK).

I intentionally put this in a file and not as text inside a test script.
I don't think a test script is the right place, it will get in the way
of the actual test code.  It would also require the developer to
copy/paste text, since you would never write the expected output, only
generate it.  Again, use it like a screenshot.

If you do want to check text you can already do that with getline().  If
you want to check highlighting you can use synIDattr() in most cases. It
gets more tricky for things like completion and popups, that's where the
dump feature comes in.

I did intentionally use a text format and not a binary format.  Partly
to make it easier to make patches and send them around. Partly to allow
me to debug the code for writing and loading these files.  But they are
not intended to be human readable or editable.  I rather keep them
small, since I expect them to be used a lot.  A few examples I tried
were less than 5 Kbyte, which should be fine.

As mentioned, I haven't written a test with this dump feature yet.  I do
intend to use Vim script for that, we'll see if that works out.  I hope
to have time tomorrow.  Hmm, we should probably include the cursor
position in the dump somehow.

Since for tests the minimum terminal size is 24 x 80 characters, we need
to use dumps that are a bit smaller than that.  Possibly 20 x 75
characters.  Then it will work everywhere. That should be enough for
simple tests, but not for checking a whole file for syntax highlight
errors.  Perhaps we can find a way to do that later.

The max-width and max-height options are for taking a dump of part of
the screen, not for setting the terminal size.  Maybe an offset would
also be useful.  But none of this is implemented yet.  Oh, I forgot to
adjust the help for this, it should have an {options} argument like the
otheres. Otherwise adding more choices is going to make it ugly.

For "waiting for a specific state": we already have term_wait(), but
it's not very reliable.  The WaitFor() function is more useful, and we
can use something like that, waiting the file contents to be equal.
Waiting for an intermediate state is not a good idea, it most often
leads to flaky tests.

Viewing the diff in three parts then does require a terminal that is
three times higher, to be able to see the whole.  Actually, one only
needs to see two parts, since the "s" key swaps the top and bottom.
This blinking will show the difference better anyway.

If the dumps are 20 lines then most developers will be able to see the
three parts, or at least two.  If we do add a way to make larger dumps
that will fail.  A vertical split could then help, if your terminal is
wide enough (more than 150 if we stick to the 75 char width).

> 4. And the whole post is written from the POV of a person thinking
> “Bram again wrote suboptimal feature without asking anybody (or Neovim
> developers specifically) regarding how they solve the issue”. Why? We
> do have similar problems, we are not against sharing experience and
> asking *before* writing feature would make design better from the
> beginning.

I do not recall any Neovim developers discussing any of their testing
stuff in the Vim developer list.  I don't see why I would ask for
comments before implementing anything, unless I don't know what to
implement.  In this case I have a very good idea of what to do, since
I'm using similar tools inside Google.  And if there are good
suggestions there is no problem using them.

In Africa some of the native tribes have a custom of beating the ground
with clubs and uttering spine chilling cries.  Anthropologists call
this a form of primitive self-expression.  In America we call it golf.

 /// Bram Moolenaar -- --   \\\
///        sponsor Vim, vote for features -- \\\
\\\  an exciting new programming language --        ///
 \\\            help me help AIDS victims --    ///

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

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 
For more options, visit

Raspunde prin e-mail lui