unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* `unreadablep'
@ 2021-12-15  7:49 Lars Ingebrigtsen
  2021-12-15  8:19 ` `unreadablep' Po Lu
                   ` (5 more replies)
  0 siblings, 6 replies; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15  7:49 UTC (permalink / raw)
  To: emacs-devel

Do we have any primitive that can be used to check whether an object is
printable or not?  Code like this (from savehist.el) makes me believe
"not":

		;; Print elements of VALUE one by one, carefully.
		(dolist (elt value)
		  (let ((start (point)))
		    (insert " ")
		    ;; Try to print and then to read an element.
		    (condition-case nil
			(progn
			  (prin1 elt (current-buffer))
			  (save-excursion
			    (goto-char start)
			    (read (current-buffer))))
		      (error
		       ;; If writing or reading gave an error, comment it out.
		       (goto-char start)
		       (insert "\n")
		       (while (not (eobp))
			 (insert ";;; ")
			 (forward-line 1))
		       (insert "\n")))
		    (goto-char (point-max))))

It would be nice to have such a function (i.e., that says whether it can
be read back after printing it).  The problem is, of course, complex
structures that require recursing (and then checking for loops), etc, so
you basically have to implement it the way printing is done if you want
it to be fast, I think?

Does anybody have any thoughts on this issue?

I wonder whether this could be efficiently implemented by, say, having
some kind of special value for PRINTCHARFUN for prin1, but I haven't
looked at the code yet.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




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

* Re: `unreadablep'
  2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
@ 2021-12-15  8:19 ` Po Lu
  2021-12-15  8:35   ` `unreadablep' Lars Ingebrigtsen
  2021-12-15  8:35 ` `unreadablep' Ihor Radchenko
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15  8:19 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?

Yes, it would be very convenient indeed.

I think the best solution would be to allow `prin1' to optionally return
whether or not any unreadable objects were printed, instead of the
object itself.



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

* Re: `unreadablep'
  2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
  2021-12-15  8:19 ` `unreadablep' Po Lu
@ 2021-12-15  8:35 ` Ihor Radchenko
  2021-12-15  9:51   ` `unreadablep' Po Lu
  2021-12-15 14:12 ` `unreadablep' Stefan Monnier
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15  8:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":
> ...
> Does anybody have any thoughts on this issue?

I can see a use of adding extra argument to prin1. If the argument is
set, prin1 errors when attempting to print unreadable object or
alternatively prints nil (or other symbol) instead of the unreadable
object.

Best,
Ihor




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

* Re: `unreadablep'
  2021-12-15  8:19 ` `unreadablep' Po Lu
@ 2021-12-15  8:35   ` Lars Ingebrigtsen
  2021-12-15  9:42     ` `unreadablep' Po Lu
  2021-12-15 17:00     ` [External] : `unreadablep' Drew Adams
  0 siblings, 2 replies; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15  8:35 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> Yes, it would be very convenient indeed.
>
> I think the best solution would be to allow `prin1' to optionally return
> whether or not any unreadable objects were printed, instead of the
> object itself.

I was thinking that for efficiency (and ease of usage), nothing would be
printed.  That is, something like

