25.0.50.1, ert: (should (bolp)) fails in batch-mode

25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Andreas Röhler]

Hi,

noticed a form

(should (bolp))

failed in ert test when called in batch-mode, while

(should (eq 0 (current-indentation)))

succeeded.

Any explanation?

See

https://travis-ci.org/emacs-berlin/general-close/builds

Thanks,

Andreas

GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.23) of 2015-08-27

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Nicolas Richard]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> noticed a form
>
> (should (bolp))
>
> failed in ert test when called in batch-mode, while
>
> (should (eq 0 (current-indentation)))

This is not about the current position : it only checks that the first
character of the line is not a whitespace character.

-- 
Nico.

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Andreas Röhler]

Am 18.09.2015 um 13:10 schrieb Nicolas Richard:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>> noticed a form
>>
>> (should (bolp))
>>
>> failed in ert test when called in batch-mode, while
>>
>> (should (eq 0 (current-indentation)))
> This is not about the current position : it only checks that the first
> character of the line is not a whitespace character.
>

Okay, thanks.

In this case position is at BOL, why (bolp) fails from batch-mode?
Test succeeds when called interactively.

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Eli Zaretskii]

> Date: Fri, 18 Sep 2015 15:51:11 +0200
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> 
> In this case position is at BOL, why (bolp) fails from batch-mode?
> Test succeeds when called interactively.

Can you show a test case for that?

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Andreas Röhler]

Am 18.09.2015 um 16:09 schrieb Eli Zaretskii:
>> Date: Fri, 18 Sep 2015 15:51:11 +0200
>> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
>> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
>>
>> In this case position is at BOL, why (bolp) fails from batch-mode?
>> Test succeeds when called interactively.
> Can you show a test case for that?
>
>

It's here:

https://travis-ci.org/emacs-berlin/general-close/builds

For now the failing commit is that before the last one.

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Tassilo Horn]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

>>> In this case position is at BOL, why (bolp) fails from batch-mode?
>>> Test succeeds when called interactively.
>> Can you show a test case for that?
>>
>>
>
> It's here:
>
> https://travis-ci.org/emacs-berlin/general-close/builds
>
> For now the failing commit is that before the last one.

This is no test case, it is a build report which also links to you tests
but those are not easily understandable.

Can you provide some minimal and isolated test case which shows the
problem?  Something like:

--8<---------------cut here---------------start------------->8---
(ert-deftest test-bolp ()
  (with-current-buffer (get-buffer "*scratch*")
    (goto-char (point-min))
    (should (bolp))
    (while (not (= 1 (forward-line 1)))
      (should (bolp)))
    (while (not (= -1 (forward-line -1)))
      (should (bolp)))))
--8<---------------cut here---------------end--------------->8---

That succeeds interactively and also in batch-mode.

I guess the problem in your setting is that it depends on your
customization if you end up at BOL in your tests.  Do your tests also
fail in an interactive session with emacs -Q?

Bye,
Tassilo

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Eli Zaretskii]

> Date: Sat, 19 Sep 2015 08:36:21 +0200
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> 
> 
> Am 18.09.2015 um 16:09 schrieb Eli Zaretskii:
> >> Date: Fri, 18 Sep 2015 15:51:11 +0200
> >> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> >> Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
> >>
> >> In this case position is at BOL, why (bolp) fails from batch-mode?
> >> Test succeeds when called interactively.
> > Can you show a test case for that?
> >
> >
> 
> It's here:
> 
> https://travis-ci.org/emacs-berlin/general-close/builds
> 
> For now the failing commit is that before the last one.

Sorry, I cannot make heads or tails out of that.  What I see is diffs
from a commit to some project that's unknown to me; what I asked for
was some simple test case one can run in "emacs -batch" and perhaps
debug it.

Is it possible to show something simpler, please?

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Andreas Röhler]

Am 19.09.2015 um 09:28 schrieb Eli Zaretskii:
>> Date: Sat, 19 Sep 2015 08:36:21 +0200

Assume test fails because

(font-lock-fontify-buffer)

doesn't work in batch-mode.

I.e. current implementation of general-close relies on face here - which 
should be changed.

;;;;;;;

(ert-deftest general-close-python-colon-test-2 ()
   (general-close-test-with-python-buffer
       "class TutorialApp(App):
     def build(self):
         return Button(text=\"Hello!\",
                       background_color=(0, 0, 1, 1)
                       font_size=150)
if __name__ == \"__main__\""
     (font-lock-fontify-buffer)
     (general-close)
     (should (eq (char-before) ?:))
     (should (eq 0 (current-indentation)))))

;;;;;;;

Thanks all!

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Stefan Monnier]

> Assume test fails because
> (font-lock-fontify-buffer)
> doesn't work in batch-mode.

Not sure if it'll help, but you should use font-lock-ensure instead
when available (new in Emacs-25).


        Stefan

Re: 25.0.50.1, ert: (should (bolp)) fails in batch-mode

[Andreas Röhler]

Am 19.09.2015 um 22:08 schrieb Stefan Monnier:
>> Assume test fails because
>> (font-lock-fontify-buffer)
>> doesn't work in batch-mode.
> Not sure if it'll help, but you should use font-lock-ensure instead
> when available (new in Emacs-25).
>
>
>          Stefan
>
>

Hmm, thx, however: looks redundant to font-lock-fontify-region.

Will make a new thread for that.

BTW the question here is if ert may deal with fontification - seems not.