* bug#13810: 24.3.50; Docstring of `newline' is confusing @ 2013-02-25 10:03 Xue Fuqiao 2013-02-25 12:23 ` Stephen Berman 0 siblings, 1 reply; 17+ messages in thread From: Xue Fuqiao @ 2013-02-25 10:03 UTC (permalink / raw) To: 13810 In the doc string of the function `newline': Insert a newline, and move to left margin of the new line if it's blank. To reproduce this bug: emacs -Q M-< M-: (newline) RET A new line appears, but the point doesn't move to left margin of the first line. Maybe the doc string of this function should be improved. In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2013-02-24 on Emacs Bzr revision: 111865 rgm@gnu.org-20130223220645-ym5xjdm8i09p2huy Windowing system distributor `The X.Org Foundation', version 11.0.11300000 System Description: Ubuntu 12.10 Configured using: `configure --config-cache --enable-link-time-optimization' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <menu> e m - r e <tab> C-g <menu> r e - e m - b u <tab> <return> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Quit Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 10:03 bug#13810: 24.3.50; Docstring of `newline' is confusing Xue Fuqiao @ 2013-02-25 12:23 ` Stephen Berman 2013-02-25 12:48 ` Xue Fuqiao 2020-09-21 14:35 ` Lars Ingebrigtsen 0 siblings, 2 replies; 17+ messages in thread From: Stephen Berman @ 2013-02-25 12:23 UTC (permalink / raw) To: Xue Fuqiao; +Cc: 13810 On Mon, 25 Feb 2013 18:03:09 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: > In the doc string of the function `newline': > > Insert a newline, and move to left margin of the new line if it's > blank. > > To reproduce this bug: > > emacs -Q > M-< > M-: (newline) RET > > A new line appears, but the point doesn't move to left margin of the > first line. I think you misread the doc string: point should -- and does -- move to the left margin of the *new* line. > Maybe the doc string of this function should be improved. However, unless I'm misreading it, there is indeed room for improvement, since point moves to the left margin of the new line whether or not it is blank, so "if it's blank" is misleading and should be deleted. Your report prompted me to check the code of newline and I think I found a bug: a comment says, "If the newline leaves the previous line blank, and we have a left margin, delete that from the blank line", but the code only checks whether the previous line consists of a *single* space or tab, so if there's more than one space or tab and the line is otherwise blank, these won't be deleted. I doubt this asymmetry is intended, so at least the following patch should be made: === modified file 'lisp/simple.el' *** lisp/simple.el 2013-02-15 23:47:50 +0000 --- lisp/simple.el 2013-02-25 12:20:47 +0000 *************** *** 400,406 **** "Propertized string representing a hard newline character.") (defun newline (&optional arg) ! "Insert a newline, and move to left margin of the new line if it's blank. If option `use-hard-newlines' is non-nil, the newline is marked with the text-property `hard'. With ARG, insert that many newlines. --- 400,406 ---- "Propertized string representing a hard newline character.") (defun newline (&optional arg) ! "Insert a newline, and move to left margin of the new line. If option `use-hard-newlines' is non-nil, the newline is marked with the text-property `hard'. With ARG, insert that many newlines. *************** *** 428,434 **** (save-excursion (goto-char beforepos) (beginning-of-line) ! (and (looking-at "[ \t]$") (> (current-left-margin) 0) (delete-region (point) (line-end-position)))) --- 428,434 ---- (save-excursion (goto-char beforepos) (beginning-of-line) ! (and (looking-at "[ \t]+$") (> (current-left-margin) 0) (delete-region (point) (line-end-position)))) Actually, if we take the comment literally, the code should check that the space left on the previous line has the length of left-margin, and only in that case delete it. But I think the comment doesn't really intend that, but rather to delete any whitespace left on an otherwise blank line, which the above patch does. Steve Berman ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 12:23 ` Stephen Berman @ 2013-02-25 12:48 ` Xue Fuqiao 2013-02-25 13:05 ` Stephen Berman 2013-02-25 13:18 ` Stephen Berman 2020-09-21 14:35 ` Lars Ingebrigtsen 1 sibling, 2 replies; 17+ messages in thread From: Xue Fuqiao @ 2013-02-25 12:48 UTC (permalink / raw) To: Stephen Berman; +Cc: 13810 On Mon, 25 Feb 2013 13:23:14 +0100 Stephen Berman <stephen.berman@gmx.net> wrote: > On Mon, 25 Feb 2013 18:03:09 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: > > In the doc string of the function `newline': > > Insert a newline, and move to left margin of the new line if it's > > blank. > > To reproduce this bug: > > > > emacs -Q > > M-< > > M-: (newline) RET > > A new line appears, but the point doesn't move to left margin of the > > first line. > I think you misread the doc string: point should -- and does -- move to > the left margin of the *new* line. You mean the *new* line is the second line (now)? > Your report prompted me to check the code of newline and I think I found > a bug: a comment says, "If the newline leaves the previous line blank, > and we have a left margin, delete that from the blank line", but the > code only checks whether the previous line consists of a *single* space > or tab, so if there's more than one space or tab and the line is > otherwise blank, these won't be deleted. What does the "left margin" mean? I'm a little confused here. Does it mean the "margin" in the variable `left-margin-width'? BTW there is another problem with the doc string of the function `newline'. The `auto-fill-function' in the doc string is somewhat ambiguous. It is a Lisp function in simple.el, but it is also is a variable defined in buffer.c. > Steve Berman -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 12:48 ` Xue Fuqiao @ 2013-02-25 13:05 ` Stephen Berman 2013-02-25 13:27 ` Xue Fuqiao 2013-02-25 15:30 ` Stefan Monnier 2013-02-25 13:18 ` Stephen Berman 1 sibling, 2 replies; 17+ messages in thread From: Stephen Berman @ 2013-02-25 13:05 UTC (permalink / raw) To: Xue Fuqiao; +Cc: 13810 On Mon, 25 Feb 2013 20:48:06 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: > On Mon, 25 Feb 2013 13:23:14 +0100 > Stephen Berman <stephen.berman@gmx.net> wrote: > >> On Mon, 25 Feb 2013 18:03:09 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: >> > In the doc string of the function `newline': >> > Insert a newline, and move to left margin of the new line if it's >> > blank. >> > To reproduce this bug: >> > >> > emacs -Q >> > M-< >> > M-: (newline) RET >> > A new line appears, but the point doesn't move to left margin of the >> > first line. >> I think you misread the doc string: point should -- and does -- move to >> the left margin of the *new* line. > > You mean the *new* line is the second line (now)? Yes; I think that's the only interpretation that makes sense when newline is called at point-max, so for consistency it should be interpreted that way everywhere. >> Your report prompted me to check the code of newline and I think I found >> a bug: a comment says, "If the newline leaves the previous line blank, >> and we have a left margin, delete that from the blank line", but the >> code only checks whether the previous line consists of a *single* space >> or tab, so if there's more than one space or tab and the line is >> otherwise blank, these won't be deleted. > > What does the "left margin" mean? I'm a little confused here. Does it mean > the "margin" in the variable `left-margin-width'? No, it's referring to (the result of setting) the variable left-margin, which is different from left-margin-width. > BTW there is another problem with the doc string of the function `newline'. > The `auto-fill-function' in the doc string is somewhat ambiguous. It is a > Lisp function in simple.el, but it is also is a variable defined in buffer.c. The doc string of newline says "Call `auto-fill-function'..."; you can only call a function, not a variable (I suppose you can call a variable something, but not just call it). Steve Berman ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 13:05 ` Stephen Berman @ 2013-02-25 13:27 ` Xue Fuqiao 2013-02-25 15:50 ` Eli Zaretskii 2013-02-25 15:30 ` Stefan Monnier 1 sibling, 1 reply; 17+ messages in thread From: Xue Fuqiao @ 2013-02-25 13:27 UTC (permalink / raw) To: Stephen Berman; +Cc: 13810 On Mon, 25 Feb 2013 14:05:31 +0100 Stephen Berman <stephen.berman@gmx.net> wrote: > On Mon, 25 Feb 2013 20:48:06 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: > > On Mon, 25 Feb 2013 13:23:14 +0100 > > Stephen Berman <stephen.berman@gmx.net> wrote: > >> On Mon, 25 Feb 2013 18:03:09 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: > >> > In the doc string of the function `newline': > >> > Insert a newline, and move to left margin of the new line if it's > >> > blank. > >> > To reproduce this bug: > >> > > >> > emacs -Q > >> > M-< > >> > M-: (newline) RET > >> > A new line appears, but the point doesn't move to left margin of the > >> > first line. > >> I think you misread the doc string: point should -- and does -- move to > >> the left margin of the *new* line. > > You mean the *new* line is the second line (now)? > Yes; I think that's the only interpretation that makes sense when > newline is called at point-max, so for consistency it should be > interpreted that way everywhere. I see, thanks. > >> Your report prompted me to check the code of newline and I think I found > >> a bug: a comment says, "If the newline leaves the previous line blank, > >> and we have a left margin, delete that from the blank line", but the > >> code only checks whether the previous line consists of a *single* space > >> or tab, so if there's more than one space or tab and the line is > >> otherwise blank, these won't be deleted. > > What does the "left margin" mean? I'm a little confused here. Does it mean > > the "margin" in the variable `left-margin-width'? > No, it's referring to (the result of setting) the variable left-margin, > which is different from left-margin-width. Ah, I see. But in (info "(emacs) Glossary"), the term "margin" only contains the meaning from `left-margin-width'. Is it another bug? > > BTW there is another problem with the doc string of the function `newline'. > > The `auto-fill-function' in the doc string is somewhat ambiguous. It is a > > Lisp function in simple.el, but it is also is a variable defined in buffer.c. > The doc string of newline says "Call `auto-fill-function'..."; you can > only call a function, not a variable (I suppose you can call a variable > something, but not just call it). 1. The variable contains the *function* called to perform auto-fill; 2. In (info "(elisp) Documentation Tips"): However, when a symbol has both a function definition and a variable definition, and you want to refer to just one of them, you can specify which one by writing one of the words `variable', `option', `function', or `command', immediately before the symbol name. However, I think most people know that the `auto-fill-function' here refers to its function cell. So it is a very minor problem. > Steve Berman -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 13:27 ` Xue Fuqiao @ 2013-02-25 15:50 ` Eli Zaretskii 2013-02-25 22:33 ` Xue Fuqiao 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2013-02-25 15:50 UTC (permalink / raw) To: Xue Fuqiao; +Cc: stephen.berman, 13810 > Date: Mon, 25 Feb 2013 21:27:42 +0800 > From: Xue Fuqiao <xfq.free@gmail.com> > Cc: 13810@debbugs.gnu.org > > > > What does the "left margin" mean? I'm a little confused here. Does it mean > > > the "margin" in the variable `left-margin-width'? > > No, it's referring to (the result of setting) the variable left-margin, > > which is different from left-margin-width. > > Ah, I see. But in (info "(emacs) Glossary"), the term "margin" only contains > the meaning from `left-margin-width'. Is it another bug? The glossary is not the place where to look for all the possible meanings of "margin". Type "i margin RET" and see there; if it tells you there are more than one hit, type comma ',' to walk through all of them. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 15:50 ` Eli Zaretskii @ 2013-02-25 22:33 ` Xue Fuqiao 2013-02-26 3:46 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Xue Fuqiao @ 2013-02-25 22:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, 13810 On Mon, 25 Feb 2013 17:50:14 +0200 Eli Zaretskii <eliz@gnu.org> wrote: > The glossary is not the place where to look for all the possible > meanings of "margin". Why? Because it has to be brief? -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 22:33 ` Xue Fuqiao @ 2013-02-26 3:46 ` Eli Zaretskii 2020-01-25 15:39 ` Stefan Kangas 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2013-02-26 3:46 UTC (permalink / raw) To: Xue Fuqiao; +Cc: stephen.berman, 13810 > Date: Tue, 26 Feb 2013 06:33:11 +0800 > From: Xue Fuqiao <xfq.free@gmail.com> > Cc: stephen.berman@gmx.net, 13810@debbugs.gnu.org > > On Mon, 25 Feb 2013 17:50:14 +0200 > Eli Zaretskii <eliz@gnu.org> wrote: > > > The glossary is not the place where to look for all the possible > > meanings of "margin". > > Why? Because it has to be brief? Because it doesn't pretend to cover everything. I do agree that it would be good in this particular case to add the other meaning of "margin" to the glossary, though. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-26 3:46 ` Eli Zaretskii @ 2020-01-25 15:39 ` Stefan Kangas 2020-01-25 17:20 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Stefan Kangas @ 2020-01-25 15:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Xue Fuqiao, stephen.berman, 13810 [-- Attachment #1: Type: text/plain, Size: 1403 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> Date: Tue, 26 Feb 2013 06:33:11 +0800 >> From: Xue Fuqiao <xfq.free@gmail.com> >> Cc: stephen.berman@gmx.net, 13810@debbugs.gnu.org >> >> On Mon, 25 Feb 2013 17:50:14 +0200 >> Eli Zaretskii <eliz@gnu.org> wrote: >> >> > The glossary is not the place where to look for all the possible >> > meanings of "margin". >> >> Why? Because it has to be brief? > > Because it doesn't pretend to cover everything. > > I do agree that it would be good in this particular case to add the > other meaning of "margin" to the glossary, though. I'm not sure it's worth mentioning in this context to be honest. One possibility would be to instead rename `left-margin' to something like `indent-column' or `electric-indent-column' so we can get rid of this terminological confusion altogether. In my testing I'm also confused as to what the `left-margin' variable is supposed to do. I tried: 1. emacs -Q 2. M-x fundamental-mode 3. M-x set-variable RET left-margin RET 3 RET Now `newline' (RET) does not indent to column 3. However, `electric-newline-and-maybe-indent' (C-j) does indent to that column. This seems to contradict the doc string of `left-margin', which says "Linefeed indents to this column in Fundamental mode." I also found some possibility for improving the doc string of `newline', and propose the attached patch. WDYT? Best regards, Stefan Kangas [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-doc-string-of-newline.patch --] [-- Type: text/x-diff, Size: 1561 bytes --] From 9b120aaa635b95bb19f3151f88f50fd04b4ac25c Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Sat, 25 Jan 2020 16:21:06 +0100 Subject: [PATCH] Improve doc string of 'newline' * lisp/simple.el (newline): Doc fix. Move 'use-hard-newlines' down, since it's less important than the meaning of the prefix argument, and is less frequently used than 'electric-indent-mode' and 'auto-fill-mode'. Change the wording to no longer call it an option. (Bug#13810) --- lisp/simple.el | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/simple.el b/lisp/simple.el index 8be27745b1..2ec3da680f 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -503,9 +503,7 @@ hard-newline (defun newline (&optional arg interactive) "Insert a newline, and move to left margin of the new line if it's blank. -If option `use-hard-newlines' is non-nil, the newline is marked with the -text-property `hard'. -With ARG, insert that many newlines. +With prefix argument ARG, insert that many newlines. If `electric-indent-mode' is enabled, this indents the final new line that it adds, and reindents the preceding line. To just insert @@ -514,6 +512,9 @@ newline If `auto-fill-mode' is enabled, this may cause automatic line breaking of the preceding line. A non-nil ARG inhibits this. +If `use-hard-newlines' is enabled, the newline is marked with the +text-property `hard'. + A non-nil INTERACTIVE argument means to run the `post-self-insert-hook'." (interactive "*P\np") (barf-if-buffer-read-only) -- 2.20.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2020-01-25 15:39 ` Stefan Kangas @ 2020-01-25 17:20 ` Eli Zaretskii 2020-01-25 18:05 ` Stefan Kangas 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2020-01-25 17:20 UTC (permalink / raw) To: Stefan Kangas; +Cc: xfq.free, stephen.berman, 13810 > From: Stefan Kangas <stefan@marxist.se> > Cc: Xue Fuqiao <xfq.free@gmail.com>, stephen.berman@gmx.net, > 13810@debbugs.gnu.org > Date: Sat, 25 Jan 2020 16:39:37 +0100 > > 1. emacs -Q > 2. M-x fundamental-mode > 3. M-x set-variable RET left-margin RET 3 RET > > Now `newline' (RET) does not indent to column 3. However, > `electric-newline-and-maybe-indent' (C-j) does indent to that > column. This seems to contradict the doc string of `left-margin', > which says "Linefeed indents to this column in Fundamental mode." Linefeed is not RET, nor "newline". It's C-j. > I also found some possibility for improving the doc string of > `newline', and propose the attached patch. WDYT? That's OK, but it's unrelated, isn't it? ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2020-01-25 17:20 ` Eli Zaretskii @ 2020-01-25 18:05 ` Stefan Kangas 2020-01-25 18:29 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Stefan Kangas @ 2020-01-25 18:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: xfq.free, stephen.berman, 13810 Eli Zaretskii <eliz@gnu.org> writes: > Linefeed is not RET, nor "newline". It's C-j. Where is this documented? I can't find "linefeed" in the index of the Emacs manual, nor in the glossary. >> I also found some possibility for improving the doc string of >> `newline', and propose the attached patch. WDYT? > > That's OK, but it's unrelated, isn't it? Yes, it's somewhat tangential. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2020-01-25 18:05 ` Stefan Kangas @ 2020-01-25 18:29 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2020-01-25 18:29 UTC (permalink / raw) To: Stefan Kangas; +Cc: xfq.free, stephen.berman, 13810 > From: Stefan Kangas <stefan@marxist.se> > Cc: xfq.free@gmail.com, stephen.berman@gmx.net, 13810@debbugs.gnu.org > Date: Sat, 25 Jan 2020 19:05:37 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Linefeed is not RET, nor "newline". It's C-j. > > Where is this documented? It's that character's official name, and supposed to be "common knowledge". Go to the end of any line in an Emacs buffer, and type "C-u C-x =" -- Emacs will show the name of the character in the *Help* buffer it pops up. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 13:05 ` Stephen Berman 2013-02-25 13:27 ` Xue Fuqiao @ 2013-02-25 15:30 ` Stefan Monnier 2013-02-25 16:43 ` Stephen Berman 1 sibling, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2013-02-25 15:30 UTC (permalink / raw) To: Stephen Berman; +Cc: Xue Fuqiao, 13810 > The doc string of newline says "Call `auto-fill-function'..."; you can > only call a function, not a variable (I suppose you can call a variable > something, but not just call it). Yet, I think that newline doesn't call the `auto-fill-function' function, but the function contained in the `auto-fill-function' variable. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 15:30 ` Stefan Monnier @ 2013-02-25 16:43 ` Stephen Berman 0 siblings, 0 replies; 17+ messages in thread From: Stephen Berman @ 2013-02-25 16:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: Xue Fuqiao, 13810 On Mon, 25 Feb 2013 10:30:50 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> The doc string of newline says "Call `auto-fill-function'..."; you can >> only call a function, not a variable (I suppose you can call a variable >> something, but not just call it). > > Yet, I think that newline doesn't call the `auto-fill-function' > function, but the function contained in the > `auto-fill-function' variable. Still, it doesn't "call the variable" ;-). Anyway, isn't the potential for confusion here rather limited, since the function auto-fill-function is a noop just there for its doc string? Steve Berman ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 12:48 ` Xue Fuqiao 2013-02-25 13:05 ` Stephen Berman @ 2013-02-25 13:18 ` Stephen Berman 2013-02-25 13:35 ` Xue Fuqiao 1 sibling, 1 reply; 17+ messages in thread From: Stephen Berman @ 2013-02-25 13:18 UTC (permalink / raw) To: Xue Fuqiao; +Cc: 13810 On Mon, 25 Feb 2013 20:48:06 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: > On Mon, 25 Feb 2013 13:23:14 +0100 > Stephen Berman <stephen.berman@gmx.net> wrote: > >> On Mon, 25 Feb 2013 18:03:09 +0800 Xue Fuqiao <xfq.free@gmail.com> wrote: >> > In the doc string of the function `newline': >> > Insert a newline, and move to left margin of the new line if it's >> > blank. >> > To reproduce this bug: >> > >> > emacs -Q >> > M-< >> > M-: (newline) RET >> > A new line appears, but the point doesn't move to left margin of the >> > first line. >> I think you misread the doc string: point should -- and does -- move to >> the left margin of the *new* line. > > You mean the *new* line is the second line (now)? It just occurred to me that your confusion was probably due to thinking of the newline character (C-j, line feed, "\n"), which is inserted at the end of the line before the new line. In the doc string the two words "new line" unambiguously refer to the line after the inserted newline character that results from calling newline, but the first word "newline" should perhaps be replaced by "newline character" or "line feed". Steve Berman ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 13:18 ` Stephen Berman @ 2013-02-25 13:35 ` Xue Fuqiao 0 siblings, 0 replies; 17+ messages in thread From: Xue Fuqiao @ 2013-02-25 13:35 UTC (permalink / raw) To: Stephen Berman; +Cc: 13810 On Mon, 25 Feb 2013 14:18:59 +0100 Stephen Berman <stephen.berman@gmx.net> wrote: > >> > In the doc string of the function `newline': > >> > Insert a newline, and move to left margin of the new line if it's > >> > blank. > >> > To reproduce this bug: > >> > emacs -Q > >> > M-< > >> > M-: (newline) RET > >> > A new line appears, but the point doesn't move to left margin of the > >> > first line. > >> I think you misread the doc string: point should -- and does -- move to > >> the left margin of the *new* line. > > You mean the *new* line is the second line (now)? > In the doc string the two > words "new line" unambiguously refer to the line after the inserted > newline character that results from calling newline, but the first word > "newline" should perhaps be replaced by "newline character" or "line > feed". Sounds fine for me. > Steve Berman -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13810: 24.3.50; Docstring of `newline' is confusing 2013-02-25 12:23 ` Stephen Berman 2013-02-25 12:48 ` Xue Fuqiao @ 2020-09-21 14:35 ` Lars Ingebrigtsen 1 sibling, 0 replies; 17+ messages in thread From: Lars Ingebrigtsen @ 2020-09-21 14:35 UTC (permalink / raw) To: Stephen Berman; +Cc: Xue Fuqiao, 13810 Stephen Berman <stephen.berman@gmx.net> writes: > Your report prompted me to check the code of newline and I think I found > a bug: a comment says, "If the newline leaves the previous line blank, > and we have a left margin, delete that from the blank line", but the > code only checks whether the previous line consists of a *single* space > or tab, so if there's more than one space or tab and the line is > otherwise blank, these won't be deleted. I doubt this asymmetry is > intended, so at least the following patch should be made: Thanks; I've now applied your patch to Emacs 28. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-09-21 14:35 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-02-25 10:03 bug#13810: 24.3.50; Docstring of `newline' is confusing Xue Fuqiao 2013-02-25 12:23 ` Stephen Berman 2013-02-25 12:48 ` Xue Fuqiao 2013-02-25 13:05 ` Stephen Berman 2013-02-25 13:27 ` Xue Fuqiao 2013-02-25 15:50 ` Eli Zaretskii 2013-02-25 22:33 ` Xue Fuqiao 2013-02-26 3:46 ` Eli Zaretskii 2020-01-25 15:39 ` Stefan Kangas 2020-01-25 17:20 ` Eli Zaretskii 2020-01-25 18:05 ` Stefan Kangas 2020-01-25 18:29 ` Eli Zaretskii 2013-02-25 15:30 ` Stefan Monnier 2013-02-25 16:43 ` Stephen Berman 2013-02-25 13:18 ` Stephen Berman 2013-02-25 13:35 ` Xue Fuqiao 2020-09-21 14:35 ` 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).