GNU bug report logs -
#29529
next-line-add-newlines shouldn't be respected in next-line-or-history-element
Previous Next
Reported by: "E. Choroba" <choroba <at> matfyz.cz>
Date: Fri, 1 Dec 2017 22:51:01 UTC
Severity: minor
Merged with 27941
Found in version 25.2
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hi,
I don't like the "end of buffer" errors, so I have switched
next-line-add-newlines to t. In recent Emacs versions, though, this makes it
impossible to browse the minibuffer history with cursor arrows: <down> adds a
newline into the minibufer instead of showing the next history element. M-n
works correctly, though.
Steps to reproduce (tested in 25.3.1):
emacs -Q
(setq next-line-add-newlines t) C-x C-e
C-x C-f <down>
Solution:
Set the variable to nil locally in next-line-or-history-element.
Patch:
diff -u <(zcat /usr/local/share/emacs/25.3/lisp/simple.el.gz) ~/simple.el
--- /dev/fd/63 2017-12-01 23:45:06.338468797 +0100
+++ /home/choroba/simple.el 2017-12-01 23:45:04.166450109 +0100
@@ -2038,6 +2038,7 @@
(interactive "^p")
(or arg (setq arg 1))
(let* ((old-point (point))
+ (next-line-add-newlines nil)
;; Remember the original goal column of possibly multi-line input
;; excluding the length of the prompt on the first line.
(prompt-end (minibuffer-prompt-end))
Cheers,
Ch.
This bug report was last modified 7 years and 169 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.