GNU bug report logs - #45318
28.0.50; mark-paragraph

Previous Next

To reply to this bug, email your comments to 45318 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; mark-paragraph
Date: Sat, 19 Dec 2020 00:11:56 -0500

Create a buffer in Fundamental mode, insert the text

this is
a test

with no newline at the end, put point at the end,  and type M-h.

It does not set the mark.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32, cairo version 1.15.10)
 of 2020-12-08 built on freetop
Repository revision: 0155bd0fdb166c97a2ce76cc5bc64fd195a676d3
Repository branch: master
System Description: Trisquel GNU/Linux Etiona (9.0)

Configured using:
 'configure --with-gnutls=ifavailable 'CFLAGS=-O0 -g''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 XDBE XIM MODULES THREADS PDUMPER

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: RMAIL

Minor modes in effect:
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug smerge-mode diff log-edit pcvs-util add-log
org-element avl-tree generator ol-eww ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group
gnus-undo gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win
ol-docview doc-view jka-compr image-mode exif ol-bibtex bibtex ol-bbdb
ol-w3m org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob-core
ob-eval org-table ol org-keys org-compat org-macs org-loaddefs
format-spec find-func cal-menu calendar cal-loaddefs cl-extra
parse-time iso8601 mhtml-mode css-mode smie eww xdg url-queue mm-url
gnus nnheader wid-edit color js imenu cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
sgml-mode help-mode mule-util shell pcomplete thingatpt files-x grep
compile comint ansi-color ring misearch multi-isearch epa-mail
rmailkwd rmailsum vc-mtn vc-hg vc-git diff-mode easy-mmode vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher shr kinsoku svg
xml dom rmailout dabbrev mailalias sendmail qp rmailmm message rmc
puny rfc822 mml mml-sec epa epg epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils dired-aux dired dired-loaddefs t-mouse term/linux view
derived paren cus-start cus-load advice finder-inf package easymenu
browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib 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 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 dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 623831 68319)
 (symbols 48 27145 3)
 (strings 32 96682 5494)
 (string-bytes 1 3156284)
 (vectors 16 54707)
 (vector-slots 8 1438240 81088)
 (floats 8 363 545)
 (intervals 56 83923 2585)
 (buffers 984 96))
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #8 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>, 45318 <at> debbugs.gnu.org
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Sat, 19 Dec 2020 17:53:11 +0100

Richard Stallman <rms <at> gnu.org> writes:

> Create a buffer in Fundamental mode, insert the text
>
> this is
> a test
>
> with no newline at the end, put point at the end,  and type M-h.
>
> It does not set the mark.

It's this bit:

	  ;; don't activate the mark when at eob
	  ((and (eobp) (> numeric-arg 0)))

Looks like this was introduced in this commit:

commit eb090f65ceb0ae8a90829e911694348583135ba5
H. Dieter Wilhelm <dieter <at> duenenhof-wilhelm.de>

Now added to the Cc's.

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

Message #11 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45318 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Sun, 03 Jan 2021 23:29:00 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Richard Stallman <rms <at> gnu.org> writes:
>
>> Create a buffer in Fundamental mode, insert the text
>>
>> this is
>> a test
>>
>> with no newline at the end, put point at the end,  and type M-h.
>>
>> It does not set the mark.
>
> It's this bit:
>
> 	  ;; don't activate the mark when at eob
> 	  ((and (eobp) (> numeric-arg 0)))

I'm sorry for the mistake.  Here's the correction of M-h for above
bug report:

modified   lisp/textmodes/paragraphs.el
@@ -401,8 +401,9 @@ mark-paragraph
 	      (goto-char (mark))
 	      (forward-paragraph arg)
 	      (point))))
