unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
@ 2021-12-16 15:18 Robert Pluim
  2021-12-16 15:30 ` Eli Zaretskii
  2021-12-19 12:01 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 13+ messages in thread
From: Robert Pluim @ 2021-12-16 15:18 UTC (permalink / raw)
  To: 52554

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

mm-inline-media-tests contains lambda's, and itʼs byte-compiled, so
when you customize its value, byte-code is saved in your .emacs. One
of its components looks like this:

     ("text/x-vcard" mm-inline-text-vcard
      #[257 "\300\301!\206	%0\302\303!\207"
            [featurep vcard locate-library "vcard"]
            3 "

     (fn HANDLE)"])

That has an embedded 'NUL' just before the \302 (Iʼve encoded it),
which causes 'buffer-file-coding-system' to be incorrect
('no-conversion in this case) so any non-ascii character causes a read
error:

$ HOME=/tmp emacs --debug-init

Debugger entered--Lisp error: (invalid-read-syntax "?" 1 0)
  read(#<buffer  *load*>)
  eval-buffer(#<buffer  *load*> nil "/tmp/.emacs" nil t)  ; Reading at buffer position 573
  load-with-code-conversion("/tmp/.emacs" "/tmp/.emacs" t t)
  load("~/.emacs" noerror nomessage)

Sample .emacs attached. There are probably other defcustom's with the
same issue, I haven't checked.


[-- Attachment #2: .emacs --]
[-- Type: application/octet-stream, Size: 577 bytes --]

[-- Attachment #3: Type: text/plain, Size: 279 bytes --]


In GNU Emacs 28.0.90 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-12-13 built on rltb
Repository revision: 9bd3f78645e14fdbaf3a569df5e0a52249c4f90e
Repository branch: emacs-28
System Description: Debian GNU/Linux 11 (bullseye)

Robert
-- 

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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 15:18 bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading Robert Pluim
@ 2021-12-16 15:30 ` Eli Zaretskii
  2021-12-16 15:46   ` Robert Pluim
  2021-12-16 16:13   ` Andreas Schwab
  2021-12-19 12:01 ` Lars Ingebrigtsen
  1 sibling, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2021-12-16 15:30 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 52554

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 16 Dec 2021 16:18:13 +0100
> 
> That has an embedded 'NUL' just before the \302 (Iʼve encoded it),
> which causes 'buffer-file-coding-system' to be incorrect
> ('no-conversion in this case) so any non-ascii character causes a read
> error:
> 
> $ HOME=/tmp emacs --debug-init
> 
> Debugger entered--Lisp error: (invalid-read-syntax "?" 1 0)
>   read(#<buffer  *load*>)
>   eval-buffer(#<buffer  *load*> nil "/tmp/.emacs" nil t)  ; Reading at buffer position 573
>   load-with-code-conversion("/tmp/.emacs" "/tmp/.emacs" t t)
>   load("~/.emacs" noerror nomessage)

Perhaps we should bind inhibit-null-byte-detection to a non-nil value
while loading the init file?





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 15:30 ` Eli Zaretskii
@ 2021-12-16 15:46   ` Robert Pluim
  2021-12-16 16:57     ` Eli Zaretskii
  2021-12-16 16:13   ` Andreas Schwab
  1 sibling, 1 reply; 13+ messages in thread
From: Robert Pluim @ 2021-12-16 15:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 52554

>>>>> On Thu, 16 Dec 2021 17:30:27 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Thu, 16 Dec 2021 16:18:13 +0100
    >> 
    >> That has an embedded 'NUL' just before the \302 (Iʼve encoded it),
    >> which causes 'buffer-file-coding-system' to be incorrect
    >> ('no-conversion in this case) so any non-ascii character causes a read
    >> error:
    >> 
    >> $ HOME=/tmp emacs --debug-init
    >> 
    >> Debugger entered--Lisp error: (invalid-read-syntax "?" 1 0)
    >> read(#<buffer  *load*>)
    >> eval-buffer(#<buffer  *load*> nil "/tmp/.emacs" nil t)  ; Reading at buffer position 573
    >> load-with-code-conversion("/tmp/.emacs" "/tmp/.emacs" t t)
    >> load("~/.emacs" noerror nomessage)

    Eli> Perhaps we should bind inhibit-null-byte-detection to a non-nil value
    Eli> while loading the init file?

The init file and 'custom-file'? (anyone who manually puts byte-code
in their .emacs either knows what theyʼre doing or will soon learn :-) )

Robert
-- 





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 15:30 ` Eli Zaretskii
  2021-12-16 15:46   ` Robert Pluim
@ 2021-12-16 16:13   ` Andreas Schwab
  2021-12-16 16:58     ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: Andreas Schwab @ 2021-12-16 16:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Robert Pluim, 52554

