unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm)
To: "Roland Winkler" <winkler@gnu.org>
Cc: 4717@debbugs.gnu.org, Chong Yidong <cyd@stupidchicken.com>,
	sdl.web@gmail.com
Subject: bug#4717: 23.1.50; C-M-h in bibtex mode
Date: Tue, 04 Nov 2014 17:15:39 +0100	[thread overview]
Message-ID: <87k33bvt5g.fsf@vsl28t2g.ww011> (raw)
In-Reply-To: <m0r5t71fjf.fsf@cam.ac.uk>

"Roland Winkler" <Roland.Winkler@physik.uni-erlangen.de> writes:

> On Sun Oct 18 2009 Chong Yidong wrote:
>> > mark-defun does not put point where beginning-of-defun puts it. But
>> > if there is an empty line preceding the beginning-of-defun location,
>> > mark-defun will put point there. Why? The docstring of mark-defun
>> > does not explain this behavior.
>> 
>> I don't know the answer.  This behavior dates to 1993, though, so I
>> don't think it's feasible to change it for Lisp mode.

Summary of this thread from 2009 about the unusual behaviour of
C-M-h (bibtex-mark-entry) in BibTeX mode

1) In BibTeX mode C-M-h does (still) not switch on a transient region
2) Point is left at the end of an entry contrary to the behaviour in
   other modes
3) The range of the marked region is different to a range when applying
   C-M-a C-SPC C-M-e
4) The optional argument ALLOW-EXTEND is not explained in the doc string


and C-M-h (mark-defun) in Lisp mode

5) Does mark an empty line before a defun (when there is an empty line)
   whereas C-M-a places point before an empty line.
6) The optional argument is not explained in the doc string

> Agreed, changing it will probably break something. Could it be that
> the empty line was included so that in a sequence of defuns (each
> normally separated by one empty line) mark-defun could by used, for
> example in combination with kill-region and yank to move around
> defuns in a simple way?

My feeling is that it is such a minor point that nobody really cared to
correct/align this.

Moreover
6) C-M-h is lacking an optional argument to mark ARG defuns compared
   with all the other marking commands

> No matter whether something like that or anything else was the
> actual reason for implementing this behavior, the docstring should
> always document the actual behavior

I would like to volunteer and also argue that point 2) i. e. putting
point *behind* a marked element(s) and advancing the marking from point
is advantageous for large elements (pages, defuns, paragraphs), when the
marked elements might span outside of the current window and the marking
commands are repeated.  In this case the buffer is scrolled
automatically with the new boundary and possible additional marking
targets become visible.

  Dieter
-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany





  reply	other threads:[~2014-11-04 16:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-15 20:56 bug#4717: 23.1.50; C-M-h in bibtex mode Chong Yidong
2009-10-15 23:09 ` Roland Winkler
2009-10-18 17:09 ` Roland Winkler
2009-10-18 20:31   ` Chong Yidong
2009-10-19  3:38     ` Roland Winkler
2009-10-13 15:26       ` Leo
2014-11-04 16:15         ` H. Dieter Wilhelm [this message]
2014-11-05 15:37           ` Stefan Monnier
2014-11-11 23:53         ` H. Dieter Wilhelm
2022-02-07  0:50       ` Lars Ingebrigtsen
2022-03-07  2:53         ` Lars Ingebrigtsen
2022-03-07  8:18           ` Colin Baxter
2022-03-07 17:39             ` Roland Winkler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k33bvt5g.fsf@vsl28t2g.ww011 \
    --to=dieter@duenenhof-wilhelm.de \
    --cc=4717@debbugs.gnu.org \
    --cc=cyd@stupidchicken.com \
    --cc=sdl.web@gmail.com \
    --cc=winkler@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).