Richard Stallman <[EMAIL PROTECTED]> writes:
> I think the current situation is best, it fixed the bug that the behavior
> was different when loading the .el file than when loading the .elc file.
>
> Sorry, I've decided I won't let this change remain installed.
> We will not move towards i
I think the current situation is best, it fixed the bug that the behavior
was different when loading the .el file than when loading the .elc file.
Sorry, I've decided I won't let this change remain installed.
We will not move towards increased use of custom-current-group.
If there was a b
define-generic-mode didn't have any defcustom forms in the past. I
added one for the mode hook variable a few days ago. So the change I
propose is backward compatible.
Ok, please do it.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug
Richard Stallman <[EMAIL PROTECTED]> writes:
> There seem to be 85 calls to define-minor-mode in the Emacs sources.
> I guess the first order of business would be to make sure each of them
> has an explicit :group.
I'll check them.
Lute.
___
Emacs-pr
After Lute's patch the define-minor-mode for `diff-minor-mode' would
have to be given an explicit :group, or diff-minor-mode-hook would be
moved from the diff-mode group (where it belongs) to the bogus
diff-minor group (if I understood Lute's patch correctly). I am now
convince
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> After Lute's patch the define-minor-mode for `diff-minor-mode' would
> have to be given an explicit :group, or diff-minor-mode-hook would be
> moved from the diff-mode group (where it belongs) to the bogus
> diff-minor group (if I understood Lute's patch
> * diff-mode.el (diff-minor-mode): Specify :group.
> * font-core.el (font-lock-mode): Specify :group.
> * reveal.el (reveal-mode): Specify :group.
> * smerge-mode.el (smerge-mode): Specify :group.
[...]
Does it make sense to have a :group for buffer-local minor modes?
The whole point of the use of custom-current-group is to try and default to
the group that was defined in the current file. Such a group is unlikely to
be "bogus".
My decision is to move away from such file-position-dependent defaults.
__
> rms didn't like this new behavior so the second patch I posted (and
> did not install yet) merely changes the behavior of define-major-mode
> back to the situation before 2005-03-31. So implying that my (second)
> patch has big consequences is not really fair.
I didn't realize you hadn't instal
>> There seem to be 85 calls to define-minor-mode in the Emacs sources.
>> I guess the first order of business would be to make sure each of them
>> has an explicit :group.
>
> I'll check them.
Done. If somebody wants to double-check, I committed these changes:
2005-04-04 Lute Kamstra <[EMAIL
Stefan Monnier wrote:
Does it make sense to have a :group for buffer-local minor modes?
I believe that currently, for a buffer-local minor mode foo-mode,
define-minor-mode does not define a defcustom for the mode variable,
but defines one for foo-mode-hook. I believe that this hook is
global.
After Lute's patch the define-minor-mode for `diff-minor-mode' would
have to be given an explicit :group, or diff-minor-mode-hook would be
moved from the diff-mode group (where it belongs) to the bogus
diff-minor group (if I understood Lute's patch correctly). I am now
convinced that there must be
Stefan Monnier wrote:
The whole point of the use of custom-current-group is to try and default to
the group that was defined in the current file. Such a group is unlikely to
be "bogus". I still think it's a much better default and it shouldn't
be removed.
I did not actually check th
> But, I guess that at the present state it will be difficult to do that
> and get rid of `custom-current-group', because many things already
> rely on `custom-current-group'. What we definitely could and, I
> believe should, do is discourage people from relying on it, because it
> is quite simply
>The use of custom-current-group seems like a bad practice to me.
[...]
> The reason for that is that most of the time the default group chosen
> by define-minor-mode is a bogus group without one of the major groups
> as its ancestors.
The whole point of the use of custom-current-group is to t
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Lute Kamstra wrote:
>
>All these things apply just as well to a :group value you specify
>explicitly. I think it's enough (and a good thing) that the user of
>define-minor-mode knows that :group defaults and to what.
>
> The docstring should
Lute Kamstra wrote:
All these things apply just as well to a :group value you specify
explicitly. I think it's enough (and a good thing) that the user of
define-minor-mode knows that :group defaults and to what.
The docstring should at least point out that this group might very
well be
Richard Stallman <[EMAIL PROTECTED]> writes:
[...]
> I also defined the :group for the defcustom of the mode hook variable
> of a generic mode with custom-current-group. So I'd like to add an
> extra argument to define-generic-mode to specify the value for :group.
>
> I see nothing w
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Richard Stallman wrote:
>
>The use of custom-current-group seems like a bad practice to me.
>It is unreliable to make one defun depend on whatever was lying around
>from a previous defun in this way. It has the result that moving
>code f
> So I think it would be better to document that define-minor-mode
> and easy-mmode-define-global-mode default the group based
> solely on the mode name.
Ok, that was the actual behavior up till now anyway. For
define-minor-mode and easy-mmode-define-global-mode, it doesn't ma
Richard Stallman wrote:
The use of custom-current-group seems like a bad practice to me.
It is unreliable to make one defun depend on whatever was lying around
from a previous defun in this way. It has the result that moving
code from one place in a file to another changes its meaning
Richard Stallman <[EMAIL PROTECTED]> writes:
> The use of custom-current-group seems like a bad practice to me.
> It is unreliable to make one defun depend on whatever was lying around
> from a previous defun in this way. It has the result that moving
> code from one place in a file to another ch
The use of custom-current-group seems like a bad practice to me.
It is unreliable to make one defun depend on whatever was lying around
from a previous defun in this way. It has the result that moving
code from one place in a file to another changes its meaning.
So I think it would be better to d
> which is evaluated at compile-time. custom-current-group uses
> load-file-name, which is nil at compile-time, so custom-current-group
> returns nil at compile-time too. This doesn't seem the intended
> behavior. What about the patch below?
Looks good, please install,
Stefan
__
In define-minor-mode and easy-mmode-define-global-mode, the default
:group value for defcustom calls is calculated by means of
(or (custom-current-group)
(intern (replace-regexp-in-string
"-mode\\'" "" mode-name)))
which is evaluated at compile-time. custom-current-grou
25 matches
Mail list logo
