GNU bug report logs -
#4717
23.1.50; C-M-h in bibtex mode
Previous Next
Reported by: Leo <sdl.web <at> gmail.com>
Date: Tue, 13 Oct 2009 15:35:04 UTC
Severity: minor
Tags: moreinfo
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4717 in the body.
You can then email your comments to 4717 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4717
; Package
emacs
.
(Tue, 13 Oct 2009 15:35:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Leo <sdl.web <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Tue, 13 Oct 2009 15:35:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4717
; Package
emacs
.
(Thu, 15 Oct 2009 21:05:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 15 Oct 2009 21:05:05 GMT)
Full text and
rfc822 format available.
Message #10 received at 4717 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4717
; Package
emacs
.
(Thu, 15 Oct 2009 23:15:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Roland Winkler" <Roland.Winkler <at> physik.uni-erlangen.de>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 15 Oct 2009 23:15:05 GMT)
Full text and
rfc822 format available.
Message #15 received at 4717 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4717
; Package
emacs
.
(Sun, 18 Oct 2009 17:15:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Roland Winkler" <Roland.Winkler <at> physik.uni-erlangen.de>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 18 Oct 2009 17:15:05 GMT)
Full text and
rfc822 format available.
Message #20 received at 4717 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4717
; Package
emacs
.
(Sun, 18 Oct 2009 20:40:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 18 Oct 2009 20:40:06 GMT)
Full text and
rfc822 format available.
Message #25 received at 4717 <at> emacsbugs.donarmstrong.com (full text, mbox):
"Roland Winkler" <Roland.Winkler <at> 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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4717
; Package
emacs
.
(Mon, 19 Oct 2009 03:45:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Roland Winkler" <Roland.Winkler <at> physik.uni-erlangen.de>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Mon, 19 Oct 2009 03:45:09 GMT)
Full text and
rfc822 format available.
Message #30 received at 4717 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Tue, 04 Nov 2014 16:16:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 4717 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" <Roland.Winkler <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Wed, 05 Nov 2014 15:39:03 GMT)
Full text and
rfc822 format available.
Message #36 received at 4717 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Tue, 11 Nov 2014 23:55:02 GMT)
Full text and
rfc822 format available.
Message #39 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Mon, 07 Feb 2022 00:52:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 4717 <at> debbugs.gnu.org (full text, mbox):
(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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Feb 2022 00:52:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Mon, 07 Mar 2022 02:54:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 4717 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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 marked as fixed in version 29.1, send any further explanations to
4717 <at> debbugs.gnu.org and Leo <sdl.web <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Mar 2022 02:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Mon, 07 Mar 2022 08:19:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 4717 <at> debbugs.gnu.org (full text, mbox):
>>>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Lars Ingebrigtsen <larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#4717
; Package
emacs
.
(Mon, 07 Mar 2022 17:40:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 4717 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 07 2022, Colin Baxter wrote:
>>>>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > Lars Ingebrigtsen <larsi <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 05 Apr 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 91 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.