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

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

[Leo]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

C-M-h which runs bibtex-mark-entry in BibTeX-mode seems to be
inconsistent with C-M-h in other modes. For example, C-M-h in
emacs-lisp-mode will mark the 'defun' with highlighted region and the
point in the beginning of the region.

In BibTeX mode, however, the region is _not_ highlighted and the point
is left at the end of the region.

I wonder if this inconsistency can be done away with.

Best wishes,

Leo

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

[Chong Yidong]

Hi Roland,

Could you take a look at this bug?  There seems to be no good reason for
bibtex to behave differently than the rest of Emacs.  What bibtex-mode
probably needs to do is to bind beginning/end-of-defun-function to
bibtex-beginning/end-of-entry.  Then you can remove bibtex-mark-entry
(or rather make it an obsolete alias for mark-defun).

WDYT?

> C-M-h which runs bibtex-mark-entry in BibTeX-mode seems to be
> inconsistent with C-M-h in other modes. For example, C-M-h in
> emacs-lisp-mode will mark the 'defun' with highlighted region and the
> point in the beginning of the region.

> In BibTeX mode, however, the region is _not_ highlighted and the point
> is left at the end of the region.

> I wonder if this inconsistency can be done away with.

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

[Roland Winkler]

On Thu Oct 15 2009 Chong Yidong wrote:
> Could you take a look at this bug? There seems to be no good
> reason for bibtex to behave differently than the rest of Emacs.
> What bibtex-mode probably needs to do is to bind
> beginning/end-of-defun-function to bibtex-beginning/end-of-entry.
> Then you can remove bibtex-mark-entry (or rather make it an
> obsolete alias for mark-defun).

I thought I could do that quickly, till I realized there is a minor
nuisance:

There are several functions / commands that could benefit from
binding beginning/end-of-defun-function to bibtex-beginning/end-of-entry.
Yet for historical reasons bibtex-beginning/end-of-entry behave
slightly different from the `standard' beginning/end-of-defun.
So the proper solution will be to make these bibtex functions behave
similar to beginning/end-of-defun
This will require to check also the internal usage of
bibtex-beginning/end-of-entry by bibtex-mode, which is just a bit
more work...

Roland

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

[Roland Winkler]

On Thu Oct 15 2009 Chong Yidong wrote:
> Could you take a look at this bug?  There seems to be no good reason for
> bibtex to behave differently than the rest of Emacs.  What bibtex-mode
> probably needs to do is to bind beginning/end-of-defun-function to
> bibtex-beginning/end-of-entry.  Then you can remove bibtex-mark-entry
> (or rather make it an obsolete alias for mark-defun).

Kind of related question:

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. Also, the optional arg of mark-defun
should be explained, too.

Thanks,

Roland

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

[Chong Yidong]

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

> 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.

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

[Roland Winkler]

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.

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?

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

Roland

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

[H. Dieter Wilhelm]

"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

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

[Stefan Monnier]

> 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

Indeed.

Ideally BibTeX's C-M-h should not be rebound, and instead
beginning-of-defun-function and end-of-defun-function should be set in
such as way that mark-defun marks the same text as bibtex-mark-entry.

> 4) The optional argument ALLOW-EXTEND is not explained in the doc string

It is, tho indirectly:

   Interactively, if this command is repeated
   or (in Transient Mark mode) if the mark is active,
   it marks the next defun after the ones already marked.

> 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.

Of course, C-SPC M-C-e M-C-e M-C-e would work about as well in that
case ;-)


        Stefan

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

[H. Dieter Wilhelm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

...

> Ideally BibTeX's C-M-h should not be rebound, and instead
> beginning-of-defun-function and end-of-defun-function should be set in
> such as way that mark-defun marks the same text as bibtex-mark-entry.

I did not yet test it good enough but your idea worked out of the box,
beginning/end-of-defun and mark-defun seem to recognise bibtex entries
already properly without further ado! :-)

>> 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.
>
> Of course, C-SPC M-C-e M-C-e M-C-e would work about as well in that
> case ;-)

And one better - in my opinion - C-M-S-e C-M-S-e ...  (But the two
methods are only working like C-M-h when point is already at the
beginning of a defun.)

Anyway, I understand now that it might be better to have two ways of
advancing a region: From point with navigation commands *and* from mark
with marking commands like C-M-e or M-}...

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

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

[Lars Ingebrigtsen]

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

It looks like the major issue here has been fixed since this was
reported -- `C-M-h' now activates the region.  But it still places point
at the end of the region (instead of the beginning, as it does in all
other modes).

Is this something that should be fixed, Roland, or would it be too
disruptive for bibtex users?

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It looks like the major issue here has been fixed since this was
> reported -- `C-M-h' now activates the region.  But it still places point
> at the end of the region (instead of the beginning, as it does in all
> other modes).
>
> Is this something that should be fixed, Roland, or would it be too
> disruptive for bibtex users?

There was no response in a month, so I went ahead and changed this
command in bibtex-mode to work like in other modes in Emacs 29.  If this
is too disruptive, go ahead and revert it (and mark this bug report as
"wontfix" instead).

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

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

[Colin Baxter]

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

    > Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> It looks like the major issue here has been fixed since this was
    >> reported -- `C-M-h' now activates the region.  But it still
    >> places point at the end of the region (instead of the beginning,
    >> as it does in all other modes).
    >> 
    >> Is this something that should be fixed, Roland, or would it be
    >> too disruptive for bibtex users?

    > There was no response in a month, so I went ahead and changed this
    > command in bibtex-mode to work like in other modes in Emacs 29.
    > If this is too disruptive, go ahead and revert it (and mark this
    > bug report as "wontfix" instead).

Personally, I find the change to be a confounded nuisance. If I am just
copying a region then I want the point to remain at the end of the
region and not return to the beginning.

Best wishes,

Colin Baxter.

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

[Roland Winkler]

On Mon, Mar 07 2022, Colin Baxter wrote:
>>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>     > Lars Ingebrigtsen <larsi@gnus.org> writes:
>     >> It looks like the major issue here has been fixed since this was
>     >> reported -- `C-M-h' now activates the region.  But it still
>     >> places point at the end of the region (instead of the beginning,
>     >> as it does in all other modes).
>     >> 
>     >> Is this something that should be fixed, Roland, or would it be
>     >> too disruptive for bibtex users?
>
>     > There was no response in a month, so I went ahead and changed this
>     > command in bibtex-mode to work like in other modes in Emacs 29.
>     > If this is too disruptive, go ahead and revert it (and mark this
>     > bug report as "wontfix" instead).
>
> Personally, I find the change to be a confounded nuisance. If I am just
> copying a region then I want the point to remain at the end of the
> region and not return to the beginning.

...Not yet a proper reply from my side: I discovered by chance that this
old thread has been active again.  But I missed the more recent emails
because they went to an old email address of mine that has been disabled
for at least ten years.

I'll try to provide a more useful reply as soon as possible.

Roland