all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Some testing issues
@ 2017-07-07 21:22 Stephen Berman
  2017-07-08  4:20 ` Noam Postavsky
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Stephen Berman @ 2017-07-07 21:22 UTC (permalink / raw)
  To: emacs-devel

I installed some new tests for todo-mode.el in master c24748a and there
were a few problems that I don't understand; maybe someone here can
enlighten me.

Several of the tests call the function todo-toggle-view-done-items,
which contains this code:

	  (if (not (pos-visible-in-window-p shown))
	      (recenter)

(`shown' stores the position of the first done item in the category, if
it is shown.)  When using todo-mode and also when stepping through the
function with Edebug, it works as expected.  But when running the tests,
sometimes -- but not always -- it fails with the error "`recenter'ing a
window that does not display current-buffer."  In those cases, the test
failure is prevented by evaluating the following sexp immediately before
calling todo-toggle-view-done-items:

          (set-window-buffer nil (current-buffer))

When using todo-mode this is not necessary, because the selected window
always contains the current buffer when the function is called, but
apparently when running the tests, this isn't always the case, although
according to Edebug it is, AFAICT.  And again, the failure only happens
in some cases, though in those, it is reliably reproducible.  In
addition, in at least one case, when I rerun the test immediately after
it fails, then it succeeds.  And lastly, in one case, the test succeeds
without the set-window-buffer call when run interactively, but fails
without it when run in batch mode from the shell.  Any idea what's going
on here?  (If anyone wants to take a closer look, comments in the test
file point out the problematic cases.)

A second problem concerns trying to reference a message in a test.  The
function todo-toggle-view-done-items outputs a message if the category
contains no done items, and the test captures this by calling
current-message immediately after todo-toggle-view-done-items.  This
works when running the test interactively, but in a batch run,
current-message is nil (though the message is output in the shell).
Why?  (I avoid the failure in batch mode by testing a different but
effectively equivalent condition.)

Finally, one of the tests involves a display overlay that hides the item
header, which as a consequence, when using todo-mode, prevented the
cursor from appearing where the code put point, resulting in a display
bug.  I fixed this (in master 264dd81) by moving point to the first
visible position after the overlay.  But when running the test, the
overlay evidently does not inhibit point, but since the test, following
the bugfix code in todo-mode.el, assumes it does, it fails.  It seems
that the test environment does not reflect the same display mechanisms
that using the code does.  I haven't found a solution or workaround for
this, so the test is currently marked ":expected-result :failed".  I
hope someone can come up with a better alternative.

I'd be grateful for any suggestions or advice.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-07 21:22 Some testing issues Stephen Berman
@ 2017-07-08  4:20 ` Noam Postavsky
  2017-07-08 14:50   ` Stephen Berman
  2017-07-08  4:45 ` Stefan Monnier
  2017-07-08  7:18 ` martin rudalics
  2 siblings, 1 reply; 16+ messages in thread
From: Noam Postavsky @ 2017-07-08  4:20 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Emacs developers