-	  ;; don't activate the mark when at eob
-	  ((and (eobp) (> numeric-arg 0)))
+	  ;; don't activate the mark when at eob in an empty paragraph
+	  ;; with a positive ARG
+	  ((and (eobp) (bolp) (> numeric-arg 0)))
 	  (t
 	   (unless (save-excursion
 		     (forward-line 0)

But I would like to extend this solution for the following case: (and
(eobp) (bolp)).  The current implementation of M-h is doing nothing (for
positive arguments) because - formally - the cursor sits in an "empty"
paragraph and there are no further paragraphs below.

But in this situation applying M-h clearly shows the user's intention to
mark the paragraph above the cursor (and possibly further ones above
when typing M-hhhh).

What is your opinion?

   Thank you


> commit eb090f65ceb0ae8a90829e911694348583135ba5
> Now added to the Cc's.

Thank you Lars

      Dieter

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Message #14 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>
Cc: 45318 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Mon, 04 Jan 2021 10:19:40 +0100

[Message part 1 (text/plain, inline)]

"H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de> writes:

> But I would like to extend this solution for the following case: (and
> (eobp) (bolp)).  The current implementation of M-h is doing nothing (for
> positive arguments) because - formally - the cursor sits in an "empty"
> paragraph and there are no further paragraphs below.
>
> But in this situation applying M-h clearly shows the user's intention to
> mark the paragraph above the cursor (and possibly further ones above
> when typing M-hhhh).
>
> What is your opinion?

I'm not quite sure I follow you, but either with the proposed patch, or
what I take to be your suggestion here, `mark-paragraph' works quite
differently here than in Emacs 27, and we should get the previous
behaviour back.

With this buffer:

[Message part 2 (image/png, inline)]

[Message part 3 (text/plain, inline)]

calling (mark-paragraph nil) gives me this in Emacs 27:

[Message part 4 (image/png, inline)]

[Message part 5 (text/plain, inline)]

I.e., it selects the previous paragraph, even if you're at the end of
the buffer.

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

Message #17 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45318 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Tue, 05 Jan 2021 23:27:30 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I'm not quite sure I follow you, but either with the proposed patch, or
> what I take to be your suggestion here, `mark-paragraph' works quite
> differently here than in Emacs 27, and we should get the previous
> behaviour back.

Right, below is my suggestion, please have a look.

Many thanks

      Dieter

PS: Please tell me if I can prepare patches in a better way or
    format..



From 35743faf181b04101ecdc61c6f6a3de3f9c6b10f Mon Sep 17 00:00:00 2001
From: Dieter Wilhelm <dieter <at> duenenhof-wilhelm.de>
Date: Tue, 5 Jan 2021 22:44:21 +0100
Subject: [PATCH] textmodes/paragraphs.el fix mark-paragraph (Bug#45318)

Thus aligning the behavior of mark-paragraph with mark-defun.
---
 lisp/textmodes/paragraphs.el | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lisp/textmodes/paragraphs.el b/lisp/textmodes/paragraphs.el
index 217ae10fe4..699c2191b8 100644
--- a/lisp/textmodes/paragraphs.el
+++ b/lisp/textmodes/paragraphs.el
@@ -386,7 +386,8 @@ mark-paragraph
 This also means when activating the mark immediately before using
 this command, the current paragraph is only marked from point."
   (interactive "P\np")
-  (let ((numeric-arg (prefix-numeric-value arg)))
+  (let ((numeric-arg (prefix-numeric-value arg))
+        (pt))
     (cond ((zerop numeric-arg))
 	  ((and allow-extend
 		(or (and (eq last-command this-command) mark-active)
@@ -401,8 +402,13 @@ mark-paragraph
 	      (goto-char (mark))
 	      (forward-paragraph arg)
 	      (point))))
-	  ;; don't activate the mark when at eob
-	  ((and (eobp) (> numeric-arg 0)))
+	  ;; check if point is behind the very last paragraph and mark
+	  ;; it when no arg is given.
+	  ((if (> (save-excursion (forward-paragraph)) 0)
+               (progn (setq pt (point))
+                      (forward-paragraph (- 1))
+                      (set-mark (point))
+                      (goto-char pt))))
 	  (t
 	   (unless (save-excursion
 		     (forward-line 0)
-- 
2.17.1


-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Message #20 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>
Cc: 45318 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Thu, 07 Jan 2021 13:11:32 +0100

"H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de> writes:

> Right, below is my suggestion, please have a look.
>
> Many thanks
>
>       Dieter
>
> PS: Please tell me if I can prepare patches in a better way or
>     format..

The patch format looks good.  :-)

However, this still doesn't quite restore how mark-paragraph works in
Emacs 27 -- it leaves point in other places than it was.

So I've reverted the previous change for now, and I've added a test.
Could you have a look at the test

cd check; make paragraphs-tests

(it's the last one), and redo your original patch in a way that doesn't
break the behaviour as demonstrated by this test?

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

Message #23 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>, 45318 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Sat, 3 Apr 2021 20:01:02 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de> writes:
>
>> Right, below is my suggestion, please have a look.
>>
>> Many thanks
>>
>>       Dieter
>>
>> PS: Please tell me if I can prepare patches in a better way or
>>     format..
>
> The patch format looks good.  :-)
>
> However, this still doesn't quite restore how mark-paragraph works in
> Emacs 27 -- it leaves point in other places than it was.
>
> So I've reverted the previous change for now, and I've added a test.
> Could you have a look at the test
>
> cd check; make paragraphs-tests
>
> (it's the last one), and redo your original patch in a way that doesn't
> break the behaviour as demonstrated by this test?

That was 12 weeks ago.  Any news here?

Message #26 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>, 45318 <at> debbugs.gnu.org,
 18847 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Mon, 11 Oct 2021 05:15:33 -0700

unarchive 18847
reopen 18847
tags 18847 - patch
forcemerge 18847 45318
thanks

Stefan Kangas <stefan <at> marxist.se> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de> writes:
>>
>>> Right, below is my suggestion, please have a look.
>>>
>>> Many thanks
>>>
>>>       Dieter
>>>
>>> PS: Please tell me if I can prepare patches in a better way or
>>>     format..
>>
>> The patch format looks good.  :-)
>>
>> However, this still doesn't quite restore how mark-paragraph works in
>> Emacs 27 -- it leaves point in other places than it was.
>>
>> So I've reverted the previous change for now, and I've added a test.
>> Could you have a look at the test
>>
>> cd check; make paragraphs-tests
>>
>> (it's the last one), and redo your original patch in a way that doesn't
>> break the behaviour as demonstrated by this test?
>
> That was 12 weeks ago.  Any news here?

It seems like Bug#18847 was fixed in a way that was lead to other
regressions.  That fix has since been reverted, so I'm reopening that
bug and merging this later bug with that one.

Message #33 received at 45318 <at> debbugs.gnu.org (full text, mbox):

From: "H. Dieter Wilhelm" <dieter <at> duenenhof-wilhelm.de>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45318 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#45318: 28.0.50; mark-paragraph
Date: Sat, 16 Oct 2021 19:33:05 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

>> (it's the last one), and redo your original patch in a way that doesn't
>> break the behaviour as demonstrated by this test?
>
> That was 12 weeks ago.  Any news here?

Not from my side.

(This year I can't afford to take a deeper look into this, but I intend
to follow it up in 2022.)

Thanks for the reminder

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.