[TENTATIVE PATCH] Digraph implementation for Evil

[Nikolai Weibull]

Hi!

Sorry about the late reply.  I had the weekend off e-mail.

On Sun, May 22, 2011 at 12:34, Vegard Øye <vegard_oye at hotmail.com> wrote:
> On 2011-05-19 19:23 +0200, Nikolai Weibull wrote:
>
>> OK, I’ve created a merge request on gitorious:
>>
>> https://gitorious.org/evil/evil/merge_requests/1
>>
>> I only wrote one test.  I would appreciate it if you wrote some more
>> so that I can learn by example.  Also, please tell me if you want
>> something other than merge requests on gitorious.

> Wow, it looks like you have done a very throughout job of implementing
> digraphs. Do you want digraph.el to be part of Evil, or do you want to
> distribute it as a standalone library? If the former, it should be
> renamed to evil-digraphs.el and loaded in evil.el, and I may make some
> modifications to it. If the latter, I would appreciate a license tag
> (for example, GPLv2) to make it clear that the file is freely
> distributable.

I hereby place it in the public domain, so please add it as
evil-digraphs.el.  You may make any modifications you deem necessary,
like removing the unneeded function digraph-read.  I’d love to see my
name in some AUTHORS or CONTRIBUTORS file, though :-).

> With regard to testing, most of our tests fall into the "vimgolf"
> category: performing a key sequence on a test buffer. The main benefit
> of such tests is that they are implementation independent. Of course,
> the implementation should be tested too, and a common approach is to
> feed values into a function and compare the output with the expected
> output. `digraph-find' could be tested in this way, e.g.,
>
>    (ert-deftest test-digraph-find ()
>      "Test `digraph-find'"
>      (should (eq (digraph-find ?L ?F) ?\n))
>      (should (eq (digraph-find ?S ?P) ?\ )))
>
> This is also a good way to check edge cases, such as incomplete or
> invalid input. (Should it throw an error? Then verify it with
> `should-error'.)

OK, thanks.

The tests ran really slow on my computer (around 1.5 minutes).  Any
way of speeding them up?

> I haven't handled merge requests on Gitorious before; the common
> approach has been to commit the changes locally, export the commit
> with "git format-patch", and post the patch on the mailing list.
> Anyhow, I'll merge once I receive a reply to the questions above.

OK, I’ll do that in the future.