bug#28937: 26.0.60; Value after elisp docstring is filled (boundaries on forward-paragraph)

bug#28937: 26.0.60; Value after elisp docstring is filled (boundaries on forward-paragraph)

[Alex]

Consider:

(defun test ()
  "This is a test docstring.
Here is some more text."
  1
  2
  3
  4
  5)
  
In an Emacs Lisp/Lisp Interaction buffer press `M-q' anywhere in the
docstring to fill the above. Notice that 1 through 5 are all filled with
the docstring, when none of them should be. Now consider:

(defun test ()
  "This is a test docstring.
Here is some more text."
  1
  2
  (3)
  4
  5)

Now only 1 and 2 are filled. This is because forward-paragraph uses the
`paragraph-start' regexp to find the start of a new paragraph. This
regexp includes `(', which is why everything from (3) isn't filled.

What should likely be done is to find the end of the docstring when
filling it and stopping the search if it reaches the end.

forward-paragraph should accept an arbitrary point as a search limit to
accomplish the above.

Once this bug is fixed, the space+colon added in bug#24622 should be
removed.

bug#28937: 26.0.60; Value after elisp docstring is filled (boundaries on forward-paragraph)

[Lars Ingebrigtsen]

Alex <agrambot@gmail.com> writes:

> Consider:
>
> (defun test ()
>   "This is a test docstring.
> Here is some more text."
>   1
>   2
>   3
>   4
>   5)
>
> In an Emacs Lisp/Lisp Interaction buffer press `M-q' anywhere in the
> docstring to fill the above. Notice that 1 through 5 are all filled with
> the docstring, when none of them should be.

I've now changed this in Emacs 28 to narrow to the string before doing
the filling, which seems to fix this problem, and hopefully shouldn't
have any adverse effects (*cough*).

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

bug#28937: 26.0.60; Value after elisp docstring is filled (boundaries on forward-paragraph)

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now changed this in Emacs 28 to narrow to the string before doing
> the filling, which seems to fix this problem, and hopefully shouldn't
> have any adverse effects (*cough*).

(*cough*)

0. emacs -Q
1. (progn
     (insert "\n\n(defvar foo nil\n  \"First.\nSecond\n\nThird.\")\n")
     (end-of-line -2)
     (dotimes (_ 15)
       (insert " abcd")))
2. C-x C-e
3. M-q

Expected result: second paragraph filled, like in Emacs 27.
Actual result: second paragraph not filled.

(*cough* :)

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-03-05 built on tia
Repository revision: 77ec25122c9a7855657de564101c9fe763b91013
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11
XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame minibuffer
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese composite
charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote threads
dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit x multi-tty make-network-process
emacs)

bug#28937: 26.0.60; Value after elisp docstring is filled (boundaries on forward-paragraph)

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> I've now changed this in Emacs 28 to narrow to the string before doing
>> the filling, which seems to fix this problem, and hopefully shouldn't
>> have any adverse effects (*cough*).
>
> (*cough*)
>
> 0. emacs -Q
> 1. (progn
>      (insert "\n\n(defvar foo nil\n  \"First.\nSecond\n\nThird.\")\n")
>      (end-of-line -2)
>      (dotimes (_ 15)
>        (insert " abcd")))
> 2. C-x C-e
> 3. M-q

(*cough* *cough*)

I hope it's not catching!

This should be fixed now -- I forgot to preserve point after doing the
narrowing.

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

bug#28937: 26.0.60; Value after elisp docstring is filled (boundaries on forward-paragraph)

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>>> I've now changed this in Emacs 28 to narrow to the string before doing
>>> the filling, which seems to fix this problem, and hopefully shouldn't
>>> have any adverse effects (*cough*).
>>
>> (*cough*)
>>
>> 0. emacs -Q
>> 1. (progn
>>      (insert "\n\n(defvar foo nil\n  \"First.\nSecond\n\nThird.\")\n")
>>      (end-of-line -2)
>>      (dotimes (_ 15)
>>        (insert " abcd")))
>> 2. C-x C-e
>> 3. M-q
>
> (*cough* *cough*)
>
> I hope it's not catching!

We may or may not want to expand M-x doctor.

> This should be fixed now

Yup, thanks!

-- 
Basil