GNU bug report logs -
#25294
26.0.50; Allow more catch-all values for cl-defmethod's &context plus major-mode specializer
Previous Next
Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Date: Thu, 29 Dec 2016 19:14:02 UTC
Severity: wishlist
Tags: moreinfo
Found in version 26.0.50
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
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 25294 in the body.
You can then email your comments to 25294 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#25294
; Package
emacs
.
(Thu, 29 Dec 2016 19:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eric Abrahamsen <eric <at> ericabrahamsen.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 29 Dec 2016 19:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When defining a method using cl-defmethod with the &context and
major-mode specializer, there should be more acceptable options for
catch-all or fall-through methods. Ie, we want to create a method that
fires regardless of the major mode. These signatures don't work, but
should:
(cl-defmethod example-method ((&context (major-mode fundamental-mode))))
(cl-defmethod example-method ((&context (major-mode nil)))
(cl-defmethod example-method ((&context (major-mode t))))
Right now the only thing that works is:
(cl-defmethod example-method ())
In GNU Emacs 26.0.50.9 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.5)
of 2016-12-26 built on clem
Repository revision: 65b997b95e284e2edc1266663e39791f68d76ad7
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Recent messages:
Reading active file via nndraft...done
Reading active file from MTester via nnmairix...done
Checking new news...done
Saving the EBDB... done
Saving Gnus registry (4516 entries) to ~/Documents/Sync/plusone/gnus.registry.eieio...
Saving Gnus registry (size 4516) to ~/Documents/Sync/plusone/gnus.registry.eieio...done
Saving /home/eric/.emacs.d/.newsrc.eld...
Saving file /home/eric/.emacs.d/.newsrc.eld...
Wrote /home/eric/.emacs.d/.newsrc.eld
Saving /home/eric/.emacs.d/.newsrc.eld...done
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 LIBSYSTEMD
Important settings:
value of $LC_CTYPE: zh_CN.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Fri, 30 Dec 2016 04:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 25294 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> When defining a method using cl-defmethod with the &context and
> major-mode specializer,
Is this about the undocumented specializer mentioned in cl-generic.el?
;;; Dispatch on major mode.
;; Two parts:
;; - first define a specializer (derived-mode <mode>) to match symbols
;; representing major modes, while obeying the major mode hierarchy.
;; - then define a context-rewriter so you can write
;; "&context (major-mode c-mode)" rather than
;; "&context (major-mode (derived-mode c-mode))".
> there should be more acceptable options for
> catch-all or fall-through methods. Ie, we want to create a method that
> fires regardless of the major mode.
If you want to ignore the major mode, why do you want to use the
major-mode specializer?
> These signatures don't work, but
> should:
>
> (cl-defmethod example-method ((&context (major-mode fundamental-mode))))
>
Should that be
(cl-defmethod example-method (&context (major-mode fundamental-mode)))
The reason this doesn't work is because fundamental isn't actually the
parent mode of text-mode or prog-mode, i.e., (get 'text-mode
'derived-mode-parent) => nil.
> (cl-defmethod example-method ((&context (major-mode nil)))
>
> (cl-defmethod example-method ((&context (major-mode t))))
>
> Right now the only thing that works is:
>
> (cl-defmethod example-method ())
Severity set to 'wishlist' from 'normal'
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Sat, 31 Dec 2016 23:09:02 GMT)
Full text and
rfc822 format available.
Added tag(s) moreinfo.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Sat, 31 Dec 2016 23:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Mon, 11 Dec 2017 23:58:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 25294 <at> debbugs.gnu.org (full text, mbox):
Ahem, I only just noticed (a year later) that there was a response to
this when I searched for bug reports I'd opened -- sorry about that.
> Is this about the undocumented specializer mentioned in cl-generic.el?
>
> ;;; Dispatch on major mode.
>
> ;; Two parts:
> ;; - first define a specializer (derived-mode <mode>) to match symbols
> ;; representing major modes, while obeying the major mode hierarchy.
> ;; - then define a context-rewriter so you can write
> ;; "&context (major-mode c-mode)" rather than
> ;; "&context (major-mode (derived-mode c-mode))".
Yes, that's it.
>> there should be more acceptable options for
>> catch-all or fall-through methods. Ie, we want to create a method that
>> fires regardless of the major mode.
>
> If you want to ignore the major mode, why do you want to use the
> major-mode specializer?
It's the equivalent of the "t" branch in a `cond' statement. You write
methods to handle specific major modes, and write another method to
handle the catch-all case of "all other modes".
>> These signatures don't work, but
>> should:
>>
>> (cl-defmethod example-method ((&context (major-mode fundamental-mode))))
>>
>
> Should that be
>
> (cl-defmethod example-method (&context (major-mode fundamental-mode)))
>
> The reason this doesn't work is because fundamental isn't actually the
> parent mode of text-mode or prog-mode, i.e., (get 'text-mode
> 'derived-mode-parent) => nil.
Right -- I still think either t or nil should do it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Tue, 12 Dec 2017 00:09:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 25294 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> Ahem, I only just noticed (a year later) that there was a response to
> this when I searched for bug reports I'd opened -- sorry about that.
It's had lots of time to rest then :)
>> If you want to ignore the major mode, why do you want to use the
>> major-mode specializer?
>
> It's the equivalent of the "t" branch in a `cond' statement. You write
> methods to handle specific major modes, and write another method to
> handle the catch-all case of "all other modes".
Still not really convinced by this, what's wrong with the last way you
put in your OP:
(cl-defmethod example-method ())
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Tue, 12 Dec 2017 01:40:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 25294 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[forwarding to list]
[Message part 2 (message/rfc822, inline)]
On 12/11/17 19:08 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Ahem, I only just noticed (a year later) that there was a response to
>> this when I searched for bug reports I'd opened -- sorry about that.
>
> It's had lots of time to rest then :)
>
>>> If you want to ignore the major mode, why do you want to use the
>>> major-mode specializer?
>>
>> It's the equivalent of the "t" branch in a `cond' statement. You write
>> methods to handle specific major modes, and write another method to
>> handle the catch-all case of "all other modes".
>
> Still not really convinced by this, what's wrong with the last way you
> put in your OP:
>
> (cl-defmethod example-method ())
A year later, older and wiser, I agree that maybe all that's needed is
more documentation. I just noticed that, at some point in the interim,
the documentation for generic functions has been greatly expanded, which
is nice!
I'd like to add the following to the docs:
1. The &context thing has to come after the required arguments, but
before any &optional or &rest things.
2. You can have an arbitrary number of forms following &context.
3. The &context arguments don't have to match the declared arguments in
`cl-defgeneric'.
4. Ergo they can be left off altogether without needing to be
specifically declared as nil or what have you, ie, my original bug
report isn't really a bug.
If this looks okay, I'll have at the docs.
Eric
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Tue, 12 Dec 2017 01:44:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 25294 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Subject: Re: bug#25294: 26.0.50; Allow more catch-all values for cl-defmethod's &context plus major-mode specializer
> To: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Mon, 11 Dec 2017 16:49:14 -0800 (51 minutes, 9 seconds ago)
>
>> Still not really convinced by this, what's wrong with the last way you
>> put in your OP:
>>
>> (cl-defmethod example-method ())
>
> A year later, older and wiser, I agree that maybe all that's needed is
> more documentation. I just noticed that, at some point in the interim,
> the documentation for generic functions has been greatly expanded, which
> is nice!
>
> I'd like to add the following to the docs:
>
> 1. The &context thing has to come after the required arguments, but
> before any &optional or &rest things.
> 2. You can have an arbitrary number of forms following &context.
> 3. The &context arguments don't have to match the declared arguments in
> `cl-defgeneric'.
> 4. Ergo they can be left off altogether without needing to be
> specifically declared as nil or what have you, ie, my original bug
> report isn't really a bug.
>
> If this looks okay, I'll have at the docs.
Sounds good to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Tue, 12 Dec 2017 05:43:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 25294 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> [forwarding to list]
Whoops, sorry.
[...]
>> A year later, older and wiser, I agree that maybe all that's needed is
>> more documentation. I just noticed that, at some point in the interim,
>> the documentation for generic functions has been greatly expanded, which
>> is nice!
>>
>> I'd like to add the following to the docs:
>>
>> 1. The &context thing has to come after the required arguments, but
>> before any &optional or &rest things.
>> 2. You can have an arbitrary number of forms following &context.
>> 3. The &context arguments don't have to match the declared arguments in
>> `cl-defgeneric'.
>> 4. Ergo they can be left off altogether without needing to be
>> specifically declared as nil or what have you, ie, my original bug
>> report isn't really a bug.
>>
>> If this looks okay, I'll have at the docs.
> Sounds good to me.
Here's my diff.
[context-spec-docs.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Tue, 12 Dec 2017 23:59:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 25294 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> +Generic functions provide a new argument-list keyword,
The way you phrased this might lead me to think that the &context
keyword should go in the cl-defgeneric form (maybe it's not so bad when
seeing in context under cl-defmethod, in patch form it's a bit
disconnected).
> +@code{&context}, which can be used to introduce extra specializers
> +that test the general environment in which the method is run. This
> +keyword should appear after the list of required arguments, but before
> +any @code{&rest} or @code{&optional} keywords.
I wonder if it would be clearer to add this to the @defmac header?
@defmac cl-defmethod name [qualifier] arguments [&context (expr spec)@dots{}] &rest [docstring] body
Hmm, maybe that ends up being too long.
> The @code{&context}
> +specializers look much like regular argument
> +specializers---(@var{expr} @var{spec})---except that @var{expr} is an
> +expression to be evaluated in the current context, and the @var{spec}
> +is a value to compare against. For example, @code{&context
> +(overwrite-mode (eql t))} will make the method applicable only when
> +@code{overwrite-mode} is turned on. The @code{&context} keyword can
> +be followed by any number of context specializers. Because the
> +context specializers are not part of the generic function's required
> +argument signature, they may be omitted in methods that don't require
> +them.
Otherwise looks fine.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Thu, 14 Dec 2017 00:07:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 25294 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> +Generic functions provide a new argument-list keyword,
>
> The way you phrased this might lead me to think that the &context
> keyword should go in the cl-defgeneric form (maybe it's not so bad when
> seeing in context under cl-defmethod, in patch form it's a bit
> disconnected).
Maybe so, yes. I'll look at it in context and see if I can't make that a
little clearer.
>> +@code{&context}, which can be used to introduce extra specializers
>> +that test the general environment in which the method is run. This
>> +keyword should appear after the list of required arguments, but before
>> +any @code{&rest} or @code{&optional} keywords.
>
> I wonder if it would be clearer to add this to the @defmac header?
>
> @defmac cl-defmethod name [qualifier] arguments [&context (expr spec)@dots{}] &rest [docstring] body
>
> Hmm, maybe that ends up being too long.
I never found those things very helpful, and that does look a little long...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25294
; Package
emacs
.
(Thu, 14 Dec 2017 21:02:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 25294 <at> debbugs.gnu.org (full text, mbox):
close 25294
quit
On 12/12/17 18:58 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> +Generic functions provide a new argument-list keyword,
>
> The way you phrased this might lead me to think that the &context
> keyword should go in the cl-defgeneric form (maybe it's not so bad when
> seeing in context under cl-defmethod, in patch form it's a bit
> disconnected).
>
>> +@code{&context}, which can be used to introduce extra specializers
>> +that test the general environment in which the method is run. This
>> +keyword should appear after the list of required arguments, but before
>> +any @code{&rest} or @code{&optional} keywords.
>
> I wonder if it would be clearer to add this to the @defmac header?
>
> @defmac cl-defmethod name [qualifier] arguments [&context (expr spec)@dots{}] &rest [docstring] body
>
> Hmm, maybe that ends up being too long.
>
>> The @code{&context}
>> +specializers look much like regular argument
>> +specializers---(@var{expr} @var{spec})---except that @var{expr} is an
>> +expression to be evaluated in the current context, and the @var{spec}
>> +is a value to compare against. For example, @code{&context
>> +(overwrite-mode (eql t))} will make the method applicable only when
>> +@code{overwrite-mode} is turned on. The @code{&context} keyword can
>> +be followed by any number of context specializers. Because the
>> +context specializers are not part of the generic function's required
>> +argument signature, they may be omitted in methods that don't require
>> +them.
>
> Otherwise looks fine.
>
Okay, that's pushed, I ended up adding the bit to the defmac statement
after all, it wraps and shouldn't be too big a deal.
Thanks,
Eric
bug closed, send any further explanations to
25294 <at> debbugs.gnu.org and Eric Abrahamsen <eric <at> ericabrahamsen.net>
Request was from
Eric Abrahamsen <eric <at> ericabrahamsen.net>
to
control <at> debbugs.gnu.org
.
(Thu, 14 Dec 2017 21:02:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 12 Jan 2018 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 210 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.