all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
@ 2022-07-26  3:42 Michael Heerdegen
  2022-07-26 12:31 ` Lars Ingebrigtsen
  2022-07-27  9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 20+ messages in thread
From: Michael Heerdegen @ 2022-07-26  3:42 UTC (permalink / raw)
  To: 56773


Hello,

emacs -Q:

(progn (readablep (current-window-configuration))
       (current-buffer))
==> #<buffer  prin1>

After evaluating such a `readablep' call, weird things can happen
because of this buffer being current.  I tried to actually display that
buffer and the window I got looked quite funny, one second later Emacs
had crashed.

TIA,

Michael.


In GNU Emacs 29.0.50 (build 31, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-07-26 built on drachen
Repository revision: c455023f93f5073e7032a2097821e23eafa6f1aa
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26  3:42 bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things Michael Heerdegen
@ 2022-07-26 12:31 ` Lars Ingebrigtsen
  2022-07-26 12:39   ` Eli Zaretskii
  2022-07-27  9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-26 12:31 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 56773

Michael Heerdegen <michael_heerdegen@web.de> writes:

> (progn (readablep (current-window-configuration))
>        (current-buffer))
> ==> #<buffer  prin1>
>
> After evaluating such a `readablep' call, weird things can happen
> because of this buffer being current.  I tried to actually display that
> buffer and the window I got looked quite funny, one second later Emacs
> had crashed.

Oops.

The problem is trivial to fix in `unreadablep' (just smack a
`save-excursion' in there), but I think this should be fixed in a better
way.  The problem is that PRINTPREPARE sets the current buffer to the
super-duper secret buffer Vprin1_to_string_buffer (i.e., " prin1"), and
we should restore the real buffer before calling
`print-unreadable-function' in `print_vectorlike'.

But which buffer that was doesn't seem to be available at that point --
it's just stored in

#define PRINTPREPARE							\
   struct buffer *old = current_buffer;					\

So we'd need to store that in a way we can access it later, but I'm not
sure where/how it'd make the most sense to do so...  Any ideas?

Meanwhile I've pushed a failing test for this to the trunk.






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26 12:31 ` Lars Ingebrigtsen
@ 2022-07-26 12:39   ` Eli Zaretskii
  2022-07-26 12:44     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2022-07-26 12:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: michael_heerdegen, 56773

> Cc: 56773@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 26 Jul 2022 14:31:19 +0200
> 
> So we'd need to store that in a way we can access it later, but I'm not
> sure where/how it'd make the most sense to do so...  Any ideas?

unwind_protect?





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26 12:39   ` Eli Zaretskii
@ 2022-07-26 12:44     ` Lars Ingebrigtsen
  2022-07-26 13:12       ` Eli Zaretskii
  2022-07-27  9:41       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-26 12:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 56773

Eli Zaretskii <eliz@gnu.org> writes:

> unwind_protect?

Where would the unwind_protect be?

The problem is here:

  if (!NILP (Vprint_unreadable_function)
      && FUNCTIONP (Vprint_unreadable_function))
    {
      specpdl_ref count = SPECPDL_INDEX ();
      /* Bind `print-unreadable-function' to nil to avoid accidental
	 infinite recursion in the function called.  */
      Lisp_Object func = Vprint_unreadable_function;
      specbind (Qprint_unreadable_function, Qnil);
      Lisp_Object result = CALLN (Ffuncall, func, obj,
				  escapeflag? Qt: Qnil);

We need to switch back to the original buffer before that Ffuncall, but
we don't know what the original function was -- it's just stored in a
local variable in prin1(-to-string).






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26 12:44     ` Lars Ingebrigtsen
@ 2022-07-26 13:12       ` Eli Zaretskii
  2022-07-26 13:24         ` Lars Ingebrigtsen
  2022-07-27  9:41       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2022-07-26 13:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: michael_heerdegen, 56773

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: michael_heerdegen@web.de,  56773@debbugs.gnu.org
> Date: Tue, 26 Jul 2022 14:44:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > unwind_protect?
> 
> Where would the unwind_protect be?
> 
> The problem is here:
> 
>   if (!NILP (Vprint_unreadable_function)
>       && FUNCTIONP (Vprint_unreadable_function))
>     {
>       specpdl_ref count = SPECPDL_INDEX ();
>       /* Bind `print-unreadable-function' to nil to avoid accidental
> 	 infinite recursion in the function called.  */
>       Lisp_Object func = Vprint_unreadable_function;
>       specbind (Qprint_unreadable_function, Qnil);
>       Lisp_Object result = CALLN (Ffuncall, func, obj,
> 				  escapeflag? Qt: Qnil);
> 
> We need to switch back to the original buffer before that Ffuncall, but
> we don't know what the original function was -- it's just stored in a
> local variable in prin1(-to-string).

I'm confused: "original function" or "original buffer"?

The original buffer is given by current_buffer before you call the
function which could change that, and the unwind_protect call should
be before calling that function.

But you already know all that, so I'm afraid I'm missing something
here.





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26 13:12       ` Eli Zaretskii
@ 2022-07-26 13:24         ` Lars Ingebrigtsen
  2022-07-27  9:30           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-26 13:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 56773

Eli Zaretskii <eliz@gnu.org> writes:

> I'm confused: "original function" or "original buffer"?

Original buffer.

> The original buffer is given by current_buffer before you call the
> function which could change that, and the unwind_protect call should
> be before calling that function.
>
> But you already know all that, so I'm afraid I'm missing something
> here.

Yes -- look at the call sequence from prin1-to-string and down to where
we're calling the function.  The buffer that was current when
prin1-to-string was called is not available from print_vectorlike, as
far as I can see.






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26 13:24         ` Lars Ingebrigtsen
@ 2022-07-27  9:30           ` Lars Ingebrigtsen
  0 siblings, 0 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-27  9:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, 56773

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes -- look at the call sequence from prin1-to-string and down to where
> we're calling the function.  The buffer that was current when
> prin1-to-string was called is not available from print_vectorlike, as
> far as I can see.

That is -- there's two things that have to be fixed.  The first thing
(which I was talking about here) is that the current_buffer has to be
made available way down in print_vectorlike, so that we don't call the
callback from the " prin1" buffer, because that's really confusing.  I
think we can accomplish that by specbinding some variable in
PRINTPREPARE.

The other thing is that we have to ensure that the stuff in PRINTFINISH
is actually done when we have a non-local exit, and putting that stuff
in an unwind_protect should fix that.  I.e., PRINTPREPARE sets up the
unwind_protect, of course.

And when doing that, we might as well get rid of the macros altogether
and do this more traditionally via functions.

Does anybody see any obvious disadvantages to doing it this way?  I
guess it could potentially make calls to `prin1' (etc) slower, but I
don't know whether that'd be noticeable.







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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26 12:44     ` Lars Ingebrigtsen
  2022-07-26 13:12       ` Eli Zaretskii
@ 2022-07-27  9:41       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-27  9:51         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-27  9:41 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: michael_heerdegen, Eli Zaretskii, 56773

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> unwind_protect?
>
> Where would the unwind_protect be?
>
> The problem is here:
>
>   if (!NILP (Vprint_unreadable_function)
>       && FUNCTIONP (Vprint_unreadable_function))
>     {
>       specpdl_ref count = SPECPDL_INDEX ();
>       /* Bind `print-unreadable-function' to nil to avoid accidental
> 	 infinite recursion in the function called.  */
>       Lisp_Object func = Vprint_unreadable_function;
>       specbind (Qprint_unreadable_function, Qnil);
>       Lisp_Object result = CALLN (Ffuncall, func, obj,
> 				  escapeflag? Qt: Qnil);
>
> We need to switch back to the original buffer before that Ffuncall, but
> we don't know what the original function was -- it's just stored in a
> local variable in prin1(-to-string).

Isn't that problem already present?  IOW, that function is still called
in the internal buffer under the current code.





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-26  3:42 bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things Michael Heerdegen
  2022-07-26 12:31 ` Lars Ingebrigtsen
@ 2022-07-27  9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-27  9:58   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-27  9:41 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 56773

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Hello,
>
> emacs -Q:
>
> (progn (readablep (current-window-configuration))
>        (current-buffer))
> ==> #<buffer  prin1>
>
> After evaluating such a `readablep' call, weird things can happen
> because of this buffer being current.  I tried to actually display that
> buffer and the window I got looked quite funny, one second later Emacs
> had crashed.

Thanks, should be fixed now.





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-27  9:41       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-27  9:51         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-27  9:51 UTC (permalink / raw)
  To: Po Lu; +Cc: michael_heerdegen, Eli Zaretskii, 56773

Po Lu <luangruo@yahoo.com> writes:

>> We need to switch back to the original buffer before that Ffuncall, but
>> we don't know what the original function was -- it's just stored in a
>> local variable in prin1(-to-string).
>
> Isn't that problem already present?  IOW, that function is still called
> in the internal buffer under the current code.

I'm not sure what you mean?  That's the problem I'm pointing out, and
asking for suggestions in how to fix.






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-27  9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-27  9:58   ` Lars Ingebrigtsen
  2022-07-27 11:57     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-27  9:58 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Po Lu, 56773

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Thanks, should be fixed now.

The other bits in PRINTFINISH aren't done, though, are they?  For
instance, the

   if (free_print_buffer)						\
     {									\
       xfree (print_buffer);						\
       print_buffer = 0;						\
     }									\

bits might lead to a memory leak.






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-27  9:58   ` Lars Ingebrigtsen
@ 2022-07-27 11:57     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-28  1:47       ` Michael Heerdegen
  2022-07-28  9:48       ` Lars Ingebrigtsen
  0 siblings, 2 replies; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-27 11:57 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Heerdegen, 56773

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Thanks, should be fixed now.
>
> The other bits in PRINTFINISH aren't done, though, are they?  For
> instance, the
>
>    if (free_print_buffer)						\
>      {									\
>        xfree (print_buffer);						\
>        print_buffer = 0;						\
>      }									\
>
> bits might lead to a memory leak.

Right, thanks.  I fixed that as well.





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-27 11:57     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-28  1:47       ` Michael Heerdegen
  2022-07-28  2:53         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-28  9:48       ` Lars Ingebrigtsen
  1 sibling, 1 reply; 20+ messages in thread
From: Michael Heerdegen @ 2022-07-28  1:47 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, 56773

Po Lu <luangruo@yahoo.com> writes:

> Right, thanks.  I fixed that as well.

Thanks for the fix.  My use case seems to behave sane now.

Michael.






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-28  1:47       ` Michael Heerdegen
@ 2022-07-28  2:53         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-28  2:53 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Lars Ingebrigtsen, 56773-done

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Right, thanks.  I fixed that as well.
>
> Thanks for the fix.  My use case seems to behave sane now.
>
> Michael.

Closing, thanks for testing.





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-27 11:57     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-28  1:47       ` Michael Heerdegen
@ 2022-07-28  9:48       ` Lars Ingebrigtsen
  2022-07-28 10:44         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-28  9:48 UTC (permalink / raw)
  To: Po Lu; +Cc: Michael Heerdegen, 56773

Po Lu <luangruo@yahoo.com> writes:

> Right, thanks.  I fixed that as well.

As I said earlier, I suspect that all of PRINTFINISH should go into the
unwind_protect form.  For instance, in the MARKERP situation, it seems
to want to adjust markers etc.  I have not analysed in detail, but those
code bits are presumably there for a reason, and may have to be run if
prin1 has done sometime (even if there's then been a non-local exit).






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-28  9:48       ` Lars Ingebrigtsen
@ 2022-07-28 10:44         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-28 10:46           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-28 10:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Heerdegen, 56773

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I said earlier, I suspect that all of PRINTFINISH should go into the
> unwind_protect form.  For instance, in the MARKERP situation, it seems
> to want to adjust markers etc.  I have not analysed in detail, but those
> code bits are presumably there for a reason, and may have to be run if
> prin1 has done sometime (even if there's then been a non-local exit).

I don't think that's very intuitive, since signalling means "get me out
of here now".





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-28 10:44         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-28 10:46           ` Lars Ingebrigtsen
  2022-07-28 11:06             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-28 10:46 UTC (permalink / raw)
  To: Po Lu; +Cc: Michael Heerdegen, 56773

Po Lu <luangruo@yahoo.com> writes:

> I don't think that's very intuitive, since signalling means "get me out
> of here now".

But we shouldn't leave things in an inconsistent state, and I suspect
that we currently do.

By the way, did you look at the test failure your change led to?






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-28 10:46           ` Lars Ingebrigtsen
@ 2022-07-28 11:06             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-28 11:09               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-28 11:06 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Heerdegen, 56773

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But we shouldn't leave things in an inconsistent state, and I suspect
> that we currently do.

I don't see any inconsistency, just the position of a marker being
changed.

> By the way, did you look at the test failure your change led to?

I didn't see one, but the spam filter is rather agressive these days, so
it would be nice for you to send it again in reply to this message.

Thanks.





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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-28 11:06             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-28 11:09               ` Lars Ingebrigtsen
  2022-07-28 11:21                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-28 11:09 UTC (permalink / raw)
  To: Po Lu; +Cc: Michael Heerdegen, 56773

Po Lu <luangruo@yahoo.com> writes:

> I didn't see one, but the spam filter is rather agressive these days, so
> it would be nice for you to send it again in reply to this message.

Test terpri backtrace:
  signal(ert-test-failed (((should (string= (with-current-buffer (mark
  ert-fail(((should (string= (with-current-buffer (marker-buffer stand
  (if (unwind-protect (setq value-197 (apply fn-195 args-196)) (setq f
  (let (form-description-199) (if (unwind-protect (setq value-197 (app
  (let ((value-197 'ert-form-evaluation-aborted-198)) (let (form-descr
  (let* ((fn-195 #'string=) (args-196 (condition-case err (let ((signa
  (let ((standard-output (save-current-buffer (set-buffer (get-buffer-
  (closure (t) nil (let* ((fn-135 #'string=) (args-136 (condition-case
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name terpri :documentation nil :body (clos
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "src/print-tests.el" "--ev
  command-line()
  normal-top-level()
Test terpri condition:
    (ert-test-failed
     ((should
       (string=
	(with-current-buffer ... ...)
	"--------\n"))
      :form
      (string= "" "--------\n")
      :value nil :explanation
      (arrays-of-different-length 0 9 "" "--------\n" first-mismatch-at 0)))
   FAILED  41/45  terpri (0.000117 sec) at src/print-tests.el:110
   passed  42/45  test-dots (0.000062 sec)
   passed  43/45  test-prin1-overrides (0.000066 sec)
   passed  44/45  test-prin1-to-string-overrides (0.000049 sec)
   passed  45/45  test-unreadable (0.000029 sec)

Ran 45 tests, 44 results as expected, 1 unexpected (2022-07-28 13:08:34+0200, 0.132581 sec)
3 expected failures

1 unexpected results:
   FAILED  terpri






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

* bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
  2022-07-28 11:09               ` Lars Ingebrigtsen
@ 2022-07-28 11:21                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 20+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-28 11:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Heerdegen, 56773

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> I didn't see one, but the spam filter is rather agressive these days, so
>> it would be nice for you to send it again in reply to this message.
>
> Test terpri backtrace:
>   signal(ert-test-failed (((should (string= (with-current-buffer (mark
>   ert-fail(((should (string= (with-current-buffer (marker-buffer stand
>   (if (unwind-protect (setq value-197 (apply fn-195 args-196)) (setq f
>   (let (form-description-199) (if (unwind-protect (setq value-197 (app
>   (let ((value-197 'ert-form-evaluation-aborted-198)) (let (form-descr
>   (let* ((fn-195 #'string=) (args-196 (condition-case err (let ((signa
>   (let ((standard-output (save-current-buffer (set-buffer (get-buffer-
>   (closure (t) nil (let* ((fn-135 #'string=) (args-136 (condition-case
>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>   ert-run-test(#s(ert-test :name terpri :documentation nil :body (clos
>   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>   ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
>   ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
>   ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
>   eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
>   command-line-1(("-L" ":." "-l" "ert" "-l" "src/print-tests.el" "--ev
>   command-line()
>   normal-top-level()
> Test terpri condition:
>     (ert-test-failed
>      ((should
>        (string=
> 	(with-current-buffer ... ...)
> 	"--------\n"))
>       :form
>       (string= "" "--------\n")
>       :value nil :explanation
>       (arrays-of-different-length 0 9 "" "--------\n" first-mismatch-at 0)))
>    FAILED  41/45  terpri (0.000117 sec) at src/print-tests.el:110
>    passed  42/45  test-dots (0.000062 sec)
>    passed  43/45  test-prin1-overrides (0.000066 sec)
>    passed  44/45  test-prin1-to-string-overrides (0.000049 sec)
>    passed  45/45  test-unreadable (0.000029 sec)
>
> Ran 45 tests, 44 results as expected, 1 unexpected (2022-07-28 13:08:34+0200, 0.132581 sec)
> 3 expected failures
>
> 1 unexpected results:
>    FAILED  terpri

Thanks, I see the problem now and will push a fix.





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

end of thread, other threads:[~2022-07-28 11:21 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-26  3:42 bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things Michael Heerdegen
2022-07-26 12:31 ` Lars Ingebrigtsen
2022-07-26 12:39   ` Eli Zaretskii
2022-07-26 12:44     ` Lars Ingebrigtsen
2022-07-26 13:12       ` Eli Zaretskii
2022-07-26 13:24         ` Lars Ingebrigtsen
2022-07-27  9:30           ` Lars Ingebrigtsen
2022-07-27  9:41       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-27  9:51         ` Lars Ingebrigtsen
2022-07-27  9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-27  9:58   ` Lars Ingebrigtsen
2022-07-27 11:57     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-28  1:47       ` Michael Heerdegen
2022-07-28  2:53         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-28  9:48       ` Lars Ingebrigtsen
2022-07-28 10:44         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-28 10:46           ` Lars Ingebrigtsen
2022-07-28 11:06             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-28 11:09               ` Lars Ingebrigtsen
2022-07-28 11:21                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

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.