bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

Evaluate this:
 
`("Foo" . (lambda ()
            "Four score and seven years ago
Our forefathers brought forth etc.
Etc., etc., etc."
            (message "HOWDY")))
 
That doc string is a literal string with two embedded newline chars.
Evaluation converts each of those chars to a string of two chars: "\n":
 
("Foo" lambda nil "Four score and seven years ago\nOur forefathers brought forth
etc.\nEtc., etc., etc."
 (message "Howdy"))
 
Shouldn't happen.  (This is particularly messy when used in defcustom
values.)
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-11-30 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
 

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Stefan Monnier]

> Evaluate this:
> `("Foo" . (lambda ()
>             "Four score and seven years ago
> Our forefathers brought forth etc.
> Etc., etc., etc."
>             (message "HOWDY")))
 
> That doc string is a literal string with two embedded newline chars.
> Evaluation converts each of those chars to a string of two chars: "\n":
 
> ("Foo" lambda nil "Four score and seven years ago\nOur forefathers brought forth
> etc.\nEtc., etc., etc."
>  (message "Howdy"))
 
It's got nothing to do with backquote.  It's just that

    "foo
    bar"

is just another way to write "foo\nbar": the Elisp reader will return
the exact same string in both cases.  So the Elisp printer can't know
which one was used originally and has to choose arbitrarily which form
to output.

> Shouldn't happen.

Unavoidable.  Tho you do get to choose somewhat the print format by
choosing between prin1 and princ (aka %s and %S in format).

> (This is particularly messy when used in defcustom values.)

I don't know what you're referring to.  I'll keep the bug open for now,
assuming that the defcustom issue will be the actual bug.


        Stefan

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> > (This is particularly messy when used in defcustom values.)
> 
> I don't know what you're referring to.  I'll keep the bug 
> open for now, assuming that the defcustom issue will be
> the actual bug.

You're right of course about the chars "\n" and a ^J char in a Lisp string.

`defcustom' does different things in this regard, depending on the :type (and
whether there is a mismatch, but that's something else no doubt).

See what the \n representation does, for example, with the file I sent to
emacs-devel yesterday, thread "Variable behavior for `mouse-3' second click at
same spot".  Here's a direct URL to the file.

http://www.emacswiki.org/emacs/mouse3.el

Eval the defcustom for `mouse3-region-popup-submenus', then use `M-x customize',
and you'll see how messy (how wide) the display is.

Independently of this, perhaps Customize should wrap long lines in some way.
Dunno.  Doesn't seem like it should be displaying lines as 168 chars wide rather
than wrapping them.

This doc-string with two newline chars gets shown as a single line without any
wrapping: 168 chars wide:

"Replace the selected rectangle by the contents of a register you name.
Note that the rectangle currently selected is first killed.  You can
restore it by yanking."

Much of the reason for adding the doc string to the lambda was to give Customize
users more info about these anonymous commands.  The way things are, I guess the
best thing for a programmer to do is create named commands and forgo anonymous
ones within option values.  Nothing wrong with that, but I think we should be
able to do better wrt Customize display.

Especially since most of the time newlines in strings _are_ shown in Customize
using newline chars rather than the two chars "\n".

Maybe the :type could be refined in this particular defcustom in some way that
would cause the Customize display to be as usual (newline chars, no "\n").
Dunno (suggestions welcome).  But at least this defcustom is not a case of
`mismatch' (mismatch seems always to display a newline char in a string as
"\n").

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Stefan Monnier]

retitle 7524 Customize should wrap long lines and pretty print sexp values
severity 7524 wishlist
thanks

> See what the \n representation does, for example, with the file I sent
> to emacs-devel yesterday, thread "Variable behavior for `mouse-3'
> second click at same spot".  Here's a direct URL to the file.

> http://www.emacswiki.org/emacs/mouse3.el

> Eval the defcustom for `mouse3-region-popup-submenus', then use `M-x
> customize', and you'll see how messy (how wide) the display is.

Since the type you use is (sexp :tag "Command"), you give relatively
little information to Custom about what it can look like (not that the
type is wrong, actually).

And yes, Custom should probably try to wrap lines somehow in such cases
(e.g. pretty-print the sexp).  During the wrapping, it could convert
the \n in strings into actual LF chars.


        Stefan

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> Since the type you use is (sexp :tag "Command"), you give relatively
> little information to Custom about what it can look like (not that the
> type is wrong, actually).

Actually, I also tried this, but it seemed to make no difference:

(repeat (choice
         (cons :tag "Item"
          (string :tag "Name")
          (restricted-sexp
           :tag "Command"
           :match-alternatives (commandp)))
         (list :tag "Separator" (const "--"))))

