GNU bug report logs -
#21072
24.5; inconsistent behaviour of `C-M-h (mark-defun)' in Emacs Lisp
Previous Next
Reported by: Raffaele Ricciardi <rfflrccrd <at> gmail.com>
Date: Thu, 16 Jul 2015 06:13:01 UTC
Severity: minor
Found in version 24.5
Done: Marcin Borkowski <mbork <at> mbork.pl>
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 21072 in the body.
You can then email your comments to 21072 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 16 Jul 2015 06:13:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raffaele Ricciardi <rfflrccrd <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 16 Jul 2015 06:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Dear Emacs maintainers,
the documentation for `mark-defun' says:
The defun marked is the one that contains point or follows point.
However, Emacs may mark the preceding defun instead, and it may
mark an unrelated preceding comment along with the defun.
Please follow this recipe:
- emacs -Q
- make sure that *scratch* contains the following code:
------------------------------------------------------------------------
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
(defun a ()
nil)
(defun b ()
nil)
------------------------------------------------------------------------
- move point anywhere inside the second defun;
- press `C-M-h' and Emacs will correctly mark the current defun;
- press `C-g C-M-h' and Emacs will incorrectly mark the previous defun;
- now move point anywhere inside the first definition;
- press `C-M-h' and Emacs will correctly mark the current defun;
- press `C-g C-M-h' and Emacs will incorrectly mark the defun along with
the preceding comment;
- now make sure that *scratch* contains the following code:
------------------------------------------------------------------------
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
(defun a ()
nil)
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
(defun b ()
nil)
------------------------------------------------------------------------
- move point anywhere inside the second comment and press `C-M-h': Emacs
will correctly mark the following defun;
- move point anywhere inside the first comment and press `C-M-h': Emacs
will incorrectly mark the comment along with the defun.
Thanks for your attention.
Best Regards.
--
In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.5)
of 2015-06-23 on debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 8.1 (jessie)
Configured using:
`configure --prefix=/opt/emacs/emacs-24.5'
Important settings:
value of $LC_MONETARY: en_GB.utf8
value of $LC_NUMERIC: en_GB.utf8
value of $LC_TIME: en_GB.utf8
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Quit
Mark set [2 times]
Quit
Mark set [2 times]
Quit
Mark set [2 times]
Quit
Mark set [2 times]
Quit
Mark set [2 times]
Quit
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 16 73007 6360)
(symbols 48 17564 0)
(miscs 40 53 254)
(strings 32 9482 4902)
(string-bytes 1 268085)
(vectors 16 8916)
(vector-slots 8 383708 18759)
(floats 8 64 360)
(intervals 56 334 13)
(buffers 960 11)
(heap 1024 48896 861))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Mon, 25 Apr 2016 11:12:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2015-07-16, at 08:12, Raffaele Ricciardi <rfflrccrd <at> gmail.com> wrote:
> Dear Emacs maintainers,
>
> the documentation for `mark-defun' says:
>
> The defun marked is the one that contains point or follows point.
>
> However, Emacs may mark the preceding defun instead, and it may
> mark an unrelated preceding comment along with the defun.
Confirmed on GNU Emacs 25.1.50.8 (commit 912e915).
Best,
--
Marcin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 01 May 2016 17:18:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> amu.edu.pl>
> Date: Mon, 25 Apr 2016 13:11:01 +0200
> Cc: 21072 <at> debbugs.gnu.org
>
> On 2015-07-16, at 08:12, Raffaele Ricciardi <rfflrccrd <at> gmail.com> wrote:
>
> > Dear Emacs maintainers,
> >
> > the documentation for `mark-defun' says:
> >
> > The defun marked is the one that contains point or follows point.
> >
> > However, Emacs may mark the preceding defun instead, and it may
> > mark an unrelated preceding comment along with the defun.
>
> Confirmed on GNU Emacs 25.1.50.8 (commit 912e915).
FWIW, I don't see why the behavior flagged "incorrect" is deemed
incorrect. It looks correct to me. In all of those examples point is
between 2 functions, so what exactly is "correct" is open to
discussion.
Am I missing something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 01 May 2016 17:50:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-01, at 19:17, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> amu.edu.pl>
>> Date: Mon, 25 Apr 2016 13:11:01 +0200
>> Cc: 21072 <at> debbugs.gnu.org
>>
>> On 2015-07-16, at 08:12, Raffaele Ricciardi <rfflrccrd <at> gmail.com> wrote:
>>
>> > Dear Emacs maintainers,
>> >
>> > the documentation for `mark-defun' says:
>> >
>> > The defun marked is the one that contains point or follows point.
>> >
>> > However, Emacs may mark the preceding defun instead, and it may
>> > mark an unrelated preceding comment along with the defun.
>>
>> Confirmed on GNU Emacs 25.1.50.8 (commit 912e915).
>
> FWIW, I don't see why the behavior flagged "incorrect" is deemed
> incorrect. It looks correct to me. In all of those examples point is
> between 2 functions, so what exactly is "correct" is open to
> discussion.
>
> Am I missing something?
Yes. Here's a fragment from `mark-defun''s docstring:
--8<---------------cut here---------------start------------->8---
Put mark at end of this defun, point at beginning.
The defun marked is the one that contains point or follows point.
--8<---------------cut here---------------end--------------->8---
And from the Emacs manual:
--8<---------------cut here---------------start------------->8---
If you use the command while point is between defuns, it uses the
following defun.
--8<---------------cut here---------------end--------------->8---
So IMHO it's not "open to discussion" - the behavior is different than
described in both the docstring (a bit implicitly) or in the manual
(explicitly).
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 01 May 2016 18:10:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> mbork.pl>
> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
> Date: Sun, 01 May 2016 19:49:36 +0200
>
> --8<---------------cut here---------------start------------->8---
> Put mark at end of this defun, point at beginning.
> The defun marked is the one that contains point or follows point.
> --8<---------------cut here---------------end--------------->8---
So if we say "either precedes or follows point" instead of "follows
point", all will be well?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 01 May 2016 19:46:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-01, at 20:09, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> mbork.pl>
>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>> Date: Sun, 01 May 2016 19:49:36 +0200
>>
>> --8<---------------cut here---------------start------------->8---
>> Put mark at end of this defun, point at beginning.
>> The defun marked is the one that contains point or follows point.
>> --8<---------------cut here---------------end--------------->8---
>
> So if we say "either precedes or follows point" instead of "follows
> point", all will be well?
Formally, yes. Though I guess it would be a bit better to fix the
commands so that it's behavior matches the docs.
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 01 May 2016 19:57:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> mbork.pl>
> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
> Date: Sun, 01 May 2016 21:45:37 +0200
>
> > So if we say "either precedes or follows point" instead of "follows
> > point", all will be well?
>
> Formally, yes. Though I guess it would be a bit better to fix the
> commands so that it's behavior matches the docs.
Why do you think that? Why is it better to always mark the function
that follows point?
Me, I think that the current behavior is a kind of feature, since it
lets the user control whether the leading commentary before a function
will or won't be marked.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 03 May 2016 18:59:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-01, at 21:56, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> mbork.pl>
>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>> Date: Sun, 01 May 2016 21:45:37 +0200
>>
>> > So if we say "either precedes or follows point" instead of "follows
>> > point", all will be well?
>>
>> Formally, yes. Though I guess it would be a bit better to fix the
>> commands so that it's behavior matches the docs.
>
> Why do you think that? Why is it better to always mark the function
> that follows point?
I don't know, I don't use `mark-defun' personally. My train of thought
was that if someone wrote something like that inthe docs, s?he thought
it was reasonable.
> Me, I think that the current behavior is a kind of feature, since it
> lets the user control whether the leading commentary before a function
> will or won't be marked.
I don't understand that. How do I control that?
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 04 May 2016 14:47:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> mbork.pl>
> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
> Date: Tue, 03 May 2016 20:58:27 +0200
>
> > Me, I think that the current behavior is a kind of feature, since it
> > lets the user control whether the leading commentary before a function
> > will or won't be marked.
>
> I don't understand that. How do I control that?
By invoking the command before or after the commentary that precedes a
function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 06 May 2016 12:28:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-04, at 16:45, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> mbork.pl>
>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>> Date: Tue, 03 May 2016 20:58:27 +0200
>>
>> > Me, I think that the current behavior is a kind of feature, since it
>> > lets the user control whether the leading commentary before a function
>> > will or won't be marked.
>>
>> I don't understand that. How do I control that?
>
> By invoking the command before or after the commentary that precedes a
> function.
Sorry, but I still don't get it. (I think this means at least that the
docs need rewording.) Take this text:
--8<---------------cut here---------------start------------->8---
(defun spam ()
(spam))
;; Lorem ipsum
(defun lorem-ipsum ()
"Lorem ipsum."
(message "Lorem ipsum."))
--8<---------------cut here---------------end--------------->8---
How do I place point so that `mark-defun' would mark `lorem-ipsum'
together with the comment before?
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 06 May 2016 13:00:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> mbork.pl>
> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
> Date: Fri, 06 May 2016 14:27:49 +0200
>
> (defun spam ()
> (spam))
>
> ;; Lorem ipsum
> (defun lorem-ipsum ()
> "Lorem ipsum."
> (message "Lorem ipsum."))
> --8<---------------cut here---------------end--------------->8---
>
> How do I place point so that `mark-defun' would mark `lorem-ipsum'
> together with the comment before?
I'm sorry, I no longer remember. It's hard to communicate when days
pass between messages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sat, 07 May 2016 03:48:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-06, at 14:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> mbork.pl>
>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>> Date: Fri, 06 May 2016 14:27:49 +0200
>>
>> (defun spam ()
>> (spam))
>>
>> ;; Lorem ipsum
>> (defun lorem-ipsum ()
>> "Lorem ipsum."
>> (message "Lorem ipsum."))
>> --8<---------------cut here---------------end--------------->8---
>>
>> How do I place point so that `mark-defun' would mark `lorem-ipsum'
>> together with the comment before?
>
> I'm sorry, I no longer remember. It's hard to communicate when days
> pass between messages.
I'm really sorry, but for me the asynchronicity of email and the
possibility of responding after a few days/weeks instead of a few
minutes is one of the main advantages of email as such (as opposed to
"tools" like Facebook, which I consider more of "toys", also because of
the difficulty to spread the conversation to weeks). I can only spend
that much time on Emacs bugs each day - similarly with other things -
and I often respond after long time (especially if the response needs
some time/effort to compose).
I'm not sure what to do next with this bug. I tried with the
abovementioned short Elisp file and failed. Since no-one said that the
current behavior is wrong, maybe I'll try to study the code of
`mark-defun' and modify the docstring/manual accordingly.
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sat, 07 May 2016 05:08:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 21072 <at> debbugs.gnu.org (full text, mbox):
I agree that the behavior is not particularly consistent, and it
does not completely correspond to the doc. What the best fix is,
I don't know.
It's been this way for a long time, so there might be people
who expect or like it to do what it does, in which case the
doc should probably be fixed somewhat.
On the other hand, I'd bet that few, if any, would complain if
better behavior were implemented.
In any case, the behavior of being able to repeat to keep selecting
more defuns further down should be kept.
I'd suggest that Someone (TM) (Marcin?) implement a better
behavior and propose it to emacs-devel. ;-)
What might be better?
1. At least consistency wrt which defun gets selected, when
betweeen defuns. The doc suggests a general rule (the next
defun), but that is not always respected.
2. Something consistent also wrt a comment before the defun
that will be selected.
3. It could be good for a numeric prefix arg to select that
many defuns.
4. It could be good for a negative prefix arg to select in
the opposite direction. This is the main improvement I'd
like to see. E.g. `M-- C-M-h' selects the previous defun;
`M-2 C-M-h' selects the two previous defuns.
Someone should play around and dream up something useful.
Wrt #2, I'm not sure what the best approach might be.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sat, 07 May 2016 06:48:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> mbork.pl>
> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
> Date: Sat, 07 May 2016 05:47:18 +0200
>
> I'm not sure what to do next with this bug. I tried with the
> abovementioned short Elisp file and failed. Since no-one said that the
> current behavior is wrong, maybe I'll try to study the code of
> `mark-defun' and modify the docstring/manual accordingly.
I'd suggest to change the doc string according to what I recommended a
few messages ago. I think that would be good enough.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 05 Jun 2016 06:31:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-07, at 08:47, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> mbork.pl>
>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>> Date: Sat, 07 May 2016 05:47:18 +0200
>>
>> I'm not sure what to do next with this bug. I tried with the
>> abovementioned short Elisp file and failed. Since no-one said that the
>> current behavior is wrong, maybe I'll try to study the code of
>> `mark-defun' and modify the docstring/manual accordingly.
>
> I'd suggest to change the doc string according to what I recommended a
> few messages ago. I think that would be good enough.
Hi Eli, hi all,
and sorry for replying after such a long time (again) - I'm afraid
I cannot help this, my time has become extremely limited recently.
I studied the code of mark-defun, and it seems that the reason for
#21072 is quite simple. I enclose a patch where the two (seemingly)
offending lines are commented; if this is acceptable, of course I'll
prepare a proper patch. (And while at that, I'll propose replacing
`(and transient-mark-mode mark-active)' with `(use-region-p)'.)
The problem is, I'm not sure whether this change won't break anything.
The only tests I found that deal with `mark-defun' are in
python-tests.el, and my version passes all three of them.
> Thanks.
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 05 Jun 2016 07:02:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 21072 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
And a forgotten attachment.
On 2016-06-05, at 08:30, Marcin Borkowski <mbork <at> mbork.pl> wrote:
> On 2016-05-07, at 08:47, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Marcin Borkowski <mbork <at> mbork.pl>
>>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>>> Date: Sat, 07 May 2016 05:47:18 +0200
>>>
>>> I'm not sure what to do next with this bug. I tried with the
>>> abovementioned short Elisp file and failed. Since no-one said that the
>>> current behavior is wrong, maybe I'll try to study the code of
>>> `mark-defun' and modify the docstring/manual accordingly.
>>
>> I'd suggest to change the doc string according to what I recommended a
>> few messages ago. I think that would be good enough.
>
> Hi Eli, hi all,
>
> and sorry for replying after such a long time (again) - I'm afraid
> I cannot help this, my time has become extremely limited recently.
>
> I studied the code of mark-defun, and it seems that the reason for
> #21072 is quite simple. I enclose a patch where the two (seemingly)
> offending lines are commented; if this is acceptable, of course I'll
> prepare a proper patch. (And while at that, I'll propose replacing
> `(and transient-mark-mode mark-active)' with `(use-region-p)'.)
>
> The problem is, I'm not sure whether this change won't break anything.
> The only tests I found that deal with `mark-defun' are in
> python-tests.el, and my version passes all three of them.
>
>> Thanks.
>
> Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
[0001-Fix-bug-21072.patch (text/x-diff, inline)]
From e717c6e8a1a0645baa8ea1a3dc965bac9fe9b540 Mon Sep 17 00:00:00 2001
From: Marcin Borkowski <mbork <at> mbork.pl>
Date: Sun, 5 Jun 2016 08:25:36 +0200
Subject: [PATCH] Fix bug#21072
---
lisp/emacs-lisp/lisp.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lisp/emacs-lisp/lisp.el b/lisp/emacs-lisp/lisp.el
index ea7cce6..4b98b80 100644
--- a/lisp/emacs-lisp/lisp.el
+++ b/lisp/emacs-lisp/lisp.el
@@ -505,8 +505,9 @@ mark-defun
(setq beg (point))
(end-of-defun)
(setq end (point))
- (while (looking-at "^\n")
- (forward-line 1))
+ ;; The two lines below seemingly caused bug#21072.
+ ;; (while (looking-at "^\n")
+ ;; (forward-line 1))
(if (> (point) opoint)
(progn
;; We got the right defun.
--
2.8.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 09 Jun 2016 11:57:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Hi everyone,
it's me again.
I looked at the tests of `mark-defun' for Python, and they did shed some
light on the weird implementation. In short, `mark-defun' first jumps
to the beginning and the to the end of the current defun, checks whether
the point is now before or after the initial position, and if before,
back up and jump to the end first and to the beginning next. This might
actually happen, since e.g. in Python, when point is on a "def"
beginning a function definition, `beginning-of-defun' goes to the start
of the _preceding_ defun. In fact, I think this is a bug in
beginning-of-defun (or more precisely, its Python version), and
consequently I think the weird code in `mark-defun' is a workaround for
a deeper bug.
I can now do one of a few things. (Not ATM, I'll have to take my time.)
1. Fix the docs so that #21072 is no longer a bug (i.e., change the docs
so that there's no discrepancy between them and code).
2a. Just fix the problem reported in #21072, hoping that it doesn't break
anything else.
2b. Write a few tests for `mark-defun',_then_ fix the problem, and check
whether these tests pass. Of course, all these tests would be for Elisp
(and maybe for C and/or JavaScript).
3. Try to come up with a better `mark-defun', still given the
limitations of `beginning-of-defun', e.g., make `mark-defun' use the
numeric prefix argument in a reasonable way (i.e., what Drew proposed).
4. Report a bug in `beginning-of-defun', and hope someone (probably not
me, I do not know enough about ppss now and do not have time to learn
that now), and then write a simpler `mark-defun' from scratch.
WDYT?
Best,
Marcin
On 2016-06-05, at 08:30, Marcin Borkowski <mbork <at> mbork.pl> wrote:
> On 2016-05-07, at 08:47, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Marcin Borkowski <mbork <at> mbork.pl>
>>> Cc: rfflrccrd <at> gmail.com, 21072 <at> debbugs.gnu.org
>>> Date: Sat, 07 May 2016 05:47:18 +0200
>>>
>>> I'm not sure what to do next with this bug. I tried with the
>>> abovementioned short Elisp file and failed. Since no-one said that the
>>> current behavior is wrong, maybe I'll try to study the code of
>>> `mark-defun' and modify the docstring/manual accordingly.
>>
>> I'd suggest to change the doc string according to what I recommended a
>> few messages ago. I think that would be good enough.
>
> Hi Eli, hi all,
>
> and sorry for replying after such a long time (again) - I'm afraid
> I cannot help this, my time has become extremely limited recently.
>
> I studied the code of mark-defun, and it seems that the reason for
> #21072 is quite simple. I enclose a patch where the two (seemingly)
> offending lines are commented; if this is acceptable, of course I'll
> prepare a proper patch. (And while at that, I'll propose replacing
> `(and transient-mark-mode mark-active)' with `(use-region-p)'.)
>
> The problem is, I'm not sure whether this change won't break anything.
> The only tests I found that deal with `mark-defun' are in
> python-tests.el, and my version passes all three of them.
>
>> Thanks.
>
> Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 21 Jun 2016 08:00:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-06-09, at 13:56, Marcin Borkowski <mbork <at> mbork.pl> wrote:
> 2b. Write a few tests for `mark-defun',_then_ fix the problem, and check
> whether these tests pass. Of course, all these tests would be for Elisp
> (and maybe for C and/or JavaScript).
Hi all,
it seems nobody cared enough to answer my question, so I made the choice
of doing the Right Thing™, and started from developing some tests for
mark-defun. Here's what I've got now.
--8<---------------cut here---------------start------------->8---
;;; elisp-mode-tests.el --- Tests for emacs-lisp-mode -*- lexical-binding: t; -*-
;; Copyright (C) 2015-2016 Free Software Foundation, Inc.
;; Author: Marcin Borkowski <mbork <at> mbork.pl>
;; Author: Dmitry Gutov <dgutov <at> yandex.ru>
;; Author: Stephen Leake <stephen_leake <at> member.fsf.org>
;; This file is part of GNU Emacs.
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
;;; Code:
(require 'ert)
;;; Helpers
;; Copied and modified from `python-tests-with-temp-buffer'
(defmacro elisp-tests-with-temp-buffer (contents &rest body)
"Create a `emacs-lisp-mode' enabled temp buffer with CONTENTS.
BODY is code to be executed within the temp buffer. Point is
always located at the beginning of buffer."
(declare (indent 1) (debug t))
`(with-temp-buffer
(emacs-lisp-mode)
(insert ,contents)
(goto-char (point-min))
,@body))
(defmacro conditional-save-excursion (arg &rest body)
"Wrap BODY in `save-excursion', but only if ARG is non-nil."
(declare (indent 1) (debug t))
`(if ,arg
(save-excursion ,@body)
,@body))
(defun look-at (string &optional count restore-point)
"Move the point to the beginning of STRING in current buffer.
Return the new point value. If COUNT is non-nil, move to COUNTth
occurrence. If RESTORE-POINT is non-nil, return the found
position, but do not move point."
(conditional-save-excursion restore-point
(setq count (or count 1))
(when (search-forward string nil t count)
(goto-char (match-beginning 0)))
(point)))
;;; Mark
(ert-deftest mark-defun-1 ()
"Test `mark-defun' with point inside the defun."
(elisp-tests-with-temp-buffer
"
\(defun func-a ()
\"A parameterless function.\"
(ignore))
;; A comment right before a defun.
\(defun func-b (argument)
\"A function with one ARGUMENT.\"
(ignore argument)
(message \"%s\" \"Argument ignored.\"))
\(defmacro macro-a (&rest body)
\"A macro with BODY.\"
`(,@body))
"
(let ((expected-mark-beginning-position-1-2
(progn
(look-at "(defun func-a ")
(previous-line 1)
(point)))
(expected-mark-end-position-1
(save-excursion
(look-at "(ignore))")
(next-line 1)
(point)))
(expected-mark-end-position-2
(save-excursion
(point)
(look-at "\"))")
(next-line 1)
(point)))
(expected-mark-beginning-position-3
(progn
(look-at "(defmacro macro-a ")
(previous-line 1)
(point)))
(expected-mark-end-position-3
(progn
(look-at "(,@body)")
(next-line 1)
(point))))
;; select the first defun
(goto-char (point-min))
(look-at "A parameterless function.")
(mark-defun)
(should (= (point) expected-mark-beginning-position-1-2))
(should (= (marker-position (mark-marker))
expected-mark-end-position-1))
;; expand to the second defun
(mark-defun 1)
(should (= (point) expected-mark-beginning-position-1-2))
(should (= (marker-position (mark-marker))
expected-mark-end-position-2))
;; select the macro
(look-at "A macro")
(mark-defun)
(should (= (point) expected-mark-beginning-position-3))
(should (= (marker-position (mark-marker))
expected-mark-end-position-3)))))
(ert-deftest mark-defun-2 ()
"Test `mark-defun' with point between defuns."
(elisp-tests-with-temp-buffer
"
\(defun func-a ()
\"A parameterless function.\"
(ignore))
;; A comment right before a defun.
\(defun func-b (argument)
\"A function with one ARGUMENT.\"
(ignore argument)
(message \"%s\" \"Argument ignored.\"))
\(defmacro macro-a (&rest body)
\"A macro with BODY.\"
`(,@body))
"
(let ((expected-mark-beginning-position-1
(progn
(look-at "(defun func-b ")
(point)))
(expected-mark-end-position-1
(save-excursion
(look-at "ignored.\"))")
(next-line 1)
(point))))
;; select the first defun
(goto-char expected-mark-end-position-1)
(previous-line 1)
(mark-defun)
(should (= (point) expected-mark-beginning-position-1))
(should (= (marker-position (mark-marker))
expected-mark-end-position-1)))))
(provide 'elisp-mode-tests)
;;; elisp-mode-tests.el ends here
--8<---------------cut here---------------end--------------->8---
These two tests pass now. The next thing would be to change them to
what /should/ pass. Before that, though, let me ask: what are your
opinion on these simple tests? Are they enough? Would you add
something?
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 21 Jun 2016 09:02:02 GMT)
Full text and
rfc822 format available.
Message #59 received at submit <at> debbugs.gnu.org (full text, mbox):
On 21.06.2016 09:58, Marcin Borkowski wrote:
> On 2016-06-09, at 13:56, Marcin Borkowski <mbork <at> mbork.pl> wrote:
>
>> 2b. Write a few tests for `mark-defun',_then_ fix the problem, and check
>> whether these tests pass. Of course, all these tests would be for Elisp
>> (and maybe for C and/or JavaScript).
> Hi all,
>
> it seems nobody cared enough to answer my question, so I made the choice
> of doing the Right Thing™, and started from developing some tests for
> mark-defun. Here's what I've got now.
>
> --8<---------------cut here---------------start------------->8---
> ;;; elisp-mode-tests.el --- Tests for emacs-lisp-mode -*- lexical-binding: t; -*-
>
> ;; Copyright (C) 2015-2016 Free Software Foundation, Inc.
>
> ;; Author: Marcin Borkowski <mbork <at> mbork.pl>
> ;; Author: Dmitry Gutov <dgutov <at> yandex.ru>
> ;; Author: Stephen Leake <stephen_leake <at> member.fsf.org>
>
> ;; This file is part of GNU Emacs.
>
> ;; GNU Emacs is free software: you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published by
> ;; the Free Software Foundation, either version 3 of the License, or
> ;; (at your option) any later version.
>
> ;; GNU Emacs is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ;; GNU General Public License for more details.
>
> ;; You should have received a copy of the GNU General Public License
> ;; along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
>
> ;;; Code:
>
> (require 'ert)
>
>
> ;;; Helpers
>
> ;; Copied and modified from `python-tests-with-temp-buffer'
> (defmacro elisp-tests-with-temp-buffer (contents &rest body)
> "Create a `emacs-lisp-mode' enabled temp buffer with CONTENTS.
> BODY is code to be executed within the temp buffer. Point is
> always located at the beginning of buffer."
> (declare (indent 1) (debug t))
> `(with-temp-buffer
> (emacs-lisp-mode)
> (insert ,contents)
> (goto-char (point-min))
> ,@body))
>
> (defmacro conditional-save-excursion (arg &rest body)
> "Wrap BODY in `save-excursion', but only if ARG is non-nil."
> (declare (indent 1) (debug t))
> `(if ,arg
> (save-excursion ,@body)
> ,@body))
>
> (defun look-at (string &optional count restore-point)
> "Move the point to the beginning of STRING in current buffer.
> Return the new point value. If COUNT is non-nil, move to COUNTth
> occurrence. If RESTORE-POINT is non-nil, return the found
> position, but do not move point."
> (conditional-save-excursion restore-point
> (setq count (or count 1))
> (when (search-forward string nil t count)
> (goto-char (match-beginning 0)))
> (point)))
>
>
> ;;; Mark
>
> (ert-deftest mark-defun-1 ()
> "Test `mark-defun' with point inside the defun."
> (elisp-tests-with-temp-buffer
> "
> \(defun func-a ()
> \"A parameterless function.\"
> (ignore))
>
> ;; A comment right before a defun.
> \(defun func-b (argument)
> \"A function with one ARGUMENT.\"
> (ignore argument)
> (message \"%s\" \"Argument ignored.\"))
>
> \(defmacro macro-a (&rest body)
> \"A macro with BODY.\"
> `(,@body))
> "
> (let ((expected-mark-beginning-position-1-2
> (progn
> (look-at "(defun func-a ")
> (previous-line 1)
> (point)))
> (expected-mark-end-position-1
> (save-excursion
> (look-at "(ignore))")
> (next-line 1)
> (point)))
> (expected-mark-end-position-2
> (save-excursion
> (point)
> (look-at "\"))")
> (next-line 1)
> (point)))
> (expected-mark-beginning-position-3
> (progn
> (look-at "(defmacro macro-a ")
> (previous-line 1)
> (point)))
> (expected-mark-end-position-3
> (progn
> (look-at "(,@body)")
> (next-line 1)
> (point))))
> ;; select the first defun
> (goto-char (point-min))
> (look-at "A parameterless function.")
> (mark-defun)
> (should (= (point) expected-mark-beginning-position-1-2))
> (should (= (marker-position (mark-marker))
> expected-mark-end-position-1))
> ;; expand to the second defun
> (mark-defun 1)
> (should (= (point) expected-mark-beginning-position-1-2))
> (should (= (marker-position (mark-marker))
> expected-mark-end-position-2))
> ;; select the macro
> (look-at "A macro")
> (mark-defun)
> (should (= (point) expected-mark-beginning-position-3))
> (should (= (marker-position (mark-marker))
> expected-mark-end-position-3)))))
>
> (ert-deftest mark-defun-2 ()
> "Test `mark-defun' with point between defuns."
> (elisp-tests-with-temp-buffer
> "
> \(defun func-a ()
> \"A parameterless function.\"
> (ignore))
>
> ;; A comment right before a defun.
> \(defun func-b (argument)
> \"A function with one ARGUMENT.\"
> (ignore argument)
> (message \"%s\" \"Argument ignored.\"))
>
> \(defmacro macro-a (&rest body)
> \"A macro with BODY.\"
> `(,@body))
> "
> (let ((expected-mark-beginning-position-1
> (progn
> (look-at "(defun func-b ")
> (point)))
> (expected-mark-end-position-1
> (save-excursion
> (look-at "ignored.\"))")
> (next-line 1)
> (point))))
> ;; select the first defun
> (goto-char expected-mark-end-position-1)
> (previous-line 1)
> (mark-defun)
> (should (= (point) expected-mark-beginning-position-1))
> (should (= (marker-position (mark-marker))
> expected-mark-end-position-1)))))
>
> (provide 'elisp-mode-tests)
> ;;; elisp-mode-tests.el ends here
> --8<---------------cut here---------------end--------------->8---
>
> These two tests pass now. The next thing would be to change them to
> what /should/ pass. Before that, though, let me ask: what are your
> opinion on these simple tests? Are they enough? Would you add
> something?
>
> Best,
>
Hi Marcin,
should no one else respond for now: please come back after release.
AFAIU the current implemention of beginning-of-defun prevents a
consistent setup of related commands. A change here would include resp.
require a major change...
Don't give up :)
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 21 Jun 2016 10:08:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-06-21, at 11:05, Andreas Röhler <andreas.roehler <at> easy-emacs.de> wrote:
> On 21.06.2016 09:58, Marcin Borkowski wrote:
>> On 2016-06-09, at 13:56, Marcin Borkowski <mbork <at> mbork.pl> wrote:
>>
>>> 2b. Write a few tests for `mark-defun',_then_ fix the problem, and check
>>> whether these tests pass. Of course, all these tests would be for Elisp
>>> (and maybe for C and/or JavaScript).
>> Hi all,
>>
>> it seems nobody cared enough to answer my question, so I made the choice
>> of doing the Right Thing™, and started from developing some tests for
>> mark-defun. Here's what I've got now.
>>
>> --8<---------------cut here---------------start------------->8---
>> ;;; elisp-mode-tests.el --- Tests for emacs-lisp-mode -*- lexical-binding: t; -*-
>>
>> ;; Copyright (C) 2015-2016 Free Software Foundation, Inc.
>>
>> ;; Author: Marcin Borkowski <mbork <at> mbork.pl>
>> ;; Author: Dmitry Gutov <dgutov <at> yandex.ru>
>> ;; Author: Stephen Leake <stephen_leake <at> member.fsf.org>
>>
>> ;; This file is part of GNU Emacs.
>>
>> ;; GNU Emacs is free software: you can redistribute it and/or modify
>> ;; it under the terms of the GNU General Public License as published by
>> ;; the Free Software Foundation, either version 3 of the License, or
>> ;; (at your option) any later version.
>>
>> ;; GNU Emacs is distributed in the hope that it will be useful,
>> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
>> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> ;; GNU General Public License for more details.
>>
>> ;; You should have received a copy of the GNU General Public License
>> ;; along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
>>
>> ;;; Code:
>>
>> (require 'ert)
>>
>>
>> ;;; Helpers
>>
>> ;; Copied and modified from `python-tests-with-temp-buffer'
>> (defmacro elisp-tests-with-temp-buffer (contents &rest body)
>> "Create a `emacs-lisp-mode' enabled temp buffer with CONTENTS.
>> BODY is code to be executed within the temp buffer. Point is
>> always located at the beginning of buffer."
>> (declare (indent 1) (debug t))
>> `(with-temp-buffer
>> (emacs-lisp-mode)
>> (insert ,contents)
>> (goto-char (point-min))
>> ,@body))
>>
>> (defmacro conditional-save-excursion (arg &rest body)
>> "Wrap BODY in `save-excursion', but only if ARG is non-nil."
>> (declare (indent 1) (debug t))
>> `(if ,arg
>> (save-excursion ,@body)
>> ,@body))
>>
>> (defun look-at (string &optional count restore-point)
>> "Move the point to the beginning of STRING in current buffer.
>> Return the new point value. If COUNT is non-nil, move to COUNTth
>> occurrence. If RESTORE-POINT is non-nil, return the found
>> position, but do not move point."
>> (conditional-save-excursion restore-point
>> (setq count (or count 1))
>> (when (search-forward string nil t count)
>> (goto-char (match-beginning 0)))
>> (point)))
>>
>>
>> ;;; Mark
>>
>> (ert-deftest mark-defun-1 ()
>> "Test `mark-defun' with point inside the defun."
>> (elisp-tests-with-temp-buffer
>> "
>> \(defun func-a ()
>> \"A parameterless function.\"
>> (ignore))
>>
>> ;; A comment right before a defun.
>> \(defun func-b (argument)
>> \"A function with one ARGUMENT.\"
>> (ignore argument)
>> (message \"%s\" \"Argument ignored.\"))
>>
>> \(defmacro macro-a (&rest body)
>> \"A macro with BODY.\"
>> `(,@body))
>> "
>> (let ((expected-mark-beginning-position-1-2
>> (progn
>> (look-at "(defun func-a ")
>> (previous-line 1)
>> (point)))
>> (expected-mark-end-position-1
>> (save-excursion
>> (look-at "(ignore))")
>> (next-line 1)
>> (point)))
>> (expected-mark-end-position-2
>> (save-excursion
>> (point)
>> (look-at "\"))")
>> (next-line 1)
>> (point)))
>> (expected-mark-beginning-position-3
>> (progn
>> (look-at "(defmacro macro-a ")
>> (previous-line 1)
>> (point)))
>> (expected-mark-end-position-3
>> (progn
>> (look-at "(,@body)")
>> (next-line 1)
>> (point))))
>> ;; select the first defun
>> (goto-char (point-min))
>> (look-at "A parameterless function.")
>> (mark-defun)
>> (should (= (point) expected-mark-beginning-position-1-2))
>> (should (= (marker-position (mark-marker))
>> expected-mark-end-position-1))
>> ;; expand to the second defun
>> (mark-defun 1)
>> (should (= (point) expected-mark-beginning-position-1-2))
>> (should (= (marker-position (mark-marker))
>> expected-mark-end-position-2))
>> ;; select the macro
>> (look-at "A macro")
>> (mark-defun)
>> (should (= (point) expected-mark-beginning-position-3))
>> (should (= (marker-position (mark-marker))
>> expected-mark-end-position-3)))))
>>
>> (ert-deftest mark-defun-2 ()
>> "Test `mark-defun' with point between defuns."
>> (elisp-tests-with-temp-buffer
>> "
>> \(defun func-a ()
>> \"A parameterless function.\"
>> (ignore))
>>
>> ;; A comment right before a defun.
>> \(defun func-b (argument)
>> \"A function with one ARGUMENT.\"
>> (ignore argument)
>> (message \"%s\" \"Argument ignored.\"))
>>
>> \(defmacro macro-a (&rest body)
>> \"A macro with BODY.\"
>> `(,@body))
>> "
>> (let ((expected-mark-beginning-position-1
>> (progn
>> (look-at "(defun func-b ")
>> (point)))
>> (expected-mark-end-position-1
>> (save-excursion
>> (look-at "ignored.\"))")
>> (next-line 1)
>> (point))))
>> ;; select the first defun
>> (goto-char expected-mark-end-position-1)
>> (previous-line 1)
>> (mark-defun)
>> (should (= (point) expected-mark-beginning-position-1))
>> (should (= (marker-position (mark-marker))
>> expected-mark-end-position-1)))))
>>
>> (provide 'elisp-mode-tests)
>> ;;; elisp-mode-tests.el ends here
>> --8<---------------cut here---------------end--------------->8---
>>
>> These two tests pass now. The next thing would be to change them to
>> what /should/ pass. Before that, though, let me ask: what are your
>> opinion on these simple tests? Are they enough? Would you add
>> something?
>>
>> Best,
>>
>
> Hi Marcin,
>
> should no one else respond for now: please come back after release.
> AFAIU the current implemention of beginning-of-defun prevents a
> consistent setup of related commands. A change here would include resp.
> require a major change...
OK, I see.
> Don't give up :)
I don't, I'm patient - I'm also working very slowly on this...
> Andreas
Thanks, best
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 11 Oct 2016 12:32:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-05-07, at 07:07, Drew Adams <drew.adams <at> oracle.com> wrote:
> I agree that the behavior is not particularly consistent, and it
> does not completely correspond to the doc. What the best fix is,
> I don't know.
>
> It's been this way for a long time, so there might be people
> who expect or like it to do what it does, in which case the
> doc should probably be fixed somewhat.
>
> On the other hand, I'd bet that few, if any, would complain if
> better behavior were implemented.
>
> In any case, the behavior of being able to repeat to keep selecting
> more defuns further down should be kept.
>
> I'd suggest that Someone (TM) (Marcin?) implement a better
> behavior and propose it to emacs-devel. ;-)
>
> What might be better?
>
> 1. At least consistency wrt which defun gets selected, when
> betweeen defuns. The doc suggests a general rule (the next
> defun), but that is not always respected.
>
> 2. Something consistent also wrt a comment before the defun
> that will be selected.
>
> 3. It could be good for a numeric prefix arg to select that
> many defuns.
>
> 4. It could be good for a negative prefix arg to select in
> the opposite direction. This is the main improvement I'd
> like to see. E.g. `M-- C-M-h' selects the previous defun;
> `M-2 C-M-h' selects the two previous defuns.
>
> Someone should play around and dream up something useful.
>
> Wrt #2, I'm not sure what the best approach might be.
Hi all,
it's been some time, and I implemented a better (?) behavior indeed.
(Yes, I know a few months passed. But I don't have a lot of time to
work on Emacs bugs now. This bug took me almost 8 hours over the past
few months.)
Basically, I took into consideration all the points Drew mentioned. I'd
like to submit my work for review. I have one technical problem,
though: I have it as a series of commits on a separate branch in my
repo, and I'm not Git-literate enough to make one patch from them.
Should I submit a series of patches? Should I rebase my commits into
one big one? (No big deal, this might be a good idea anyway.)
In the course of my work, I have also implemented a macro to help write
tests for the new behavior (there are 6 ERT tests, with 40 assertions
total). Here it is (for review):
--8<---------------cut here---------------start------------->8---
(defvar elisp-test-point-marker-regex "=!\\([a-zA-Z0-9-]+\\)="
"A regexp matching placeholders for point position for
`elisp-tests-with-temp-buffer'.")
;; Copied and heavily modified from `python-tests-with-temp-buffer'
(defmacro elisp-tests-with-temp-buffer (contents &rest body)
"Create a `emacs-lisp-mode' enabled temp buffer with CONTENTS.
BODY is code to be executed within the temp buffer. Point is
always located at the beginning of buffer. Special markers of
the form =!NAME= in CONTENTS are removed, and a for each one
a variable called NAME is bound to the position of such
a marker."
(declare (indent 1) (debug t))
`(with-temp-buffer
(emacs-lisp-mode)
(insert ,contents)
(goto-char (point-min))
(while (re-search-forward elisp-test-point-marker-regex nil t)
(delete-region (match-beginning 0)
(match-end 0)))
(goto-char (point-min))
,(let (marker-list)
(with-temp-buffer
(insert (cond ((symbolp contents)
(symbol-value contents))
(t contents)))
(goto-char (point-min))
(while (re-search-forward elisp-test-point-marker-regex nil t)
(push (list (intern (match-string-no-properties 1))
(match-beginning 0))
marker-list)
(delete-region (match-beginning 0)
(match-end 0))))
`(let ,marker-list
,@body))))
--8<---------------cut here---------------end--------------->8---
And it can be used like this:
--8<---------------cut here---------------start------------->8---
(defvar mark-defun-test-buffer
";; Comment header
=!before-1=
\(defun func-1 (arg)
=!inside-1=\"docstring\"
body)
=!after-1==!before-2=
;; Comment before a defun
\(d=!inside-2=efun func-2 (arg)
\"docstring\"
body)
=!after-2==!before-3=
\(defun func-3 (arg)
\"docstring\"=!inside-3=
body)
=!after-3==!before-4=(defun func-4 (arg)
\"docstring\"=!inside-4=
body)
=!after-4=
;; end
"
"Test buffer for `mark-defun'.")
(ert-deftest mark-defun-no-arg-region-inactive ()
"Test `mark-defun' with no prefix argument and inactive
region."
(elisp-tests-with-temp-buffer
mark-defun-test-buffer
;; mark-defun inside a defun, with comments and an empty line
;; before
(goto-char inside-1)
(mark-defun)
(should (= (point) before-1))
(should (= (mark) after-1))))
--8<---------------cut here---------------end--------------->8---
WDYT?
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 11 Oct 2016 15:31:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> Basically, I took into consideration all the points Drew mentioned. I'd
> like to submit my work for review.
Thanks for working on this, Marcin.
> I have one technical problem,
> though: I have it as a series of commits on a separate branch in my
> repo, and I'm not Git-literate enough to make one patch from them.
Hopefully someone else can help with that.
(For my part, if the code needed is small and you just include it here
then I will give it a try and let you know what I think (FWIW).)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 11 Oct 2016 17:08:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-10-11, at 17:30, Drew Adams <drew.adams <at> oracle.com> wrote:
>> Basically, I took into consideration all the points Drew mentioned. I'd
>> like to submit my work for review.
>
> Thanks for working on this, Marcin.
You're welcome.
BTW, as I probably already mentioned, while working on this, I found
a bug in end-of-defun, and until it's fixed, I have to use a silly
workaround.
>> I have one technical problem,
>> though: I have it as a series of commits on a separate branch in my
>> repo, and I'm not Git-literate enough to make one patch from them.
>
> Hopefully someone else can help with that.
I'd hope so!
> (For my part, if the code needed is small and you just include it here
> then I will give it a try and let you know what I think (FWIW).)
Here's the code (sans tests):
--8<---------------cut here---------------start------------->8---
(defun in-comment-line-p ()
"Return non-nil if the point is in a comment line.
See http://lists.gnu.org/archive/html/help-gnu-emacs/2016-08/msg00141.html"
(save-excursion
(forward-line 0)
(unless (looking-at "^\\s-*$")
(< (line-end-position)
(let ((ppss (syntax-ppss)))
(when (nth 4 ppss)
(goto-char (nth 8 ppss)))
(forward-comment (point-max))
(point))))))
(defun beginning-of-defun-comments (&optional arg)
"Move to the beginning of ARGth defun, including comments."
(interactive "^p")
(unless arg (setq arg 1))
(beginning-of-defun arg)
(unless (bobp)
(while (progn
(forward-line -1)
(in-comment-line-p)))
(forward-line 1)))
(defun mark-defun (&optional arg)
"Put mark at end of this defun, point at beginning.
The defun marked is the one that contains point or follows point.
With positive ARG, mark this and that many next defuns.
If (in Transient Mark mode) the mark is active, it marks the next
defun after the one(s) already marked. With positive ARG, mark
that many more defuns. With negative ARG, mark that many more
previous defuns."
(interactive "p")
(setq arg (or arg 1))
(cond ((use-region-p)
(if (>= arg 0)
(set-mark
(save-excursion
(goto-char (mark))
;; change the dotimes below to (end-of-defun arg) once bug #24427 is fixed
(dotimes (_ignore arg)
(end-of-defun))
(point)))
(beginning-of-defun-comments (- arg))))
(t
(let ((opoint (point))
beg end)
(push-mark opoint)
;; Try first in this order for the sake of languages with nested
;; functions where several can end at the same place as with the
;; offside rule, e.g. Python.
(beginning-of-defun-comments)
(setq beg (point))
(end-of-defun)
(setq end (point))
(when (and (<= (point) opoint)
(> arg 0))
;; beginning-of-defun moved back one defun so we got the wrong
;; one. If ARG < 0, however, we actually want to go back.
(goto-char opoint)
(end-of-defun)
(setq end (point))
(beginning-of-defun-comments)
(setq beg (point)))
(goto-char beg)
(cond ((> arg 0)
;; change the dotimes below to (end-of-defun arg) once bug #24427 is fixed
(dotimes (_ignore arg)
(end-of-defun))
(setq end (point))
(push-mark end nil t)
(goto-char beg))
(t
(goto-char beg)
(beginning-of-defun (1- (- arg)))
(push-mark end nil t))))))
(while (progn
(forward-line -1)
(looking-at "^\\s-*$")))
(forward-line 1))
--8<---------------cut here---------------end--------------->8---
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 11 Oct 2016 17:53:01 GMT)
Full text and
rfc822 format available.
Message #74 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2016-10-11 13:07, Marcin Borkowski wrote:
>>> >> I have one technical problem,
>>> >> though: I have it as a series of commits on a separate branch in my
>>> >> repo, and I'm not Git-literate enough to make one patch from them.
>> >
>> > Hopefully someone else can help with that.
> I'd hope so!
Would http://stackoverflow.com/questions/616556/how-do-you-squash-commits-into-one-patch-with-git-format-patch help? The top answer is the one I'd recommend.
Cheers,
Clément.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 11 Oct 2016 20:28:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 21072 <at> debbugs.gnu.org (full text, mbox):
BTW, IMO this should be removed: "(in Transient Mark Mode)". (This is
not really related to this bug, however.)
Unless transient-mark-mode is enabled there is not even any notion of
the mark being "active". That notion is valid only for t-m-m. It
makes no sense to speak of an active mark or region, otherwise.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 11 Oct 2016 21:16:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 21072 <at> debbugs.gnu.org (full text, mbox):
1. Respect of the optional arg even for non-interactive use is an
improvement, I think.
2. And it seems that no code distributed with Emacs calls `mark-defun'
with the optional arg. So no problem there. And it is unlikely
that 3rd-party code would call with the arg and expect it to be
ignored (as was the case before).
3. With this at the top of *scratch* (note the blank line at top)
and point between the comment and the defun, each of `M-- C-M-h'
and `C-M-h' seems to loop indefinitely.
-------------8<----------------
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
(defun a ()
nil)
-------------8<----------------
4. And with the same thing, but without the blank line at the top,
both `M-- C-M-h' and `C-M-h' select the defun plus the comment,
except that they do not select the first comment line. Intended?
5. `M-- C-M-h' and `C-M-h' always seem to select blank lines before
the defun. Should they (what for)?
6. Interactively, I would rather see repeated use of `C-M-h', after an
initial use of `C-M-h' with a negative prefix arg (e.g. `M-- C-M-h'),
continue to select defuns backward. IOW, not need to use `M--'
explicitly for each `C-M-h'.
You can just hold down `C-M-h', to select multiple defuns forward.
I would like to be able to do the same thing, but backward, by
using `M-- C-M-h C-M-h C-M-h C-M-h...' (just hold down the chord).
If you do that, then a negative prefix arg should not mean backward;
it should just mean change direction (backward if previous command
was not `mark-defun').
7. Someone will really need to test this with more than just Emacs Lisp.
The comments talk about Python and nesting, etc.
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 28 Oct 2016 05:35:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-10-11, at 23:15, Drew Adams <drew.adams <at> oracle.com> wrote:
> 1. Respect of the optional arg even for non-interactive use is an
> improvement, I think.
Thanks.
> 2. And it seems that no code distributed with Emacs calls `mark-defun'
> with the optional arg. So no problem there. And it is unlikely
> that 3rd-party code would call with the arg and expect it to be
> ignored (as was the case before).
I would guess so.
> 3. With this at the top of *scratch* (note the blank line at top)
> and point between the comment and the defun, each of `M-- C-M-h'
> and `C-M-h' seems to loop indefinitely.
>
> -------------8<----------------
>
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
>
> (defun a ()
> nil)
> -------------8<----------------
I'll investigate it, thanks for the report.
> 4. And with the same thing, but without the blank line at the top,
> both `M-- C-M-h' and `C-M-h' select the defun plus the comment,
> except that they do not select the first comment line. Intended?
No, see above.
> 5. `M-- C-M-h' and `C-M-h' always seem to select blank lines before
> the defun. Should they (what for)?
I'm pretty sure that they should select blank lines either before or
after the defun. I just chose the "before" way.
> 6. Interactively, I would rather see repeated use of `C-M-h', after an
> initial use of `C-M-h' with a negative prefix arg (e.g. `M-- C-M-h'),
> continue to select defuns backward. IOW, not need to use `M--'
> explicitly for each `C-M-h'.
>
> You can just hold down `C-M-h', to select multiple defuns forward.
> I would like to be able to do the same thing, but backward, by
> using `M-- C-M-h C-M-h C-M-h C-M-h...' (just hold down the chord).
>
> If you do that, then a negative prefix arg should not mean backward;
> it should just mean change direction (backward if previous command
> was not `mark-defun').
That's interesting. I'd like to implement it, but this will take time
(apart from other things, I have a 10-days-old son now:-).)
> 7. Someone will really need to test this with more than just Emacs Lisp.
> The comments talk about Python and nesting, etc.
Definitely. I do not feel competent enough for that, though. (I'm
pretty sure I've seen some ERT stuff for testing that with Python, I'll
check it.)
> HTH.
Yes, definitely - thanks a lot!
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 28 Oct 2016 14:34:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> > 5. `M-- C-M-h' and `C-M-h' always seem to select blank lines
> > before the defun. Should they (what for)?
>
> I'm pretty sure that they should select blank lines either before or
> after the defun. I just chose the "before" way.
Yes, that is consistent with, say `mark-paragraph'.
> > 6. Interactively, I would rather see repeated use of `C-M-h',
> > after an initial use of `C-M-h' with a negative prefix arg
> > (e.g. `M-- C-M-h'), continue to select defuns backward. IOW,
> > not need to use `M--' explicitly for each `C-M-h'.
> >
> > You can just hold down `C-M-h', to select multiple defuns
> > forward. I would like to be able to do the same thing, but
> > backward, by using `M-- C-M-h C-M-h C-M-h C-M-h...' (just
> > hold down the chord).
> >
> > If you do that, then a negative prefix arg should not mean
> > backward; it should just mean change direction (backward if
> > previous command was not `mark-defun').
>
> That's interesting. I'd like to implement it, but this will take
> time (apart from other things, I have a 10-days-old son now:-).)
Thanks for considering it. And congratulations on young Borkowski!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 02 Nov 2016 07:29:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-10-11, at 23:15, Drew Adams <drew.adams <at> oracle.com> wrote:
> 3. With this at the top of *scratch* (note the blank line at top)
> and point between the comment and the defun, each of `M-- C-M-h'
> and `C-M-h' seems to loop indefinitely.
>
> -------------8<----------------
>
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
>
> (defun a ()
> nil)
> -------------8<----------------
>
> 4. And with the same thing, but without the blank line at the top,
> both `M-- C-M-h' and `C-M-h' select the defun plus the comment,
> except that they do not select the first comment line. Intended?
Well, both these behaviors are manifestations of the same bug. Below is
the corrected version. (And below that a question.)
--8<---------------cut here---------------start------------->8---
(defun mark-defun (&optional arg)
"Put mark at end of this defun, point at beginning.
The defun marked is the one that contains point or follows point.
With positive ARG, mark this and that many next defuns.
If the mark is active, it marks the next defun after the one(s)
already marked. With positive ARG, mark that many more defuns.
With negative ARG, mark that many more previous defuns."
(interactive "p")
(setq arg (or arg 1))
(cond ((use-region-p)
(if (>= arg 0)
(set-mark
(save-excursion
(goto-char (mark))
;; change the dotimes below to (end-of-defun arg) once bug #24427 is fixed
(dotimes (_ignore arg)
(end-of-defun))
(point)))
(beginning-of-defun-comments (- arg))))
(t
(let ((opoint (point))
beg end)
(push-mark opoint)
;; Try first in this order for the sake of languages with nested
;; functions where several can end at the same place as with the
;; offside rule, e.g. Python.
(beginning-of-defun-comments)
(setq beg (point))
(end-of-defun)
(setq end (point))
(when (and (<= (point) opoint)
(> arg 0))
;; beginning-of-defun moved back one defun so we got the wrong
;; one. If ARG < 0, however, we actually want to go back.
(goto-char opoint)
(end-of-defun)
(setq end (point))
(beginning-of-defun-comments)
(setq beg (point)))
(goto-char beg)
(cond ((> arg 0)
;; change the dotimes below to (end-of-defun arg) once bug #24427 is fixed
(dotimes (_ignore arg)
(end-of-defun))
(setq end (point))
(push-mark end nil t)
(goto-char beg))
(t
(goto-char beg)
(beginning-of-defun (1- (- arg)))
(push-mark end nil t))))))
(while (progn
(forward-line -1)
(and (looking-at "^\\s-*$")
(not (bobp)))))
(or (bobp) (forward-line 1)))
--8<---------------cut here---------------end--------------->8---
> 6. Interactively, I would rather see repeated use of `C-M-h', after an
> initial use of `C-M-h' with a negative prefix arg (e.g. `M-- C-M-h'),
> continue to select defuns backward. IOW, not need to use `M--'
> explicitly for each `C-M-h'.
>
> You can just hold down `C-M-h', to select multiple defuns forward.
> I would like to be able to do the same thing, but backward, by
> using `M-- C-M-h C-M-h C-M-h C-M-h...' (just hold down the chord).
>
> If you do that, then a negative prefix arg should not mean backward;
> it should just mean change direction (backward if previous command
> was not `mark-defun').
Just to be sure: you mean only the minus sign as argument, not
a negative number? I'm also wondering whether to allow that for
non-interactive use, too: I'm pretty sure nobody would want to call
(mark-defun '-) from Lisp code, and it might make testing slightly
easier.
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 02 Nov 2016 18:26:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> Well, both these behaviors are manifestations of the same bug.
> Below is the corrected version. (And below that a question.)
The test cases I mentioned work now. Thx. I didn't try anything
beyond those cases. Hopefully others will test a bit more.
> > 6. Interactively, I would rather see repeated use of `C-M-h',
> > after an initial use of `C-M-h' with a negative prefix arg
> > (e.g. `M-- C-M-h'), continue to select defuns backward.
> > IOW, not need to use `M--' explicitly for each `C-M-h'.
> >
> > You can just hold down `C-M-h', to select multiple defuns
> > forward. I would like to be able to do the same thing,
> > but backward, by using `M-- C-M-h C-M-h C-M-h C-M-h...'
> > (just hold down the chord).
> >
> > If you do that, then a negative prefix arg should not mean
> > backward; it should just mean change direction (backward if
> > previous command was not `mark-defun').
>
> Just to be sure: you mean only the minus sign as argument, not
> a negative number?
No, not really. But use your own judgment, I guess.
This is the kind of behavior I had in mind. This is for
`transpose-sexps', but it shows the behavior. _Any_ negative
arg flips the direction. At the outset, a negative arg means
move backward. The absolute value of ARG is the number of
sexps to move over.
(defun reversible-transpose-sexps (arg)
"Reversible and repeatable `transpose-sexps'.
Like `transpose-sexps', but:
1. Leaves point after the moved sexp.
2. When repeated, a negative prefix arg flips the direction."
(interactive "p")
(when (eq last-command 'rev-transp-sexps-back) (setq arg (- arg)))
(transpose-sexps arg)
(unless (natnump arg)
(backward-sexp (abs arg))
(skip-syntax-backward " .")
(setq this-command 'rev-transp-sexps-back)))
(If you happen to try this with ARG=0, be aware that what you
see is just the peculiar `transpose-sexps' behavior for ARG=0.
This is not related to the code here.)
> I'm also wondering whether to allow that for
> non-interactive use, too: I'm pretty sure nobody would want to call
> (mark-defun '-) from Lisp code, and it might make testing slightly
> easier.
I think the behavior should be the same. But see above. The
arg passed should be numeric (positive, zero, or negative), IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 04 Nov 2016 07:49:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-10-28, at 16:32, Drew Adams <drew.adams <at> oracle.com> wrote:
> Thanks for considering it. And congratulations on young Borkowski!
Thanks!
On 2016-11-02, at 19:25, Drew Adams <drew.adams <at> oracle.com> wrote:
>> Well, both these behaviors are manifestations of the same bug.
>> Below is the corrected version. (And below that a question.)
>
> The test cases I mentioned work now. Thx. I didn't try anything
> beyond those cases. Hopefully others will test a bit more.
I would hope so.
> No, not really. But use your own judgment, I guess.
I guess your version is simpler (no need to use raw prefix arg), and
hence better.
> This is the kind of behavior I had in mind. This is for
> `transpose-sexps', but it shows the behavior. _Any_ negative
> arg flips the direction. At the outset, a negative arg means
> move backward. The absolute value of ARG is the number of
> sexps to move over.
>
> (defun reversible-transpose-sexps (arg)
> "Reversible and repeatable `transpose-sexps'.
> Like `transpose-sexps', but:
> 1. Leaves point after the moved sexp.
> 2. When repeated, a negative prefix arg flips the direction."
> (interactive "p")
> (when (eq last-command 'rev-transp-sexps-back) (setq arg (- arg)))
> (transpose-sexps arg)
> (unless (natnump arg)
> (backward-sexp (abs arg))
> (skip-syntax-backward " .")
> (setq this-command 'rev-transp-sexps-back)))
Very nice trick with the 'last-command, thanks! I included this in my
code. I will also write some tests for that (it seems to work, but...)
and send the code soon.
>> I'm also wondering whether to allow that for
>> non-interactive use, too: I'm pretty sure nobody would want to call
>> (mark-defun '-) from Lisp code, and it might make testing slightly
>> easier.
>
> I think the behavior should be the same. But see above. The
> arg passed should be numeric (positive, zero, or negative), IMO.
Again - I agree, this makes coding (though not necessarily testing!)
simpler.
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 27 Nov 2016 07:41:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2016-11-04, at 08:48, Marcin Borkowski <mbork <at> mbork.pl> wrote:
> Very nice trick with the 'last-command, thanks! I included this in my
> code. I will also write some tests for that (it seems to work, but...)
> and send the code soon.
Hi Drew, hi all,
so it turned out that my code only seemed to work. (The last-command
trick was fine, but what I thought corrected the bob bug only introduced
another one.) Here's the (yet another) version. (I'm not sharing my
tests yet - I haven't yet written any tests covering the last-command
trick.) I'd be very thankful for any feedback (although I will have
even less time for Emacs bug work during the next two months - not only
my son needs considerable time and effort, the same goes for my
students;-).)
--8<---------------cut here---------------start------------->8---
(defun in-comment-line-p ()
"Return non-nil if the point is in a comment line.
See http://lists.gnu.org/archive/html/help-gnu-emacs/2016-08/msg00141.html"
(save-excursion
(forward-line 0)
(unless (looking-at "^\\s-*$")
(< (line-end-position)
(let ((ppss (syntax-ppss)))
(when (nth 4 ppss)
(goto-char (nth 8 ppss)))
(forward-comment (point-max))
(point))))))
(defun beginning-of-defun-comments (&optional arg)
"Move to the beginning of ARGth defun, including comments."
(interactive "^p")
(unless arg (setq arg 1))
(beginning-of-defun arg)
(let (nbobp)
(while (progn
(setq nbobp (zerop (forward-line -1)))
(and (in-comment-line-p)
nbobp)))
(when nbobp
(forward-line 1))))
(defun mark-defun (&optional arg)
"Put mark at end of this defun, point at beginning.
The defun marked is the one that contains point or follows point.
With positive ARG, mark this and that many next defuns; with negative
ARG, change the direction of marking.
If the mark is active, it marks the next defun after the one(s)
already marked. With positive ARG, mark that many more defuns.
With negative ARG, mark that many more previous defuns."
(interactive "p")
(setq arg (or arg 1))
;; Trick with 'mark-defun-back due to Drew Adams
(when (eq last-command 'mark-defun-back)
(setq arg (- arg)))
(when (< arg 0)
(setq this-command 'mark-defun-back))
(cond ((use-region-p)
(if (>= arg 0)
(set-mark
(save-excursion
(goto-char (mark))
;; change the dotimes below to (end-of-defun arg) once bug #24427 is fixed
(dotimes (_ignore arg)
(end-of-defun))
(point)))
(beginning-of-defun-comments (- arg))))
(t
(let ((opoint (point))
beg end)
(push-mark opoint)
;; Try first in this order for the sake of languages with nested
;; functions where several can end at the same place as with the
;; offside rule, e.g. Python.
(beginning-of-defun-comments)
(setq beg (point))
(end-of-defun)
(setq end (point))
(when (or (and (<= (point) opoint)
(> arg 0))
(= beg (point-min))) ; we were before the first defun!
;; beginning-of-defun moved back one defun so we got the wrong
;; one. If ARG < 0, however, we actually want to go back.
(goto-char opoint)
(end-of-defun)
(setq end (point))
(beginning-of-defun-comments)
(setq beg (point)))
(goto-char beg)
(cond ((> arg 0)
;; change the dotimes below to (end-of-defun arg) once bug #24427 is fixed
(dotimes (_ignore arg)
(end-of-defun))
(setq end (point))
(push-mark end nil t)
(goto-char beg))
(t
(goto-char beg)
(beginning-of-defun (1- (- arg)))
(push-mark end nil t))))))
(let (nbobp)
(while (progn
(setq nbobp (zerop (forward-line -1)))
(and (looking-at "^\\s-*$")
nbobp)))
(when nbobp
(forward-line 1))))
--8<---------------cut here---------------end--------------->8---
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 27 Nov 2016 18:52:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Again, thanks for working on this.
> (defun in-comment-line-p ()
> "Return non-nil if the point is in a comment line.
> See http://lists.gnu.org/archive/html/help-gnu-emacs/2016-
> 08/msg00141.html"
The second doc-string sentence should just be a comment in the
code, if it is needed at all.
> If the mark is active, it marks the next defun after the one(s)
> already marked. With positive ARG, mark that many more defuns.
more -> next
> ;; Trick with 'mark-defun-back due to Drew Adams
No need for the attribution. ;-)
I didn't really test, but for this:
(defun a ()
nil)
(defun b ()
nil)
;;;;
(defun c ()
nil)
With point anywhere in either of the last two defuns or
on the comment line between them, `M-- C-M-h' selects not
only the expected defun but also the last line of the
defun before it.
E.g., with point at the beginning of the comment line,
this is selected:
nil)
(defun a ()
nil)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 07 Feb 2017 06:23:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Hi Drew, hi all,
sorry for the delay - as I mentioned last time, I was going to have
a very busy semester, which now came to an end - and hence I'm back.
On 2016-11-27, at 19:51, Drew Adams <drew.adams <at> oracle.com> wrote:
> Again, thanks for working on this.
>
>> (defun in-comment-line-p ()
>> "Return non-nil if the point is in a comment line.
>> See http://lists.gnu.org/archive/html/help-gnu-emacs/2016-
>> 08/msg00141.html"
>
> The second doc-string sentence should just be a comment in the
> code, if it is needed at all.
Done, thanks.
>
>> If the mark is active, it marks the next defun after the one(s)
>> already marked. With positive ARG, mark that many more defuns.
>
> more -> next
Done, thanks.
>
>> ;; Trick with 'mark-defun-back due to Drew Adams
>
> No need for the attribution. ;-)
Why not;-)? I'll change it to a link to your message, however - this
might be actually more useful for future developers.
> I didn't really test, but for this:
>
> (defun a ()
> nil)
> (defun b ()
> nil)
> ;;;;
> (defun c ()
> nil)
>
> With point anywhere in either of the last two defuns or
> on the comment line between them, `M-- C-M-h' selects not
> only the expected defun but also the last line of the
> defun before it.
>
> E.g., with point at the beginning of the comment line,
> this is selected:
>
> nil)
> (defun a ()
> nil)
Yep, you're right. However, this seems to be a strange feature of
beginning-of-defun. Place the point at the very same place at say M-:
(beginning-of-defun 0). See?
Since I guess almost nobody follows this discussion anymore, I'll ask
about it in a separate thread on emacs-devel. The question remains,
however: should I "fix" beginning-of-defun or just circumvent this
behavior in my code?
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 07 Feb 2017 16:16:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> >> ;; Trick with 'mark-defun-back due to Drew Adams
> >
> > No need for the attribution. ;-)
>
> Why not;-)? I'll change it to a link to your message, however - this
> might be actually more useful for future developers.
Yes, that's more useful; thx.
> > I didn't really test, but for this:
> >
> > (defun a ()
> > nil)
> > (defun b ()
> > nil)
> > ;;;;
> > (defun c ()
> > nil)
> >
> > With point anywhere in either of the last two defuns or
> > on the comment line between them, `M-- C-M-h' selects not
> > only the expected defun but also the last line of the
> > defun before it.
> >
> > E.g., with point at the beginning of the comment line,
> > this is selected:
> >
> > nil)
> > (defun a ()
> > nil)
>
> Yep, you're right. However, this seems to be a strange feature of
> beginning-of-defun. Place the point at the very same place at say M-:
> (beginning-of-defun 0). See?
>
> Since I guess almost nobody follows this discussion anymore, I'll ask
> about it in a separate thread on emacs-devel. The question remains,
> however: should I "fix" beginning-of-defun or just circumvent this
> behavior in my code?
Yes, please pose the question for emacs-devel. And thanks for
working on this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 14 Feb 2017 10:45:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 21072 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-02-13, at 20:00, John Wiegley <jwiegley <at> gmail.com> wrote:
>>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> I'd rather interpret John as being entirely serious. :) Tests are good.
>
> Dmitry is quite right; any patch that comes with a battery of new tests is
> already a huge plus in my book.
Thanks - as I said, I was a bit unsure;-).
Here's my proposed contribution, formatted as two patches. The first
one introduces the testing machinery; the second one introduces
mark-defun and its tests.
WDYT?
--
Marcin Borkowski
[0001-Add-elisp-tests-with-temp-buffer-a-new-testing-macro.patch (text/x-diff, attachment)]
[0002-Fix-bug-21072-and-rework-mark-defun.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 14 Feb 2017 13:03:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 14.02.2017 12:45, Marcin Borkowski wrote:
> +(defun in-comment-line-p ()
This needs a different name.
Something like beginning-of-defun--in-comment-line-p might be a good choice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 14 Feb 2017 19:06:03 GMT)
Full text and
rfc822 format available.
Message #116 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-02-14, at 14:02, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> On 14.02.2017 12:45, Marcin Borkowski wrote:
>> +(defun in-comment-line-p ()
>
> This needs a different name.
>
> Something like beginning-of-defun--in-comment-line-p might be a good choice.
Why? It seems to me that it may be of general use.
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 15 Feb 2017 06:46:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-02-14, at 20:25, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> Why? It seems to me that it may be of general use.
>
> If you want it to be general, it'll have to be better defined.
> What is a "comment line"?
A line containing only a comment (possibly after whitespace). I guess
the docstring could benefit from explaining this.
Thanks,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 15 Feb 2017 07:57:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 21072 <at> debbugs.gnu.org (full text, mbox):
>>> Why? It seems to me that it may be of general use.
>> If you want it to be general, it'll have to be better defined.
>> What is a "comment line"?
> A line containing only a comment (possibly after whitespace).
Is a line (using C syntax) like:
/* blablabla
considered as a "comment line"?
What about the likely next line:
blablabla */
?
How about
blablabla
on a line between the previous two (i.e. within a comment)?
Regardless of the answer you give above, I'm wondering in which kind of
circumstance we'd want to test if we're on "a line containing only
a comment".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 15 Feb 2017 19:18:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-02-15, at 08:56, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>>>> Why? It seems to me that it may be of general use.
>>> If you want it to be general, it'll have to be better defined.
>>> What is a "comment line"?
>> A line containing only a comment (possibly after whitespace).
>
> Is a line (using C syntax) like:
>
> /* blablabla
>
> considered as a "comment line"?
Yes.
> What about the likely next line:
>
> blablabla */
Yes.
>
> ?
> How about
>
> blablabla
>
> on a line between the previous two (i.e. within a comment)?
Yes.
(However, I found a minor bug: an empty line, even between a line "/*"
and another with "*/" is _not_ considered a comment line by my
function. I'll try to fix it.
> Regardless of the answer you give above, I'm wondering in which kind of
> circumstance we'd want to test if we're on "a line containing only
> a comment".
You will be surprised, then, that I actually did use a very similar
function in completely another circumstance: a command that counts
source lines of code in a region, and excludes lines containing only
whitespace, comments and docstrings. (Never mind the discussion about
whether SLOC is meaningful in any sense;-).)
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 15 Feb 2017 19:28:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 21072 <at> debbugs.gnu.org (full text, mbox):
>> Regardless of the answer you give above, I'm wondering in which kind of
>> circumstance we'd want to test if we're on "a line containing only
>> a comment".
> You will be surprised, then, that I actually did use a very similar
> function in completely another circumstance: a command that counts
> source lines of code in a region, and excludes lines containing only
> whitespace, comments and docstrings. (Never mind the discussion about
> whether SLOC is meaningful in any sense;-).)
My point is that it's not very frequent to need this exact definition of
a "comment line" and that there are various other possible definitions
one might need in other circumstances.
So at the very least, the doc should clarify which definition of
"comment line" it uses.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 16 Feb 2017 04:41:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-02-15, at 20:27, Stefan Monnier <monnier <at> IRO.UMontreal.CA> wrote:
>>> Regardless of the answer you give above, I'm wondering in which kind of
>>> circumstance we'd want to test if we're on "a line containing only
>>> a comment".
>> You will be surprised, then, that I actually did use a very similar
>> function in completely another circumstance: a command that counts
>> source lines of code in a region, and excludes lines containing only
>> whitespace, comments and docstrings. (Never mind the discussion about
>> whether SLOC is meaningful in any sense;-).)
>
> My point is that it's not very frequent to need this exact definition of
> a "comment line" and that there are various other possible definitions
> one might need in other circumstances.
> So at the very least, the doc should clarify which definition of
> "comment line" it uses.
Understood. Do you have then any better idea for the name of this
function? beginning-of-defun--incomment-line-p seems to specific,
in-comment-line-p _may_ be indeed too general. (I'll make the docstring
more precise, of course.)
Thank you all for looking at the patch,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 16 Feb 2017 13:23:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> Understood. Do you have then any better idea for the name of this
> function? beginning-of-defun--incomment-line-p seems to specific,
> in-comment-line-p _may_ be indeed too general.
I'll let someone else decide if it deserves a "non-prefixed" name, but
as for the name after the potential prefix, I think focusing on
"comment" is the wrong idea. Maybe `insignificant-line-p`? Or `emptyish-line-p`?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 17 Feb 2017 08:55:03 GMT)
Full text and
rfc822 format available.
Message #137 received at 21072 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-02-16, at 14:22, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> Understood. Do you have then any better idea for the name of this
>> function? beginning-of-defun--incomment-line-p seems to specific,
>> in-comment-line-p _may_ be indeed too general.
>
> I'll let someone else decide if it deserves a "non-prefixed" name, but
> as for the name after the potential prefix, I think focusing on
> "comment" is the wrong idea. Maybe `insignificant-line-p`? Or `emptyish-line-p`?
OK, so I have renamed it and expanded the docstring. I attach
a corrected patch (the second one, the first one is the same as before).
Is there anything else I can do before we may apply this patch and
consider bug#21072 fixed?
(Notice that three places could be still corrected: two when bug#24427
is fixed and possibly another one when the strange behavior of
(beginning-of-defun 0) is fixed - I will officially file a bug about it
later. But these apparently will have to wait.)
Best,
--
Marcin Borkowski
[0002-Fix-bug-21072-and-rework-mark-defun.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 07 Mar 2017 16:47:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Marcin Borkowski <mbork <at> mbork.pl>
> Date: Fri, 17 Feb 2017 09:54:51 +0100
> Cc: 21072 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
>
> OK, so I have renamed it and expanded the docstring. I attach
> a corrected patch (the second one, the first one is the same as before).
>
> Is there anything else I can do before we may apply this patch and
> consider bug#21072 fixed?
Thanks, this looks good, but please move the tests to lisp-tests.el,
to keep our conventions wrt test names.
Then this could go in.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 07 Mar 2017 16:51:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 17.02.2017 10:54, Marcin Borkowski wrote:
> +(defun in-emptyish-line-p ()
In case you were wondering, I'm still not sure this is a valuable
addition to our public API.
But if Eli says it's okay, then it's probably okay.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 07 Mar 2017 16:55:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 7 Mar 2017 18:50:33 +0200
> Cc: 21072 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
>
> On 17.02.2017 10:54, Marcin Borkowski wrote:
> > +(defun in-emptyish-line-p ()
>
> In case you were wondering, I'm still not sure this is a valuable
> addition to our public API.
>
> But if Eli says it's okay, then it's probably okay.
I don't really have an opinion, but perhaps it would be better to make
it an internal function for now, indeed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 29 Mar 2017 06:31:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-03-07, at 17:50, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> On 17.02.2017 10:54, Marcin Borkowski wrote:
>> +(defun in-emptyish-line-p ()
>
> In case you were wondering, I'm still not sure this is a valuable
> addition to our public API.
Well, I renamed it anyway.
Thanks,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 29 Mar 2017 06:31:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-03-07, at 17:53, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Tue, 7 Mar 2017 18:50:33 +0200
>> Cc: 21072 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
>>
>> On 17.02.2017 10:54, Marcin Borkowski wrote:
>> > +(defun in-emptyish-line-p ()
>>
>> In case you were wondering, I'm still not sure this is a valuable
>> addition to our public API.
>>
>> But if Eli says it's okay, then it's probably okay.
>
> I don't really have an opinion, but perhaps it would be better to make
> it an internal function for now, indeed.
Yep, that's what I did.
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 29 Mar 2017 06:35:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-03-07, at 17:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Marcin Borkowski <mbork <at> mbork.pl>
>> Date: Fri, 17 Feb 2017 09:54:51 +0100
>> Cc: 21072 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
>>
>> OK, so I have renamed it and expanded the docstring. I attach
>> a corrected patch (the second one, the first one is the same as before).
>>
>> Is there anything else I can do before we may apply this patch and
>> consider bug#21072 fixed?
>
> Thanks, this looks good, but please move the tests to lisp-tests.el,
> to keep our conventions wrt test names.
>
> Then this could go in.
I just pushed it to a branch, forgetting about this email. I'll fix it
and report back. For now, I deleted the branch I pushed; I'll pish it
again as soon as I correct this.
Thanks,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 31 Mar 2017 11:19:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-03-29, at 08:34, Marcin Borkowski <mbork <at> mbork.pl> wrote:
> On 2017-03-07, at 17:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Marcin Borkowski <mbork <at> mbork.pl>
>>> Date: Fri, 17 Feb 2017 09:54:51 +0100
>>> Cc: 21072 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
>>>
>>> OK, so I have renamed it and expanded the docstring. I attach
>>> a corrected patch (the second one, the first one is the same as before).
>>>
>>> Is there anything else I can do before we may apply this patch and
>>> consider bug#21072 fixed?
>>
>> Thanks, this looks good, but please move the tests to lisp-tests.el,
>> to keep our conventions wrt test names.
>>
>> Then this could go in.
>
> I just pushed it to a branch, forgetting about this email. I'll fix it
> and report back. For now, I deleted the branch I pushed; I'll pish it
> again as soon as I correct this.
OK, I pushed the branch "fix-bug-21072". Can anyone confirm that it's
ok and either merge it into master or tell me that I can do it?
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 02 Apr 2017 20:23:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski wrote:
> OK, I pushed the branch "fix-bug-21072". Can anyone confirm that it's
> ok and either merge it into master or tell me that I can do it?
Nitpick: branch should have been called fix/bug-21072
(given lack of response to http://debbugs.gnu.org/25610, I can't blame you)
While I'm nitpicking, please don't cc emacs-devel on bug reports.
:)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 02 Apr 2017 22:56:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
>
> OK, I pushed the branch "fix-bug-21072". Can anyone confirm that it's
> ok and either merge it into master or tell me that I can do it?
>
> +** New macro 'elisp-tests-with-temp-buffer'
> +which helps writing tests for functions that should change buffers in
> +specific ways or manipulate point or mark positions.
> +
> +---
I don't this should be documented in NEWS since the macro is being added
to a test file, so it's not part of Emacs' libraries. Also, the format
of the NEWS entry is wrong in the same way as the next one (see below).
> +With a prefix argument, it marks that many defuns or extends the
> +region by the appropriate number of defuns. With negative prefix
> +argument it marks defuns in the opposite direction and also changes
> +the direction of selecting for subsequent uses of @code{mark-defun}.
This doesn't say what exactly happens with zero as argument. The code
seems to do something odd. Perhaps it should just be a user-error
instead? Or maybe just a nop.
> modified etc/NEWS
> @@ -363,6 +363,15 @@ words where first character is upper rather than title case, e.g.,
> "DŽungla" instead of "Džungla".
>
>
> +** New behavior of 'mark-defun' implemented
> +Prefix argument selects that many (or that many more) defuns.
> +Negative prefix arg flips the direction of selection. Also,
> +'mark-defun' between defuns correctly selects N following defuns (or
> +-N previous for negative arguments). Finally, comments preceding the
> +defun are selected unless they are separated from the defun by a blank
> +line.
> +
> ++++
> * Changes in Specialized Modes and Packages in Emacs 26.1
>
This entry should go before the page separator, and the "+++" should go
on the line just above the entry, not after it.
> +(defun beginning-of-defun-comments (&optional arg)
> + (let (nbobp)
> + (while (progn
> + (setq nbobp (zerop (forward-line -1)))
> + (and (not (looking-at "^\\s-*$"))
> + (beginning-of-defun--in-emptyish-line-p)
> + nbobp)))
> + (when nbobp
> + (forward-line 1))))
The looking-at call is redundant, right? Anyway, can't that all be
replaced by just
(forward-comment (- (point)))
(unless (bolp)
(forward-line 1))
> +(defun mark-defun (&optional arg)
> + (let (nbobp)
> + (while (progn
> + (setq nbobp (zerop (forward-line -1)))
> + (and (looking-at "^\\s-*$")
> + nbobp)))
> + (when nbobp
> + (forward-line 1))))
I think this can be just
(skip-chars-backward "[:space:]\n")
(unless (bolp)
(forward-line 1))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 07 Apr 2017 08:25:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Hey,
and thanks for your feedback!
My answers to particular points are below.
On 2017-04-03, at 00:56, npostavs <at> users.sourceforge.net wrote:
> Marcin Borkowski <mbork <at> mbork.pl> writes:
>
>>
>> OK, I pushed the branch "fix-bug-21072". Can anyone confirm that it's
>> ok and either merge it into master or tell me that I can do it?
>
>>
>> +** New macro 'elisp-tests-with-temp-buffer'
>> +which helps writing tests for functions that should change buffers in
>> +specific ways or manipulate point or mark positions.
>> +
>> +---
>
> I don't this should be documented in NEWS since the macro is being added
> to a test file, so it's not part of Emacs' libraries. Also, the format
> of the NEWS entry is wrong in the same way as the next one (see below).
I deleted that from etc/NEWS.
>> +With a prefix argument, it marks that many defuns or extends the
>> +region by the appropriate number of defuns. With negative prefix
>> +argument it marks defuns in the opposite direction and also changes
>> +the direction of selecting for subsequent uses of @code{mark-defun}.
>
> This doesn't say what exactly happens with zero as argument. The code
> seems to do something odd. Perhaps it should just be a user-error
> instead? Or maybe just a nop.
Good catch. I guess a no-op is fine.
>> modified etc/NEWS
>> @@ -363,6 +363,15 @@ words where first character is upper rather than title case, e.g.,
>> "DŽungla" instead of "Džungla".
>>
>>
>> +** New behavior of 'mark-defun' implemented
>> +Prefix argument selects that many (or that many more) defuns.
>> +Negative prefix arg flips the direction of selection. Also,
>> +'mark-defun' between defuns correctly selects N following defuns (or
>> +-N previous for negative arguments). Finally, comments preceding the
>> +defun are selected unless they are separated from the defun by a blank
>> +line.
>> +
>> ++++
>> * Changes in Specialized Modes and Packages in Emacs 26.1
>>
>
> This entry should go before the page separator, and the "+++" should go
> on the line just above the entry, not after it.
That one I do not understand. This means that "+++" goes essentially
_to the previous entry_, which doesn't seem to make sense (especially
when viewing NEWS folded, which I assume everyone does, right?).
>> +(defun beginning-of-defun-comments (&optional arg)
>
>> + (let (nbobp)
>> + (while (progn
>> + (setq nbobp (zerop (forward-line -1)))
>> + (and (not (looking-at "^\\s-*$"))
>> + (beginning-of-defun--in-emptyish-line-p)
>> + nbobp)))
>> + (when nbobp
>> + (forward-line 1))))
>
>
> The looking-at call is redundant, right? Anyway, can't that all be
Hm. Probably yes, although this seems to be not very well documented in
`forward-comment's docs.
> replaced by just
>
> (forward-comment (- (point)))
> (unless (bolp)
> (forward-line 1))
My tests say no. Consider these contents of a buffer:
--8<---------------cut here---------------start------------->8---
;; Comment at the bob
(defun func (arg)
"docstring"
body)
--8<---------------cut here---------------end--------------->8---
Put the point inside the defun and call mark-defun. Your version marks
the comment at the beginning, mine doesn't.
>> +(defun mark-defun (&optional arg)
>
>> + (let (nbobp)
>> + (while (progn
>> + (setq nbobp (zerop (forward-line -1)))
>> + (and (looking-at "^\\s-*$")
>> + nbobp)))
>> + (when nbobp
>> + (forward-line 1))))
>
> I think this can be just
>
> (skip-chars-backward "[:space:]\n")
> (unless (bolp)
> (forward-line 1))
This OTOH does pass my tests, though I guess it would be clearer to
replace (bolp) with (bobp) in the above code (if I understand correctly,
in this situation they should be equivalent). WDYT?
Thanks a lot,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 07 Apr 2017 08:27:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-02, at 22:22, Glenn Morris <rgm <at> gnu.org> wrote:
> Marcin Borkowski wrote:
>
>> OK, I pushed the branch "fix-bug-21072". Can anyone confirm that it's
>> ok and either merge it into master or tell me that I can do it?
>
> Nitpick: branch should have been called fix/bug-21072
> (given lack of response to http://debbugs.gnu.org/25610, I can't blame you)
OK, I'll fix that. Thanks.
> While I'm nitpicking, please don't cc emacs-devel on bug reports.
>
> :)
Well, I guess the CC was somehow justified in that I wanted to ask
people about the new features I introduced while fixing an old bug.
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 07 Apr 2017 14:42:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On Fri, Apr 7, 2017 at 4:25 AM, Marcin Borkowski <mbork <at> mbork.pl> wrote:
>>> +** New behavior of 'mark-defun' implemented
[...]
>>> +line.
>>> +
>>> ++++
>>> * Changes in Specialized Modes and Packages in Emacs 26.1
>>>
>>
>> This entry should go before the page separator, and the "+++" should go
>> on the line just above the entry, not after it.
>
> That one I do not understand. This means that "+++" goes essentially
> _to the previous entry_, which doesn't seem to make sense (especially
> when viewing NEWS folded, which I assume everyone does, right?).
Hmm, no, I wasn't really aware of folding (you mean via
`outline-hide-sublevels', right?).
I guess the convention wasn't made with folding in mind, but the "+++"
and "---" markup is just temporary anyway.
>
>>> +(defun beginning-of-defun-comments (&optional arg)
>>
>>> + (let (nbobp)
>>> + (while (progn
>>> + (setq nbobp (zerop (forward-line -1)))
>>> + (and (not (looking-at "^\\s-*$"))
>>> + (beginning-of-defun--in-emptyish-line-p)
>>> + nbobp)))
>>> + (when nbobp
>>> + (forward-line 1))))
>>
>>
>> The looking-at call is redundant, right? Anyway, can't that all be
>> replaced by just
>>
>> (forward-comment (- (point)))
>> (unless (bolp)
>> (forward-line 1))
>
> My tests say no.
Oh, right, I thought it was doing backward-comment, but the difference
is that it stops at blank lines, thus the *non-redundant* looking-at
call.
I wonder if that's a sensible thing to do for languages that have
multiline comments though, e.g. Javascript:
/*
This function returns 0
*/
function foo () {
return 0;
}
Although we might say that such comments should have "*" on the empty lines.
>
>>> +(defun mark-defun (&optional arg)
>>
>>> + (let (nbobp)
>>> + (while (progn
>>> + (setq nbobp (zerop (forward-line -1)))
>>> + (and (looking-at "^\\s-*$")
>>> + nbobp)))
>>> + (when nbobp
>>> + (forward-line 1))))
>>
>> I think this can be just
>>
>> (skip-chars-backward "[:space:]\n")
>> (unless (bolp)
>> (forward-line 1))
>
> This OTOH does pass my tests, though I guess it would be clearer to
> replace (bolp) with (bobp) in the above code (if I understand correctly,
> in this situation they should be equivalent). WDYT?
Yes, I believe they are equivalent. I guess using bobp would explain
better when this happens, though I feel bolp better explains why we're
doing forward-line. I don't think it matters very much either way, go
with whichever you like best.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 18 Apr 2017 12:35:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-07, at 16:41, Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
>>> This entry should go before the page separator, and the "+++" should go
>>> on the line just above the entry, not after it.
>>
>> That one I do not understand. This means that "+++" goes essentially
>> _to the previous entry_, which doesn't seem to make sense (especially
>> when viewing NEWS folded, which I assume everyone does, right?).
>
> Hmm, no, I wasn't really aware of folding (you mean via
> `outline-hide-sublevels', right?).
Actually, via Org-mode. Is there anyone who does that without Org-mode?
Out of curiosity: why???
> I guess the convention wasn't made with folding in mind, but the "+++"
> and "---" markup is just temporary anyway.
OK. Anyway, I fixed that.
> [...]
>
> Oh, right, I thought it was doing backward-comment, but the difference
> is that it stops at blank lines, thus the *non-redundant* looking-at
> call.
>
> I wonder if that's a sensible thing to do for languages that have
> multiline comments though, e.g. Javascript:
>
> /*
>
> This function returns 0
>
> */
> function foo () {
> return 0;
> }
>
> Although we might say that such comments should have "*" on the empty lines.
Definitely. OTOH, what if they don't...? I'm not sure how to detect
such a situation. Any ideas?
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 18 Apr 2017 14:05:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> > Hmm, no, I wasn't really aware of folding (you mean via
> > `outline-hide-sublevels', right?).
>
> Actually, via Org-mode. Is there anyone who does that
> without Org-mode? Out of curiosity: why???
Yes, I do. ;-)
And so do you, if you use `C-h n' (`view-emacs-news') and
you sometimes hide sublevels there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 18 Apr 2017 14:39:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 18 Apr 2017 07:04:10 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 21072 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
>
> > > Hmm, no, I wasn't really aware of folding (you mean via
> > > `outline-hide-sublevels', right?).
> >
> > Actually, via Org-mode. Is there anyone who does that
> > without Org-mode? Out of curiosity: why???
>
> Yes, I do. ;-)
And so do I.
> And so do you, if you use `C-h n' (`view-emacs-news') and
> you sometimes hide sublevels there.
Right.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 19 Apr 2017 00:04:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
>> Oh, right, I thought it was doing backward-comment, but the difference
>> is that it stops at blank lines, thus the *non-redundant* looking-at
>> call.
>>
>> I wonder if that's a sensible thing to do for languages that have
>> multiline comments though, e.g. Javascript:
>>
>> /*
>>
>> This function returns 0
>>
>> */
>> function foo () {
>> return 0;
>> }
>>
>> Although we might say that such comments should have "*" on the empty lines.
>
> Definitely. OTOH, what if they don't...? I'm not sure how to detect
> such a situation. Any ideas?
(defun beginning-of-defun-comments (&optional arg)
"Move to the beginning of ARGth defun, including comments."
(interactive "^p")
(unless arg (setq arg 1))
(beginning-of-defun arg)
(while (let ((pt (prog1 (point) (forward-line -1)))
(ppss (syntax-ppss)))
(cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
((and (parse-partial-sexp
(point) (line-end-position) nil t ppss)
(not (bolp)) (eolp)))
(t (goto-char pt) nil)))))
However there will always be some comment style that doesn't work, e.g.
// Some description followed by a blank.
function name(arg) {
}
Another option is to give up the comment marking, it seems a bit
complicated to implement and explain to users.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 19 Apr 2017 00:36:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 21072 <at> debbugs.gnu.org (full text, mbox):
<npostavs <at> users.sourceforge.net> wrote:
> (defun beginning-of-defun-comments (&optional arg)
> "Move to the beginning of ARGth defun, including comments."
> (interactive "^p")
> (unless arg (setq arg 1))
> (beginning-of-defun arg)
> (while (let ((pt (prog1 (point) (forward-line -1)))
> (ppss (syntax-ppss)))
> (cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
> ((and (parse-partial-sexp
> (point) (line-end-position) nil t ppss)
> (not (bolp)) (eolp)))
> (t (goto-char pt) nil)))))
>
> However there will always be some comment style that doesn't work, e.g.
>
> // Some description followed by a blank.
>
> function name(arg) {
>
> }
>
> Another option is to give up the comment marking, it seems a bit
> complicated to implement and explain to users.
Would it help to lean on (forward-comment -1) more?
Something like this:
(defun beginning-of-defun-comments (&optional arg)
(interactive "^p")
(let ((arg (or arg 1))
point)
(beginning-of-defun arg)
(setq point (point))
(while (not (eq point (setq point (progn (forward-comment -1) (point))))))
(skip-chars-forward "[:space:]\r\n")))
Having to `skip-chars-forward' at the end seems a bit awkward, but I
think it does work on the recently mentioned JavaScript examples.
John
John
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 20 Apr 2017 00:49:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 21072 <at> debbugs.gnu.org (full text, mbox):
John Mastro <john.b.mastro <at> gmail.com> wrote:
> Would it help to lean on (forward-comment -1) more?
>
> Something like this:
>
> (defun beginning-of-defun-comments (&optional arg)
> (interactive "^p")
> (let ((arg (or arg 1))
> point)
> (beginning-of-defun arg)
> (setq point (point))
> (while (not (eq point (setq point (progn (forward-comment -1) (point))))))
> (skip-chars-forward "[:space:]\r\n")))
>
> Having to `skip-chars-forward' at the end seems a bit awkward, but I
> think it does work on the recently mentioned JavaScript examples.
I realized that `forward-comment' returns nil when something besides a
comment or whitespace was found, so my idea boils down to:
(defun beginning-of-defun-comments (&optional arg)
(interactive "^p")
(beginning-of-defun (or arg 1))
(while (forward-comment -1))
(skip-chars-forward "[:space:]\r\n"))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 20 Apr 2017 12:11:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-20, at 02:47, John Mastro <john.b.mastro <at> gmail.com> wrote:
> I realized that `forward-comment' returns nil when something besides a
> comment or whitespace was found, so my idea boils down to:
>
> (defun beginning-of-defun-comments (&optional arg)
> (interactive "^p")
> (beginning-of-defun (or arg 1))
> (while (forward-comment -1))
> (skip-chars-forward "[:space:]\r\n"))
Hi John,
this definitely does not work - my `beginning-of-defun-comments' stops
at the first blank line, yours does not.
Thanks anyway,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 21 Apr 2017 12:24:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-19, at 02:04, npostavs <at> users.sourceforge.net wrote:
> Marcin Borkowski <mbork <at> mbork.pl> writes:
>
>>> Oh, right, I thought it was doing backward-comment, but the difference
>>> is that it stops at blank lines, thus the *non-redundant* looking-at
>>> call.
>>>
>>> I wonder if that's a sensible thing to do for languages that have
>>> multiline comments though, e.g. Javascript:
>>>
>>> /*
>>>
>>> This function returns 0
>>>
>>> */
>>> function foo () {
>>> return 0;
>>> }
>>>
>>> Although we might say that such comments should have "*" on the empty lines.
>>
>> Definitely. OTOH, what if they don't...? I'm not sure how to detect
>> such a situation. Any ideas?
>
> (defun beginning-of-defun-comments (&optional arg)
> "Move to the beginning of ARGth defun, including comments."
> (interactive "^p")
> (unless arg (setq arg 1))
> (beginning-of-defun arg)
> (while (let ((pt (prog1 (point) (forward-line -1)))
> (ppss (syntax-ppss)))
> (cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
> ((and (parse-partial-sexp
> (point) (line-end-position) nil t ppss)
> (not (bolp)) (eolp)))
> (t (goto-char pt) nil)))))
Still not there - I tried first on Elisp, like this:
;; A comment
(defun ...)
and it left the point at the end of the "A comment" line instead of at
the beginning...
> However there will always be some comment style that doesn't work, e.g.
>
> // Some description followed by a blank.
>
> function name(arg) {
>
> }
>
> Another option is to give up the comment marking, it seems a bit
> complicated to implement and explain to users.
I'm tempted to leave it is it is in my branch. For one, I'm a bit tired
by all this and I'd like to move on; also, as you said above, there is
little hope to do it "100% correctly", and I guess my solution may be
good enough. (I'm pretty sure it's better than the status quo, at
least.)
I wouldn't like to resign from marking comments; I think it is pretty
useful.
So I'm going to delete the branch with the wrong name and push another
one, with the fixes we discussed earlier.
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 21 Apr 2017 12:30:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Hi all,
as I mentioned a few minutes ago, I pushed the fix/bug-21072 branch with
a few fixes discussed in this thread. If it is in good enoug shape to
merge into master, please tell me and I'll do it; if not, I'll fix what
should be fixed (commit messages?)
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sat, 22 Apr 2017 18:04:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
> On 2017-04-19, at 02:04, npostavs <at> users.sourceforge.net wrote:
>
>> Marcin Borkowski <mbork <at> mbork.pl> writes:
>>
>>>> Oh, right, I thought it was doing backward-comment, but the difference
>>>> is that it stops at blank lines, thus the *non-redundant* looking-at
>>>> call.
>>>>
>>>> I wonder if that's a sensible thing to do for languages that have
>>>> multiline comments though, e.g. Javascript:
>>>>
>>>> /*
>>>>
>>>> This function returns 0
>>>>
>>>> */
>>>> function foo () {
>>>> return 0;
>>>> }
>>>>
>>>> Although we might say that such comments should have "*" on the empty lines.
>>>
>>> Definitely. OTOH, what if they don't...? I'm not sure how to detect
>>> such a situation. Any ideas?
>>
>> (defun beginning-of-defun-comments (&optional arg)
[...]
>
> Still not there - I tried first on Elisp, like this:
>
> ;; A comment
> (defun ...)
>
> and it left the point at the end of the "A comment" line instead of at
> the beginning...
Hmm, I don't get that, although I did miss an inf loop when the comment
is at beginning of buffer. Here is a fixed version:
(defun beginning-of-defun-comments (&optional arg)
"Move to the beginning of ARGth defun, including comments."
(interactive "^p")
(unless arg (setq arg 1))
(beginning-of-defun arg)
(while (let ((pt (point))
(ppss (and (zerop (forward-line -1)) (syntax-ppss))))
(cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
((and ppss
(parse-partial-sexp
(point) (line-end-position) nil t ppss)
(not (bolp)) (eolp)))
(t (goto-char pt) nil)))))
>
> I'm tempted to leave it is it is in my branch. For one, I'm a bit tired
> by all this and I'd like to move on; also, as you said above, there is
> little hope to do it "100% correctly", and I guess my solution may be
> good enough. (I'm pretty sure it's better than the status quo, at
> least.)
Yeah, since there's no perfect answer, I think it's fine if you just go
with whichever version you like best. If people disagree, we'll find
out in bug reports :)
> as I mentioned a few minutes ago, I pushed the fix/bug-21072 branch with
> a few fixes discussed in this thread. If it is in good enoug shape to
> merge into master, please tell me and I'll do it; if not, I'll fix what
> should be fixed (commit messages?)
Looks good to me (apart from the commit messages).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Mon, 24 Apr 2017 12:18:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-22, at 20:05, npostavs <at> users.sourceforge.net wrote:
>> Still not there - I tried first on Elisp, like this:
>>
>> ;; A comment
>> (defun ...)
>>
>> and it left the point at the end of the "A comment" line instead of at
>> the beginning...
>
> Hmm, I don't get that, although I did miss an inf loop when the comment
> is at beginning of buffer. Here is a fixed version:
>
> (defun beginning-of-defun-comments (&optional arg)
> "Move to the beginning of ARGth defun, including comments."
> (interactive "^p")
> (unless arg (setq arg 1))
> (beginning-of-defun arg)
> (while (let ((pt (point))
> (ppss (and (zerop (forward-line -1)) (syntax-ppss))))
> (cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
> ((and ppss
> (parse-partial-sexp
> (point) (line-end-position) nil t ppss)
> (not (bolp)) (eolp)))
> (t (goto-char pt) nil)))))
Still the same here, also in emacs -Q.
>> I'm tempted to leave it is it is in my branch. For one, I'm a bit tired
>> by all this and I'd like to move on; also, as you said above, there is
>> little hope to do it "100% correctly", and I guess my solution may be
>> good enough. (I'm pretty sure it's better than the status quo, at
>> least.)
>
> Yeah, since there's no perfect answer, I think it's fine if you just go
> with whichever version you like best. If people disagree, we'll find
> out in bug reports :)
;-)
>> as I mentioned a few minutes ago, I pushed the fix/bug-21072 branch with
>> a few fixes discussed in this thread. If it is in good enoug shape to
>> merge into master, please tell me and I'll do it; if not, I'll fix what
>> should be fixed (commit messages?)
>
> Looks good to me (apart from the commit messages).
What should they look like, then? Should I make all of them into the
ChangeLog format, or just rebase/squash all of them so that there are
two of them only (one for the testing tool and one for the
beginning-of-defun)?
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Mon, 24 Apr 2017 12:51:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
> On 2017-04-22, at 20:05, npostavs <at> users.sourceforge.net wrote:
>
>>> Still not there - I tried first on Elisp, like this:
>>>
>>> ;; A comment
>>> (defun ...)
>>>
>>> and it left the point at the end of the "A comment" line instead of at
>>> the beginning...
>>
>> Hmm, I don't get that, although I did miss an inf loop when the comment
>> is at beginning of buffer. Here is a fixed version:
>
> Still the same here, also in emacs -Q.
Hmm, I was testing before now just by evaluating the changed functions
after startup, I must have messed something up. I think this one might
be okay.
(defun beginning-of-defun-comments (&optional arg)
"Move to the beginning of ARGth defun, including comments."
(interactive "^p")
(unless arg (setq arg 1))
(beginning-of-defun arg)
(while (let ((pt (line-beginning-position))
(ppss (and (zerop (forward-line -1)) (syntax-ppss))))
(cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
((and ppss
(parse-partial-sexp
(point) (line-end-position) nil t ppss)
(not (bolp)) (eolp)))
(t (goto-char pt) nil)))))
>>
>> Looks good to me (apart from the commit messages).
Actually, now that I've applied this thing properly, I notice 2 test
failures in batch mode:
2 unexpected results:
FAILED mark-defun-arg-region-active
FAILED mark-defun-no-arg-region-active
They pass when run in interactive mode (I haven't looked into why).
>
> What should they look like, then? Should I make all of them into the
> ChangeLog format, or just rebase/squash all of them so that there are
> two of them only (one for the testing tool and one for the
> beginning-of-defun)?
Yeah, I would go ahead and squash them, since you need to rebase to fix
commit messages anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 25 Apr 2017 11:44:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-24, at 14:52, npostavs <at> users.sourceforge.net wrote:
> Marcin Borkowski <mbork <at> mbork.pl> writes:
>
>> On 2017-04-22, at 20:05, npostavs <at> users.sourceforge.net wrote:
>>
>>>> Still not there - I tried first on Elisp, like this:
>>>>
>>>> ;; A comment
>>>> (defun ...)
>>>>
>>>> and it left the point at the end of the "A comment" line instead of at
>>>> the beginning...
>>>
>>> Hmm, I don't get that, although I did miss an inf loop when the comment
>>> is at beginning of buffer. Here is a fixed version:
>>
>> Still the same here, also in emacs -Q.
>
> Hmm, I was testing before now just by evaluating the changed functions
> after startup, I must have messed something up. I think this one might
> be okay.
>
> (defun beginning-of-defun-comments (&optional arg)
> "Move to the beginning of ARGth defun, including comments."
> (interactive "^p")
> (unless arg (setq arg 1))
> (beginning-of-defun arg)
> (while (let ((pt (line-beginning-position))
> (ppss (and (zerop (forward-line -1)) (syntax-ppss))))
> (cond ((nth 4 ppss) (goto-char (nth 8 ppss)))
> ((and ppss
> (parse-partial-sexp
> (point) (line-end-position) nil t ppss)
> (not (bolp)) (eolp)))
> (t (goto-char pt) nil)))))
Quick tests show that you are right. I'd like to understand the code,
too - that will take me a while.
>>> Looks good to me (apart from the commit messages).
>
> Actually, now that I've applied this thing properly, I notice 2 test
> failures in batch mode:
>
> 2 unexpected results:
> FAILED mark-defun-arg-region-active
> FAILED mark-defun-no-arg-region-active
>
> They pass when run in interactive mode (I haven't looked into why).
That seems strange - all tests pass here with M-x ert. What do you mean
by "batch mode"?
>> What should they look like, then? Should I make all of them into the
>> ChangeLog format, or just rebase/squash all of them so that there are
>> two of them only (one for the testing tool and one for the
>> beginning-of-defun)?
>
> Yeah, I would go ahead and squash them, since you need to rebase to fix
> commit messages anyway.
Will do.
Thanks,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 25 Apr 2017 12:13:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
>>
>> Actually, now that I've applied this thing properly, I notice 2 test
>> failures in batch mode:
>>
>> 2 unexpected results:
>> FAILED mark-defun-arg-region-active
>> FAILED mark-defun-no-arg-region-active
>>
>> They pass when run in interactive mode (I haven't looked into why).
>
> That seems strange - all tests pass here with M-x ert.
Yes, same here (that's what I mean by "interactive mode").
> What do you mean by "batch mode"?
I mean 'emacs -Q -batch -l .../lisp-tests.el -f ert-run-tests-batch-and-exit'
which is what 'make check' or 'cd test && make lisp-tests' do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 25 Apr 2017 20:50:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On Tue, Apr 25, 2017 at 7:43 AM, Marcin Borkowski <mbork <at> mbork.pl> wrote:
>>
>> Hmm, I was testing before now just by evaluating the changed functions
>> after startup, I must have messed something up. I think this one might
>> be okay.
>
> Quick tests show that you are right. I'd like to understand the code,
> too - that will take me a while.
I started commenting the code a bit which made me think of some more
strange corner cases, like
/* foo */ foo;
function () {
return 0;
}
and I ended up with this
(defun beginning-of-defun-comments (&optional arg)
"Move to the beginning of ARGth defun, including comments."
(interactive "^p")
(unless arg (setq arg 1))
(beginning-of-defun arg)
(let (bobp)
(while (let ((ppss (progn (setq bobp (= (forward-line -1) -1))
(syntax-ppss (line-end-position)))))
(while (and (nth 4 ppss) ; If eol is in a line-spanning comment,
(< (nth 8 ppss) (line-beginning-position)))
(goto-char (nth 8 ppss)) ; skip to comment start.
(setq ppss (syntax-ppss (line-end-position))))
(and (not bobp)
(progn (skip-syntax-backward
"-" (line-beginning-position))
(not (bolp))) ; Check for blank line.
(progn (parse-partial-sexp
(line-beginning-position) (line-end-position)
nil t (syntax-ppss (line-beginning-position)))
(eolp))))) ; Check for non-comment text.
(forward-line (if bobp 0 1))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 27 Apr 2017 16:44:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-24, at 14:52, npostavs <at> users.sourceforge.net wrote:
> Actually, now that I've applied this thing properly, I notice 2 test
> failures in batch mode:
>
> 2 unexpected results:
> FAILED mark-defun-arg-region-active
> FAILED mark-defun-no-arg-region-active
>
> They pass when run in interactive mode (I haven't looked into why).
Strangely enough, they also fail with my original code. Does anyone
have any idea why that might be the case?
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Thu, 27 Apr 2017 21:49:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On Thu, Apr 27, 2017 at 12:43 PM, Marcin Borkowski <mbork <at> mbork.pl> wrote:
>
> On 2017-04-24, at 14:52, npostavs <at> users.sourceforge.net wrote:
>
>> Actually, now that I've applied this thing properly, I notice 2 test
>> failures in batch mode:
>>
>> 2 unexpected results:
>> FAILED mark-defun-arg-region-active
>> FAILED mark-defun-no-arg-region-active
>>
>> They pass when run in interactive mode (I haven't looked into why).
>
> Strangely enough, they also fail with my original code. Does anyone
> have any idea why that might be the case?
Oh I see what it is, your test depends on `transient-mark-mode' being
enabled. With --batch, that defaults to nil. Should we be testing in
both modes or just explicitly set it to t?
PS I noticed some problems with elisp-tests-with-temp-buffer while
looking at this, I pushed a fix to fix/bug-21072 [1: 04741f0].
1: 2017-04-27 17:38:09 -0400 04741f02cca95147581e05cb49b54e6dbf8bed56
Fix elisp-tests-with-temp-buffer compilation
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 14:49:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-27, at 23:48, Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
> On Thu, Apr 27, 2017 at 12:43 PM, Marcin Borkowski <mbork <at> mbork.pl> wrote:
>>
>> On 2017-04-24, at 14:52, npostavs <at> users.sourceforge.net wrote:
>>
>>> Actually, now that I've applied this thing properly, I notice 2 test
>>> failures in batch mode:
>>>
>>> 2 unexpected results:
>>> FAILED mark-defun-arg-region-active
>>> FAILED mark-defun-no-arg-region-active
>>>
>>> They pass when run in interactive mode (I haven't looked into why).
>>
>> Strangely enough, they also fail with my original code. Does anyone
>> have any idea why that might be the case?
>
> Oh I see what it is, your test depends on `transient-mark-mode' being
> enabled. With --batch, that defaults to nil. Should we be testing in
> both modes or just explicitly set it to t?
Good catch, thanks! I'll set it to t, since this functionality is
intended to be used in t-t-m anyway. OTOH, I'm curious where it breaks
with that disabled - I'll look into it now, I guess.
> PS I noticed some problems with elisp-tests-with-temp-buffer while
> looking at this, I pushed a fix to fix/bug-21072 [1: 04741f0].
>
> 1: 2017-04-27 17:38:09 -0400 04741f02cca95147581e05cb49b54e6dbf8bed56
> Fix elisp-tests-with-temp-buffer compilation
Thanks a lot, I'll take a look!
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 15:19:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-27, at 23:48, Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
> PS I noticed some problems with elisp-tests-with-temp-buffer while
> looking at this, I pushed a fix to fix/bug-21072 [1: 04741f0].
>
> 1: 2017-04-27 17:38:09 -0400 04741f02cca95147581e05cb49b54e6dbf8bed56
> Fix elisp-tests-with-temp-buffer compilation
I started looking at this, and I have a few questions.
1. What is the difference between (debug t) and (debug form body)? From
my understanding of the manual, there seems to be none.
2. I still don't fully get the `eval-and-compile' stuff. What exactly
happens when the file is compiled? I understand that its forms are not
evaluated. But are the _defmacro_ forms evaluated during compilation?
If not, what happens when the compiler compiles a function containing
a macro invocation?
3. Do I get it correctly that the purpose of the `ignore' calls is to
silence the compiler warnings about `let'ting a variable which is then
not used in the body of `let'?
That's it for now. Sorry if my questions are elementary - I'm still
struggling with this compilation stuff...
TIA,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 16:11:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> 1. What is the difference between (debug t) and (debug form body)? From
> my understanding of the manual, there seems to be none.
Indeed, no significant difference.
> 2. I still don't fully get the `eval-and-compile' stuff. What exactly
> happens when the file is compiled?
During compilation, (eval-and-compile E) will be treated (i.e. compiled)
just like E, except that E is evaluated along the way (so the
definitions present in E are available during compilation).
> I understand that its forms are not evaluated.
They are. It's for `eval-when-compile` that they aren't.
> But are the _defmacro_ forms evaluated during compilation?
The defmacro forms are always evaluated (and byte-compiled) during
compilation (as if they were implicitly wrapped inside an
eval-and-compile).
> 3. Do I get it correctly that the purpose of the `ignore' calls is to
> silence the compiler warnings about `let'ting a variable which is then
> not used in the body of `let'?
Yes.
Stfean
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 18:06:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On Sun, Apr 30, 2017 at 12:10 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> 1. What is the difference between (debug t) and (debug form body)? From
>> my understanding of the manual, there seems to be none.
>
> Indeed, no significant difference.
Oops, I meant (debug sexp body), then I changed it for some reason and
forgot to change back to the correct thing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 18:47:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 21072 <at> debbugs.gnu.org (full text, mbox):
>>> 1. What is the difference between (debug t) and (debug form body)? From
>>> my understanding of the manual, there seems to be none.
>> Indeed, no significant difference.
> Oops, I meant (debug sexp body), then I changed it for some reason and
> forgot to change back to the correct thing.
Ah that changes everything: (debug (sexp body)) is quite different from
(debug t) since it says that the first argument is not an expression
(and hence shouldn't be instrumented).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 19:17:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>> 1. What is the difference between (debug t) and (debug form body)? From
>>>> my understanding of the manual, there seems to be none.
>>> Indeed, no significant difference.
>> Oops, I meant (debug sexp body), then I changed it for some reason and
>> forgot to change back to the correct thing.
>
> Ah that changes everything: (debug (sexp body)) is quite different from
> (debug t) since it says that the first argument is not an expression
> (and hence shouldn't be instrumented).
I guess it's related to the fact that the first argument is evaluated by
the macro itself at compile time, with (debug t) or (debug form body) I
get an error when trying to instrument one of tests using that macro:
Debugger entered--Lisp error: (wrong-type-argument char-or-string-p (edebug-after 0 3 mark-defun-test-buffer))
insert((edebug-after 0 3 mark-defun-test-buffer))
(progn (insert (cond ((symbolp contents) (symbol-value contents)) (t contents))) (goto-char (point-min)) [...])
(unwind-protect [...] (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
(save-current-buffer (set-buffer temp-buffer) [...])
(let ((temp-buffer (generate-new-buffer " *temp*"))) [...])
(let* ((var-pos nil) (text (let ((temp-buffer (generate-new-buffer " *temp*"))) [...]))) [...])
(closure (t) (contents &rest body) "Create an `emacs-lisp-mode' enabled temp buffer with CONTENTS[...]
macroexpand((elisp-tests-with-temp-buffer [...]
[...]
edebug-eval-defun((4))
apply(edebug-eval-defun (4))
eval-defun((4))
funcall-interactively(eval-defun (4))
call-interactively(eval-defun nil nil)
command-execute(eval-defun)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 20:10:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> I guess it's related to the fact that the first argument is evaluated by
> the macro itself at compile time, with (debug t) or (debug form body) I
> get an error when trying to instrument one of tests using that macro:
Yes, you can either use (debug (sexp body)) to avoid instrumenting the
first arg, or you might use (debug (def-form body)) so as to warn that
the first argument is not evaluated at the "normal" time.
Stefan
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p
> (edebug-after 0 3 mark-defun-test-buffer))
> insert((edebug-after 0 3 mark-defun-test-buffer))
> (progn (insert (cond ((symbolp contents) (symbol-value contents)) (t
> contents))) (goto-char (point-min)) [...])
> (unwind-protect [...] (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
> (save-current-buffer (set-buffer temp-buffer) [...])
> (let ((temp-buffer (generate-new-buffer " *temp*"))) [...])
> (let* ((var-pos nil) (text (let ((temp-buffer (generate-new-buffer " *temp*"))) [...]))) [...])
> (closure (t) (contents &rest body) "Create an `emacs-lisp-mode' enabled
> temp buffer with CONTENTS[...]
> macroexpand((elisp-tests-with-temp-buffer [...]
> [...]
> edebug-eval-defun((4))
> apply(edebug-eval-defun (4))
> eval-defun((4))
> funcall-interactively(eval-defun (4))
> call-interactively(eval-defun nil nil)
> command-execute(eval-defun)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 21:40:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I guess it's related to the fact that the first argument is evaluated by
>> the macro itself at compile time, with (debug t) or (debug form body) I
>> get an error when trying to instrument one of tests using that macro:
>
> Yes, you can either use (debug (sexp body)) to avoid instrumenting the
> first arg, or you might use (debug (def-form body)) so as to warn that
> the first argument is not evaluated at the "normal" time.
I'm not sure exactly what def-form means, but using it gives a similar
error.
Debugger entered--Lisp error: (wrong-type-argument char-or-string-p (edebug-enter (quote test <at> mark-defun-no-arg-region-inactive) nil (function (lambda nil (edebug-after 0 3 mark-defun-test-buffer)))))
insert((edebug-enter (quote test <at> mark-defun-no-arg-region-inactive) nil (function (lambda nil (edebug-after 0 3 mark-defun-test-buffer)))))
[...]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 22:05:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 21072 <at> debbugs.gnu.org (full text, mbox):
>>> I guess it's related to the fact that the first argument is evaluated by
>>> the macro itself at compile time, with (debug t) or (debug form body) I
>>> get an error when trying to instrument one of tests using that macro:
>>
>> Yes, you can either use (debug (sexp body)) to avoid instrumenting the
>> first arg, or you might use (debug (def-form body)) so as to warn that
>> the first argument is not evaluated at the "normal" time.
> I'm not sure exactly what def-form means, but using it gives a similar
> error.
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p
> (edebug-enter (quote test <at> mark-defun-no-arg-region-inactive) nil (function
> (lambda nil (edebug-after 0 3 mark-defun-test-buffer)))))
> insert((edebug-enter (quote test <at> mark-defun-no-arg-region-inactive) nil
> (function (lambda nil (edebug-after 0 3 mark-defun-test-buffer)))))
> [...]
This suggests that the first arg is not "evaluated by the macro itself
at compile time", but instead is passed unevaluated to `insert`, in
which case it can't be instrumented.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sun, 30 Apr 2017 22:21:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> This suggests that the first arg is not "evaluated by the macro itself
> at compile time", but instead is passed unevaluated to `insert`, in
> which case it can't be instrumented.
Oh, I see, this patch works, although it surprised me a bit to start
stepping immediately when doing the C-u C-M-x.
--- i/test/lisp/emacs-lisp/lisp-tests.el
+++ w/test/lisp/emacs-lisp/lisp-tests.el
@@ -320,12 +320,10 @@ elisp-tests-with-temp-buffer
of the form =!NAME= in CONTENTS are removed, and a for each one a
variable called NAME is bound to the position of the word's
start."
- (declare (indent 1) (debug (form body)))
+ (declare (indent 1) (debug (def-form body)))
(let* ((var-pos nil)
(text (with-temp-buffer
- (insert (cond ((symbolp contents)
- (symbol-value contents))
- (t contents)))
+ (insert (eval contents))
(goto-char (point-min))
(while (re-search-forward elisp-test-point-position-regex nil t)
(push (list (intern (match-string-no-properties 1))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 03 May 2017 05:27:02 GMT)
Full text and
rfc822 format available.
Message #257 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-30, at 18:10, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> 2. I still don't fully get the `eval-and-compile' stuff. What exactly
>> happens when the file is compiled?
>
> During compilation, (eval-and-compile E) will be treated (i.e. compiled)
> just like E, except that E is evaluated along the way (so the
> definitions present in E are available during compilation).
>
>> I understand that its forms are not evaluated.
>
> They are. It's for `eval-when-compile` that they aren't.
Thanks for your answer, but I'm still not sure. Are the tables below
right?
Running:
| form | evaled? | compiled? |
|---------------------------------+---------+-----------|
| (defun ...) | yes | no |
| (eval-when-compile (defun ...)) | no | no |
| (eval-and-compile (defun ...)) | yes | no |
| (defmacro ...) | yes | no |
Compilation:
| form | evaled? | compiled? |
|---------------------------------+---------+-----------|
| (defun ...) | no | yes |
| (eval-when-compile (defun ...)) | yes | yes |
| (eval-and-compile (defun ...)) | yes | yes |
| (defmacro ...) | yes | yes |
TIA,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 03 May 2017 08:44:01 GMT)
Full text and
rfc822 format available.
Message #260 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
> Thanks for your answer, but I'm still not sure. Are the tables below
> right?
>
> Running:
>
> | form | evaled? | compiled? |
> |---------------------------------+---------+-----------|
> | (defun ...) | yes | no |
> | (eval-when-compile (defun ...)) | no | no |
> | (eval-and-compile (defun ...)) | yes | no |
> | (defmacro ...) | yes | no |
I find this table very confusing. Does the second column really mean
"Is the form evaluated when it is compiled when it is not compiled"?
I suggest to have a look at the definitions. AFAICT the semantics of
`eval-when-compile' and `eval-and-compile' are defined by (1) their
regular definitions in byte-run.el and (2) the specifications in the
definition of `byte-compile-initial-macro-environment'. Even if you
don't know much details, it all should be human readable.
Regards,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 03 May 2017 12:46:01 GMT)
Full text and
rfc822 format available.
Message #263 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> Running:
I assume you mean "without compilation" (i.e. using only the .el file).
> | form | evaled? | compiled? |
> |---------------------------------+---------+-----------|
> | (defun ...) | yes | no |
> | (eval-when-compile (defun ...)) | no | no |
^^
yes
> Compilation:
And
> | form | evaled? | compiled? |
> |---------------------------------+---------+-----------|
> | (defun ...) | no | yes |
> | (eval-when-compile (defun ...)) | yes | yes |
^^^
no
Instead, the whole expression is compiled as a constant holding the
value returned from the evaluation. Hence this can be used for things
like (eval-when-compile (+ 3 4)).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 03 May 2017 15:21:01 GMT)
Full text and
rfc822 format available.
Message #266 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-05-01, at 00:21, npostavs <at> users.sourceforge.net wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> This suggests that the first arg is not "evaluated by the macro itself
>> at compile time", but instead is passed unevaluated to `insert`, in
>> which case it can't be instrumented.
>
> Oh, I see, this patch works, although it surprised me a bit to start
> stepping immediately when doing the C-u C-M-x.
>
> --- i/test/lisp/emacs-lisp/lisp-tests.el
> +++ w/test/lisp/emacs-lisp/lisp-tests.el
> @@ -320,12 +320,10 @@ elisp-tests-with-temp-buffer
> of the form =!NAME= in CONTENTS are removed, and a for each one a
> variable called NAME is bound to the position of the word's
> start."
> - (declare (indent 1) (debug (form body)))
> + (declare (indent 1) (debug (def-form body)))
> (let* ((var-pos nil)
> (text (with-temp-buffer
> - (insert (cond ((symbolp contents)
> - (symbol-value contents))
> - (t contents)))
> + (insert (eval contents))
> (goto-char (point-min))
> (while (re-search-forward elisp-test-point-position-regex nil t)
> (push (list (intern (match-string-no-properties 1))
Hi Stefan and Noam,
I finally analyzed Noam's code, and the very same thing occurred to me:
that using `(eval contents)' would both be more reasonable (after all,
CONTENTS might be neither a symbol nor a string, but some expression!)
and at the same time consistent with Noam's rewording of the docstring.
Thanks!
I'm in a train now, and with limited access to the internet, so I'll get
back to this thread (and push the branch after clean-up - I guess I'll
have to delete the current branch first, right?) soon.
It's good that the Emacs manuals are available offline - I'll read about
arguments to `debug' now. ;-)
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 09 May 2017 12:39:01 GMT)
Full text and
rfc822 format available.
Message #269 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Hi Noam, Stefan et al.,
I finally found some time to make the branch nicer, deleted it from the
server and pushed the new one. Could you look at it one more time and
merge it to master (or greenlight me to do it)?
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 10 May 2017 02:53:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
> I finally found some time to make the branch nicer, deleted it from the
> server and pushed the new one. Could you look at it one more time and
> merge it to master (or greenlight me to do it)?
[[c1c3403cf2]]
> Fix Bug#21072 and rework `mark-defun'
>
> * test/lisp/progmodes/elisp-mode-tests.el (mark-defun-test-buffer):
> New variable
> (mark-defun-no-arg-region-inactive)
> (mark-defun-no-arg-region-active)
> (mark-defun-arg-region-active)
> (mark-defun-pos-arg-region-inactive)
There should be a colon after the close paren on each of those lines.
> (mark-defun-neg-arg-region-inactive, mark-defun-bob): Add tests for
> the new `mark-defun'
>
> * lisp/emacs-lisp/lisp.el (beginning-of-defun--in-emptyish-line-p):
> New function
> (beginning-of-defun-comments): New function
> (mark-defun): Fix bug#21072, also rewrite large parts of `mark-defun'
> to accept a numerical prefix argument
There should be a period at the end of each entry.
[[aeed45da]]
> * lisp/emacs-lisp/lisp.el (mark-defun): simplify moving the point
Missing capitalization and period (if you're not just squashing this).
[[b8fd2c2ca1]]
> * Fix elisp-tests-with-temp-buffer compilation
[...]
Please add to this the patch from
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21072#254.
[[7efd2f2ea1]]
> Modify `beginning-of-defun-comments'
If you are keeping this one, I would add to the commit message:
* lisp/emacs-lisp/lisp.el (beginning-of-defun-comments): Try not to stop
in the middle of a multiline comment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 10 May 2017 03:17:02 GMT)
Full text and
rfc822 format available.
Message #275 received at 21072 <at> debbugs.gnu.org (full text, mbox):
>> * test/lisp/progmodes/elisp-mode-tests.el (mark-defun-test-buffer):
>> New variable
>> (mark-defun-no-arg-region-inactive)
>> (mark-defun-no-arg-region-active)
>> (mark-defun-arg-region-active)
>> (mark-defun-pos-arg-region-inactive)
> There should be a colon after the close paren on each of those lines.
Actually, AFAIK the normal "many functions" format looks like:
* filename (functionname1, functionname2)
(functionname3, functionname4)
(functionname5, functionname6)
(functionname7, functionname8): New functions.
we even tried to make the auto-fill code DTRT in the change-log-mode.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 10 May 2017 03:30:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Actually, AFAIK the normal "many functions" format looks like:
>
> * filename (functionname1, functionname2)
> (functionname3, functionname4)
> (functionname5, functionname6)
> (functionname7, functionname8): New functions.
>
> we even tried to make the auto-fill code DTRT in the change-log-mode.
Oh, huh, I took the example in CONTRIBUTE (under "Preferred form for
several entries with the same content:") to mean that lines should end
with colon, but I guess that only applies to multiple file entries, not
functions? The GNU ChangeLog standards do indeed say to end the line
with just a close paren [1].
[1]: https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Wed, 10 May 2017 16:33:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 21072 <at> debbugs.gnu.org (full text, mbox):
> From: npostavs <at> users.sourceforge.net
> Date: Tue, 09 May 2017 23:31:24 -0400
> Cc: Marcin Borkowski <mbork <at> mbork.pl>, 21072 <at> debbugs.gnu.org
>
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> > Actually, AFAIK the normal "many functions" format looks like:
> >
> > * filename (functionname1, functionname2)
> > (functionname3, functionname4)
> > (functionname5, functionname6)
> > (functionname7, functionname8): New functions.
> >
> > we even tried to make the auto-fill code DTRT in the change-log-mode.
>
> Oh, huh, I took the example in CONTRIBUTE (under "Preferred form for
> several entries with the same content:") to mean that lines should end
> with colon, but I guess that only applies to multiple file entries, not
> functions?
Yes, correct.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 12 May 2017 09:42:02 GMT)
Full text and
rfc822 format available.
Message #284 received at 21072 <at> debbugs.gnu.org (full text, mbox):
On 2017-05-10, at 04:53, npostavs <at> users.sourceforge.net wrote:
> Marcin Borkowski <mbork <at> mbork.pl> writes:
>
>> I finally found some time to make the branch nicer, deleted it from the
>> server and pushed the new one. Could you look at it one more time and
>> merge it to master (or greenlight me to do it)?
>
> [[c1c3403cf2]]
>> Fix Bug#21072 and rework `mark-defun'
>>
>> * test/lisp/progmodes/elisp-mode-tests.el (mark-defun-test-buffer):
>> New variable
>> (mark-defun-no-arg-region-inactive)
>> (mark-defun-no-arg-region-active)
>> (mark-defun-arg-region-active)
>> (mark-defun-pos-arg-region-inactive)
>
> There should be a colon after the close paren on each of those lines.
>
>> (mark-defun-neg-arg-region-inactive, mark-defun-bob): Add tests for
>> the new `mark-defun'
>>
>> * lisp/emacs-lisp/lisp.el (beginning-of-defun--in-emptyish-line-p):
>> New function
>> (beginning-of-defun-comments): New function
>> (mark-defun): Fix bug#21072, also rewrite large parts of `mark-defun'
>> to accept a numerical prefix argument
>
> There should be a period at the end of each entry.
>
> [[aeed45da]]
>> * lisp/emacs-lisp/lisp.el (mark-defun): simplify moving the point
>
> Missing capitalization and period (if you're not just squashing this).
>
>
> [[b8fd2c2ca1]]
>> * Fix elisp-tests-with-temp-buffer compilation
> [...]
>
> Please add to this the patch from
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21072#254.
>
> [[7efd2f2ea1]]
>> Modify `beginning-of-defun-comments'
>
> If you are keeping this one, I would add to the commit message:
>
> * lisp/emacs-lisp/lisp.el (beginning-of-defun-comments): Try not to stop
> in the middle of a multiline comment.
Thanks.
All done, branch deleted and pushed again. Hopefully it's ok now. (I'm
still learning to write commit messages...)
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Fri, 12 May 2017 20:32:01 GMT)
Full text and
rfc822 format available.
Message #287 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> mbork.pl> writes:
> All done, branch deleted and pushed again. Hopefully it's ok now.
Looks good to me.
> (I'm still learning to write commit messages...)
Turns out, so am I :)
Reply sent
to
Marcin Borkowski <mbork <at> mbork.pl>:
You have taken responsibility.
(Sun, 14 May 2017 05:13:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Raffaele Ricciardi <rfflrccrd <at> gmail.com>:
bug acknowledged by developer.
(Sun, 14 May 2017 05:13:02 GMT)
Full text and
rfc822 format available.
Message #292 received at 21072-done <at> debbugs.gnu.org (full text, mbox):
On 2017-05-12, at 11:42, Marcin Borkowski <mbork <at> mbork.pl> wrote:
> All done, branch deleted and pushed again. Hopefully it's ok now. (I'm
> still learning to write commit messages...)
Hi all,
since seemingly nobody objected, I merged my branch into master and
marked the bug as done.
Best,
--
Marcin Borkowski
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Mon, 15 May 2017 00:18:02 GMT)
Full text and
rfc822 format available.
Message #295 received at 21072 <at> debbugs.gnu.org (full text, mbox):
It seems this causes two python tests to fail.
See eg http://hydra.nixos.org/build/52829789
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Tue, 16 May 2017 22:37:02 GMT)
Full text and
rfc822 format available.
Message #298 received at 21072 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> It seems this causes two python tests to fail.
> See eg http://hydra.nixos.org/build/52829789
It seems again to be an issue of different behaviour with
transient-mark-mode disabled.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21072; Package
emacs.
(Sat, 20 May 2017 22:29:02 GMT)
Full text and
rfc822 format available.
Message #301 received at 21072 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> Glenn Morris <rgm <at> gnu.org> writes:
>
>> It seems this causes two python tests to fail.
>> See eg http://hydra.nixos.org/build/52829789
>
> It seems again to be an issue of different behaviour with
> transient-mark-mode disabled.
I've set the tests to use transient-mark-mode [1: ee54d2f4e4], we might
have to revisit the non transient-mark-mode behaviour though.
[1: ee54d2f4e4]: 2017-05-20 18:28:23 -0400
; Set transient-mark-mode to let mark-defun tests pass
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee54d2f4e439b4a211c8fb7541ce22bac65bde8f
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 18 Jun 2017 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.