Discussion:
[Emacs-diffs] master 1a6f595: * src/minibuf.c (read_minibuf): Add a FIXME comment.
(too old to reply)
Stefan Monnier
2018-04-25 01:39:14 UTC
Permalink
+ /* 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
Paul Eggert
2018-04-25 04:09:50 UTC
Permalink
Post by Stefan Monnier
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.
Stefan Monnier
2018-04-25 11:59:45 UTC
Permalink
Post by Paul Eggert
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.
Post by Paul Eggert
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
Paul Eggert
2018-04-25 19:30:35 UTC
Permalink
Post by Stefan Monnier
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.

Loading...