And for the default value that causes a `mismatch' in older Emacs versions (20
through 23) for some reason - so I reverted to just `sexp'.

(Can you see anything wrong with that type spec?  Dunno why older versions give
the value a `mismatch'.)
 
> And yes, Custom should probably try to wrap lines somehow in 
> such cases (e.g. pretty-print the sexp).  During the wrapping,
> it could convert the \n in strings into actual LF chars.

Thanks.  I don't know the difference between the buglist wishlist status and the
Emacs TODO list.  I imagine that the difference is that almost anything that any
user requests gets put on the wishlist but only things that Emacs Dev thinks are
important get put on the TODO list.  But either is OK, I guess.

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Stefan Monnier]

> Here's a direct URL to the file.
> http://www.emacswiki.org/emacs/mouse3.el

Nitpick: actually, it's not "a direct URL to the file".  It's a URL to
an html page; very annoying if you ask me since Emacs doesn't display
HTML nearly as well as Elisp.


        Stefan

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> > Here's a direct URL to the file.
> > http://www.emacswiki.org/emacs/mouse3.el
> 
> Nitpick: actually, it's not "a direct URL to the file".  It's a URL to
> an html page;


Call it what you will.  It's a URL to the file (direct or not, depending on your
view of "the file"): click the URL and you will see the file in your Web
browser.

Here is a more direct URL to the file:
http://www.emacswiki.org/emacs/download/mouse3.el 

Even that you could argue only takes you to a download action for the file.  

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> very annoying if you ask me since Emacs doesn't display
> HTML nearly as well as Elisp.

Poor Emacs.  While waiting for Emacs to become a less annoying Web browser, you
might want to try a different one?

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Lennart Borgman]

On Mon, Dec 6, 2010 at 7:10 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> very annoying if you ask me since Emacs doesn't display
>> HTML nearly as well as Elisp.
>
> Poor Emacs.  While waiting for Emacs to become a less annoying Web browser, you
> might want to try a different one?

Maybe this can help:

   http://www.20thingsilearned.com//open-source

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Stefan Monnier]

> Here is a more direct URL to the file:
> http://www.emacswiki.org/emacs/download/mouse3.el
> Even that you could argue only takes you to a download action for the file.

No, it's a URL which Emacs accepts fine and it then shows me the
contents in the right mode and everything.


        Stefan

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> Maybe this can help:
>    http://www.20thingsilearned.com//open-source

This is the first thing I see there (in IE 7):

 "This illustrated book was designed for HTML5-compliant browsers
  and will not work with your current browser.
  For the best viewing experience, please download a modern browser,
  or install the Google Chrome Frame plug-in and try launching this site again."

A browser that doesn't handle everything in HTML5 is not "modern"?  Hmph!

FWIW, in spite of that pretentious warning, the site was just as readable in IE
7 as in Google Chrome.

Anyway, I read what was written there, but found it pretty content-less.  What's
the point?

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Lennart Borgman]

On Mon, Dec 6, 2010 at 10:38 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> Maybe this can help:
>>    http://www.20thingsilearned.com//open-source
>
> This is the first thing I see there (in IE 7):
>
>  "This illustrated book was designed for HTML5-compliant browsers
>  and will not work with your current browser.
>  For the best viewing experience, please download a modern browser,
>  or install the Google Chrome Frame plug-in and try launching this site again."
>
> A browser that doesn't handle everything in HTML5 is not "modern"?  Hmph!

Maybe they say that a bit too early...

> Anyway, I read what was written there, but found it pretty content-less.  What's
> the point?

Oh, it is a pretty little thing. And it actually tells how others do
to display html. (And maybe Emacs can do that soon too.)

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> > Here is a more direct URL to the file:
> > http://www.emacswiki.org/emacs/download/mouse3.el
> > Even that you could argue only takes you to a download 
> > action for the file.
> 
> No, it's a URL which Emacs accepts fine and it then shows me the
> contents in the right mode and everything.

Emacs Wiki deliberately has an HTML page as the entry point for each Lisp file.
That HTML page shows the Lisp code (with coloring no less), and it has a
Download link for those who might want to download it.  All of that is for user
convenience (e.g. preview before perhaps download).

I happen to agree with that design, but you need not agree and are welcome to
find it annoying.  I'd argue that the annoyance really comes from your (Emacs)
browser, but you need not agree with that either.

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Stefan Monnier]

>> > Here is a more direct URL to the file:
>> > http://www.emacswiki.org/emacs/download/mouse3.el
>> > Even that you could argue only takes you to a download 
>> > action for the file.
>> 
>> No, it's a URL which Emacs accepts fine and it then shows me the
>> contents in the right mode and everything.

> Emacs Wiki deliberately has an HTML page as the entry point for each
> Lisp file.  That HTML page shows the Lisp code (with coloring no
> less), and it has a Download link for those who might want to download
> it.  All of that is for user convenience (e.g. preview before perhaps
> download).

> I happen to agree with that design, but you need not agree and are
> welcome to find it annoying.

I fully agree with this web-site design as well.  But when you post here
a link to source Elisp code, you should expect people to want to look at
it inside Emacs rather than inside a browser.  So you should send a URL
to the actual Elisp file, to to its HTML rendering.

And remember, it was just a nitpick.  You've blown it way out
of proportion.


        Stefan

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Drew Adams]

> And yes, Custom should probably try to wrap lines somehow in 
> such cases (e.g. pretty-print the sexp).

Any chance this pretty-printing will actually get done?
The utility goes well beyond `\n' in strings.

Just now I created a defcustom whose :type is
(repeat (restricted-sexp
         :tag "Keymap"
         :match-alternatives (keymapp 'nil)))

And you cannot believe how ugly such a value is, not to mention how error-prone
editing it would be!  Regardless of what one might think of trying to use a
keymap value this way, the point is that any non-trivial Lisp sexp needs to be
pretty-printed.

`restricted-sexp can be a quick-and-dirty substitute for defining the widgets
needed to get a new :type construct.  But it is rendered pretty unusable without
(at least) pretty-printing.

There are likely to be plenty of Lisp values for which pretty-printing would
help.  Any chance you will add this to the Emacs TO-DO list?

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Mauro Aranda]

[-- Attachment #1.1: Type: text/plain, Size: 1255 bytes --]

tags 7524 patch
quit

"Drew Adams" <drew.adams@oracle.com> writes:

>> > (This is particularly messy when used in defcustom values.)
>>
>> I don't know what you're referring to.  I'll keep the bug
>> open for now, assuming that the defcustom issue will be
>> the actual bug.
>
> You're right of course about the chars "\n" and a ^J char in a Lisp
string.
>
> `defcustom' does different things in this regard, depending on the :type
(and
> whether there is a mismatch, but that's something else no doubt).
>
> See what the \n representation does, for example, with the file I sent to
> emacs-devel yesterday, thread "Variable behavior for `mouse-3' second
click at
> same spot".  Here's a direct URL to the file.
>
> http://www.emacswiki.org/emacs/mouse3.el
>
> Eval the defcustom for `mouse3-region-popup-submenus', then use `M-x
customize',
> and you'll see how messy (how wide) the display is.
>

If I understand this bug report correctly, the wishlist item is about
pretty printing restricted-sexp values, which makes sense to me.  Values
of the sexp widget already get pretty-printed, but not the values of the
restricted-sexp widget.

I attach a patch to pretty-print restricted sexp values too, by using the
same function that the sexp widget uses.

[-- Attachment #1.2: Type: text/html, Size: 1674 bytes --]

[-- Attachment #2: 0001-Pretty-print-restricted-sexp-values-too.patch --]
[-- Type: text/x-patch, Size: 926 bytes --]

From 0cf7d7537ccbf6b68f031e47775e220607aa191e Mon Sep 17 00:00:00 2001
From: Mauro Aranda <maurooaranda@gmail.com>
Date: Wed, 7 Oct 2020 20:02:04 -0300
Subject: [PATCH] Pretty print restricted sexp values too

* lisp/wid-edit.el (restricted-sexp widget): Use
widget-sexp-value-to-internal to pretty print the widget's value, when
it is a valid one.  (Bug#7524)
---
 lisp/wid-edit.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index c3366b62cd..009c6b4faf 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -3584,7 +3584,7 @@ 'restricted-sexp
   :match 'widget-restricted-sexp-match
   :value-to-internal (lambda (widget value)
 		       (if (widget-apply widget :match value)
-			   (prin1-to-string value)
+                           (widget-sexp-value-to-internal widget value)
 			 value)))
 
 (defun widget-restricted-sexp-match (widget value)
-- 
2.28.0

bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

[Lars Ingebrigtsen]

Mauro Aranda <maurooaranda@gmail.com> writes:

> If I understand this bug report correctly, the wishlist item is about
> pretty printing restricted-sexp values, which makes sense to me.  Values
> of the sexp widget already get pretty-printed, but not the values of the
> restricted-sexp widget.
>
> I attach a patch to pretty-print restricted sexp values too, by using the
> same function that the sexp widget uses.

I think that makes sense, even if my understanding of the widget code is
limited, so I've applied this to Emacs 28.

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