(defun unreadablep (object)
  (condition-case nil
      (prin1 object 'error-on-unprintable)
    (:success t)
    (unprintable-error nil)))

and then prin1 would signal an error if it encounters an unprintable
object in the structure, but otherwise print nothing.

But I still haven't actually looked at the prin1 code, so I'm not sure
whether that would be messy or not.  😀 The advantage of using the prin1
code to do the checking (instead of implementing a separate function to
traverse the data itself) is that we'd be pretty sure that there aren't
any glitches between the prin1 implementation and the checker
implementation...

But having `prin1' return whether it printed something unreadable also
sounds attractive.  I guess it depends on the use case.  If you're
saying

(if (unprintable o)
    (insert ";; " (prin1 o (current-buffer)))
  (prin1 o (current-buffer)))

then you're traversing the data twice, which isn't efficient, so
inserting it first and then checking would be nice.  But if you're doing

(when (unprintable o)
  (error "Nope"))

then it'd be inconvenient for it to be printing anything.

And what about `prin1-to-string'?  It has to return the string...  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-15  8:35   ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-15  9:42     ` Po Lu
  2021-12-15 11:16       ` `unreadablep' Lars Ingebrigtsen
  2021-12-15 17:00     ` [External] : `unreadablep' Drew Adams
  1 sibling, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15  9:42 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But having `prin1' return whether it printed something unreadable also
> sounds attractive.  I guess it depends on the use case.  If you're
> saying
>
> (if (unprintable o)
>     (insert ";; " (prin1 o (current-buffer)))
>   (prin1 o (current-buffer)))
>
> then you're traversing the data twice, which isn't efficient, so
> inserting it first and then checking would be nice.

Yes, my thoughts exactly.



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

* Re: `unreadablep'
  2021-12-15  8:35 ` `unreadablep' Ihor Radchenko
@ 2021-12-15  9:51   ` Po Lu
  2021-12-15 10:20     ` `unreadablep' Ihor Radchenko
  0 siblings, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15  9:51 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Lars Ingebrigtsen, emacs-devel

Ihor Radchenko <yantar92@gmail.com> writes:

> I can see a use of adding extra argument to prin1. If the argument is
> set, prin1 errors when attempting to print unreadable object or
> alternatively prints nil (or other symbol) instead of the unreadable
> object.

Why an extra argument, and not a variable, say,
`throw-printing-unreadably'?  There are many callers of prin1 that could
benefit from this.



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

* Re: `unreadablep'
  2021-12-15  9:51   ` `unreadablep' Po Lu
@ 2021-12-15 10:20     ` Ihor Radchenko
  2021-12-15 10:21       ` `unreadablep' Ihor Radchenko
  2021-12-15 10:21       ` `unreadablep' Po Lu
  0 siblings, 2 replies; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15 10:20 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I can see a use of adding extra argument to prin1. If the argument is
>> set, prin1 errors when attempting to print unreadable object or
>> alternatively prints nil (or other symbol) instead of the unreadable
>> object.
>
> Why an extra argument, and not a variable, say,
> `throw-printing-unreadably'?  There are many callers of prin1 that could
> benefit from this.

Variable would indeed be better. Using variable is more consistent with
the existing behaviour. prin1 can already be controlled by variables
like print-level, print-circle, etc

Though the name should probably start with print-. Maybe something like
print-unreadable (t by default, nil will make prin1 throw an error, and
'replace to print the value of print-unreadable-as instead of unreadable
object).

Yet another option may be not printing anything when print-unreadable is
t and throwing an error when print-unreadable is 'error, but I am not
sure if that much customisation is too much.

Best,
Ihor



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

* Re: `unreadablep'
  2021-12-15 10:20     ` `unreadablep' Ihor Radchenko
@ 2021-12-15 10:21       ` Ihor Radchenko
  2021-12-15 10:21       ` `unreadablep' Po Lu
  1 sibling, 0 replies; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15 10:21 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel

Ihor Radchenko <yantar92@gmail.com> writes:

> Yet another option may be not printing anything when print-unreadable is
> t and throwing an error when print-unreadable is 'error, but I am not
> sure if that much customisation is too much.
* t -> nil



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

* Re: `unreadablep'
  2021-12-15 10:20     ` `unreadablep' Ihor Radchenko
  2021-12-15 10:21       ` `unreadablep' Ihor Radchenko
@ 2021-12-15 10:21       ` Po Lu
  2021-12-15 10:36         ` `unreadablep' Ihor Radchenko
  1 sibling, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15 10:21 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Lars Ingebrigtsen, emacs-devel

Ihor Radchenko <yantar92@gmail.com> writes:

> Variable would indeed be better. Using variable is more consistent with
> the existing behaviour. prin1 can already be controlled by variables
> like print-level, print-circle, etc
>
> Though the name should probably start with print-. Maybe something like
> print-unreadable (t by default, nil will make prin1 throw an error, and
> 'replace to print the value of print-unreadable-as instead of unreadable
> object).
>
> Yet another option may be not printing anything when print-unreadable is
> t and throwing an error when print-unreadable is 'error, but I am not
> sure if that much customisation is too much.

How about `print-throw-if-printing-unreadably'?



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

* Re: `unreadablep'
  2021-12-15 10:21       ` `unreadablep' Po Lu
@ 2021-12-15 10:36         ` Ihor Radchenko
  2021-12-15 10:44           ` `unreadablep' Po Lu
  0 siblings, 1 reply; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15 10:36 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel

Po Lu <luangruo@yahoo.com> writes:

>> Variable would indeed be better. Using variable is more consistent with
>> the existing behaviour. prin1 can already be controlled by variables
>> like print-level, print-circle, etc
>>
>> Though the name should probably start with print-. Maybe something like
>> print-unreadable (t by default, nil will make prin1 throw an error, and
>> 'replace to print the value of print-unreadable-as instead of unreadable
>> object).
> ...
> How about `print-throw-if-printing-unreadably'?

I don't have strong opinion about print-unreadable vs.
print-throw-if-printing-unreadably, except that the latter feels too
long (which is not a big deal).

I am more interested in the ability to print nil (or something else)
instead of unreadable objects. My motivations is org-element-cache where
we cannot currently store buffer objects because they cannot be restored
from printed cache while not increasing the write time significantly (it
is bad enough as it is).

Best,
Ihor



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

* Re: `unreadablep'
  2021-12-15 10:36         ` `unreadablep' Ihor Radchenko
@ 2021-12-15 10:44           ` Po Lu
  2021-12-15 11:12             ` `unreadablep' Ihor Radchenko
  0 siblings, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15 10:44 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Lars Ingebrigtsen, emacs-devel

Ihor Radchenko <yantar92@gmail.com> writes:

> I don't have strong opinion about print-unreadable vs.
> print-throw-if-printing-unreadably, except that the latter feels too
> long (which is not a big deal).

> I am more interested in the ability to print nil (or something else)
> instead of unreadable objects. My motivations is org-element-cache where
> we cannot currently store buffer objects because they cannot be restored
> from printed cache while not increasing the write time significantly (it
> is bad enough as it is).

Maybe we could have a `print-unreadable-function' that accepts
`printcharfun' as an argument.  That would be very nice indeed.



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

* Re: `unreadablep'
  2021-12-15 10:44           ` `unreadablep' Po Lu
@ 2021-12-15 11:12             ` Ihor Radchenko
  2021-12-15 11:16               ` `unreadablep' Po Lu
  0 siblings, 1 reply; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15 11:12 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel


Po Lu <luangruo@yahoo.com> writes:
>> I am more interested in the ability to print nil (or something else)
>> instead of unreadable objects. My motivations is org-element-cache where
>> we cannot currently store buffer objects because they cannot be restored
>> from printed cache while not increasing the write time significantly (it
>> is bad enough as it is).
>
> Maybe we could have a `print-unreadable-function' that accepts
> `printcharfun' as an argument.  That would be very nice indeed.

Do you imply that `print-unreadable-function' should return the new
value to be printed? If so, it is indeed more flexible. Passing the
unreadable value to the function would also be useful (e.g. we can print
buffer file name instead of buffer object).

Best,
Ihor



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

* Re: `unreadablep'
  2021-12-15 11:12             ` `unreadablep' Ihor Radchenko
@ 2021-12-15 11:16               ` Po Lu
  2021-12-15 11:39                 ` `unreadablep' Ihor Radchenko
  0 siblings, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15 11:16 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Lars Ingebrigtsen, emacs-devel

Ihor Radchenko <yantar92@gmail.com> writes:

>> Maybe we could have a `print-unreadable-function' that accepts
>> `printcharfun' as an argument.  That would be very nice indeed.

> Do you imply that `print-unreadable-function' should return the new
> value to be printed? If so, it is indeed more flexible. Passing the
> unreadable value to the function would also be useful (e.g. we can print
> buffer file name instead of buffer object).

It would accept a function that is called to print characters, like the
`printcharfun' argument to prin1.



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

* Re: `unreadablep'
  2021-12-15  9:42     ` `unreadablep' Po Lu
@ 2021-12-15 11:16       ` Lars Ingebrigtsen
  2021-12-15 11:25         ` `unreadablep' Po Lu
  0 siblings, 1 reply; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15 11:16 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

>> But having `prin1' return whether it printed something unreadable also
>> sounds attractive.  I guess it depends on the use case.  If you're
>> saying
>>
>> (if (unprintable o)
>>     (insert ";; " (prin1 o (current-buffer)))
>>   (prin1 o (current-buffer)))
>>
>> then you're traversing the data twice, which isn't efficient, so
>> inserting it first and then checking would be nice.
>
> Yes, my thoughts exactly.

And we could implement `readablep' (probably better without "un") as

(defun readablep (object)
  (prin1 object #'ignore 'return-readablep))

and not actually print anything (for the cases where it's more
convenient to call a predicate).

There's perhaps a slight performance issue -- if the unreadable object
is the first in a long list, we could have exited a lot sooner, but I'm
not sure that's really much of an issue in practice.  If it is, we could
perhaps change PRINTCHARFUN to take two arguments in this case, where
the second is EVERYTHING-IS-READABLE-SO-FAR, and then PRINTCHARFUN could
throw an error if it wishes...

Or, as has been suggested, add a new print-* variable to have the same
effect -- it'd fit in with the current design (of having a bunch of
print-* variables).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-15 11:16       ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-15 11:25         ` Po Lu
  2021-12-15 12:19           ` `unreadablep' Lars Ingebrigtsen
  0 siblings, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15 11:25 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There's perhaps a slight performance issue -- if the unreadable object
> is the first in a long list, we could have exited a lot sooner, but I'm
> not sure that's really much of an issue in practice.  If it is, we could
> perhaps change PRINTCHARFUN to take two arguments in this case, where
> the second is EVERYTHING-IS-READABLE-SO-FAR, and then PRINTCHARFUN could
> throw an error if it wishes...
>
> Or, as has been suggested, add a new print-* variable to have the same
> effect -- it'd fit in with the current design (of having a bunch of
> print-* variables).

Yes, now I think the `print-unreadable-function' solution would be best;
we could just cause a non-local exit from within that function.



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

* Re: `unreadablep'
  2021-12-15 11:16               ` `unreadablep' Po Lu
@ 2021-12-15 11:39                 ` Ihor Radchenko
  0 siblings, 0 replies; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15 11:39 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel

Po Lu <luangruo@yahoo.com> writes:

>> Do you imply that `print-unreadable-function' should return the new
>> value to be printed? If so, it is indeed more flexible. Passing the
>> unreadable value to the function would also be useful (e.g. we can print
>> buffer file name instead of buffer object).
>
> It would accept a function that is called to print characters, like the
> `printcharfun' argument to prin1.

I was confused by the name. `printcharfun' in prin1 can be a buffer, a
marker, etc. Doing the same for the `print-unreadable-function' makes it
tricky to implement. How does `print-unreadable-function' print into a
buffer or marker? It would be cumbersome to consider all such cases if
the user simply wants to print nil in place of unreadable objects.

If the `printcharfun' passed to `print-unreadable-function' is strictly
an ordinary function that does actual printing, I can see a problem with
circular objects. Consider something like
(#1=a #<unreadable> #2=b #1 #1 #2).
If the main print loop is not aware of what was printed by
`print-unreadable-function' and the function tries to print reference to
b, we may get incorrect object:
(#1=a b #2=b #1 #1 #2)
The object printed instead of unreadable value will break circular
structure.

Of course, the described problem will depend on the details of
implementation.

Best,
Ihor



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

* Re: `unreadablep'
  2021-12-15 11:25         ` `unreadablep' Po Lu
@ 2021-12-15 12:19           ` Lars Ingebrigtsen
  2021-12-15 12:22             ` `unreadablep' Po Lu
  0 siblings, 1 reply; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15 12:19 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> Yes, now I think the `print-unreadable-function' solution would be best;
> we could just cause a non-local exit from within that function.

The PRINTCHARFUN just gets a single character at a time, doesn't it?  So
it's not at the correct level to determine whether something is
unreadable or not...

I wonder whether two new simple read-* variables would cover all the use
cases (without having to go through prin1 twice ever).

1) When you want to signal an error, but use the representation
otherwise:

(use-thing
  (let ((print-error-on-unreadable t))
    (condition-case nil
       (prin1-to-string object)
      (unreadable-error (user-error "can't use this")))))

This would signal an error as soon as prin1 sees something unprintable,
so it'd be fast.

2) When you always want to insert it, but tweak it (a la savehist):

(let ((print-return-readable t)
      (start (point)))
  (unless (prin1 object (current-buffer))
    (goto-char start)
    (insert ";; ")))

I think that should cover the use cases?

Perhaps this is over engineering, but it would be nice to implement
things like this efficiently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-15 12:19           ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-15 12:22             ` Po Lu
  2021-12-15 12:35               ` `unreadablep' Lars Ingebrigtsen
  2021-12-15 12:36               ` `unreadablep' Ihor Radchenko
  0 siblings, 2 replies; 37+ messages in thread
From: Po Lu @ 2021-12-15 12:22 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Yes, now I think the `print-unreadable-function' solution would be best;
>> we could just cause a non-local exit from within that function.

> The PRINTCHARFUN just gets a single character at a time, doesn't it?  So
> it's not at the correct level to determine whether something is
> unreadable or not...

The idea is that `print-unreadable-function' is called _with_ the object
and the printcharfun (and possibly some prin1 state, but I haven't
thought of the details yet) when prin1 encounters an unreadable object.

So if you want to error something when trying to print an unreadable
object, you can just set that to a function that throws.



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

* Re: `unreadablep'
  2021-12-15 12:22             ` `unreadablep' Po Lu
@ 2021-12-15 12:35               ` Lars Ingebrigtsen
  2021-12-15 12:42                 ` `unreadablep' Po Lu
  2021-12-15 12:36               ` `unreadablep' Ihor Radchenko
  1 sibling, 1 reply; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15 12:35 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> The idea is that `print-unreadable-function' is called _with_ the object
> and the printcharfun (and possibly some prin1 state, but I haven't
> thought of the details yet) when prin1 encounters an unreadable object.
>
> So if you want to error something when trying to print an unreadable
> object, you can just set that to a function that throws.

Right...

Skimming print_object and friends, it seems like the vast majority of
the unprintable objects are in print_vectorlike, so I guess such a
change could be made (pretty much?) locally to that function...

So I think doing it that way should be pretty easy to implement, and
it's certainly general enough to be used in both of the cases I
sketched.  But the logic would have to be such that if
`print-unreadable-function' returns some special value, then printing
continues as normally (to implement the "just tell me if what was
printed is readable" case).

And calling out to Lisp in this case may be slower than the other
solution sketched.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-15 12:22             ` `unreadablep' Po Lu
  2021-12-15 12:35               ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-15 12:36               ` Ihor Radchenko
  2021-12-15 12:37                 ` `unreadablep' Po Lu
  1 sibling, 1 reply; 37+ messages in thread
From: Ihor Radchenko @ 2021-12-15 12:36 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> The idea is that `print-unreadable-function' is called _with_ the object
> and the printcharfun (and possibly some prin1 state, but I haven't
> thought of the details yet) when prin1 encounters an unreadable object.

What about just calling with the object and then proceeding as usual
inside prin1, but using the return value of print-unreadable-function in
place of the old unreadable value?

Best,
Ihor



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

* Re: `unreadablep'
  2021-12-15 12:36               ` `unreadablep' Ihor Radchenko
@ 2021-12-15 12:37                 ` Po Lu
  0 siblings, 0 replies; 37+ messages in thread
From: Po Lu @ 2021-12-15 12:37 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Lars Ingebrigtsen, emacs-devel

Ihor Radchenko <yantar92@gmail.com> writes:

> What about just calling with the object and then proceeding as usual
> inside prin1, but using the return value of print-unreadable-function in
> place of the old unreadable value?

It wouldn't allow to differentiate unreadable values printed specially
from readable ones later at read time, but I see no harm in providing
that feature as well.



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

* Re: `unreadablep'
  2021-12-15 12:35               ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-15 12:42                 ` Po Lu
  2021-12-15 12:44                   ` `unreadablep' Lars Ingebrigtsen
  0 siblings, 1 reply; 37+ messages in thread
From: Po Lu @ 2021-12-15 12:42 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Right...
>
> Skimming print_object and friends, it seems like the vast majority of
> the unprintable objects are in print_vectorlike, so I guess such a
> change could be made (pretty much?) locally to that function...

Don't we also have Lisp_Misc and friends?  (But I'm not sure Lisp_Misc
is ever supposed to be printed at all, and I don't see Lisp_Misc
anywhere, so perhaps my recollection is faulty.)

> So I think doing it that way should be pretty easy to implement, and
> it's certainly general enough to be used in both of the cases I
> sketched.  But the logic would have to be such that if
> `print-unreadable-function' returns some special value, then printing
> continues as normally (to implement the "just tell me if what was
> printed is readable" case).

We could have it return nil in that case.

> And calling out to Lisp in this case may be slower than the other
> solution sketched.

Unreadable objects are in general rare in printed objects, and a funcall
followed by a test against nil will not add any significant overhead to
prin1 either, so I wouldn't be worried about that.

Let's not optimize prematurely, especially with something like prin1 :)



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

* Re: `unreadablep'
  2021-12-15 12:42                 ` `unreadablep' Po Lu
@ 2021-12-15 12:44                   ` Lars Ingebrigtsen
  2021-12-15 12:46                     ` `unreadablep' Po Lu
  0 siblings, 1 reply; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15 12:44 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> Unreadable objects are in general rare in printed objects, and a funcall
> followed by a test against nil will not add any significant overhead to
> prin1 either, so I wouldn't be worried about that.

Yeah, that's true.

> Let's not optimize prematurely, especially with something like prin1 :)

Well, we do want prin1 to be fast.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-15 12:44                   ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-15 12:46                     ` Po Lu
  2021-12-15 12:51                       ` `unreadablep' Po Lu
  2021-12-15 12:58                       ` `unreadablep' Lars Ingebrigtsen
  0 siblings, 2 replies; 37+ messages in thread
From: Po Lu @ 2021-12-15 12:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, we do want prin1 to be fast.  😀

It isn't the fastest as it is, but that's besides the point: avoiding a
completely optional call into Lisp because it "might be slow" is a
textbook case of putting the horse before the dog, so to speak.



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

* Re: `unreadablep'
  2021-12-15 12:46                     ` `unreadablep' Po Lu
@ 2021-12-15 12:51                       ` Po Lu
  2021-12-15 12:58                       ` `unreadablep' Lars Ingebrigtsen
  1 sibling, 0 replies; 37+ messages in thread
From: Po Lu @ 2021-12-15 12:51 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> It isn't the fastest as it is, but that's besides the point: avoiding a
> completely optional call into Lisp because it "might be slow" is a
> textbook case of putting the horse before the dog, so to speak.
                                                ^^^

Sorry, I meant to say "cart" here.  :P



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

* Re: `unreadablep'
  2021-12-15 12:46                     ` `unreadablep' Po Lu
  2021-12-15 12:51                       ` `unreadablep' Po Lu
@ 2021-12-15 12:58                       ` Lars Ingebrigtsen
  1 sibling, 0 replies; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-15 12:58 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> It isn't the fastest as it is, but that's besides the point: avoiding a
> completely optional call into Lisp because it "might be slow" is a
> textbook case of putting the horse before the dog, so to speak.

Well, we're discussing several different ways to implement basically the
same functionality.  If one's slower than the other, that's an issue.

But I think your idea is good -- a way to customise the printing of
unprintable objects could be useful in general, and not just to
implement `readablep'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
  2021-12-15  8:19 ` `unreadablep' Po Lu
  2021-12-15  8:35 ` `unreadablep' Ihor Radchenko
@ 2021-12-15 14:12 ` Stefan Monnier
  2021-12-16  5:48   ` `unreadablep' Lars Ingebrigtsen
  2021-12-15 15:32 ` `unreadablep' Steingold
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 37+ messages in thread
From: Stefan Monnier @ 2021-12-15 14:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":

IIRC we discussed such a feature but it never got installed.

My memory suggests the plan was to add something like
a `print-unreadable-function` that gets called with the offending
object.  It could then print it any which way it wants, or signal an
error or ...


        Stefan




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

* Re: `unreadablep'
  2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
                   ` (2 preceding siblings ...)
  2021-12-15 14:12 ` `unreadablep' Stefan Monnier
@ 2021-12-15 15:32 ` Steingold
  2021-12-15 16:04   ` `unreadablep' Qiantan Hong
  2021-12-15 16:09 ` `unreadablep' Steingold
  2021-12-15 20:21 ` `unreadablep' Philipp Stephani
  5 siblings, 1 reply; 37+ messages in thread
From: Steingold @ 2021-12-15 15:32 UTC (permalink / raw)
  To: emacs-devel

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-15 08:49:58 +0100]:
>
> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":
>
> 		;; Print elements of VALUE one by one, carefully.
> 		(dolist (elt value)
> 		  (let ((start (point)))
> 		    (insert " ")
> 		    ;; Try to print and then to read an element.
> 		    (condition-case nil
> 			(progn
> 			  (prin1 elt (current-buffer))
> 			  (save-excursion
> 			    (goto-char start)
> 			    (read (current-buffer))))
> 		      (error
> 		       ;; If writing or reading gave an error, comment it out.
> 		       (goto-char start)
> 		       (insert "\n")
> 		       (while (not (eobp))
> 			 (insert ";;; ")
> 			 (forward-line 1))
> 		       (insert "\n")))
> 		    (goto-char (point-max))))
>
> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?
>
> Does anybody have any thoughts on this issue?

I think the above code is _perfect_.
Why would one want to know in advance if the object is printable readably?
Only to decide how to print it, right?
Then the optimal approach is to _try_ to print readably and then take an
alternative/remedial action on failure.
This will usually save a structure traversal.

> I wonder whether this could be efficiently implemented by, say, having
> some kind of special value for PRINTCHARFUN for prin1, but I haven't
> looked at the code yet.

Yeah, we could create a "/dev/null"-type object and pass it to prin1.
However, this would still make the above approach better in most cases.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2022
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://honestreporting.com https://iris.org.il https://ffii.org
DRM "access management" == prison "freedom management".




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

* Re: `unreadablep'
  2021-12-15 15:32 ` `unreadablep' Steingold
@ 2021-12-15 16:04   ` Qiantan Hong
  0 siblings, 0 replies; 37+ messages in thread
From: Qiantan Hong @ 2021-12-15 16:04 UTC (permalink / raw)
  To: sds@gnu.org; +Cc: emacs-devel@gnu.org

> On Dec 15, 2021, at 7:32 AM, Steingold <sds@gnu.org> wrote:
> 
>> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-15 08:49:58 +0100]:
>> 
>> Do we have any primitive that can be used to check whether an object is
>> printable or not?  Code like this (from savehist.el) makes me believe
>> "not":
>> 
>> 		;; Print elements of VALUE one by one, carefully.
>> 		(dolist (elt value)
>> 		  (let ((start (point)))
>> 		    (insert " ")
>> 		    ;; Try to print and then to read an element.
>> 		    (condition-case nil
>> 			(progn
>> 			  (prin1 elt (current-buffer))
>> 			  (save-excursion
>> 			    (goto-char start)
>> 			    (read (current-buffer))))
>> 		      (error
>> 		       ;; If writing or reading gave an error, comment it out.
>> 		       (goto-char start)
>> 		       (insert "\n")
>> 		       (while (not (eobp))
>> 			 (insert ";;; ")
>> 			 (forward-line 1))
>> 		       (insert "\n")))
>> 		    (goto-char (point-max))))
>> 
>> It would be nice to have such a function (i.e., that says whether it can
>> be read back after printing it).  The problem is, of course, complex
>> structures that require recursing (and then checking for loops), etc, so
>> you basically have to implement it the way printing is done if you want
>> it to be fast, I think?
>> 
>> Does anybody have any thoughts on this issue?
> 
> I think the above code is _perfect_.
> Why would one want to know in advance if the object is printable readably?
> Only to decide how to print it, right?
> Then the optimal approach is to _try_ to print readably and then take an
> alternative/remedial action on failure.
> This will usually save a structure traversal.
print already traverse it once, read traverse it twice.
If print support it natively we save in the best case one
half of the work.



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

