* bug#4717: 23.1.50; C-M-h in bibtex mode
@ 2009-10-15 20:56 Chong Yidong
2009-10-15 23:09 ` Roland Winkler
2009-10-18 17:09 ` Roland Winkler
0 siblings, 2 replies; 13+ messages in thread
From: Chong Yidong @ 2009-10-15 20:56 UTC (permalink / raw)
To: Roland Winkler; +Cc: 4717
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
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
1 sibling, 0 replies; 13+ messages in thread
From: Roland Winkler @ 2009-10-15 23:09 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4717
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
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
1 sibling, 1 reply; 13+ messages in thread
From: Roland Winkler @ 2009-10-18 17:09 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4717
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2009-10-18 17:09 ` Roland Winkler
@ 2009-10-18 20:31 ` Chong Yidong
2009-10-19 3:38 ` Roland Winkler
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-10-18 20:31 UTC (permalink / raw)
To: Roland Winkler; +Cc: 4717
"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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2009-10-18 20:31 ` Chong Yidong
@ 2009-10-19 3:38 ` Roland Winkler
2009-10-13 15:26 ` Leo
2022-02-07 0:50 ` Lars Ingebrigtsen
0 siblings, 2 replies; 13+ messages in thread
From: Roland Winkler @ 2009-10-19 3:38 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4717
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
@ 2009-10-13 15:26 ` Leo
2014-11-04 16:15 ` H. Dieter Wilhelm
2014-11-11 23:53 ` H. Dieter Wilhelm
0 siblings, 2 replies; 13+ messages in thread
From: Leo @ 2009-10-13 15:26 UTC (permalink / raw)
To: emacs-pretest-bug
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2009-10-13 15:26 ` Leo
@ 2014-11-04 16:15 ` H. Dieter Wilhelm
2014-11-05 15:37 ` Stefan Monnier
2014-11-11 23:53 ` H. Dieter Wilhelm
1 sibling, 1 reply; 13+ messages in thread
From: H. Dieter Wilhelm @ 2014-11-04 16:15 UTC (permalink / raw)
To: Roland Winkler; +Cc: 4717, Chong Yidong, sdl.web
"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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2014-11-04 16:15 ` H. Dieter Wilhelm
@ 2014-11-05 15:37 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2014-11-05 15:37 UTC (permalink / raw)
To: H. Dieter Wilhelm; +Cc: 4717, Chong Yidong, Roland Winkler, sdl.web
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2009-10-13 15:26 ` Leo
2014-11-04 16:15 ` H. Dieter Wilhelm
@ 2014-11-11 23:53 ` H. Dieter Wilhelm
1 sibling, 0 replies; 13+ messages in thread
From: H. Dieter Wilhelm @ 2014-11-11 23:53 UTC (permalink / raw)
To: 4717
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2009-10-19 3:38 ` Roland Winkler
2009-10-13 15:26 ` Leo
@ 2022-02-07 0:50 ` Lars Ingebrigtsen
2022-03-07 2:53 ` Lars Ingebrigtsen
1 sibling, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-07 0:50 UTC (permalink / raw)
To: Roland Winkler; +Cc: 4717, Chong Yidong
(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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2022-02-07 0:50 ` Lars Ingebrigtsen
@ 2022-03-07 2:53 ` Lars Ingebrigtsen
2022-03-07 8:18 ` Colin Baxter
0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-07 2:53 UTC (permalink / raw)
To: Roland Winkler; +Cc: 4717, Chong Yidong
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2022-03-07 2:53 ` Lars Ingebrigtsen
@ 2022-03-07 8:18 ` Colin Baxter
2022-03-07 17:39 ` Roland Winkler
0 siblings, 1 reply; 13+ messages in thread
From: Colin Baxter @ 2022-03-07 8:18 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 4717, Chong Yidong, Roland Winkler
>>>>> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4717: 23.1.50; C-M-h in bibtex mode
2022-03-07 8:18 ` Colin Baxter
@ 2022-03-07 17:39 ` Roland Winkler
0 siblings, 0 replies; 13+ messages in thread
From: Roland Winkler @ 2022-03-07 17:39 UTC (permalink / raw)
To: 4717
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-03-07 17:39 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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).