Re: [Emacs-diffs] master 1a6f595: * src/minibuf.c (read_minibuf): Add a FIXME comment.

Re: [Emacs-diffs] master 1a6f595: * src/minibuf.c (read_minibuf): Add a FIXME comment.

[Stefan Monnier]

> +  /* Why does this code set print-escape-newlines?  No call to Fprin1
> +     or to Fprint is anywhere in sight.  FIXME: Either remove the next
> +     two lines of code along with this comment, or replace this
> +     comment with an explanation for why the two lines are needed.  */
>    Fmake_local_variable (Qprint_escape_newlines);
>    print_escape_newlines = 1;

My guess is that it's because the miniwindow is mostly single-line, so
"prints" usually work better with \n than with LF.  I expect that while
there might not be any prin1/print in sight nowadays that probably
hasn't always been the case.


        Stefan

Re: [Emacs-diffs] master 1a6f595: * src/minibuf.c (read_minibuf): Add a FIXME comment.

[Paul Eggert]

Stefan Monnier wrote:
> My guess is that it's because the miniwindow is mostly single-line, so
> "prints" usually work better with \n than with LF.  I expect that while
> there might not be any prin1/print in sight nowadays that probably
> hasn't always been the case.

I went back to the earliest (circa 1991) minibuf.c in our repository and 
couldn't see a print1/print there either.

Perhaps this dates back to an earlier time when the minibuffer (or at least the 
minibuffer prompt) couldn't be multiline, so Emacs wanted to output "\n" rather 
than an actual newline when prompting or when echoing data.

Anyway, I doubt whether the code is needed now, as multiline prompts and data 
work just fine now in the minibuffer.

I filed a bug report for this (Bug#31251) to give others a chance to comment.

Re: [Emacs-diffs] master 1a6f595: * src/minibuf.c (read_minibuf): Add a FIXME comment.

[Stefan Monnier]

> I went back to the earliest (circa 1991) minibuf.c in our repository and
> couldn't see a print1/print there either.

I expect the potential prints where done via `format` and/or from Elisp code.

> Perhaps this dates back to an earlier time when the minibuffer (or at least
> the minibuffer prompt) couldn't be multiline,

Not sure what earlier time you're thinking of.  My minibuffer-only frame
is still single-line, with no sign that it will grow a second line any
time soon.

In any case, I don't think this buffer-local binding is right, so
I suggest removing it on `master`.


        Stefan

Re: [Emacs-diffs] master 1a6f595: * src/minibuf.c (read_minibuf): Add a FIXME comment.

[Paul Eggert]

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

On 04/25/2018 04:59 AM, Stefan Monnier wrote:
> Not sure what earlier time you're thinking of.  My minibuffer-only frame
> is still single-line, with no sign that it will grow a second line any
> time soon.
>
> In any case, I don't think this buffer-local binding is right, so
> I suggest removing it on `master`.

I vaguely recall that the minibuffer used to have problems if you did 
stuff like (read-from-minibuffer "line1\nline2"). This now works and the 
minibuffer displays as multiple lines (and does not use backslash-n in 
the display). My memory of course could be faulty.

Anyway, thanks for the second pair of eyes. I installed the attached 
into master and will close bug#31251.


[-- Attachment #2: 0001-Don-t-set-print-escape-newlines-in-the-minibuffer.txt --]
[-- Type: text/plain, Size: 2163 bytes --]

From 920d107d78cba5c390661d7a7f4b1a823ddfef0d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 25 Apr 2018 12:20:04 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20set=20print-escape-newlines=20i?=
 =?UTF-8?q?n=20the=20minibuffer?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This appears to be an unnecessary and possibly-confusing
revenant from ancient code (Bug#31251).  See thread containing:
https://lists.gnu.org/r/emacs-devel/2018-04/msg00654.html
* src/minibuf.c (read_minibuf): Do not set print-escape-newlines.
* src/print.c (syms_of_print): Do not defsym print-escape-newlines
or print-escape-control-characters, as these symbols are not used
in C code.
---
 src/minibuf.c | 7 -------
 src/print.c   | 2 --
 2 files changed, 9 deletions(-)

diff --git a/src/minibuf.c b/src/minibuf.c
index 11b3fe2b9c..c41958d85f 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -595,13 +595,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   XWINDOW (minibuf_window)->hscroll = 0;
   XWINDOW (minibuf_window)->suspend_auto_hscroll = 0;
 
-  /* Why does this code set print-escape-newlines?  No call to Fprin1
-     or to Fprint is anywhere in sight.  FIXME: Either remove the next
-     two lines of code along with this comment, or replace this
-     comment with an explanation for why the two lines are needed.  */
-  Fmake_local_variable (Qprint_escape_newlines);
-  print_escape_newlines = 1;
-
   /* Erase the buffer.  */
   {
     ptrdiff_t count1 = SPECPDL_INDEX ();
diff --git a/src/print.c b/src/print.c
index a8bbb9d37a..7c6856af48 100644
--- a/src/print.c
+++ b/src/print.c
@@ -2447,10 +2447,8 @@ priorities.  */);
   defsubr (&Sredirect_debugging_output);
   defsubr (&Sprint_preprocess);
 
-  DEFSYM (Qprint_escape_newlines, "print-escape-newlines");
   DEFSYM (Qprint_escape_multibyte, "print-escape-multibyte");
   DEFSYM (Qprint_escape_nonascii, "print-escape-nonascii");
-  DEFSYM (Qprint_escape_control_characters, "print-escape-control-characters");
 
   print_prune_charset_plist = Qnil;
   staticpro (&print_prune_charset_plist);
-- 
2.14.3