bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4717: 23.1.50; C-M-h in bibtex mode


From: H. Dieter Wilhelm
Subject: bug#4717: 23.1.50; C-M-h in bibtex mode
Date: Tue, 04 Nov 2014 17:15:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

"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 via email to

[Prev in Thread] Current Thread [Next in Thread]