* Re: `unreadablep'
  2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
                   ` (3 preceding siblings ...)
  2021-12-15 15:32 ` `unreadablep' Steingold
@ 2021-12-15 16:09 ` Steingold
  2021-12-15 20:21 ` `unreadablep' Philipp Stephani
  5 siblings, 0 replies; 37+ messages in thread
From: Steingold @ 2021-12-15 16:09 UTC (permalink / raw)
  To: emacs-devel

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-15 08:49:58 +0100]:
>
> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":
>
> 		;; Print elements of VALUE one by one, carefully.
> 		(dolist (elt value)
> 		  (let ((start (point)))
> 		    (insert " ")
> 		    ;; Try to print and then to read an element.
> 		    (condition-case nil
> 			(progn
> 			  (prin1 elt (current-buffer))
> 			  (save-excursion
> 			    (goto-char start)
> 			    (read (current-buffer))))
> 		      (error
> 		       ;; If writing or reading gave an error, comment it out.
> 		       (goto-char start)
> 		       (insert "\n")
> 		       (while (not (eobp))
> 			 (insert ";;; ")
> 			 (forward-line 1))
> 		       (insert "\n")))
> 		    (goto-char (point-max))))

I think the above code would have been perfect, if

1. prin1 were replaced with something like `(write ... :readably t)`
   (http://clhs.lisp.se/Body/f_wr_pr.htm), _and_

2. there were no `read` after `prin1`

(BTW, the return value of `read` is ignored, to be "honest", it should
be compared to `elt` using `equal`)

> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?
>
> Does anybody have any thoughts on this issue?

Why would one want to know in advance if the object is printable readably?
Only to decide how to print it, right?
Then the optimal approach is to _try_ to print readably and then take an
alternative/remedial action on failure.
This will usually save a structure traversal.

Thus I would advocate for a `print-readably' variable that would emulate
the CL behavior <http://clhs.lisp.se/Body/v_pr_rda.htm>.