On Dez 16 2021, Eli Zaretskii wrote:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Thu, 16 Dec 2021 16:18:13 +0100
>> 
>> That has an embedded 'NUL' just before the \302 (Iʼve encoded it),
>> which causes 'buffer-file-coding-system' to be incorrect
>> ('no-conversion in this case) so any non-ascii character causes a read
>> error:
>> 
>> $ HOME=/tmp emacs --debug-init
>> 
>> Debugger entered--Lisp error: (invalid-read-syntax "?" 1 0)
>>   read(#<buffer  *load*>)
>>   eval-buffer(#<buffer  *load*> nil "/tmp/.emacs" nil t)  ; Reading at buffer position 573
>>   load-with-code-conversion("/tmp/.emacs" "/tmp/.emacs" t t)
>>   load("~/.emacs" noerror nomessage)
>
> Perhaps we should bind inhibit-null-byte-detection to a non-nil value
> while loading the init file?

I'd rather think that custom-save-variable should bind
print-escape-control-characters to t.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 15:46   ` Robert Pluim
@ 2021-12-16 16:57     ` Eli Zaretskii
  0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2021-12-16 16:57 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 52554

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 52554@debbugs.gnu.org
> Date: Thu, 16 Dec 2021 16:46:36 +0100
> 
>     Eli> Perhaps we should bind inhibit-null-byte-detection to a non-nil value
>     Eli> while loading the init file?
> 
> The init file and 'custom-file'?

Yep.





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 16:13   ` Andreas Schwab
@ 2021-12-16 16:58     ` Eli Zaretskii
  2021-12-17  8:23       ` Robert Pluim
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2021-12-16 16:58 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: rpluim, 52554

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  52554@debbugs.gnu.org
> Date: Thu, 16 Dec 2021 17:13:53 +0100
> 
> On Dez 16 2021, Eli Zaretskii wrote:
> 
> >> $ HOME=/tmp emacs --debug-init
> >> 
> >> Debugger entered--Lisp error: (invalid-read-syntax "?" 1 0)
> >>   read(#<buffer  *load*>)
> >>   eval-buffer(#<buffer  *load*> nil "/tmp/.emacs" nil t)  ; Reading at buffer position 573
> >>   load-with-code-conversion("/tmp/.emacs" "/tmp/.emacs" t t)
> >>   load("~/.emacs" noerror nomessage)
> >
> > Perhaps we should bind inhibit-null-byte-detection to a non-nil value
> > while loading the init file?
> 
> I'd rather think that custom-save-variable should bind
> print-escape-control-characters to t.

Maybe we should do both?





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 16:58     ` Eli Zaretskii
@ 2021-12-17  8:23       ` Robert Pluim
  2021-12-17  8:29         ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Robert Pluim @ 2021-12-17  8:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 52554, Andreas Schwab

>>>>> On Thu, 16 Dec 2021 18:58:19 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Andreas Schwab <schwab@linux-m68k.org>
    >> Cc: Robert Pluim <rpluim@gmail.com>,  52554@debbugs.gnu.org
    >> Date: Thu, 16 Dec 2021 17:13:53 +0100
    >> 
    >> On Dez 16 2021, Eli Zaretskii wrote:
    >> 
    >> >> $ HOME=/tmp emacs --debug-init
    >> >> 
    >> >> Debugger entered--Lisp error: (invalid-read-syntax "?" 1 0)
    >> >>   read(#<buffer  *load*>)
    >> >>   eval-buffer(#<buffer  *load*> nil "/tmp/.emacs" nil t)  ; Reading at buffer position 573
    >> >>   load-with-code-conversion("/tmp/.emacs" "/tmp/.emacs" t t)
    >> >>   load("~/.emacs" noerror nomessage)
    >> >
    >> > Perhaps we should bind inhibit-null-byte-detection to a non-nil value
    >> > while loading the init file?
    >> 
    >> I'd rather think that custom-save-variable should bind
    >> print-escape-control-characters to t.

    Eli> Maybe we should do both?

In `custom-save-all' perhaps? There are many code paths for saving
customizations, they donʼt all go via `custom-save-variable'.

Robert
-- 





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-17  8:23       ` Robert Pluim
@ 2021-12-17  8:29         ` Eli Zaretskii
  2021-12-17  8:45           ` Robert Pluim
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2021-12-17  8:29 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 52554, schwab

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  52554@debbugs.gnu.org
> Date: Fri, 17 Dec 2021 09:23:48 +0100
> 
>     >> I'd rather think that custom-save-variable should bind
>     >> print-escape-control-characters to t.
> 
>     Eli> Maybe we should do both?
> 
> In `custom-save-all' perhaps? There are many code paths for saving
> customizations, they donʼt all go via `custom-save-variable'.

If they all go through custom-save-all, then I think it should be done
there, yes.





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-17  8:29         ` Eli Zaretskii
@ 2021-12-17  8:45           ` Robert Pluim
  2021-12-17 12:11             ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Robert Pluim @ 2021-12-17  8:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 52554, schwab

>>>>> On Fri, 17 Dec 2021 10:29:09 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Andreas Schwab <schwab@linux-m68k.org>,  52554@debbugs.gnu.org
    >> Date: Fri, 17 Dec 2021 09:23:48 +0100
    >> 
    >> >> I'd rather think that custom-save-variable should bind
    >> >> print-escape-control-characters to t.
    >> 
    Eli> Maybe we should do both?
    >> 
    >> In `custom-save-all' perhaps? There are many code paths for saving
    >> customizations, they donʼt all go via `custom-save-variable'.

    Eli> If they all go through custom-save-all, then I think it should be done
    Eli> there, yes.

OK, Iʼll run with the following for a while, and see if anything crops
up.

diff --git c/lisp/cus-edit.el i/lisp/cus-edit.el
index 5c4448ae71..1936733098 100644
--- c/lisp/cus-edit.el
+++ i/lisp/cus-edit.el
@@ -4723,7 +4723,10 @@ custom-save-all
         (delay-mode-hooks (emacs-lisp-mode)))
       (let ((inhibit-read-only t)
 	    (print-length nil)
-	    (print-level nil))
+	    (print-level nil)
+            ;; We might be saving byte-code with embedded NULs, which can
+            ;; cause problems when read back (Bug#52554).
+            (print-escape-control-characters t))
         (atomic-change-group
 	  (custom-save-variables)
 	  (custom-save-faces)))
diff --git c/lisp/startup.el i/lisp/startup.el
index 505d7b83f4..f8db46ff3f 100644
--- c/lisp/startup.el
+++ i/lisp/startup.el
@@ -964,7 +964,11 @@ startup--load-user-init-file
         (debug-on-error-initial
          (if (eq init-file-debug t)
              'startup
-           init-file-debug)))
+           init-file-debug))
+        ;; The init file might contain byte-code with embedded NULs,
+        ;; which can cause problems when read back, so disable null
+        ;; byte detection (Bug#52554).
+        (inhibit-null-byte-detection t))
     (let ((debug-on-error debug-on-error-initial))
       (condition-case-unless-debug error
           (when init-file-user

Robert
-- 





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-17  8:45           ` Robert Pluim
@ 2021-12-17 12:11             ` Eli Zaretskii
  2022-03-16 18:02               ` Robert Pluim
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2021-12-17 12:11 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 52554, schwab

> From: Robert Pluim <rpluim@gmail.com>
> Cc: schwab@linux-m68k.org,  52554@debbugs.gnu.org
> Date: Fri, 17 Dec 2021 09:45:17 +0100
> 
>     >> >> I'd rather think that custom-save-variable should bind
>     >> >> print-escape-control-characters to t.
>     >> 
>     Eli> Maybe we should do both?
>     >> 
>     >> In `custom-save-all' perhaps? There are many code paths for saving
>     >> customizations, they donʼt all go via `custom-save-variable'.
> 
>     Eli> If they all go through custom-save-all, then I think it should be done
>     Eli> there, yes.
> 
> OK, Iʼll run with the following for a while, and see if anything crops
> up.

Thanks.





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-16 15:18 bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading Robert Pluim
  2021-12-16 15:30 ` Eli Zaretskii
@ 2021-12-19 12:01 ` Lars Ingebrigtsen
       [not found]   ` <87h7b3ve9a.fsf@gmail.com>
  1 sibling, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-19 12:01 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 52554

Robert Pluim <rpluim@gmail.com> writes:

> mm-inline-media-tests contains lambda's, and itʼs byte-compiled, so
> when you customize its value, byte-code is saved in your .emacs. One
> of its components looks like this:
>
>      ("text/x-vcard" mm-inline-text-vcard
>       #[257 "\300\301!\206	%0\302\303!\207"
>             [featurep vcard locate-library "vcard"]
>             3 "
>
>      (fn HANDLE)"])

I see that you've fixed the actual bug in a later patch, but I just
wanted to ask -- should that variable be a user option at all?  Long
list variables are seldom useful as user options.  Instead users should
prepend choices with `push' or something.

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





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
       [not found]   ` <87h7b3ve9a.fsf@gmail.com>
@ 2021-12-20  9:22     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 13+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-20  9:22 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 52554

Robert Pluim <rpluim@gmail.com> writes:

> It is kind of awkward to use, but then again, I only wanted to delete
> an entry, and itʼs not something Iʼd do often. The embedded code
> bothers me more: customize is supposed to be about configuration
> variables.

Yup.  I'm not sure how to express stuff like

    ("image/png"
     mm-inline-image
     ,(lambda (handle)
       (mm-valid-and-fit-image-p 'png handle)))

and

    ("text/x-vcard"
     mm-inline-text-vcard
     ,(lambda (_handle)
       (or (featurep 'vcard)
	   (locate-library "vcard"))))

in a defcustom-friendly way without having an explosion of helper
functions, though.

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





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

* bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading
  2021-12-17 12:11             ` Eli Zaretskii
@ 2022-03-16 18:02               ` Robert Pluim
  0 siblings, 0 replies; 13+ messages in thread
From: Robert Pluim @ 2022-03-16 18:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 52554, schwab

tags 52554 fixed
close 52554 29.1
quit

>>>>> On Fri, 17 Dec 2021 14:11:06 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> 
    >> OK, Iʼll run with the following for a while, and see if anything crops
    >> up.

    Eli> Thanks.

I haven't seen any negative effect so far, so:

Closing.
Committed as a86205b060





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

end of thread, other threads:[~2022-03-16 18:02 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-16 15:18 bug#52554: 28.0.90; mm-inline-media-tests customization breaks .emacs reading Robert Pluim
2021-12-16 15:30 ` Eli Zaretskii
2021-12-16 15:46   ` Robert Pluim
2021-12-16 16:57     ` Eli Zaretskii
2021-12-16 16:13   ` Andreas Schwab
2021-12-16 16:58     ` Eli Zaretskii
2021-12-17  8:23       ` Robert Pluim
2021-12-17  8:29         ` Eli Zaretskii
2021-12-17  8:45           ` Robert Pluim
2021-12-17 12:11             ` Eli Zaretskii
2022-03-16 18:02               ` Robert Pluim
2021-12-19 12:01 ` Lars Ingebrigtsen
     [not found]   ` <87h7b3ve9a.fsf@gmail.com>
2021-12-20  9:22     ` Lars Ingebrigtsen

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).