Gary Johnson wrote:

> > > > > > Would be nice to point to what's wrong.  Ah, I see that an
> > > > > > Xfunctions.diff file is generated.  Hmm, but "diff" might not be
> > > > > > available.
> > > > > 
> > > > > Yeah, but I don't know what to do about that.  I suppose I could
> > > > > save the lists to Lists instead of files and do a rudimentary diff
> > > > > of two Lists.  (Having Unix tools makes life so much easier.)
> > > > 
> > > > We probably should make assert_equalfile() better.  Show the context of
> > > > where the difference was found.  However, in this case the question is
> > > > also where the list comes from, that could be added as a third argument.
> > > 
> > > You have a better idea of the style you'd like than I do, but I can
> > > take a stab at that if you'd like.
> > > 
> > > By a third argument for where the list comes from, do you mean an
> > > optional {msg} argument as used by other assert_*() functions?
> > 
> > Yes, mentioning what is being compared already helps a bit.
> > 
> > > > > > The sorting should be done without ignoring case?  At least for a 
> > > > > > binary
> > > > > > search it should.
> > > > > 
> > > > > The type of sorting seems to differ between lists.  The
> > > > > global_functions in evalfunc.c seems to be sorted in ASCII or "C"
> > > > > order, which makes sense for source code, while the ":help
> > > > > functions" in eval.txt seems to be sorted in dictionary order, i.e.,
> > > > > ignoring case, which is reasonable for documentation.  I guess the
> > > > > latter depends on the expectations of the reader.  I tried to follow
> > > > > what was already there, although that was inconsistent.  I don't
> > > > > personally have a preference.
> > > > 
> > > > In case of doubt I would prefer to do what ":sort" without arguments
> > > > ends up with.  It's just easier to maintain that way.
> > > 
> > > I'll fix that in the source and in the test.
> > 
> > I removed the "i" argument from the sort command and it only found two
> > places that needed adjustment.
> 
> A complete patch is attached.  This patch includes:
> 
> -  a sorted list of functions for ":help functions";
> -  addition of functions missing from ":help function-list";
> -  a new test for checking that lists remain complete and sorted;
> -  fixes to a few misspellings.
> 
> The new test uses the new msg argument to assert_equalfile() to make
> the failure messages a little more clear.  The function lists have
> been updated since my earlier patch to include functions added since
> then.
> 
> An issue with the new test is that if it fails, an external diff
> program is required to produce meaningful output files for
> debugging.  I looked briefly at writing an internal diff function,
> but decided that it was more trouble than it was worth and one more
> thing to maintain.  Also, now that the major problems with the lists
> have been fixed, the test should fail only for a developer who has
> added a new function and that person should know where the problem
> lies.
> 
> The patch was based on Vim 8.2.895.

Thanks.

Hmm, not sure why asin() was dropped from the list in eval.txt.
Looks like the diff isn't against head.  I'll have to make a patch
anyway, to avoid that the patched version (not the github version) fails
when adding the test.


-- 
GALAHAD:   Camelot ...
LAUNCELOT: Camelot ...
GAWAIN:    It's only a model.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202006041323.054DNT49738713%40masaka.moolenaar.net.

Raspunde prin e-mail lui