[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Learning something more about Emacs tests

From: Eli Zaretskii
Subject: Re: Learning something more about Emacs tests
Date: Fri, 18 Dec 2015 21:30:31 +0200

> From: Lele Gaifax <address@hidden>
> Date: Fri, 18 Dec 2015 18:34:45 +0100
>   (ert-deftest tabulated-list-visual-move ()
>     ;; See Bug#22194
>     (tabulated-list--test-with-buffer
>      (goto-char (point-min))
>      (skip-chars-forward "[:blank:]")
>      (skip-chars-forward "[:word:]-")
>      (backward-char)
>      ;; now the cursor is on the ending “e” of “zzzz-game”
>      (funcall-interactively 'next-line 3)
>      (funcall-interactively 'next-line)
>      (should (equal (line-number-at-pos (point)) 5))))
> To my surprise, this test passes, either before or after Eli's fix. I tried
> several variants in the way I call the next-line function, but either moving
> one line at at time or in two steps like I did above, I was not able to
> reproduce the initial bug case.
> Even executing it interactively, there is some "subtle" difference in hitting
> the “n” key (bound to next-line) and doing that with “M-: 
> (funcall-interactively 'next-line)”.
> *Before* Eli's fix, in the latter case after the second evaluation the cursor
> ends at column 1 (ie just before the package name) and stays there in the
> succeeding evaluations. *After* the fix, it goes at column 7 (that is, one
> space after the name “mode”) and stays there.
> On the other hand, using the “n” key to invoke it, before the fix it exhibit
> the behaviour described in the bug report, while now it honors the goal-column
> (or something similar): if the package name on the current line is longer than
> the first one, the cursor stays at the initial column.
> What am I doing wrong? How can I programmatically exercise the next-line
> function retaining the interactive behaviour?

Your problem is not interactive call, your problem is interactive
_session_.  When the variable noninteractive is non-nil, both
line-move (called by next-line) and vertical-motion behave
differently: they move by physical lines, not screen lines.  So the
bug, which was in the code that moves by visual lines, doesn't happen.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]