* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 @ 2023-09-01 14:17 Alan Mackenzie 2023-09-19 10:32 ` Alan Mackenzie ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Alan Mackenzie @ 2023-09-01 14:17 UTC (permalink / raw) To: 65680 Hello, Emacs. In cl-print-to-string-with-limit appears the following binding: (print-length (cond ((null limit) nil) ((eq limit t) print-length) (t (min limit 50)))) ^^^^^^^^^^^^ .. This has the effect of ignoring the parameter LIMIT (unless it is very small) and instead truncating the printed size to 50. There is a similar mechanism to limit print-level to 8. Although the doc string doesn't explicitly say it won't truncate like this, it kind of implies that LIMIT is the size it will truncate to. This excessive truncation is a bug. cl-print-to-string-with-limit is used by backtrace--print-to-string with a LIMIT of 5000 to print the first line of a debug buffer. The error message gets rudely truncated at 50 characters with an ellipsis, e.g.: Debugger entered--Lisp error: (error "Invalid call to `edebug-before'. Is your debug sp...") .. We shouldn't be doing this. It is irritating to the user. Correct would be to print: Debugger entered--Lisp error: (error "Invalid call to `edebug-before'. Is your debug spec correct?") .. I propose fixing this bug by removing these limits on print-length and print-level in cl-print-to-string-with-limit. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-01 14:17 bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 Alan Mackenzie @ 2023-09-19 10:32 ` Alan Mackenzie 2023-09-21 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-03 2:11 ` Michael Heerdegen 2 siblings, 0 replies; 15+ messages in thread From: Alan Mackenzie @ 2023-09-19 10:32 UTC (permalink / raw) To: 65680-done; +Cc: acm The bug has been fixed. On Fri, Sep 01, 2023 at 14:17:12 +0000, Alan Mackenzie wrote: > Hello, Emacs. > In cl-print-to-string-with-limit appears the following binding: > (print-length (cond > ((null limit) nil) > ((eq limit t) print-length) > (t (min limit 50)))) > ^^^^^^^^^^^^ > .. This has the effect of ignoring the parameter LIMIT (unless it is > very small) and instead truncating the printed size to 50. There is a > similar mechanism to limit print-level to 8. > Although the doc string doesn't explicitly say it won't truncate like > this, it kind of implies that LIMIT is the size it will truncate to. > This excessive truncation is a bug. > cl-print-to-string-with-limit is used by backtrace--print-to-string with > a LIMIT of 5000 to print the first line of a debug buffer. The error > message gets rudely truncated at 50 characters with an ellipsis, e.g.: > Debugger entered--Lisp error: (error "Invalid call to `edebug-before'. Is your debug sp...") > .. We shouldn't be doing this. It is irritating to the user. Correct > would be to print: > Debugger entered--Lisp error: (error "Invalid call to `edebug-before'. Is your debug spec correct?") > .. I propose fixing this bug by removing these limits on print-length and > print-level in cl-print-to-string-with-limit. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-01 14:17 bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 Alan Mackenzie 2023-09-19 10:32 ` Alan Mackenzie @ 2023-09-21 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 16:36 ` Eli Zaretskii 2023-09-21 17:07 ` Alan Mackenzie 2023-10-03 2:11 ` Michael Heerdegen 2 siblings, 2 replies; 15+ messages in thread From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-21 16:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 65680 Alan Mackenzie [2023-09-01 14:17:12] wrote: > Hello, Emacs. > > In cl-print-to-string-with-limit appears the following binding: > > (print-length (cond > ((null limit) nil) > ((eq limit t) print-length) > (t (min limit 50)))) > ^^^^^^^^^^^^ > > .. This has the effect of ignoring the parameter LIMIT (unless it is > very small) and instead truncating the printed size to 50. There is a > similar mechanism to limit print-level to 8. > > Although the doc string doesn't explicitly say it won't truncate like > this, it kind of implies that LIMIT is the size it will truncate to. > This excessive truncation is a bug. See also bug#34183. > .. I propose fixing this bug by removing these limits on print-length and > print-level in cl-print-to-string-with-limit. Sounds a bit drastic. Strings can be obnoxiously long, so it's important for cl-print to be able to truncate them. [ IOW, I'm not happy with commit 761f8901fffdb155cbcc7f3b5a2329161c2c1826. ] Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-21 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-21 16:36 ` Eli Zaretskii 2023-09-21 17:07 ` Alan Mackenzie 1 sibling, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2023-09-21 16:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: acm, 65680 > Cc: 65680@debbugs.gnu.org > Date: Thu, 21 Sep 2023 12:16:57 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> > > > .. I propose fixing this bug by removing these limits on print-length and > > print-level in cl-print-to-string-with-limit. > > Sounds a bit drastic. Strings can be obnoxiously long, so it's > important for cl-print to be able to truncate them. > [ IOW, I'm not happy with commit > 761f8901fffdb155cbcc7f3b5a2329161c2c1826. ] Then how about if we reinstate the limit, but with a larger limit for strings, in a separate variable? Do you have a suggestion for the value of such a limit? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-21 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 16:36 ` Eli Zaretskii @ 2023-09-21 17:07 ` Alan Mackenzie 2023-09-21 17:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 18:33 ` Eli Zaretskii 1 sibling, 2 replies; 15+ messages in thread From: Alan Mackenzie @ 2023-09-21 17:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: acm, 65680 Hello, Stefan. On Thu, Sep 21, 2023 at 12:16:57 -0400, Stefan Monnier wrote: > Alan Mackenzie [2023-09-01 14:17:12] wrote: > > Hello, Emacs. > > In cl-print-to-string-with-limit appears the following binding: > > (print-length (cond > > ((null limit) nil) > > ((eq limit t) print-length) > > (t (min limit 50)))) > > ^^^^^^^^^^^^ > > .. This has the effect of ignoring the parameter LIMIT (unless it is > > very small) and instead truncating the printed size to 50. There is a > > similar mechanism to limit print-level to 8. > > Although the doc string doesn't explicitly say it won't truncate like > > this, it kind of implies that LIMIT is the size it will truncate to. > > This excessive truncation is a bug. > See also bug#34183. > > .. I propose fixing this bug by removing these limits on print-length and > > print-level in cl-print-to-string-with-limit. > Sounds a bit drastic. Strings can be obnoxiously long, so it's > important for cl-print to be able to truncate them. There is clearly no human-sized bound on string lengths, so they can indeed be very long. Most of the time they're not. But they are very frequently longer than 50 characters. > [ IOW, I'm not happy with commit > 761f8901fffdb155cbcc7f3b5a2329161c2c1826. ] Well I did post about it to emacs-devel on Sunday and Monday, asking if anybody had any objection. Nobody, not even you, responded. I still believe that not truncating strings is better than truncating them to the minute length of 50. In fact, why truncate strings at all in cl-prin1? They're not truncated in prin1, etc. The reason for truncating lists and vectors is to prevent infinite printing when there's a circular list or vector, something which cannot happen with a string. If somebody doesn't want a string longer that 50 to get printed, then she shouldn't call cl-prin1 with it. The mistake in Emacs before my patch was a category error: wrongly believing that print-length applies to a string length too. It doesn't. String lengths are a completely different kettle of fish from list lengths. To solve this problem properly, we need, as Eli has suggested, a separate variable called something like print-string-length, to be set independently of print-length (and print-level). A sensible value for this variable in printing backtraces might be, say, 500. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-21 17:07 ` Alan Mackenzie @ 2023-09-21 17:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 19:22 ` Drew Adams 2023-09-21 18:33 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-21 17:51 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 65680 >> > .. I propose fixing this bug by removing these limits on print-length and >> > print-level in cl-print-to-string-with-limit. > >> Sounds a bit drastic. Strings can be obnoxiously long, so it's >> important for cl-print to be able to truncate them. > > There is clearly no human-sized bound on string lengths, so they can > indeed be very long. Most of the time they're not. But they are very > frequently longer than 50 characters. Agreed. >> [ IOW, I'm not happy with commit >> 761f8901fffdb155cbcc7f3b5a2329161c2c1826. ] > > Well I did post about it to emacs-devel on Sunday and Monday, asking if > anybody had any objection. Nobody, not even you, responded. I'm not on `emacs-devel` nowadays :-) > I still believe that not truncating strings is better than truncating > them to the minute length of 50. In fact, why truncate strings at all in > cl-prin1? They're not truncated in prin1, etc. The main purpose of `prin1` is to print Sexp in a way that can be read back. I.e. for machine-consumption. The main purpose of `cl-prin1` OTOH is for human consumption. For this reason it started truncating strings while `prin1` doesn't bother doing so. > The reason for truncating lists and vectors is to prevent infinite > printing when there's a circular list or vector, something which > cannot happen with a string. Not really, no. It's rather for things like keeping the length of backtrace lines under control. > If somebody doesn't want a string longer that 50 to get printed, then she > shouldn't call cl-prin1 with it. You're arguing against the wrong guy: I filed bug#34183 because I found the (current implementation of) string truncation annoying. That doesn't mean it's always annoying. > The mistake in Emacs before my patch was a category error: wrongly > believing that print-length applies to a string length too. That's bug#34183, indeed. > It doesn't. String lengths are a completely different kettle of fish > from list lengths. Not completely: they're all concerned with truncating the output so the human gets to see what comes afterwards, and to a large extent their optimal value for any given string/list/vector is probably one that corresponds more or less to the same output string length. > To solve this problem properly, we need, as Eli has suggested, a separate > variable called something like print-string-length, to be set > independently of print-length (and print-level). Sounds good. > A sensible value for this variable in printing backtraces might be, > say, 500. 500 is "damn long" for a line in a backtrace, IMO. If I need to see that much of the string, I won't mind having to click the "..." to reveal it. I'd vote for a default limit somewhere between "one or two lines of 80 columns". FWIW, after filing bug#34183 I hacked my local Emacs to use (* 8 print-length) for max string length (leading to 96 chars by default, IIRC), thinking I'd tweak it later based on experience. I never felt like tweaking it, tho, so it looks like it's a good approximation of my ideal choice. We could make its default value dynamically computed from `print-length`, so things like `cl-print-to-string-with-limit` don't need to be adjusted. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-21 17:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-21 19:22 ` Drew Adams 2023-09-21 20:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 15+ messages in thread From: Drew Adams @ 2023-09-21 19:22 UTC (permalink / raw) To: Stefan Monnier, Alan Mackenzie; +Cc: 65680@debbugs.gnu.org > > I still believe that not truncating strings is better than truncating > > them to the minute length of 50. In fact, why truncate strings at all > > in cl-prin1? They're not truncated in prin1, etc. > > The main purpose of `prin1` is to print Sexp in a way that can be > read back. I.e. for machine-consumption. > The main purpose of `cl-prin1` OTOH is for human consumption. > For this reason it started truncating strings while `prin1` doesn't > bother doing so. Not to muddy the waters too much, but FWIW: `cl-prin1' is a far cry from an emulation of Common Lisp `prin1'. (And for Common Lisp `prin1' there is _no_ truncation. That is, nothing in the standard allows for truncation. But _implementations_ could provide an option that allows for truncation, AFAICS.) > > It doesn't. String lengths are a completely different kettle of fish > > from list lengths. > > Not completely: they're all concerned with truncating the output so the > human gets to see what comes afterwards, and to a large extent their > optimal value for any given string/list/vector is probably one that > corresponds more or less to the same output string length. FWIW: Common Lisp treats strings very differently from arrays, vectors, and lists. It specifically does not let variable `*print-length*' apply to strings (and there is no other var that does so). > > To solve this problem properly, we need, as Eli has > > suggested, a separate variable called something like > > print-string-length, to be set independently of > > print-length (and print-level). > > Sounds good. Yes, that would be reasonable. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-21 19:22 ` Drew Adams @ 2023-09-21 20:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-21 20:00 UTC (permalink / raw) To: Drew Adams; +Cc: Alan Mackenzie, 65680@debbugs.gnu.org > Not to muddy the waters too much, but FWIW: `cl-prin1' > is a far cry from an emulation of Common Lisp `prin1'. Please don't discuss Common Lisp here. This is a bug report bout Emacs Lisp. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-21 17:07 ` Alan Mackenzie 2023-09-21 17:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-09-21 18:33 ` Eli Zaretskii [not found] ` <ZQ1m766tulSqvuC6@ACM> 1 sibling, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2023-09-21 18:33 UTC (permalink / raw) To: Alan Mackenzie; +Cc: acm, 65680, monnier > Cc: acm@muc.de, 65680@debbugs.gnu.org > Date: Thu, 21 Sep 2023 17:07:58 +0000 > From: Alan Mackenzie <acm@muc.de> > > > [ IOW, I'm not happy with commit > > 761f8901fffdb155cbcc7f3b5a2329161c2c1826. ] > > Well I did post about it to emacs-devel on Sunday and Monday, asking if > anybody had any objection. Nobody, not even you, responded. TTTT, 2 days is too short a time to assume no one has anything to say about a change. I had a busy day and just couldn't get to it, before I saw you have already installed it. > To solve this problem properly, we need, as Eli has suggested, a separate > variable called something like print-string-length, to be set > independently of print-length (and print-level). A sensible value for > this variable in printing backtraces might be, say, 500. 500 is too large a value, my vote is for 200 at most. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <ZQ1m766tulSqvuC6@ACM>]
[parent not found: <83msxe779i.fsf@gnu.org>]
[parent not found: <ZQ2JVhy-e8NpCJqq@ACM>]
[parent not found: <837coi74ia.fsf@gnu.org>]
[parent not found: <jwva5tefif5.fsf-monnier+emacs@gnu.org>]
[parent not found: <ZRRGZaRf3WU9z6m_@ACM>]
[parent not found: <83v8btywz3.fsf@gnu.org>]
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 [not found] ` <83v8btywz3.fsf@gnu.org> @ 2023-09-29 16:49 ` Alan Mackenzie 2023-09-29 16:53 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Alan Mackenzie @ 2023-09-29 16:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, 65680-done, monnier Hello, Eli. On Fri, Sep 29, 2023 at 15:39:44 +0300, Eli Zaretskii wrote: > > Date: Wed, 27 Sep 2023 15:12:37 +0000 > > Cc: Eli Zaretskii <eliz@gnu.org> > > From: Alan Mackenzie <acm@muc.de> > > I've implemented cl-print-string-length in cl-print.el, but not as a > > customisable variable (for consistency with print-{length,level}). I > > manipulate it in cl-print-string-with-limit by binding it to (- limit > > 3), then multiplying it by ¾ at each successive trial printing. > > I haven't yet made any amendment to the CL manual. > Please do. It seems that cl-print.el is entirely undocumented in the CL manual. I've opened bug #66267 for this. I intend to work on it in the coming days. > > Here's the patch I propose to commit: > OK, modulo Stefan's comment. I've committed it, and I'm closing bug #65680 with this post. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-29 16:49 ` Alan Mackenzie @ 2023-09-29 16:53 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2023-09-29 16:53 UTC (permalink / raw) To: Alan Mackenzie; +Cc: acm, 65680-done, monnier > Date: Fri, 29 Sep 2023 16:49:57 +0000 > Cc: monnier@iro.umontreal.ca, 65680-done@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie <acm@muc.de> > > > > Here's the patch I propose to commit: > > > OK, modulo Stefan's comment. > > I've committed it, and I'm closing bug #65680 with this post. Thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-09-01 14:17 bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 Alan Mackenzie 2023-09-19 10:32 ` Alan Mackenzie 2023-09-21 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-03 2:11 ` Michael Heerdegen 2023-10-03 9:18 ` Alan Mackenzie 2023-10-03 10:26 ` Alan Mackenzie 2 siblings, 2 replies; 15+ messages in thread From: Michael Heerdegen @ 2023-10-03 2:11 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 65680 Hello Alan, in 01229fe0096 "Stop truncating strings too much in cl-print-string-with-limit" there is an error: the first `cond' condition will error when limit is nil (`zerop' expects a number): | @@ -557,6 +572,11 @@ cl-print-to-string-with-limit | ((null limit) nil) | ((eq limit t) print-level) | (t (min 8 (truncate (log limit)))))) | + (cl-print-string-length | + (cond | + ((or (null limit) (zerop limit)) nil) | + ((eq limit t) cl-print-string-length) | + (t (max 0 (- limit 3))))) TIA, Michael. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-10-03 2:11 ` Michael Heerdegen @ 2023-10-03 9:18 ` Alan Mackenzie 2023-10-03 10:26 ` Alan Mackenzie 1 sibling, 0 replies; 15+ messages in thread From: Alan Mackenzie @ 2023-10-03 9:18 UTC (permalink / raw) To: Michael Heerdegen; +Cc: 65680 Hello, Michael. On Tue, Oct 03, 2023 at 04:11:16 +0200, Michael Heerdegen wrote: > Hello Alan, > in 01229fe0096 "Stop truncating strings too much in > cl-print-string-with-limit" there is an error: the first `cond' > condition will error when limit is nil (`zerop' expects a number): I think you mean when limit is t. When limit is nil, the (null limit) inside the `or' will catch it. Thanks for pointing out this bug. I'll fix it. > | @@ -557,6 +572,11 @@ cl-print-to-string-with-limit > | ((null limit) nil) > | ((eq limit t) print-level) > | (t (min 8 (truncate (log limit)))))) > | + (cl-print-string-length > | + (cond > | + ((or (null limit) (zerop limit)) nil) > | + ((eq limit t) cl-print-string-length) > | + (t (max 0 (- limit 3))))) > TIA, > Michael. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-10-03 2:11 ` Michael Heerdegen 2023-10-03 9:18 ` Alan Mackenzie @ 2023-10-03 10:26 ` Alan Mackenzie 2023-10-03 23:35 ` Michael Heerdegen 1 sibling, 1 reply; 15+ messages in thread From: Alan Mackenzie @ 2023-10-03 10:26 UTC (permalink / raw) To: Michael Heerdegen; +Cc: acm, 65680 Hello, Michael. On Tue, Oct 03, 2023 at 04:11:16 +0200, Michael Heerdegen wrote: > Hello Alan, > in 01229fe0096 "Stop truncating strings too much in > cl-print-string-with-limit" there is an error: the first `cond' > condition will error when limit is nil (`zerop' expects a number): > | @@ -557,6 +572,11 @@ cl-print-to-string-with-limit > | ((null limit) nil) > | ((eq limit t) print-level) > | (t (min 8 (truncate (log limit)))))) > | + (cl-print-string-length > | + (cond > | + ((or (null limit) (zerop limit)) nil) > | + ((eq limit t) cl-print-string-length) > | + (t (max 0 (- limit 3))))) > TIA, This should now be fixed on the master branch. > Michael. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 2023-10-03 10:26 ` Alan Mackenzie @ 2023-10-03 23:35 ` Michael Heerdegen 0 siblings, 0 replies; 15+ messages in thread From: Michael Heerdegen @ 2023-10-03 23:35 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 65680 Alan Mackenzie <acm@muc.de> writes: > I think you mean when limit is t. Yes of course - sorry for the typo. > This should now be fixed on the master branch. Thank you. Michael. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2023-10-03 23:35 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-09-01 14:17 bug#65680: cl-print-to-string-with-limit erroneously imposes a maximum print-length of 50 Alan Mackenzie 2023-09-19 10:32 ` Alan Mackenzie 2023-09-21 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 16:36 ` Eli Zaretskii 2023-09-21 17:07 ` Alan Mackenzie 2023-09-21 17:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 19:22 ` Drew Adams 2023-09-21 20:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-09-21 18:33 ` Eli Zaretskii [not found] ` <ZQ1m766tulSqvuC6@ACM> [not found] ` <83msxe779i.fsf@gnu.org> [not found] ` <ZQ2JVhy-e8NpCJqq@ACM> [not found] ` <837coi74ia.fsf@gnu.org> [not found] ` <jwva5tefif5.fsf-monnier+emacs@gnu.org> [not found] ` <ZRRGZaRf3WU9z6m_@ACM> [not found] ` <83v8btywz3.fsf@gnu.org> 2023-09-29 16:49 ` Alan Mackenzie 2023-09-29 16:53 ` Eli Zaretskii 2023-10-03 2:11 ` Michael Heerdegen 2023-10-03 9:18 ` Alan Mackenzie 2023-10-03 10:26 ` Alan Mackenzie 2023-10-03 23:35 ` Michael Heerdegen
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).