> I wonder whether this could be efficiently implemented by, say, having
> some kind of special value for PRINTCHARFUN for prin1, but I haven't
> looked at the code yet.

Yeah, we could create a "/dev/null"-type object and pass it to prin1.
However, this would still make the above approach better in most cases.

(My original reply was, apparently, sent just to Lars, and was incorrect)

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2022
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://www.memritv.org https://www.dhimmitude.org http://think-israel.org
When you are arguing with an idiot, your opponent is doing the same.




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

* RE: [External] : Re: `unreadablep'
  2021-12-15  8:35   ` `unreadablep' Lars Ingebrigtsen
  2021-12-15  9:42     ` `unreadablep' Po Lu
@ 2021-12-15 17:00     ` Drew Adams
  1 sibling, 0 replies; 37+ messages in thread
From: Drew Adams @ 2021-12-15 17:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Po Lu; +Cc: emacs-devel@gnu.org

> I was thinking that for efficiency (and ease of usage),
> nothing would be printed.  That is, something like
> 
> (defun unreadablep (object)
>   (condition-case nil
>       (prin1 object 'error-on-unprintable)
>     (:success t)
>     (unprintable-error nil)))

FWIW, I've always used this.

(defun bmkp-readable-p (value)
  "Return non-nil if VALUE is Lisp-readable if printed using `prin1'."
  (cond ((numberp value))
        ((symbolp value))
        ((and (stringp value)           ; String with no text properties.
              (if (fboundp 'equal-including-properties) ; Emacs 22+.
                  (equal-including-properties value (substring-no-properties value))
                (and (null (text-properties-at 0 value))
                     (= 0 (next-property-change 0 value))))))
        (t (with-temp-buffer
             (condition-case nil
                 (let ((print-readably  t)
                       (print-level     nil)
                       (print-circle    bmkp-propertize-bookmark-names-flag)
                       (print-gensym    bmkp-propertize-bookmark-names-flag))
                   (prin1 value (current-buffer))
                   (read (point-min-marker))
                   t)
               (error nil))))))         ; Could not print and read back.

Yes, it tries to print and then read back.
It would be great to have something better.

[And yes, "readable" is better than "unreadable",
as most tests will be (when (readablep X) ...).]

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

* Re: `unreadablep'
  2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
                   ` (4 preceding siblings ...)
  2021-12-15 16:09 ` `unreadablep' Steingold
@ 2021-12-15 20:21 ` Philipp Stephani
  5 siblings, 0 replies; 37+ messages in thread
From: Philipp Stephani @ 2021-12-15 20:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Emacs developers

Am Mi., 15. Dez. 2021 um 09:16 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).

Yes, this would be useful in many places where we need to serialize
Lisp objects (e.g. for the sandbox stuff).

>  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?

It's a DFS of a DAG, not quite rocket science. The difficulty is
rather in getting the details right (e.g. you can't allow symbols
interned in a non-default obarray because you wouldn't get the same
symbol back).

> I wonder whether this could be efficiently implemented by, say, having
> some kind of special value for PRINTCHARFUN for prin1, but I haven't
> looked at the code yet.

Maybe just introduce another C function `prin1-if-readable' or so that
errors out (with a specific error symbol so that callers can catch it)
if the object can't be printed in a readable way. That should also
bind the print variables correctly (e.g. bind print-level to nil) so
ensure that the result really represents an equivalent List object.
The new function would likely reuse the existing `print' machinery,
with the `escapeflag' parameter turned into a generic `flags' enum.
I guess it would make sense to also forbid some "exotic" objects
(circular objects, uninterned symbols) that rarely make sense to
serialize.



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

* Re: `unreadablep'
  2021-12-15 14:12 ` `unreadablep' Stefan Monnier
@ 2021-12-16  5:48   ` Lars Ingebrigtsen
  2021-12-16  8:03     ` `unreadablep' Eli Zaretskii
  2021-12-16 15:35     ` `unreadablep' Qiantan Hong
  0 siblings, 2 replies; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-16  5:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Po Lu, Eli Zaretskii, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> My memory suggests the plan was to add something like
> a `print-unreadable-function` that gets called with the offending
> object.  It could then print it any which way it wants, or signal an
> error or ...

Then it seems like most everybody's who's weighed in is in favour of
that solution, but perhaps Eli has an opinion.  Eli?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-16  5:48   ` `unreadablep' Lars Ingebrigtsen
@ 2021-12-16  8:03     ` Eli Zaretskii
  2021-12-17  7:18       ` `unreadablep' Lars Ingebrigtsen
  2021-12-16 15:35     ` `unreadablep' Qiantan Hong
  1 sibling, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2021-12-16  8:03 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, monnier, emacs-devel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org, Po Lu <luangruo@yahoo.com>, Eli Zaretskii
>  <eliz@gnu.org>
> Date: Thu, 16 Dec 2021 06:48:49 +0100
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > My memory suggests the plan was to add something like
> > a `print-unreadable-function` that gets called with the offending
> > object.  It could then print it any which way it wants, or signal an
> > error or ...
> 
> Then it seems like most everybody's who's weighed in is in favour of
> that solution, but perhaps Eli has an opinion.  Eli?

It's fine by me, thanks.



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

* Re: `unreadablep'
  2021-12-16  5:48   ` `unreadablep' Lars Ingebrigtsen
  2021-12-16  8:03     ` `unreadablep' Eli Zaretskii
@ 2021-12-16 15:35     ` Qiantan Hong
  2021-12-17  7:19       ` `unreadablep' Lars Ingebrigtsen
  1 sibling, 1 reply; 37+ messages in thread
From: Qiantan Hong @ 2021-12-16 15:35 UTC (permalink / raw)
  To: larsi@gnus.org; +Cc: Po Lu, Eli Zaretskii, Stefan Monnier, emacs-devel@gnu.org

>> My memory suggests the plan was to add something like
>> a `print-unreadable-function` that gets called with the offending
>> object.  It could then print it any which way it wants, or signal an
>> error or ...
> 
> Then it seems like most everybody's who's weighed in is in favour of
> that solution
Is it possible to also provide a companion function for read?
Namely, read-unreadable-function, that gets called when
encountering #<.



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

* Re: `unreadablep'
  2021-12-16  8:03     ` `unreadablep' Eli Zaretskii
@ 2021-12-17  7:18       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-17  7:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, monnier, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> Then it seems like most everybody's who's weighed in is in favour of
>> that solution, but perhaps Eli has an opinion.  Eli?
>
> It's fine by me, thanks.

OK; I'll open a bug report so track the work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

* Re: `unreadablep'
  2021-12-16 15:35     ` `unreadablep' Qiantan Hong
@ 2021-12-17  7:19       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 37+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-17  7:19 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: Po Lu, Eli Zaretskii, Stefan Monnier, emacs-devel@gnu.org

Qiantan Hong <qhong@mit.edu> writes:

> Is it possible to also provide a companion function for read?
> Namely, read-unreadable-function, that gets called when
> encountering #<.

Hm...  I almost thought we had that somewhere, but perhaps not?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



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

end of thread, other threads:[~2021-12-17  7:19 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-15  7:49 `unreadablep' Lars Ingebrigtsen
2021-12-15  8:19 ` `unreadablep' Po Lu
2021-12-15  8:35   ` `unreadablep' Lars Ingebrigtsen
2021-12-15  9:42     ` `unreadablep' Po Lu
2021-12-15 11:16       ` `unreadablep' Lars Ingebrigtsen
2021-12-15 11:25         ` `unreadablep' Po Lu
2021-12-15 12:19           ` `unreadablep' Lars Ingebrigtsen
2021-12-15 12:22             ` `unreadablep' Po Lu
2021-12-15 12:35               ` `unreadablep' Lars Ingebrigtsen
2021-12-15 12:42                 ` `unreadablep' Po Lu
2021-12-15 12:44                   ` `unreadablep' Lars Ingebrigtsen
2021-12-15 12:46                     ` `unreadablep' Po Lu
2021-12-15 12:51                       ` `unreadablep' Po Lu
2021-12-15 12:58                       ` `unreadablep' Lars Ingebrigtsen
2021-12-15 12:36               ` `unreadablep' Ihor Radchenko
2021-12-15 12:37                 ` `unreadablep' Po Lu
2021-12-15 17:00     ` [External] : `unreadablep' Drew Adams
2021-12-15  8:35 ` `unreadablep' Ihor Radchenko
2021-12-15  9:51   ` `unreadablep' Po Lu
2021-12-15 10:20     ` `unreadablep' Ihor Radchenko
2021-12-15 10:21       ` `unreadablep' Ihor Radchenko
2021-12-15 10:21       ` `unreadablep' Po Lu
2021-12-15 10:36         ` `unreadablep' Ihor Radchenko
2021-12-15 10:44           ` `unreadablep' Po Lu
2021-12-15 11:12             ` `unreadablep' Ihor Radchenko
2021-12-15 11:16               ` `unreadablep' Po Lu
2021-12-15 11:39                 ` `unreadablep' Ihor Radchenko
2021-12-15 14:12 ` `unreadablep' Stefan Monnier
2021-12-16  5:48   ` `unreadablep' Lars Ingebrigtsen
2021-12-16  8:03     ` `unreadablep' Eli Zaretskii
2021-12-17  7:18       ` `unreadablep' Lars Ingebrigtsen
2021-12-16 15:35     ` `unreadablep' Qiantan Hong
2021-12-17  7:19       ` `unreadablep' Lars Ingebrigtsen
2021-12-15 15:32 ` `unreadablep' Steingold
2021-12-15 16:04   ` `unreadablep' Qiantan Hong
2021-12-15 16:09 ` `unreadablep' Steingold
2021-12-15 20:21 ` `unreadablep' Philipp Stephani

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).