On Fri, Jul 7, 2017 at 5:22 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
> Several of the tests call the function todo-toggle-view-done-items,
> which contains this code:
>
>           (if (not (pos-visible-in-window-p shown))
>               (recenter)
>
> (`shown' stores the position of the first done item in the category, if
> it is shown.)  When using todo-mode and also when stepping through the
> function with Edebug, it works as expected.

If I comment out the set-window-buffer call it fails for me in Edebug
as well (when running the first time).

By the way, in order to run successfully I did also need the following
patch, otherwise all the tests failed (I think it only happens for me
because I'm running from an Emacs that's living under my home
directory).

modified   test/lisp/calendar/todo-mode-tests.el
@@ -46,6 +46,7 @@ (defmacro with-todo-test (&rest body)
   "Set up an isolated todo-mode test environment."
   (declare (debug (body)))
   `(let* ((todo-test-home (make-temp-file "todo-test-home-" t))
+          (abbreviated-home-dir nil)
           (process-environment (cons (format "HOME=%s" todo-test-home)
                                      process-environment))
           (todo-directory todo-test-data-dir)

>  But when running the tests,
> sometimes -- but not always -- it fails with the error "`recenter'ing a
> window that does not display current-buffer."  In those cases, the test
> failure is prevented by evaluating the following sexp immediately before
> calling todo-toggle-view-done-items:
>
>           (set-window-buffer nil (current-buffer))
>
> When using todo-mode this is not necessary, because the selected window
> always contains the current buffer when the function is called, but
> apparently when running the tests, this isn't always the case, although
> according to Edebug it is, AFAICT.

When I evaluate (selected-window) in edebug before the call, I see
that the selected window is showing the *ert* buffer.

>  And again, the failure only happens
> in some cases, though in those, it is reliably reproducible.  In
> addition, in at least one case, when I rerun the test immediately after
> it fails, then it succeeds.

I think it succeeds the second time because the *ert* buffer is in a
different state.

>  And lastly, in one case, the test succeeds
> without the set-window-buffer call when run interactively, but fails
> without it when run in batch mode from the shell.  Any idea what's going
> on here?  (If anyone wants to take a closer look, comments in the test
> file point out the problematic cases.)

todo-test-toggle-item-header04? I added a `message' call, and it seems
that in batch mode the selected window shows *scratch* whereas in
interactive mode it shows *ert*. I would say the success in
interactive mode is just a coincidence.

>
> A second problem concerns trying to reference a message in a test.  The
> function todo-toggle-view-done-items outputs a message if the category
> contains no done items, and the test captures this by calling
> current-message immediately after todo-toggle-view-done-items.  This
> works when running the test interactively, but in a batch run,
> current-message is nil (though the message is output in the shell).
> Why?

I think it's simply that there is no echo-area or any concept of a
"current" message when running in batch mode.
lread-tests--last-message might be worth looking at:

(defun lread-tests--last-message ()
  (with-current-buffer "*Messages*"
    (save-excursion
      (goto-char (point-max))
      (skip-chars-backward "\n")
      (buffer-substring (line-beginning-position) (point)))))



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-07 21:22 Some testing issues Stephen Berman
  2017-07-08  4:20 ` Noam Postavsky
@ 2017-07-08  4:45 ` Stefan Monnier
  2017-07-08 14:52   ` Stephen Berman
  2017-07-08  7:18 ` martin rudalics
  2 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2017-07-08  4:45 UTC (permalink / raw)
  To: emacs-devel

> Several of the tests call the function todo-toggle-view-done-items,
> which contains this code:
>
> 	  (if (not (pos-visible-in-window-p shown))
> 	      (recenter)

This code is indeed brittle: pos-visible-in-window-p presumes that
(current-buffer) is the same as (window-buffer (selected-window)), but
that's not always the case.


        Stefan




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-07 21:22 Some testing issues Stephen Berman
  2017-07-08  4:20 ` Noam Postavsky
  2017-07-08  4:45 ` Stefan Monnier
@ 2017-07-08  7:18 ` martin rudalics
  2017-07-08 14:51   ` Stephen Berman
  2 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2017-07-08  7:18 UTC (permalink / raw)
  To: Stephen Berman, emacs-devel

 > And lastly, in one case, the test succeeds
 > without the set-window-buffer call when run interactively, but fails
 > without it when run in batch mode from the shell.  Any idea what's going
 > on here?  (If anyone wants to take a closer look, comments in the test
 > file point out the problematic cases.)

The interactive call might succeed because command_loop_1 makes the
selected window's buffer current in

       set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents));

Supposedly, testing ‘recenter’ doesn't make much sense without a frame.

 > A second problem concerns trying to reference a message in a test.  The
 > function todo-toggle-view-done-items outputs a message if the category
 > contains no done items, and the test captures this by calling
 > current-message immediately after todo-toggle-view-done-items.  This
 > works when running the test interactively, but in a batch run,
 > current-message is nil (though the message is output in the shell).
 > Why?  (I avoid the failure in batch mode by testing a different but
 > effectively equivalent condition.)

‘current-message’ returns "the string currently displayed in the echo
area" and there's no echo area in batch mode.

 > Finally, one of the tests involves a display overlay that hides the item
 > header, which as a consequence, when using todo-mode, prevented the
 > cursor from appearing where the code put point, resulting in a display
 > bug.  I fixed this (in master 264dd81) by moving point to the first
 > visible position after the overlay.  But when running the test, the
 > overlay evidently does not inhibit point, but since the test, following
 > the bugfix code in todo-mode.el, assumes it does, it fails.  It seems
 > that the test environment does not reflect the same display mechanisms
 > that using the code does.  I haven't found a solution or workaround for
 > this, so the test is currently marked ":expected-result :failed".  I
 > hope someone can come up with a better alternative.

You need a frame to display something and there's none in batch mode.
Hence you can't test display features in batch mode.

martin




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08  4:20 ` Noam Postavsky
@ 2017-07-08 14:50   ` Stephen Berman
  2017-07-08 22:01     ` Noam Postavsky
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2017-07-08 14:50 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Emacs developers

On Sat, 8 Jul 2017 00:20:23 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Fri, Jul 7, 2017 at 5:22 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
>> Several of the tests call the function todo-toggle-view-done-items,
>> which contains this code:
>>
>>           (if (not (pos-visible-in-window-p shown))
>>               (recenter)
>>
>> (`shown' stores the position of the first done item in the category, if
>> it is shown.)  When using todo-mode and also when stepping through the
>> function with Edebug, it works as expected.
>
> If I comment out the set-window-buffer call it fails for me in Edebug
> as well (when running the first time).

You're right, I must have misrembered or been thinking of a different
case; sorry.

> By the way, in order to run successfully I did also need the following
> patch, otherwise all the tests failed (I think it only happens for me
> because I'm running from an Emacs that's living under my home
> directory).
>
> modified   test/lisp/calendar/todo-mode-tests.el
> @@ -46,6 +46,7 @@ (defmacro with-todo-test (&rest body)
>    "Set up an isolated todo-mode test environment."
>    (declare (debug (body)))
>    `(let* ((todo-test-home (make-temp-file "todo-test-home-" t))
> +          (abbreviated-home-dir nil)
>            (process-environment (cons (format "HOME=%s" todo-test-home)
>                                       process-environment))
>            (todo-directory todo-test-data-dir)

The only test file that sets abbreviated-home-dir is package-test.el, in
the macro with-package-test, which was indeed the inspiration for
with-todo-test.  I assume this would only effect cases like yours, and
hence make the test environment more robust, or are possible problems
that setting it to nil could raise?

>>  But when running the tests,
>> sometimes -- but not always -- it fails with the error "`recenter'ing a
>> window that does not display current-buffer."  In those cases, the test
>> failure is prevented by evaluating the following sexp immediately before
>> calling todo-toggle-view-done-items:
>>
>>           (set-window-buffer nil (current-buffer))
>>
>> When using todo-mode this is not necessary, because the selected window
>> always contains the current buffer when the function is called, but
>> apparently when running the tests, this isn't always the case, although
>> according to Edebug it is, AFAICT.
>
> When I evaluate (selected-window) in edebug before the call, I see
> that the selected window is showing the *ert* buffer.

Yes, I should have checked again before posting that.

>>  And again, the failure only happens
>> in some cases, though in those, it is reliably reproducible.  In
>> addition, in at least one case, when I rerun the test immediately after
>> it fails, then it succeeds.
>
> I think it succeeds the second time because the *ert* buffer is in a
> different state.

What state is that?  In Edebug it appears to be the same as on the first
test run: current-buffer is todo-test-1.todo and selected-window is the
one showing the *ert* buffer, yet now (pos-visible-in-window-p shown) is
non-nil, while on the first run it is nil.  I don't see what makes the
difference -- certainly not the value of the variable `shown', which is
226 and that position in window displaying *ert* is visible in both runs.

>>  And lastly, in one case, the test succeeds
>> without the set-window-buffer call when run interactively, but fails
>> without it when run in batch mode from the shell.  Any idea what's going
>> on here?  (If anyone wants to take a closer look, comments in the test
>> file point out the problematic cases.)
>
> todo-test-toggle-item-header04? I added a `message' call, and it seems
> that in batch mode the selected window shows *scratch* whereas in
> interactive mode it shows *ert*. I would say the success in
> interactive mode is just a coincidence.

Well, it's a reliably reproducible coincidence, which seems like a
contradiction in terms.

>> A second problem concerns trying to reference a message in a test.  The
>> function todo-toggle-view-done-items outputs a message if the category
>> contains no done items, and the test captures this by calling
>> current-message immediately after todo-toggle-view-done-items.  This
>> works when running the test interactively, but in a batch run,
>> current-message is nil (though the message is output in the shell).
>> Why?
>
> I think it's simply that there is no echo-area or any concept of a
> "current" message when running in batch mode.

Yes, as Martin also pointed out; I didn't realize (or stop to think
about) that.

> lread-tests--last-message might be worth looking at:
>
> (defun lread-tests--last-message ()
>   (with-current-buffer "*Messages*"
>     (save-excursion
>       (goto-char (point-max))
>       (skip-chars-backward "\n")
>       (buffer-substring (line-beginning-position) (point)))))

Thanks for the pointer, and for the feedback.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08  7:18 ` martin rudalics
@ 2017-07-08 14:51   ` Stephen Berman
  2017-07-09  7:46     ` martin rudalics
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2017-07-08 14:51 UTC (permalink / raw)
  To: martin rudalics; +Cc: emacs-devel

On Sat, 08 Jul 2017 09:18:08 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> And lastly, in one case, the test succeeds
>> without the set-window-buffer call when run interactively, but fails
>> without it when run in batch mode from the shell.  Any idea what's going
>> on here?  (If anyone wants to take a closer look, comments in the test
>> file point out the problematic cases.)
>
> The interactive call might succeed because command_loop_1 makes the
> selected window's buffer current in
>
>       set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents));
>
> Supposedly, testing ‘recenter’ doesn't make much sense without a frame.

True, though when I step through the code in the interactive test, the
condition (pos-visible-in-window-p shown) is true, so recenter is not
called; so the question to me is why this is not the case in the batch run.

>> A second problem concerns trying to reference a message in a test.  The
>> function todo-toggle-view-done-items outputs a message if the category
>> contains no done items, and the test captures this by calling
>> current-message immediately after todo-toggle-view-done-items.  This
>> works when running the test interactively, but in a batch run,
>> current-message is nil (though the message is output in the shell).
>> Why?  (I avoid the failure in batch mode by testing a different but
>> effectively equivalent condition.)
>
> ‘current-message’ returns "the string currently displayed in the echo
> area" and there's no echo area in batch mode.

Yes, as Noam also pointed out; I didn't think carefully enough about the
use of current-message.

>> Finally, one of the tests involves a display overlay that hides the item
>> header, which as a consequence, when using todo-mode, prevented the
>> cursor from appearing where the code put point, resulting in a display
>> bug.  I fixed this (in master 264dd81) by moving point to the first
>> visible position after the overlay.  But when running the test, the
>> overlay evidently does not inhibit point, but since the test, following
>> the bugfix code in todo-mode.el, assumes it does, it fails.  It seems
>> that the test environment does not reflect the same display mechanisms
>> that using the code does.  I haven't found a solution or workaround for
>> this, so the test is currently marked ":expected-result :failed".  I
>> hope someone can come up with a better alternative.
>
> You need a frame to display something and there's none in batch mode.
> Hence you can't test display features in batch mode.

Thanks for clarifying that for me.  I guess I'll have to leave such
features untested, or is there an alternative?

Thanks for the feedback.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08  4:45 ` Stefan Monnier
@ 2017-07-08 14:52   ` Stephen Berman
  2017-07-10 17:33     ` Stefan Monnier
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2017-07-08 14:52 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On Sat, 08 Jul 2017 00:45:10 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Several of the tests call the function todo-toggle-view-done-items,
>> which contains this code:
>>
>> 	  (if (not (pos-visible-in-window-p shown))
>> 	      (recenter)
>
> This code is indeed brittle: pos-visible-in-window-p presumes that
> (current-buffer) is the same as (window-buffer (selected-window)), but
> that's not always the case.

Is there a less brittle way to test the visibility of point?  At least
as far as using todo-toggle-view-done-items in todo-mode in concerned,
(current-buffer) is equivalent to (window-buffer (selected-window)), but
apparently that is not so in the test environment.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08 14:50   ` Stephen Berman
@ 2017-07-08 22:01     ` Noam Postavsky
  2017-07-14  9:55       ` Stephen Berman
  0 siblings, 1 reply; 16+ messages in thread
From: Noam Postavsky @ 2017-07-08 22:01 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Emacs developers

On Sat, Jul 8, 2017 at 10:50 AM, Stephen Berman <stephen.berman@gmx.net> wrote:
>>    `(let* ((todo-test-home (make-temp-file "todo-test-home-" t))
>> +          (abbreviated-home-dir nil)
>>            (process-environment (cons (format "HOME=%s" todo-test-home)
>>                                       process-environment))
>
> The only test file that sets abbreviated-home-dir is package-test.el, in
> the macro with-package-test, which was indeed the inspiration for
> with-todo-test.  I assume this would only effect cases like yours, and
> hence make the test environment more robust, or are possible problems
> that setting it to nil could raise?

abbreviated-home-dir is essentially a cache used by
abbreviate-file-name, and when the value of HOME is changed the cached
value is wrong, hence why setting it to nil is the right thing.
Possibly we should record the value of HOME we cached and clear it
automatically when a new one is used so that this kind of thing is not
needed.

>>
>> I think it succeeds the second time because the *ert* buffer is in a
>> different state.
>
> What state is that?  In Edebug it appears to be the same as on the first
> test run: current-buffer is todo-test-1.todo and selected-window is the
> one showing the *ert* buffer, yet now (pos-visible-in-window-p shown) is
> non-nil, while on the first run it is nil.  I don't see what makes the
> difference -- certainly not the value of the variable `shown', which is
> 226 and that position in window displaying *ert* is visible in both runs.

Maybe the set-window-buffer from the other tests leaks in? For some
reason I can't reproduce this today, every time I run with the
set-window-buffer commented out it consistently fails. I'm sure
yesterday I saw it succeeding after the first time.

>> todo-test-toggle-item-header04? I added a `message' call, and it seems
>> that in batch mode the selected window shows *scratch* whereas in
>> interactive mode it shows *ert*. I would say the success in
>> interactive mode is just a coincidence.
>
> Well, it's a reliably reproducible coincidence, which seems like a
> contradiction in terms.

I mean "coincidence" in the same way that the 5th digit of pi being 5
is a "coincidence" (slightly less reliable than that though,
presumably if we made `initial-scratch-message' long enough the batch
mode behaviour would change).



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08 14:51   ` Stephen Berman
@ 2017-07-09  7:46     ` martin rudalics
  2017-07-14  9:55       ` Stephen Berman
  0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2017-07-09  7:46 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

 > True, though when I step through the code in the interactive test, the
 > condition (pos-visible-in-window-p shown) is true, so recenter is not
 > called; so the question to me is why this is not the case in the batch run.

‘pos-visible-in-window-p’ is specified as

DEFUN ("pos-visible-in-window-p", Fpos_visible_in_window_p,
   ...
   Lisp_Object in_window = Qnil;

   ...
   return in_window;

so if none of the conditions it checks succeeds, it will return nil.

 > Thanks for clarifying that for me.  I guess I'll have to leave such
 > features untested, or is there an alternative?

You can wrap them in a (skip-unless (display-graphic-p)) which means
that they are allowed to fail in interactive use only.

martin




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08 14:52   ` Stephen Berman
@ 2017-07-10 17:33     ` Stefan Monnier
  2017-07-14  9:56       ` Stephen Berman
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2017-07-10 17:33 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

> Is there a less brittle way to test the visibility of point?

Of course, but you first have to use a less brittle question:
which "point"?  If you just use "point" it normally refer to a location
in the current buffer regardless of any window and hence "visibility"
is ill-defined.  So to make it less brittle, you first have to
explicitly select the window that interests you (i.e. look for a window
which displays the current buffer).


        Stefan



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-08 22:01     ` Noam Postavsky
@ 2017-07-14  9:55       ` Stephen Berman
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Berman @ 2017-07-14  9:55 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Emacs developers

On Sat, 8 Jul 2017 18:01:12 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Sat, Jul 8, 2017 at 10:50 AM, Stephen Berman <stephen.berman@gmx.net> wrote:
>>>    `(let* ((todo-test-home (make-temp-file "todo-test-home-" t))
>>> +          (abbreviated-home-dir nil)
>>>            (process-environment (cons (format "HOME=%s" todo-test-home)
>>>                                       process-environment))
>>
>> The only test file that sets abbreviated-home-dir is package-test.el, in
>> the macro with-package-test, which was indeed the inspiration for
>> with-todo-test.  I assume this would only effect cases like yours, and
>> hence make the test environment more robust, or are possible problems
>> that setting it to nil could raise?
>
> abbreviated-home-dir is essentially a cache used by
> abbreviate-file-name, and when the value of HOME is changed the cached
> value is wrong, hence why setting it to nil is the right thing.
> Possibly we should record the value of HOME we cached and clear it
> automatically when a new one is used so that this kind of thing is not
> needed.

In the mean time, it sounds like setting it to nil is appropriate.

>>>
>>> I think it succeeds the second time because the *ert* buffer is in a
>>> different state.
>>
>> What state is that?  In Edebug it appears to be the same as on the first
>> test run: current-buffer is todo-test-1.todo and selected-window is the
>> one showing the *ert* buffer, yet now (pos-visible-in-window-p shown) is
>> non-nil, while on the first run it is nil.  I don't see what makes the
>> difference -- certainly not the value of the variable `shown', which is
>> 226 and that position in window displaying *ert* is visible in both runs.
>
> Maybe the set-window-buffer from the other tests leaks in? For some
> reason I can't reproduce this today, every time I run with the
> set-window-buffer commented out it consistently fails. I'm sure
> yesterday I saw it succeeding after the first time.

There should be no leakage, because the state is cleared after each
individual test run (at least, that's what with-todo-test is supposed to
do).

>>> todo-test-toggle-item-header04? I added a `message' call, and it seems
>>> that in batch mode the selected window shows *scratch* whereas in
>>> interactive mode it shows *ert*. I would say the success in
>>> interactive mode is just a coincidence.
>>
>> Well, it's a reliably reproducible coincidence, which seems like a
>> contradiction in terms.
>
> I mean "coincidence" in the same way that the 5th digit of pi being 5
> is a "coincidence" (slightly less reliable than that though,
> presumably if we made `initial-scratch-message' long enough the batch
> mode behaviour would change).

Ah, ok.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-09  7:46     ` martin rudalics
@ 2017-07-14  9:55       ` Stephen Berman
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Berman @ 2017-07-14  9:55 UTC (permalink / raw)
  To: martin rudalics; +Cc: Stephen Berman, emacs-devel

On Sun, 09 Jul 2017 09:46:10 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> True, though when I step through the code in the interactive test, the
>> condition (pos-visible-in-window-p shown) is true, so recenter is not
>> called; so the question to me is why this is not the case in the batch run.
>
> ‘pos-visible-in-window-p’ is specified as
>
> DEFUN ("pos-visible-in-window-p", Fpos_visible_in_window_p,
>   ...
>   Lisp_Object in_window = Qnil;
>
>   ...
>   return in_window;
>
> so if none of the conditions it checks succeeds, it will return nil.

I see; thanks.

>> Thanks for clarifying that for me.  I guess I'll have to leave such
>> features untested, or is there an alternative?
>
> You can wrap them in a (skip-unless (display-graphic-p)) which means
> that they are allowed to fail in interactive use only.

Seems like a good idea; thanks for the pointer.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-10 17:33     ` Stefan Monnier
@ 2017-07-14  9:56       ` Stephen Berman
  2017-07-14 13:44         ` Stefan Monnier
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2017-07-14  9:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On Mon, 10 Jul 2017 13:33:15 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Is there a less brittle way to test the visibility of point?
>
> Of course, but you first have to use a less brittle question:
> which "point"?  If you just use "point" it normally refer to a location
> in the current buffer regardless of any window and hence "visibility"
> is ill-defined.  So to make it less brittle, you first have to
> explicitly select the window that interests you (i.e. look for a window
> which displays the current buffer).

Well, as I noted, when pos-visible-in-window-p is called in
todo-toggle-view-done-items, the selected window is displaying the
current buffer and AFAICT that can't go wrong when using todo-mode as
intended (i.e., not invoking todo-toggle-view-done-items outside of
todo-mode).  So I don't see any need to explicitly select the window
here.  In the test environment, however, that seems not to be an
invariant, so calling set-window-buffer is apparently needed.

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-14  9:56       ` Stephen Berman
@ 2017-07-14 13:44         ` Stefan Monnier
  2017-07-17 10:02           ` Stephen Berman
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2017-07-14 13:44 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

> Well, as I noted, when pos-visible-in-window-p is called in
> todo-toggle-view-done-items, the selected window is displaying the
> current buffer and AFAICT that can't go wrong when using todo-mode as
> intended (i.e., not invoking todo-toggle-view-done-items outside of
> todo-mode).

Then I suggest you add a (cl-assert (eq (current-buffer)
(window-buffer))) and then declare that it's the caller's responsibility
(e.g. the test environment) to make sure this is true.

This said, another approach is to say that `recenter` is simply not
needed in case the buffer is not displayed anywhere (which could
presumably happen if you call this code from some ad-hoc Elisp
function), so if (eq (current-buffer) (window-buffer)) is nil, just
don't bother checking visibility nor recentering.


        Stefan



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-14 13:44         ` Stefan Monnier
@ 2017-07-17 10:02           ` Stephen Berman
  2017-07-17 18:22             ` Stefan Monnier
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2017-07-17 10:02 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On Fri, 14 Jul 2017 09:44:10 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> Well, as I noted, when pos-visible-in-window-p is called in
>> todo-toggle-view-done-items, the selected window is displaying the
>> current buffer and AFAICT that can't go wrong when using todo-mode as
>> intended (i.e., not invoking todo-toggle-view-done-items outside of
>> todo-mode).
>
> Then I suggest you add a (cl-assert (eq (current-buffer)
> (window-buffer))) and then declare that it's the caller's responsibility
> (e.g. the test environment) to make sure this is true.

The tests have assumed this responsibility with the invocation of
set-window-buffer.

> This said, another approach is to say that `recenter` is simply not
> needed in case the buffer is not displayed anywhere (which could
> presumably happen if you call this code from some ad-hoc Elisp
> function), so if (eq (current-buffer) (window-buffer)) is nil, just
> don't bother checking visibility nor recentering.

If I'm not misunderstanding you, I think adding this check, or the above
assertion, to this defun in todo-mode.el is an unwarrented precaution,
because it assumes a use of todo-toggle-view-done-items other than the
one it was defined for.  In principle that's possible, but the same goes
for any Elisp command, and the vast majority of them surely take no such
precautions.  There are a few todo-mode commands that are intended to be
called from outside of todo-mode, and for these I have tried to make
sure they DTRT, but for the others, as with most specialized elisp
commands, don't you think it's reasonable, and sufficient, to rely on
the user's common sense?  (The case of tests is, of course, different,
but as you note, it is (or should be) their responsibility to satisfy
the assumptions of the code being tested, I think even if the
assumptions aren't made explicit in the code.)

Steve Berman



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Some testing issues
  2017-07-17 10:02           ` Stephen Berman
@ 2017-07-17 18:22             ` Stefan Monnier
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2017-07-17 18:22 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

> If I'm not misunderstanding you, I think adding this check, or the above
> assertion, to this defun in todo-mode.el is an unwarrented precaution,

I don't understand enough of the overall use of the code to
know which of the two options is best.  If I had to choose, I'd ask you,


        Stefan



^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-07-17 18:22 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-07 21:22 Some testing issues Stephen Berman
2017-07-08  4:20 ` Noam Postavsky
2017-07-08 14:50   ` Stephen Berman
2017-07-08 22:01     ` Noam Postavsky
2017-07-14  9:55       ` Stephen Berman
2017-07-08  4:45 ` Stefan Monnier
2017-07-08 14:52   ` Stephen Berman
2017-07-10 17:33     ` Stefan Monnier
2017-07-14  9:56       ` Stephen Berman
2017-07-14 13:44         ` Stefan Monnier
2017-07-17 10:02           ` Stephen Berman
2017-07-17 18:22             ` Stefan Monnier
2017-07-08  7:18 ` martin rudalics
2017-07-08 14:51   ` Stephen Berman
2017-07-09  7:46     ` martin rudalics
2017-07-14  9:55       ` Stephen Berman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.