[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.