GNU bug report logs -
#6991
Please keep bytecode out of *Backtrace* buffers
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Tue, 7 Sep 2010 01:34:01 UTC
Severity: wishlist
Tags: fixed, notabug
Merged with 15789
Found in version 24.3.50
Fixed in version 26.1
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6991 in the body.
You can then email your comments to 6991 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Tue, 07 Sep 2010 01:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 07 Sep 2010 01:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Please keep bytecode out of *Backtrace* buffers.
* It is unreadable.
* It will cause problems when sent via email. Even if one runs col(1)
and strings(1) on it, nobody can read it anyway.
* The mountain of gobbledygook makes people reading give up on trying to help.
E.g., http://article.gmane.org/gmane.emacs.w3m/8695
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Wed, 22 Feb 2012 01:05:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
jidanni <at> jidanni.org:
bug acknowledged by developer.
(Wed, 22 Feb 2012 01:05:05 GMT)
Full text and
rfc822 format available.
Message #10 received at 6991-done <at> debbugs.gnu.org (full text, mbox):
No. Closed as wontfix.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Wed, 22 Feb 2012 16:46:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> No. Closed as wontfix.
Why? No reason given. This is a reasonable request, which would improve
correspondence about bugs and user difficulties.
Users who are aware of the problem often have to manually excise such binary
codes and replace them with `...' or nothing. Users who are unaware of the
problem can end up sending an incomplete backtrace.
This should at least be a wishlist item, IMO. Or at least give a convincing
argument why the request is not appropriate.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 22 Feb 2012 16:47:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Wed, 22 Feb 2012 17:06:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 6991 <at> debbugs.gnu.org (full text, mbox):
On Wed, Feb 22, 2012 at 17:43, Drew Adams <drew.adams <at> oracle.com> wrote:
> Why? No reason given. This is a reasonable request, which would improve
> correspondence about bugs and user difficulties.
>
> Users who are aware of the problem often have to manually excise such binary
> codes and replace them with `...' or nothing.
Yes. Not two days ago I had to do exactly that.
> This should at least be a wishlist item, IMO. Or at least give a convincing
> argument why the request is not appropriate.
Agreed.
Juanma
Reply sent
to
Juanma Barranquero <lekktu <at> gmail.com>:
You have taken responsibility.
(Wed, 22 Feb 2012 17:06:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
jidanni <at> jidanni.org:
bug acknowledged by developer.
(Wed, 22 Feb 2012 17:06:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 22 Mar 2012 11:24:04 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 02 Jul 2012 17:34:01 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
"Drew Adams" <drew.adams <at> oracle.com>
to
control <at> debbugs.gnu.org.
(Mon, 02 Jul 2012 17:37:02 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 02 Jul 2012 17:37:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 02 Jul 2012 17:46:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> > Why? No reason given. This is a reasonable request, which
> > would improve correspondence about bugs and user difficulties.
And no response to that question. I've reopened this bug.
> > Users who are aware of the problem often have to manually
> > excise such binary codes and replace them with `...' or nothing.
>
> Yes. Not two days ago I had to do exactly that.
I do it quite frequently. And I see portions of backtrace text sent by email
and posted to websites quite often - including in this bug list!
Posting a backtrace is a common and reasonable way to communicate about many
Emacs problems. Needing to hand-sanitize a backtrace log to remove byte code
portions is silly. That's what machines and software are for.
> > This should at least be a wishlist item, IMO. Or at least
> > give a convincing argument why the request is not appropriate.
>
> Agreed.
Users should be able to control this (e.g. via an option, and perhaps even a
toggle key in buffer *Backtrace*.
The usefulness of this should be a no-brainer.
I cannot speak to the difficulty of implementating the fix.
Reply sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
You have taken responsibility.
(Mon, 02 Jul 2012 17:46:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
jidanni <at> jidanni.org:
bug acknowledged by developer.
(Mon, 02 Jul 2012 17:46:03 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 02 Jul 2012 17:50:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 02 Jul 2012 18:44:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 6991 <at> debbugs.gnu.org (full text, mbox):
>> > Why? No reason given. This is a reasonable request, which
>> > would improve correspondence about bugs and user difficulties.
> And no response to that question. I've reopened this bug.
You can try the simple patch below. It doesn't cut it for me, and
I think the only way to make it work well would be to change the
representation of the byte-codes so that they're not just a "unibyte
string" but an object with a distinctive type: the patch only catches
the case where the byte-codes appear within a printed
byte-compiled-function, not when they're arguments to the `byte-code'
function or to the `make-byte-code' function, and I'm sure there can be
other cases.
Stefan
=== modified file 'src/print.c'
--- src/print.c 2012-06-28 11:11:48 +0000
+++ src/print.c 2012-07-02 18:37:46 +0000
@@ -1937,8 +1937,11 @@
else
{
ptrdiff_t size = ASIZE (obj);
+ int bytecode = 0;
+
if (COMPILEDP (obj))
{
PRINTCHAR ('#');
+ bytecode = 1;
size &= PSEUDOVECTOR_SIZE_MASK;
}
@@ -1978,6 +1981,9 @@
{
if (i) PRINTCHAR (' ');
tem = AREF (obj, i);
+ if (bytecode && i == 1 && INTEGERP (Vprint_level))
+ strout ("\"..<bytecode>..\"", 16, 16, printcharfun);
+ else
print_object (tem, printcharfun, escapeflag);
}
if (size < real_size)
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility.
(Mon, 02 Jul 2012 18:44:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
jidanni <at> jidanni.org:
bug acknowledged by developer.
(Mon, 02 Jul 2012 18:44:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 02 Jul 2012 19:12:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> You can try the simple patch below. It doesn't cut it for me, and
> I think the only way to make it work well would be to change the
> representation of the byte-codes so that they're not just a "unibyte
> string" but an object with a distinctive type: the patch only catches
> the case where the byte-codes appear within a printed
> byte-compiled-function, not when they're arguments to the `byte-code'
> function or to the `make-byte-code' function, and I'm sure
> there can be other cases.
Thanks, but I don't build Emacs. Hopefully something like this will be added to
Emacs itself, even if it is only a partial solution.
Did you mean to close the bug? It seems to be getting closed just because (?)
6991-done is in the recipients list.
If you did not mean to close it, let's please reopen it. Even if it is made
only a wishlist item, it is a useful enhancement request.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 03 Jul 2012 14:39:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Thu, 24 Jan 2013 22:44:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> Sent: Monday, July 02, 2012 12:06 PM
>
> > You can try the simple patch below. It doesn't cut it for me, and
> > I think the only way to make it work well would be to change the
> > representation of the byte-codes so that they're not just a "unibyte
> > string" but an object with a distinctive type: the patch
> > only catches the case where the byte-codes appear within a printed
> > byte-compiled-function, not when they're arguments to the
> > `byte-code' function or to the `make-byte-code' function, and I'm sure
> > there can be other cases.
>
> Thanks, but I don't build Emacs. Hopefully something like
> this will be added to Emacs itself, even if it is only a partial
> solution.
>
> Did you mean to close the bug? It seems to be getting closed
> just because (?) 6991-done is in the recipients list.
>
> If you did not mean to close it, let's please reopen it.
> Even if it is made only a wishlist item, it is a useful enhancement
> request.
Can we please follow up on this? The status seems to be `wishlist' but tagged
`wontfix', which doesn't make a lot of sense to me.
I cannot build Emacs to test this. Could someone else please test it? Or could
it please be installed without testing? (Seriously.)
It would _really_ be helpful if there were no binary crap in Lisp backtraces.
Does that stuff actually help anyone? If so, perhaps we can keep it as a
(non-default) option, but otherwise, can't we simply elide anything that is not
a printable character, at the least?
I mean replace it by `...', not just change a `display' property. The problems
I encounter arise from trying to copy + paste the backtrace.
I don't understand why we even have backtraces that one cannot copy & paste
completely, into, e.g., an email. What's the point of that? If I try to paste
a copied backtrace I need to paste bits of it piecemeal, because the binary
parts do not paste. That is tedious and error prone. Many users might not even
realize that the backtrace did not get completely pasted.
Why is it so hard to advance on something like this? Stefan provided a C patch
to test, and that was the end of the thread.
So much stuff gets added to the Emacs C sources anyway, sometimes breaking all
kinds of stuff. Why don't you please just go ahead and install your patch,
Stefan, so we can see whether and how much it helps?
Please consider trying to do something to advance this schmilblick. I am sure
that it will be appreciated by more than just me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Wed, 07 Aug 2013 22:26:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Can we please fix this? What about Stefan's patch? Etc.
> Sent: Thursday, January 24, 2013 2:43 PM
>
> > Sent: Monday, July 02, 2012 12:06 PM
> >
> > > You can try the simple patch below. It doesn't cut it for me, and
> > > I think the only way to make it work well would be to change the
> > > representation of the byte-codes so that they're not just a "unibyte
> > > string" but an object with a distinctive type: the patch
> > > only catches the case where the byte-codes appear within a printed
> > > byte-compiled-function, not when they're arguments to the
> > > `byte-code' function or to the `make-byte-code' function, and I'm sure
> > > there can be other cases.
> >
> > Thanks, but I don't build Emacs. Hopefully something like
> > this will be added to Emacs itself, even if it is only a partial
> > solution.
> >
> > Did you mean to close the bug? It seems to be getting closed
> > just because (?) 6991-done is in the recipients list.
> >
> > If you did not mean to close it, let's please reopen it.
> > Even if it is made only a wishlist item, it is a useful enhancement
> > request.
>
> Can we please follow up on this? The status seems to be `wishlist' but
> tagged `wontfix', which doesn't make a lot of sense to me.
>
> I cannot build Emacs to test this. Could someone else please test it? Or
> could it please be installed without testing? (Seriously.)
>
> It would _really_ be helpful if there were no binary crap in Lisp
> backtraces. Does that stuff actually help anyone? If so, perhaps we can
> keep it as a (non-default) option, but otherwise, can't we simply elide
> anything that is not a printable character, at the least?
>
> I mean replace it by `...', not just change a `display' property. The
> problems
> I encounter arise from trying to copy + paste the backtrace.
>
> I don't understand why we even have backtraces that one cannot copy & paste
> completely, into, e.g., an email. What's the point of that? If I try to
> paste a copied backtrace I need to paste bits of it piecemeal, because the
> binary parts do not paste. That is tedious and error prone. Many users
> might not even realize that the backtrace did not get completely pasted.
>
> Why is it so hard to advance on something like this? Stefan provided a C
> patch to test, and that was the end of the thread.
>
> So much stuff gets added to the Emacs C sources anyway, sometimes breaking
> all kinds of stuff. Why don't you please just go ahead and install your
> patch, Stefan, so we can see whether and how much it helps?
>
> Please consider trying to do something to advance this schmilblick. I am
> sure that it will be appreciated by more than just me.
Removed tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 01 Feb 2014 07:29:02 GMT)
Full text and
rfc822 format available.
Added tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 01 Feb 2014 07:29:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Fri, 26 Feb 2016 06:43:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> You can try the simple patch below. It doesn't cut it for me, and
> I think the only way to make it work well would be to change the
> representation of the byte-codes so that they're not just a "unibyte
> string" but an object with a distinctive type: the patch only catches
> the case where the byte-codes appear within a printed
> byte-compiled-function, not when they're arguments to the `byte-code'
> function or to the `make-byte-code' function, and I'm sure there can be
> other cases.
The patch doesn't seem to do what we want.
If we don't have debug-on-error, it's OK:
eval: Wrong number of arguments: #[(&optional handle) "..<bytecode>.." [article-buffer handle temp-buffer coding-system-for-read coding-system-for-write default-process-coding-system mm-dissect-buffer t buffer-name generate-new-buffer ...] 28], 2
But with debug-on-error, the backtrace is as byte-ey as ever:
Debugger entered--Lisp error: (wrong-number-of-arguments #[(&optional handle) "p \204
\306\307!\214``}\210\212 \211@\203\245\310 @!\203\245\311\312!r
q\210\313\216\314 \210\315 @!\210\316\317 8 \211@;\203A @\202E A@@)\"\210\320\211 B\321 A@\322\"\211\203}\323\324\307#\211\203}\325=\204}\326\327 \"\330 \210\331 \210c\210\332ed\333\324\324\334\335\336\337\340\337\341\342\341\343\341\344\345\346\347-\"\350\346\347.\"\341\351\352\353&\210.*\354 *\207" [article-buffer handle temp-buffer coding-system-for-read coding-system-for-write default-process-coding-system mm-dissect-buffer t buffer-name generate-new-buffer " *temp*" #[nil "\301!\205 \302!\207" [temp-buffer buffer-name kill-buffer] 2] mm-disable-multibyte insert-buffer-substring mm-decode-content-transfer-encoding 2 utf-8 mail-content-type-get charset mm-charset-to-coding-system nil ascii decode-coding-string buffer-string erase-buffer mm-enable-multibyte call-process-region "w3m" "-halfdump" "-no-cookie" "-I" "UTF-8" "-O" "-o" "ext_halfdump=1" "display_ins_del=2" "pre_conv=1" "-t" format "%s" "-cols" "display_image=on" "-T" "text/html" gnus-html-wash-tags tab-width gnus-html-frame-width] 28] 2)
gnus-article-html(1 2)
eval((gnus-article-html 1 2) nil)
eval-expression((gnus-article-html 1 2) nil)
funcall-interactively(eval-expression (gnus-article-html 1 2) nil)
call-interactively(eval-expression nil nil)
command-execute(eval-expression)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Reply sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>:
You have taken responsibility.
(Fri, 26 Feb 2016 06:43:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
jidanni <at> jidanni.org:
bug acknowledged by developer.
(Fri, 26 Feb 2016 06:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Fri, 26 Feb 2016 14:13:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Why is this bug classified as "Won't Fix"? Isn't this something
we would all like to see fixed? Not fixing today does not mean
that it should not be fixed.
What's more, _users_ currently do the work by hand, so it must
be possible to at least partly (probably fully) get it done
by program. If users can manually (time-consuming and error-prone)
redact the byte-code when pasting a backtrace into a mail etc.
then that can be done by program.
The fact that no one has done this yet is not a good reason
to close this as "wont-fix".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Fri, 26 Feb 2016 14:13:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 27 Feb 2016 00:54:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 6991 <at> debbugs.gnu.org (full text, mbox):
>>>>> Drew Adams <drew.adams <at> oracle.com> writes:
> What's more, _users_ currently do the work by hand, so it must be possible
> to at least partly (probably fully) get it done by program. If users can
> manually (time-consuming and error-prone) redact the byte-code when pasting
> a backtrace into a mail etc. then that can be done by program.
Drew, can you show me what it will look like to have the elision performed?
Sometimes the byte-code contains strings that give me a clue as to the
problem, so I'm wondering what will disappear if this is fixed.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 27 Feb 2016 00:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 27 Feb 2016 01:51:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> Drew, can you show me what it will look like to have the elision
> performed? Sometimes the byte-code contains strings that give me
> a clue as to the problem, so I'm wondering what will disappear if
> this is fixed.
Nothing prevents letting a user control the degree of elision.
If someone thinks that part of a #[...] occurrence might be
helpful then a yankable and readable part of it could be included.
In general, my guess is that most #[...] occurrences can just
be removed (replaced by an elision indicator).
I can show what I do, at least:
1. I start by trying to yank a whole backtrace into a bug-report
buffer.
2. That typically doesn't work completely: some of the yanked
text is truncated (not yanked) because it is binary stuff
from byte-code.
3. So I often have to yank separate pieces of a backtrace - parts
that are yankable (which might still contain some byte-code,
but byte-code that is yankable).
4. I remove anything that is problematic/meaningless, leaving
ordinary text that humans can read. In my experience there
is nothing in the byte code that is of interest and that
doesn't also appear anyway in the non-byte-code part of the
backtrace.
5. I can include some from an Emacs 24.5 backtrace (Emacs 25 is
unusable for me - crashes within a minute or two, and has
done so for a couple years now).
6. Caveat: I byte-compile my code with the oldest Emacs version
that that particular code supports. That could be Emacs 20,
22, 23 (or maybe 24 or 25, for some libraries).
Here's a backtrace with some byte-code in it:
Debugger entered--entering a function:
* icicle-ucs-names()
* #[(prompt &optional names) "\204
See, only the top two lines got pasted (even into an Outlook
window, and the second line was truncated at the first null
byte (it appears as ^@ in the backtrace, where that is a null
char and not two chars).
The " \204 that you (might) see here looks like this in Emacs:
"^H\204^G^@\306" etc., but each of those ^LETTER occurrences
is a control char, not a doublet with first char ^.
Then I would yank a bit more, not bothering to copy the
same byte-code that appears in the third line:
* apply(#[(prompt &optional names) "\204
Then I would copy and paste some more - in this case all of
the rest of the backtrace has no byte-code:
* read-char-by-name("Unicode (name or hex): ")
(list (read-char-by-name "Unicode (name or hex): ") (prefix-numeric-value current-prefix-arg) t t)
call-interactively(ucsc-insert nil nil)
command-execute(ucsc-insert)
Then I would clean up the byte-code that was successfully
yanked, probably replacing it with "...". I don't have a
special way of doing these things. I just edit manually,
to give something like this:
Debugger entered--entering a function:
* icicle-ucs-names()
* #[(prompt &optional names) "..." [names cands prompt new-prompt enable-recursive-minibuffers completion-ignore-case icicle-ucs-names delq nil mapcar icicle-make-char-candidate copy-sequence t (1) " " ((3 (face icicle-candidate-part))) icicle-mctize-all lambda (string pred action) if (eq action (quote metadata)) (quote (metadata (category . unicode-name))) complete-with-action action quote (string pred) completing-read string-match-p "\\`[0-9a-fA-F]+\\'" string-to-number 16 "^#" read assoc-string try-completion icicle-transform-multi-completion (2) get-text-property 0 icicle-whole-candidate characterp error "Invalid character: `%s'" add-to-list icicle-read-char-history icicle-read-char-by-name-multi-completion-flag icicle-show-multi-completion-flag icicle-multi-completing-p icicle-list-use-nth-parts icicle-transform-before-sort-p ...] 10 "Read a character... I'VE ELIDED MOST OF A LONG DOC STRING HERE")
* apply(#[(prompt &optional names) - same as line above.)
* read-char-by-name("Unicode (name or hex): ")
(list (read-char-by-name "Unicode (name or hex): ") (prefix-numeric-value current-prefix-arg) t t)
call-interactively(ucsc-insert nil nil)
command-execute(ucsc-insert)
In this case I also manually elided a long doc string, not
just byte-code.
Is it worthwhile to keep some of what is inside #[...]?
Here, I did - I removed only the binary code stuff. But it
might be good in most cases to just elide each occurrence of
#[STUFF].
HTH - Drew
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 27 Feb 2016 01:51:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 27 Feb 2016 04:14:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 6991 <at> debbugs.gnu.org (full text, mbox):
John Wiegley <jwiegley <at> gmail.com> writes:
>>>>>> Drew Adams <drew.adams <at> oracle.com> writes:
>
>> What's more, _users_ currently do the work by hand, so it must be possible
>> to at least partly (probably fully) get it done by program. If users can
>> manually (time-consuming and error-prone) redact the byte-code when pasting
>> a backtrace into a mail etc. then that can be done by program.
>
> Drew, can you show me what it will look like to have the elision performed?
> Sometimes the byte-code contains strings that give me a clue as to the
> problem, so I'm wondering what will disappear if this is fixed.
I thought the post I made yesterday showed the difference? And it's
that the byte codes themselves get replaced by "..<bytecode>..", and not
the symbols (etc.) that are useful for figuring out backtraces.
But the patch was backwards -- it inhibited it outside of backtraces
instead of in backtraces.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 27 Feb 2016 04:14:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>:
You have taken responsibility.
(Sat, 27 Feb 2016 04:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
jidanni <at> jidanni.org:
bug acknowledged by developer.
(Sat, 27 Feb 2016 04:14:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 26 Mar 2016 11:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Sat, 19 Nov 2016 00:23:02 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 19 Nov 2016 00:23:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) patch.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Sat, 19 Nov 2016 00:23:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 01:56:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 6991 <at> debbugs.gnu.org (full text, mbox):
It looks like this bug was closed a couple times because
6991-done <at> debbugs.gnu.org was added to the Cc list. I've removed it,
and let's try not to add it again.
Drew Adams <drew.adams <at> oracle.com> writes:
>
> Here's a backtrace with some byte-code in it:
>
> Debugger entered--entering a function:
> * icicle-ucs-names()
> * #[(prompt &optional names) "\204
>
>
> See, only the top two lines got pasted (even into an Outlook
> window, and the second line was truncated at the first null
> byte (it appears as ^@ in the backtrace, where that is a null
> char and not two chars).
I would propose something like the below, which will cause the NUL byte
to be rendered as \0 instead of ^@. We could potentially do this with
other control characters too, if they cause trouble too?
I do think it's worth keeping the bytecode in the backtrace, because
it's not useless: you can run `disassemble' on it and get something
meaningful. Perhaps hiding the byte code with display properties would
be useful.
modified src/print.c
@@ -1477,18 +1477,20 @@ print_object (Lisp_Object obj, Lisp_Object printcharfun, bool escapeflag)
could be taken as part of it,
output `\ ' to prevent that. */
if (need_nonhex && c_isxdigit (c))
print_c_string ("\\ ", printcharfun);
+ need_nonhex = false;
if (c == '\n' && print_escape_newlines
? (c = 'n', true)
: c == '\f' && print_escape_newlines
? (c = 'f', true)
+ : c == '\0' && print_escape_nonascii
+ ? (c = '0', need_nonhex = true)
: c == '\"' || c == '\\')
printchar ('\\', printcharfun);
printchar (c, printcharfun);
- need_nonhex = false;
}
}
printchar ('\"', printcharfun);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 02:39:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> I would propose something like the below, which will cause the NUL
> byte to be rendered as \0 instead of ^@. We could potentially do this
> with other control characters too, if they cause trouble too?
>
> I do think it's worth keeping the bytecode in the backtrace, because
> it's not useless: you can run `disassemble' on it and get something
> meaningful. Perhaps hiding the byte code with display properties
> would be useful.
Any improvement is an improvement. Please go for it. Thx.
That's a simple change that shouldn't introduce new problems.
If others propose more elaborate improvements, they will likely
be independent - this won't bother them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 07:42:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: npostavs <at> users.sourceforge.net
> Date: Fri, 18 Nov 2016 20:55:54 -0500
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
> John Wiegley <johnw <at> gnu.org>,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, 6991 <at> debbugs.gnu.org
>
> Drew Adams <drew.adams <at> oracle.com> writes:
> >
> > Here's a backtrace with some byte-code in it:
> >
> > Debugger entered--entering a function:
> > * icicle-ucs-names()
> > * #[(prompt &optional names) "\204
> >
> >
> > See, only the top two lines got pasted (even into an Outlook
> > window, and the second line was truncated at the first null
> > byte (it appears as ^@ in the backtrace, where that is a null
> > char and not two chars).
>
> I would propose something like the below, which will cause the NUL byte
> to be rendered as \0 instead of ^@. We could potentially do this with
> other control characters too, if they cause trouble too?
Isn't the fact that copying text into the clipboard stops at the first
null character a Windows-specific issue? And if it isn't Windows
specific, isn't it at least specific to selections?
I think Emacs doesn't need this change for all occurrences of the null
byte, because Emacs Lisp strings and buffer text will happily DTRT
with them (they were designed to do so). So I thin we should only
"fix" this problem where it happens, not in print functions in
general.
> I do think it's worth keeping the bytecode in the backtrace, because
> it's not useless: you can run `disassemble' on it and get something
> meaningful.
Exactly. But if we change print_object like you suggest, there's no
way of being sure the null bytes won't be mangled by some application
of a print function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 14:39:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> I would propose something like the below, which will cause the NUL byte
>> to be rendered as \0 instead of ^@. We could potentially do this with
>> other control characters too, if they cause trouble too?
>
> Isn't the fact that copying text into the clipboard stops at the first
> null character a Windows-specific issue? And if it isn't Windows
> specific, isn't it at least specific to selections?
It seems to be application specific. When I copy to a Firefox text area
on GNU/Linux I get a truncated result, but using xclip | od -c, I can
see the NUL byte and following characters are there.
>
> I think Emacs doesn't need this change for all occurrences of the null
> byte, because Emacs Lisp strings and buffer text will happily DTRT
> with them (they were designed to do so). So I thin we should only
> "fix" this problem where it happens, not in print functions in
> general.
We could try fixing this in `gui-select-text', but the problem there is
that we don't necessarily know that replace NUL with "\0" is valid.
>
> Exactly. But if we change print_object like you suggest, there's no
> way of being sure the null bytes won't be mangled by some application
> of a print function.
I'm not sure what you mean.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 15:08:01 GMT)
Full text and
rfc822 format available.
Message #124 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: npostavs <at> users.sourceforge.net
> Cc: 6991 <at> debbugs.gnu.org, lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, drew.adams <at> oracle.com
> Date: Sat, 19 Nov 2016 09:39:09 -0500
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> I would propose something like the below, which will cause the NUL byte
> >> to be rendered as \0 instead of ^@. We could potentially do this with
> >> other control characters too, if they cause trouble too?
> >
> > Isn't the fact that copying text into the clipboard stops at the first
> > null character a Windows-specific issue? And if it isn't Windows
> > specific, isn't it at least specific to selections?
>
> It seems to be application specific. When I copy to a Firefox text area
> on GNU/Linux I get a truncated result, but using xclip | od -c, I can
> see the NUL byte and following characters are there.
If this happens on both Windows and X, then both xselect.c and
w32select.c should "encode" null bytes. Would that solve the problem?
> > Exactly. But if we change print_object like you suggest, there's no
> > way of being sure the null bytes won't be mangled by some application
> > of a print function.
>
> I'm not sure what you mean.
A literal string can be printed, and the result is generally the
string itself. But with your suggestion, the null bytes will be
lossily converted to something else.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 15:21:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: npostavs <at> users.sourceforge.net
>> Cc: 6991 <at> debbugs.gnu.org, lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, drew.adams <at> oracle.com
>> Date: Sat, 19 Nov 2016 09:39:09 -0500
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> I would propose something like the below, which will cause the NUL byte
>> >> to be rendered as \0 instead of ^@. We could potentially do this with
>> >> other control characters too, if they cause trouble too?
>> >
>> > Isn't the fact that copying text into the clipboard stops at the first
>> > null character a Windows-specific issue? And if it isn't Windows
>> > specific, isn't it at least specific to selections?
>>
>> It seems to be application specific. When I copy to a Firefox text area
>> on GNU/Linux I get a truncated result, but using xclip | od -c, I can
>> see the NUL byte and following characters are there.
>
> If this happens on both Windows and X, then both xselect.c and
> w32select.c should "encode" null bytes. Would that solve the problem?
When printing a string literal, a null byte can be encoded as "\0", but
in general, when copying an arbitrary piece of text this encoding might
not necessarily be correct.
>
>> > Exactly. But if we change print_object like you suggest, there's no
>> > way of being sure the null bytes won't be mangled by some application
>> > of a print function.
>>
>> I'm not sure what you mean.
>
> A literal string can be printed, and the result is generally the
> string itself. But with your suggestion, the null bytes will be
> lossily converted to something else.
I don't think it's lossy. Furthermore, newlines and form feeds are
already being converted to "\n" and "\f", respectively. Bytes higher
than 0x80 are also converted to octal escapes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 17:09:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Showing the byte-compiled code is not very useful.
Perhaps it would be good to make the byte-compiled function have the
name of the function it was compiled from as one of its elements.
We could make princ output <byte-compiled FUNNAME ARGLIST ADDRESS>
while not changing what prin1 outputs.
Then the debugger could use princ for byte-compiled functions,
and provide some commmand to access the actual function object to examine it.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 18:37:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: npostavs <at> users.sourceforge.net
> Cc: 6991 <at> debbugs.gnu.org, lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, drew.adams <at> oracle.com
> Date: Sat, 19 Nov 2016 10:20:51 -0500
>
> >> > Isn't the fact that copying text into the clipboard stops at the first
> >> > null character a Windows-specific issue? And if it isn't Windows
> >> > specific, isn't it at least specific to selections?
> >>
> >> It seems to be application specific. When I copy to a Firefox text area
> >> on GNU/Linux I get a truncated result, but using xclip | od -c, I can
> >> see the NUL byte and following characters are there.
> >
> > If this happens on both Windows and X, then both xselect.c and
> > w32select.c should "encode" null bytes. Would that solve the problem?
>
> When printing a string literal, a null byte can be encoded as "\0", but
> in general, when copying an arbitrary piece of text this encoding might
> not necessarily be correct.
Not sure what you have in mind. Can you show an example of when it's
not correct?
At least on MS-Windows, we only support text selections, so doing so
in w32select.c should be TRT, because clipboard text cannot include
null bytes on Windows, AFAIK. I also think it's TRT elsewhere, when
the selection value is some kind of text.
> > A literal string can be printed, and the result is generally the
> > string itself. But with your suggestion, the null bytes will be
> > lossily converted to something else.
>
> I don't think it's lossy.
It's lossy because you can never know whether it came from a null byte
or from a literal ASCII text "\0".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 19 Nov 2016 22:33:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: npostavs <at> users.sourceforge.net
>> Cc: 6991 <at> debbugs.gnu.org, lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, drew.adams <at> oracle.com
>> Date: Sat, 19 Nov 2016 10:20:51 -0500
>>
>> >> > Isn't the fact that copying text into the clipboard stops at the first
>> >> > null character a Windows-specific issue? And if it isn't Windows
>> >> > specific, isn't it at least specific to selections?
>> >>
>> >> It seems to be application specific. When I copy to a Firefox text area
>> >> on GNU/Linux I get a truncated result, but using xclip | od -c, I can
>> >> see the NUL byte and following characters are there.
>> >
>> > If this happens on both Windows and X, then both xselect.c and
>> > w32select.c should "encode" null bytes. Would that solve the problem?
>>
>> When printing a string literal, a null byte can be encoded as "\0", but
>> in general, when copying an arbitrary piece of text this encoding might
>> not necessarily be correct.
>
> Not sure what you have in mind. Can you show an example of when it's
> not correct?
I can't really think of a practical example, but it seems that the same
objection you raised below applies: how would you know whether what was
copied had the literal ASCII text "\0" or a null byte?
>
> At least on MS-Windows, we only support text selections, so doing so
> in w32select.c should be TRT, because clipboard text cannot include
> null bytes on Windows, AFAIK. I also think it's TRT elsewhere, when
> the selection value is some kind of text.
It doesn't really feel like the Right Thing to me, there's no particular
reason to choose "\0" for this, e.g., why not use "^@" (an ASCII caret
followed by at sign)? In the case of printing a string literal, it's
established that a backslash means escaping within the double quotes.
>
>> > A literal string can be printed, and the result is generally the
>> > string itself. But with your suggestion, the null bytes will be
>> > lossily converted to something else.
>>
>> I don't think it's lossy.
>
> It's lossy because you can never know whether it came from a null byte
> or from a literal ASCII text "\0".
It's already the case that ASCII text "\0" is printed as "\\0", without
my patch:
(print (string 0 ?\\ ?0) (current-buffer))
"^@\\0" ;; I replaced the null byte with "^@" to avoid trouble with
;; email clients
With my patch, ^@ is replaced with \0:
(print (string 0 ?\\ ?0) (current-buffer))
"\0\\0"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 20 Nov 2016 15:48:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: npostavs <at> users.sourceforge.net
> Cc: 6991 <at> debbugs.gnu.org, lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, drew.adams <at> oracle.com
> Date: Sat, 19 Nov 2016 17:33:11 -0500
>
> >> > If this happens on both Windows and X, then both xselect.c and
> >> > w32select.c should "encode" null bytes. Would that solve the problem?
> >>
> >> When printing a string literal, a null byte can be encoded as "\0", but
> >> in general, when copying an arbitrary piece of text this encoding might
> >> not necessarily be correct.
> >
> > Not sure what you have in mind. Can you show an example of when it's
> > not correct?
>
> I can't really think of a practical example, but it seems that the same
> objection you raised below applies: how would you know whether what was
> copied had the literal ASCII text "\0" or a null byte?
We can't. But since null bytes cannot be put into the Windows
clipboard, we have only 2 possible ways of action: either replace the
null bytes with something else, or lose everything past the first null
bytes (which is the current behavior, against which this bug report
was submitted). So if we want to solve this problem, what else can we
do except use some lossy conversion?
> > At least on MS-Windows, we only support text selections, so doing so
> > in w32select.c should be TRT, because clipboard text cannot include
> > null bytes on Windows, AFAIK. I also think it's TRT elsewhere, when
> > the selection value is some kind of text.
>
> It doesn't really feel like the Right Thing to me, there's no particular
> reason to choose "\0" for this, e.g., why not use "^@" (an ASCII caret
> followed by at sign)?
If you thought I was arguing against ^@ and for \0, then this is a
misunderstanding: I don't really care one way of the other. I was
saying that we must do _something_ to replace those null bytes, if we
want the text beyond the first one be seen in the application into
which you paste.
> > It's lossy because you can never know whether it came from a null byte
> > or from a literal ASCII text "\0".
>
> It's already the case that ASCII text "\0" is printed as "\\0", without
> my patch:
>
> (print (string 0 ?\\ ?0) (current-buffer))
>
> "^@\\0" ;; I replaced the null byte with "^@" to avoid trouble with
> ;; email clients
>
> With my patch, ^@ is replaced with \0:
>
> (print (string 0 ?\\ ?0) (current-buffer))
>
> "\0\\0"
It just doesn't feel right to me to fix a problem that is specific to
selections in a general-purpose low-level facility for printing
strings. Emacs can handle null bytes in strings very well, so I see
no need to change the print functions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Tue, 22 Nov 2016 18:08:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 6991 <at> debbugs.gnu.org (full text, mbox):
On Sun, Nov 20, 2016 at 10:46 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> It just doesn't feel right to me to fix a problem that is specific to
> selections in a general-purpose low-level facility for printing
> strings. Emacs can handle null bytes in strings very well, so I see
> no need to change the print functions.
Does the fact that this replacement would only happen when
`print-escape-nonascii' is non-nil help at all? And the fact that this
same function already escapes newline, formfeed, and every character
larger than 0x80 (all of which Emacs can handle in strings too)?
Can we have both solutions? The selection fix is lossy, so avoiding
the need for it where possible seems like a good thing to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Tue, 22 Nov 2016 18:55:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Tue, 22 Nov 2016 13:07:13 -0500
> Cc: 6991 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
> Drew Adams <drew.adams <at> oracle.com>
>
> On Sun, Nov 20, 2016 at 10:46 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > It just doesn't feel right to me to fix a problem that is specific to
> > selections in a general-purpose low-level facility for printing
> > strings. Emacs can handle null bytes in strings very well, so I see
> > no need to change the print functions.
>
> Does the fact that this replacement would only happen when
> `print-escape-nonascii' is non-nil help at all? And the fact that this
> same function already escapes newline, formfeed, and every character
> larger than 0x80 (all of which Emacs can handle in strings too)?
>
> Can we have both solutions? The selection fix is lossy, so avoiding
> the need for it where possible seems like a good thing to me.
I'm confused: which problem the above is supposed to fix? Are we
still talking about putting null bytes in selections, or are we
talking about something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Tue, 22 Nov 2016 21:08:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 6991 <at> debbugs.gnu.org (full text, mbox):
On Tue, Nov 22, 2016 at 1:52 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Tue, 22 Nov 2016 13:07:13 -0500
>> Cc: 6991 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>,
>> Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
>> Drew Adams <drew.adams <at> oracle.com>
>>
>> On Sun, Nov 20, 2016 at 10:46 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >
>> > It just doesn't feel right to me to fix a problem that is specific to
>> > selections in a general-purpose low-level facility for printing
>> > strings. Emacs can handle null bytes in strings very well, so I see
>> > no need to change the print functions.
>>
>> Does the fact that this replacement would only happen when
>> `print-escape-nonascii' is non-nil help at all? And the fact that this
>> same function already escapes newline, formfeed, and every character
>> larger than 0x80 (all of which Emacs can handle in strings too)?
>>
>> Can we have both solutions? The selection fix is lossy, so avoiding
>> the need for it where possible seems like a good thing to me.
>
> I'm confused: which problem the above is supposed to fix? Are we
> still talking about putting null bytes in selections, or are we
> talking about something else?
The original bug report is about copying backtraces containing byte
code to other applications (e.g., web browser, mail client, etc). The
byte code in backtraces is currently printed with several characters
backslash escaped (newline, formfeed, backslash, double quote, and
characters higher than 0x80). I propose to extend this escaping to
null bytes as well. That will (somewhat indirectly) solve the problem
of copying backtraces to other applications, without lossyness (i.e.,
(equal (read (print str)) str) remains true). It won't solve the
problem of copying arbitrary text containing null bytes to other
applications, it only avoids the most common case of the user needing
to copy text containing null bytes.
So in addition to that, your proposal to escape null bytes in xselect
and w32select would still be needed to cover the general case. The
drawback to replacing nulls in the {x,w32}select code is that the
conversion is lossy, and there is a slightly increased chance of the
user not noticing there was lossy conversion (relative to the current
lossy "conversion" of truncating the string).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Wed, 23 Nov 2016 16:07:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Tue, 22 Nov 2016 16:07:06 -0500
> Cc: 6991 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
> Drew Adams <drew.adams <at> oracle.com>
>
> > I'm confused: which problem the above is supposed to fix? Are we
> > still talking about putting null bytes in selections, or are we
> > talking about something else?
>
> The original bug report is about copying backtraces containing byte
> code to other applications (e.g., web browser, mail client, etc). The
> byte code in backtraces is currently printed with several characters
> backslash escaped (newline, formfeed, backslash, double quote, and
> characters higher than 0x80). I propose to extend this escaping to
> null bytes as well. That will (somewhat indirectly) solve the problem
> of copying backtraces to other applications, without lossyness (i.e.,
> (equal (read (print str)) str) remains true). It won't solve the
> problem of copying arbitrary text containing null bytes to other
> applications, it only avoids the most common case of the user needing
> to copy text containing null bytes.
I'm not necessarily opposed, but I never had any problems with binary
nulls, except when copying to clipboard.
> So in addition to that, your proposal to escape null bytes in xselect
> and w32select would still be needed to cover the general case. The
> drawback to replacing nulls in the {x,w32}select code is that the
> conversion is lossy, and there is a slightly increased chance of the
> user not noticing there was lossy conversion (relative to the current
> lossy "conversion" of truncating the string).
Yes, it's lossy, but what other alternative do we have, except losing
much more?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 26 Nov 2016 17:18:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Tue, 22 Nov 2016 16:07:06 -0500
>> Cc: 6991 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>,
>> Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
>> Drew Adams <drew.adams <at> oracle.com>
>>
>> > I'm confused: which problem the above is supposed to fix? Are we
>> > still talking about putting null bytes in selections, or are we
>> > talking about something else?
>>
>> The original bug report is about copying backtraces containing byte
>> code to other applications (e.g., web browser, mail client, etc). The
>> byte code in backtraces is currently printed with several characters
>> backslash escaped (newline, formfeed, backslash, double quote, and
>> characters higher than 0x80). I propose to extend this escaping to
>> null bytes as well. That will (somewhat indirectly) solve the problem
>> of copying backtraces to other applications, without lossyness (i.e.,
>> (equal (read (print str)) str) remains true). It won't solve the
>> problem of copying arbitrary text containing null bytes to other
>> applications, it only avoids the most common case of the user needing
>> to copy text containing null bytes.
>
> I'm not necessarily opposed, but I never had any problems with binary
> nulls, except when copying to clipboard.
I've never needed to copy binary nulls except when a backtrace had one.
>
>> So in addition to that, your proposal to escape null bytes in xselect
>> and w32select would still be needed to cover the general case. The
>> drawback to replacing nulls in the {x,w32}select code is that the
>> conversion is lossy, and there is a slightly increased chance of the
>> user not noticing there was lossy conversion (relative to the current
>> lossy "conversion" of truncating the string).
>
> Yes, it's lossy, but what other alternative do we have, except losing
> much more?
Yes, there's no perfect solution. That's why I prefer to solve just the
immediate problem by extending the escaping in `print' to cover null
bytes. And this will keep working if, for example, we make the general
case of copying null bytes to clipboard use a customizable replacement.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 26 Nov 2016 18:55:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> Yes, there's no perfect solution. That's why I prefer to solve just the
> immediate problem by extending the escaping in `print' to cover null
> bytes.
FWIW, I agree. The only issue I can see here is that depending on how
it's done, it could affect the size of the .elc files (by using two bytes
per bytecode 0 rather than 1). Nothing too terrible, but it's probably
worth checking whether it does make such a difference and if so how serious
it is.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 26 Nov 2016 23:46:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Why not take the bytecode _entirely_ out of the backtrace buffer?
Is it ever any use?
I proposed a week ago to print bytecode functions differently,
without showing the bytecode.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 27 Nov 2016 00:34:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 6991 <at> debbugs.gnu.org (full text, mbox):
On Sat, Nov 26, 2016 at 6:45 PM, Richard Stallman <rms <at> gnu.org> wrote:
>
> Why not take the bytecode _entirely_ out of the backtrace buffer?
> Is it ever any use?
It can be disassembled, and may hold useful information that would
otherwise be missing.
>
> I proposed a week ago to print bytecode functions differently,
> without showing the bytecode.
I think it might make sense to hide the bytecode with display
properties, but keep the text itself so that it's not lost when copied
to an email.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 27 Nov 2016 03:36:01 GMT)
Full text and
rfc822 format available.
Message #166 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2016-11-26 19:33, Noam Postavsky wrote:
> I think it might make sense to hide the bytecode with display
> properties, but keep the text itself so that it's not lost when copied
> to an email.
This sounds like a great idea! Maybe with an indication that bytecode was omitted? Something like "[bytecode]"?
I wonder if it would make sense to move `backtrace' to Lisp, too; it would make it easier to customize it.
Clément.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 27 Nov 2016 03:38:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sat, 26 Nov 2016 19:33:30 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>,
> Stefan Monnier <monnier <at> iro.umontreal.ca>, 6991 <at> debbugs.gnu.org,
> Lars Magne Ingebrigtsen <larsi <at> gnus.org>
>
> I think it might make sense to hide the bytecode with display
> properties, but keep the text itself so that it's not lost when copied
> to an email.
Text properties won't prevent the hidden text from being copied.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 27 Nov 2016 14:12:01 GMT)
Full text and
rfc822 format available.
Message #172 received at 6991 <at> debbugs.gnu.org (full text, mbox):
On Sat, Nov 26, 2016 at 10:36 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 26 Nov 2016 19:33:30 -0500
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>,
>> Stefan Monnier <monnier <at> iro.umontreal.ca>, 6991 <at> debbugs.gnu.org,
>> Lars Magne Ingebrigtsen <larsi <at> gnus.org>
>>
>> I think it might make sense to hide the bytecode with display
>> properties, but keep the text itself so that it's not lost when copied
>> to an email.
>
> Text properties won't prevent the hidden text from being copied.
Yes, that was my intention.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 27 Nov 2016 23:23:01 GMT)
Full text and
rfc822 format available.
Message #175 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Why not take the bytecode _entirely_ out of the backtrace buffer?
> > Is it ever any use?
> It can be disassembled, and may hold useful information that would
> otherwise be missing.
That is no reason to put the bytecode in the backtrace by default.
We can make another way to get the bytecode when you really want that.
> I think it might make sense to hide the bytecode with display
> properties, but keep the text itself so that it's not lost when copied
> to an email.
That might be a good approach.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 12 Feb 2017 02:26:01 GMT)
Full text and
rfc822 format available.
Message #178 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> FWIW, I agree. The only issue I can see here is that depending on how
> it's done, it could affect the size of the .elc files (by using two bytes
> per bytecode 0 rather than 1). Nothing too terrible, but it's probably
> worth checking whether it does make such a difference and if so how serious
> it is.
On average it increases Emacs' .elc by ~200 bytes each, 276kB in total,
or 100.62%.
[elc-sizes.org.gz (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
But actually, while looking at this, I understood more about what the
print_escape_nonascii flag is used for (i.e., multibyte vs unibyte
stuff), and I no longer think it makes sense for it to affect printing
the NUL byte anyway.
I propose adding a new flag print_escape_control_characters instead (see
patch #3 in the series). I also implemented hiding the byte code
functions with text properties in #4. It's not quite satisfactory
though, because it doesn't cover byte code functions values that are
arguments, only byte code being called. I think printing needs to be
made more flexible in order to cleanly catch all byte code values.
Patch #5 replaces NUL bytes with "\0" in X selections (I guess it covers
w32 as well? Haven't checked yet).
[backtrace-6991-screenshot.png (image/png, attachment)]
[v1-0001-Operate-on-frame-list-instead-of-printed-backtrac.patch (text/plain, attachment)]
[v1-0002-Improve-ert-backtrace-recording.patch (text/plain, attachment)]
[v1-0003-Escape-control-characters-in-backtraces-Bug-6991.patch (text/plain, attachment)]
[v1-0004-Hide-byte-code-in-backtraces-Bug-6991.patch (text/plain, attachment)]
[v1-0005-Escape-NUL-bytes-in-X-selections-Bug-6991.patch (text/plain, attachment)]
Forcibly Merged 6991 15789.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Wed, 22 Feb 2017 04:44:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 28 May 2017 14:57:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
npostavs <at> users.sourceforge.net writes:
> I propose adding a new flag print_escape_control_characters instead (see
> patch #3 in the series). I also implemented hiding the byte code
> functions with text properties in #4. It's not quite satisfactory
> though, because it doesn't cover byte code functions values that are
> arguments, only byte code being called. I think printing needs to be
> made more flexible in order to cleanly catch all byte code values.
> Patch #5 replaces NUL bytes with "\0" in X selections (I guess it covers
> w32 as well? Haven't checked yet).
Updated the patchset to use cl-prin1, now it applies to function values
in arguments as well. This one actually doesn't include the byte code
text at all (path of least resistance: cl-print-object wasn't already
omitting bytecode and I haven't bothered adding it).
[v2-0001-Operate-on-frame-list-instead-of-printed-backtrac.patch (text/x-diff, attachment)]
[v2-0002-Improve-ert-backtrace-recording.patch (text/x-diff, attachment)]
[v2-0003-Escape-control-characters-in-backtraces-Bug-6991.patch (text/x-diff, attachment)]
[v2-0004-Hide-byte-code-in-backtraces-Bug-6991.patch (text/x-diff, attachment)]
[v2-0005-Escape-NUL-bytes-in-X-selections-Bug-6991.patch (text/x-diff, attachment)]
[v2-0006-Don-t-redundantly-cl-print-arglist-in-function-do.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sat, 24 Jun 2017 22:27:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
npostavs <at> users.sourceforge.net writes:
> npostavs <at> users.sourceforge.net writes:
>
>> I propose adding a new flag print_escape_control_characters instead (see
>> patch #3 in the series). I also implemented hiding the byte code
>> functions with text properties in #4. It's not quite satisfactory
>> though, because it doesn't cover byte code functions values that are
>> arguments, only byte code being called. I think printing needs to be
>> made more flexible in order to cleanly catch all byte code values.
>> Patch #5 replaces NUL bytes with "\0" in X selections (I guess it covers
>> w32 as well? Haven't checked yet).
>
> Updated the patchset to use cl-prin1, now it applies to function values
> in arguments as well. This one actually doesn't include the byte code
> text at all (path of least resistance: cl-print-object wasn't already
> omitting bytecode and I haven't bothered adding it).
I made use of cl-prin1 depend on a custom option, and replace NUL bytes
also in w32. I think this is ready to merge now, I will probably do so
sometime next week.
[v3-0001-Operate-on-frame-list-instead-of-printed-backtrac.patch (text/x-diff, attachment)]
[v3-0002-Improve-ert-backtrace-recording.patch (text/x-diff, attachment)]
[v3-0003-Escape-control-characters-in-backtraces-Bug-6991.patch (text/x-diff, attachment)]
[v3-0004-Don-t-redundantly-cl-print-arglist-in-function-do.patch (text/x-diff, attachment)]
[v3-0005-Hide-byte-code-in-backtraces-Bug-6991.patch (text/x-diff, attachment)]
[v3-0006-Escape-NUL-bytes-in-X-selections-Bug-6991.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Sun, 25 Jun 2017 19:12:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> I made use of cl-prin1 depend on a custom option, and replace NUL bytes
> also in w32. I think this is ready to merge now, I will probably do so
> sometime next week.
A few questions below.
> + (when fun-file
> + (make-text-button fun-pt (+ fun-pt (length (symbol-name fun)))
> + :type 'help-function-def
> + 'help-args (list fun fun-file))))
Hmm... this looks like code which was moved from elsewhere, yet I can't
find this elsewhere in your patch(es).
I think that other code is in debugger-make-xrefs, so can't we remove
debugger-make-xrefs?
> + (let ((frames (nthcdr
> + ;; Remove debug--implement-debug-on-entry and the
> + ;; advice's `apply' frame.
> + (if (eq (car args) 'debug) 3 1)
> + (backtrace-frames 'debug)))
> + (print-escape-newlines t)
> + (print-level 8)
> + (print-length 50))
Why let-bind print-* here rather than inside debugger-insert-backtrace?
> + (when (eq (car args) 'exit)
> + (setf (cl-getf (nth 3 (car frames)) :debug-on-exit) nil))
This looks like code which was moved from elsewhere, yet I can't find
this elsewhere in your patch(es). What am I missing?
> + (pcase (help-split-fundoc (documentation object 'raw) object)
> + (`(,_ . ,(and doc (guard (stringp doc))))
> + (princ " " stream)
> + (prin1 doc stream)))
Maybe this deserves a one-line comment explaining that the arglist part
was already printed via help-function-arglist.
> +(defcustom debugger-print-function #'cl-prin1
> + "Function used to print values in the debugger backtraces."
> + :type 'function
> + :options '(cl-prin1 prin1)
> + :group 'debugger
> + :version "26.1")
The `:group 'debugger` is redundant (as is the case for all defcustom
in this file).
> +(defvar cl-print-compiled)
Is this used somewhere?
> - (prin1 fun)
> - (if args (prin1 args) (princ "()")))
> + (funcall debugger-print-function fun)
> + (if args (cl-prin1 args) (princ "()")))
This `cl-prin1` should be replaced with debugger-print-function, right?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 26 Jun 2017 03:34:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>
>> + (when fun-file
>> + (make-text-button fun-pt (+ fun-pt (length (symbol-name fun)))
>> + :type 'help-function-def
>> + 'help-args (list fun fun-file))))
>
> Hmm... this looks like code which was moved from elsewhere, yet I can't
> find this elsewhere in your patch(es).
> I think that other code is in debugger-make-xrefs, so can't we remove
> debugger-make-xrefs?
I'm not sure exactly what you mean by "looks like code which was moved".
It does replace the functionality of debugger-make-xrefs. But
`ert--make-xrefs-region' is still using `debugger-make-xrefs', and I
don't quite see how to remove that usage.
>> + (let ((frames (nthcdr
>> + ;; Remove debug--implement-debug-on-entry and the
>> + ;; advice's `apply' frame.
>> + (if (eq (car args) 'debug) 3 1)
>> + (backtrace-frames 'debug)))
>> + (print-escape-newlines t)
>> + (print-level 8)
>> + (print-length 50))
>
> Why let-bind print-* here rather than inside debugger-insert-backtrace?
I thought moving those inside might needlessly make the function less
flexible, though nobody is currently making use of the flexibility so
maybe it's not worth it...
>> + (when (eq (car args) 'exit)
>> + (setf (cl-getf (nth 3 (car frames)) :debug-on-exit) nil))
>
> This looks like code which was moved from elsewhere, yet I can't find
> this elsewhere in your patch(es). What am I missing?
backtrace--print-frame I guess? I haven't changed the printing for
`backtrace', perhaps I should...
>> + (pcase (help-split-fundoc (documentation object 'raw) object)
>> + (`(,_ . ,(and doc (guard (stringp doc))))
>> + (princ " " stream)
>> + (prin1 doc stream)))
>
> Maybe this deserves a one-line comment explaining that the arglist part
> was already printed via help-function-arglist.
Sure.
>> +(defcustom debugger-print-function #'cl-prin1
>> + "Function used to print values in the debugger backtraces."
>> + :type 'function
>> + :options '(cl-prin1 prin1)
>> + :group 'debugger
>> + :version "26.1")
>
> The `:group 'debugger` is redundant (as is the case for all defcustom
> in this file).
Yeah, I just followed the others, I'll remove it.
>> +(defvar cl-print-compiled)
>
> Is this used somewhere?
Oh, I think that's leftover from avoiding Bug#27117.
>> - (prin1 fun)
>> - (if args (prin1 args) (princ "()")))
>> + (funcall debugger-print-function fun)
>> + (if args (cl-prin1 args) (princ "()")))
>
> This `cl-prin1` should be replaced with debugger-print-function, right?
Oops!
[v4-0001-Operate-on-frame-list-instead-of-printed-backtrac.patch (text/plain, attachment)]
[v4-0002-Improve-ert-backtrace-recording.patch (text/plain, attachment)]
[v4-0003-Escape-control-characters-in-backtraces-Bug-6991.patch (text/plain, attachment)]
[v4-0004-Don-t-redundantly-cl-print-arglist-in-function-do.patch (text/plain, attachment)]
[v4-0005-Hide-byte-code-in-backtraces-Bug-6991.patch (text/plain, attachment)]
[v4-0006-Escape-NUL-bytes-in-X-selections-Bug-6991.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 26 Jun 2017 04:03:01 GMT)
Full text and
rfc822 format available.
Message #195 received at 6991 <at> debbugs.gnu.org (full text, mbox):
>>> + (when fun-file
>>> + (make-text-button fun-pt (+ fun-pt (length (symbol-name fun)))
>>> + :type 'help-function-def
>>> + 'help-args (list fun fun-file))))
>> Hmm... this looks like code which was moved from elsewhere, yet I can't
>> find this elsewhere in your patch(es).
>> I think that other code is in debugger-make-xrefs, so can't we remove
>> debugger-make-xrefs?
> I'm not sure exactly what you mean by "looks like code which was moved".
It's not functionality described as new in the commit log, so it's
presumably behavior which was earlier implemented elsewhere.
> It does replace the functionality of debugger-make-xrefs. But
> `ert--make-xrefs-region' is still using `debugger-make-xrefs', and I
> don't quite see how to remove that usage.
I see. Maybe we should move it to ert.el, then?
>>> + (let ((frames (nthcdr
>>> + ;; Remove debug--implement-debug-on-entry and the
>>> + ;; advice's `apply' frame.
>>> + (if (eq (car args) 'debug) 3 1)
>>> + (backtrace-frames 'debug)))
>>> + (print-escape-newlines t)
>>> + (print-level 8)
>>> + (print-length 50))
>>
>> Why let-bind print-* here rather than inside debugger-insert-backtrace?
> I thought moving those inside might needlessly make the function less
> flexible, though nobody is currently making use of the flexibility so
> maybe it's not worth it...
Hmm... I can agree with it for level and length, but I think that the
escape-newline behavior is indispensable.
>>> + (when (eq (car args) 'exit)
>>> + (setf (cl-getf (nth 3 (car frames)) :debug-on-exit) nil))
>>
>> This looks like code which was moved from elsewhere, yet I can't find
>> this elsewhere in your patch(es). What am I missing?
> backtrace--print-frame I guess? I haven't changed the printing for
> `backtrace', perhaps I should...
Hmm... I don't see anything that corresponds to this setf in
backtrace--print-frame. What do the above 2 lines do, and where is the
corresponding code in the current debug.el? Or is that a new feature in
your code? (if so, where is it documented in the commit message?)
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 26 Jun 2017 12:50:02 GMT)
Full text and
rfc822 format available.
Message #198 received at 6991 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> It does replace the functionality of debugger-make-xrefs. But
>> `ert--make-xrefs-region' is still using `debugger-make-xrefs', and I
>> don't quite see how to remove that usage.
>
> I see. Maybe we should move it to ert.el, then?
Sure.
>>>> + (print-escape-newlines t)
>>>> + (print-level 8)
>>>> + (print-length 50))
>>>
>>> Why let-bind print-* here rather than inside debugger-insert-backtrace?
>
>> I thought moving those inside might needlessly make the function less
>> flexible, though nobody is currently making use of the flexibility so
>> maybe it's not worth it...
>
> Hmm... I can agree with it for level and length, but I think that the
> escape-newline behavior is indispensable.
Okay, that makes sense.
>>>> + (when (eq (car args) 'exit)
>>>> + (setf (cl-getf (nth 3 (car frames)) :debug-on-exit) nil))
>>>
>>> This looks like code which was moved from elsewhere, yet I can't find
>>> this elsewhere in your patch(es). What am I missing?
>
>> backtrace--print-frame I guess? I haven't changed the printing for
>> `backtrace', perhaps I should...
>
> Hmm... I don't see anything that corresponds to this setf in
> backtrace--print-frame. What do the above 2 lines do, and where is the
> corresponding code in the current debug.el? Or is that a new feature in
> your code? (if so, where is it documented in the commit message?)
Ah, sorry, my memory of the old code got a little fuzzy, it doesn't
correspond to backtrace--print-frame (that function only contains the
code which reads the :debug-on-exit flag). It's actually replacing the
code removed in this hunk:
@@ -301,10 +319,7 @@ (defun debugger-setup-buffer (args)
(setq pos (point))
(setq debugger-value (nth 1 args))
(prin1 debugger-value (current-buffer))
- (insert ?\n)
- (delete-char 1)
- (insert ? )
- (beginning-of-line))
+ (insert ?\n))
;; Watchpoint triggered.
((and `watchpoint (let `(,symbol ,newval . ,details) (cdr args)))
(insert
So it's another instance of operating on the backtrace frame object
directly, instead of manipulating the text after printing (i.e.,
unsetting the :debug-on-exit flag instead of erasing its representation
"*" in the buffer).
Also, as I'm looking at this, I wonder if I should replace the (prin1
debugger-value ...) calls with (funcall debugger-print-function ...)
too. Hmm, and I probably shouldn't have moved those print-*
let-bindings at all because they could be relevant to the code printing
"frame 0".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 26 Jun 2017 14:55:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> Ah, sorry, my memory of the old code got a little fuzzy, it doesn't
> correspond to backtrace--print-frame (that function only contains the
> code which reads the :debug-on-exit flag). It's actually replacing the
> code removed in this hunk:
> @@ -301,10 +319,7 @@ (defun debugger-setup-buffer (args)
> (setq pos (point))
> (setq debugger-value (nth 1 args))
> (prin1 debugger-value (current-buffer))
> - (insert ?\n)
> - (delete-char 1)
> - (insert ? )
> - (beginning-of-line))
> + (insert ?\n))
> ;; Watchpoint triggered.
> ((and `watchpoint (let `(,symbol ,newval . ,details) (cdr args)))
> (insert
> So it's another instance of operating on the backtrace frame object
> directly, instead of manipulating the text after printing (i.e.,
> unsetting the :debug-on-exit flag instead of erasing its representation
> "*" in the buffer).
Ah, yes, I see it now, thanks. It's a good change, then: the new code
is more clear. I wonder why we do that, tho:
the previous code didn't have a comment, so I'm left guessing that maybe
it's that we don't want to advertise as "will stop when exiting foo"
a function which we're exiting?
> Also, as I'm looking at this, I wonder if I should replace the (prin1
> debugger-value ...) calls with (funcall debugger-print-function ...)
Sounds right.
> too. Hmm, and I probably shouldn't have moved those print-*
> let-bindings at all because they could be relevant to the code printing
> "frame 0".
Good point.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Tue, 27 Jun 2017 03:56:01 GMT)
Full text and
rfc822 format available.
Message #204 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
> I wonder why we do that, tho:
> the previous code didn't have a comment, so I'm left guessing that maybe
> it's that we don't want to advertise as "will stop when exiting foo"
> a function which we're exiting?
I tried git-blame, but that code seems to have been like that since
"initial revision" (1991). I think your guess sounds reasonable.
Anyway, here are the updated patches.
[0001-Operate-on-frame-list-instead-of-printed-backtrace.patch (text/plain, attachment)]
[0002-Improve-ert-backtrace-recording.patch (text/plain, attachment)]
[0003-Escape-control-characters-in-backtraces-Bug-6991.patch (text/plain, attachment)]
[0004-Don-t-redundantly-cl-print-arglist-in-function-docst.patch (text/plain, attachment)]
[0005-Hide-byte-code-in-backtraces-Bug-6991.patch (text/plain, attachment)]
[0006-Escape-NUL-bytes-in-X-selections-Bug-6991.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Tue, 27 Jun 2017 16:19:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> Anyway, here are the updated patches.
Looks good to me, thanks,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Thu, 29 Jun 2017 23:51:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 6991 <at> debbugs.gnu.org (full text, mbox):
tags 6991 fixed
close 6991 26.1
quit
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>> Anyway, here are the updated patches.
>
> Looks good to me, thanks,
Thanks for the review, it was very helpful!
Pushed to master (with minor fix to make sure debugger-print-function is
used only after the commit which defines it, plus some commit message
typos).
[1: 522e3c1585]: 2017-06-29 19:29:10 -0400
Operate on frame list instead of printed backtrace
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=522e3c15853279bf2a0ed1759c5b0ba3c9e0b7be
[2: ead545824e]: 2017-06-29 19:37:25 -0400
Improve ert backtrace recording
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ead545824e511ab18d18b5223eab80e1f4fe3d64
[3: eb9d3eca80]: 2017-06-29 19:40:22 -0400
Escape control characters in backtraces (Bug#6991)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=eb9d3eca801c1ea847956a96fafd29eef9bbe5d1
[4: b567c48869]: 2017-06-29 19:40:23 -0400
Don't redundantly cl-print arglist in function docstring again
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b567c48869b1484c6b1d263afc5cb67f22e99125
[5: 0ae28c71c7]: 2017-06-29 19:40:23 -0400
Hide byte code in backtraces (Bug#6991)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0ae28c71c739dfecbe94a5ff6786e81021d2d1cf
[6: c87c87fcc3]: 2017-06-29 19:40:23 -0400
Escape NUL bytes in X selections (Bug#6991)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c87c87fcc361494815bbd1d92f450b0b80a3ecbb
[7: 169532b0eb]: 2017-06-29 19:42:32 -0400
; Merge: Backtrace printing improvements (Bug#6991)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=169532b0ebc3acb0b1c943d0b3d8b569cd57ca4b
Added tag(s) fixed.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Thu, 29 Jun 2017 23:51:03 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 26.1, send any further explanations to
6991 <at> debbugs.gnu.org and jidanni <at> jidanni.org
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Thu, 29 Jun 2017 23:51:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 28 Jul 2017 11:24:06 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Rocky Bernstein <rocky.bernstein <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 11 Sep 2017 02:03:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 11 Sep 2017 10:59:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
have started looking at decompiling ELISP bytecode using the techniques
from uncompyle6 <https://pypi.python.org/pypi/uncompyle6> .
So far the results are promising. Of course one isn't going to get the
exact source text back.
For the bytecode for source text
(setq a nil)
(setq b nil)
when decompiled gives the equivalent:
(setq a (setq b nil))
And macros will be in their expanded form. But I believe nevertheless
programmers will have a very good idea of what was going on when an error
was raised.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Mon, 11 Sep 2017 14:29:01 GMT)
Full text and
rfc822 format available.
Message #224 received at 6991 <at> debbugs.gnu.org (full text, mbox):
> From: Rocky Bernstein <rocky <at> gnu.org>
> Date: Mon, 11 Sep 2017 06:57:58 -0400
>
> have started looking at decompiling ELISP bytecode using the techniques from uncompyle6 .
>
> So far the results are promising. Of course one isn't going to get the exact source text back.
>
> For the bytecode for source text
>
> (setq a nil)
> (setq b nil)
>
> when decompiled gives the equivalent:
>
> (setq a (setq b nil))
>
> And macros will be in their expanded form. But I believe nevertheless programmers will have a very good idea
> of what was going on when an error was raised.
Sounds interesting and potentially useful. Please keep up the good
work.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#6991; Package
emacs.
(Wed, 13 Sep 2017 01:14:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 6991 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for the kind words. Right now I see no obstacles to getting this
done. Just lots of work, and not enough hands. I'm going to try to get the
local Emacs group interested in helping out. And if not in this, then
contributing to documenting bytecode in of itself is something that would
be of value.
What I have right now is at https://github.com/rocky/elisp-decompile .
Alas, for expediency it is right now written in Python.
On Mon, Sep 11, 2017 at 10:28 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Rocky Bernstein <rocky <at> gnu.org>
> > Date: Mon, 11 Sep 2017 06:57:58 -0400
> >
> > have started looking at decompiling ELISP bytecode using the techniques
> from uncompyle6 .
> >
> > So far the results are promising. Of course one isn't going to get the
> exact source text back.
> >
> > For the bytecode for source text
> >
> > (setq a nil)
> > (setq b nil)
> >
> > when decompiled gives the equivalent:
> >
> > (setq a (setq b nil))
> >
> > And macros will be in their expanded form. But I believe nevertheless
> programmers will have a very good idea
> > of what was going on when an error was raised.
>
> Sounds interesting and potentially useful. Please keep up the good
> work.
>
> Thanks.
>
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 11 Oct 2017 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 254 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.