>Loading a file should change Emacs's state as little as possible, so the
>init-value of a minor mode should *describe* (not determine) the default
>state of the minor-mode (in the case where the minor-mode function is not
>executed).
> I understood that. However setting the mode
Your arguments seem persuasive. If nobody comes up with
a strong objection in a few days, please install your patch.
But please also add a comment explaining briefly what
the remaining problem is.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http:/
Stefan Monnier wrote:
Please check the commit-history of this piece of code (e.g. with
vc-annotate) to see that it used to do what you say it "should" do
(i.e. also call the minor-mode function if the init-value is non-nil).
First of all, I assume the lack of reaction to my patch mean
> The code I propose to remove does not take care of a problem which the
> original code it replaced did address and which the current comment
> still falsely claims it addresses: loading the file does currently
> _not_ enable the minor mode if the standard value is non-nil and the
> minor mode var
Since the current version of `define-minor-mode', is incompatible with
the new :initialize function customize-initialize-safe-default,
_something_ needs to be done. (It currently breaks the building of
Emacs on certain operating systems and additional uses of
customize-initialize-safe-default coul
Richard Stallman wrote:
It would be cleaner to do the same thing for :set and :type--to suppress
the default one when there is an explicit one.
Done.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman
>From my previous message:
So, to do what the comment says, we should replace the default
:initialize for minor modes from 'custom-initialize-default to
'custom-initialize-set.
Well actually, one might need to replace `custom-initialize-default'
with a new :initialize function, custom-in
Here is the code:
;; If the mode is global, call the function according to the default.
,(if globalp
`(if (and load-file-name (not (equal ,init-value ,mode)))
(eval-after-load load-file-name '(,mode (if ,mode 1 -1
I believe that this code definitely s
Can you prevent users and Custom from doing it? If not, the "should not"
consideration is fairly meaningless.
No code can prevent users from making mistakes. No code can reliably
correct user mistakes and I do not believe that one should try to do
that. Just alert the user that there may
Stefan Monnier wrote:
>Miles complained loudly (in the form of comments, some of which
>may still be in the current elisp code ;-)
> These comments make no sense.
If you do not understand them, I fear you may not understand the problem
well enough to judge what's the least
>AFAIK, the motivation was also for some other cases where the user may
>somehow setq the variable before loading the file. IIRC this setq may
>actually be done by Custom (at a time where it doesn't yet know that
>the var have a :setter).
> The user should not set a minor mode var
More precisely, without my changes, if you specify an explicit
:initialize keyword, the expansion of the define-minor-mode form
contains two :initialize keywords, first
":initialize 'custom-initialize-default" and then, at some later place
the explicit :initialize.
That's not c
Stefan Monnier wrote:
AFAIK, the motivation was also for some other cases where the user may
somehow setq the variable before loading the file. IIRC this setq may
actually be done by Custom (at a time where it doesn't yet know that the var
have a :setter).
The user should not set a m
> I have the impression that the offending code in define-minor-mode:
> ;; If the mode is global, call the function according to the default.
>,(if globalp
>`(if (and load-file-name (not (equal ,init-value ,mode)))
>(eval-after-load load-file-name '(,mode (if ,mo
>From my previous message:
There is the question of whether my changes should be reverted. They
do not result in any change in behavior whatsoever, but they avoid
confusion for somebody who expands the macro to see what the
define-minor-mode form he wrote really does (as anybody who u
Richard Stallman wrote:
Please install the doc string changes.
Actually, after rechecking things today, it appears that my changes to
the define-minor-mode code concerning the :initialize keyword were not
necessary. I tested things yesterday and that testing seemed to show
that the changes we
I have the impression that the offending code in define-minor-mode:
;; If the mode is global, call the function according to the default.
,(if globalp
`(if (and load-file-name (not (equal ,init-value ,mode)))
(eval-after-load load-file-name '(,mode (if ,mode 1 -1
The culprit is this code in define-minor-mode. That code is strange,
since it does exactly what custom-initialize-default tries to avoid:
;; If the mode is global, call the function according to the default.
,(if globalp
`(if (and load-file-name (not (equal ,init-value ,mode)))
> On Wed, 13 Jul 2005 21:08:55 -0500 (CDT), Luc Teirlinck <[EMAIL
> PROTECTED]> said:
> I reinstalled my original changes, deleted the autoload for tooltip
> mode and committed my changes to define-minor-mode. The two last
> steps should enable Emacs to be built on Mac OS 9, even with my
I reinstalled my original changes, deleted the autoload for tooltip
mode and committed my changes to define-minor-mode. The two last
steps should enable Emacs to be built on Mac OS 9, even with my
changes, although I can not test that.
Unfortunately, I can not reinstate the use of
`
Unfortunately, I can not reinstate the use of
`custom-reevaluate-setting' for tooltip-mode in startup.el. Unless we
would be willing to load tooltip.el even on systems where it makes no
sense, we just have to live with the code duplication here.
How do you reach this conclusion?
I forgot that the argument to defcustom gets evaluated outside the
:initialize function. I will implement another solution.
I don't think so. Here's the body of `defcustom':
(nconc (list 'custom-declare-variable
(list 'quote symbol)
(list 'quote val
Richard Stallman wrote:
I am not sure that method would work well, but maybe it would.
However, sticking with the present approach is safer.
We know it can't ignore errors for variables we did not intend
that for.
I agree. The alternative might, at the very least, require compiler
de
I forgot to mention that the reported bug concerning
`blink-cursor-mode' was due to define-minor-mode overriding the
":initialize 'custom-initialize-safe-default" with
`custom-initialize-default'. The patch I sent prevents
define-minor-mode from overriding an explicitly specified
`:initialize' key
YAMAMOTO Mitsuharu wrote:
> I tried the latest CVS with Mac OS 9, which cannot dump, but it
> failed to load frame.elc with "Symbol's value as variable is void:
> no-blinking-cursor" on startup. Strangely, the rest of the similar
> cases (such as loading tooltip.elc) worked well.
>From my previous message:
I forgot that the argument to defcustom gets evaluated outside the
:initialize function. I will implement another solution.
Actually I just reverted most of my changes, until we decide on what
to do with the problem. The two new :initialize functions probably
sh
I reverted most of my previous changes. Emacs should now build
correctly on all operating systems (unless it fails to do so for
unrelated reasons), but I can not check this, as I only have access to
GNU/Linux.
Sincerely,
Luc.
___
Emacs-devel mailing
I forgot that the argument to defcustom gets evaluated outside the
:initialize function. I will implement another solution. Also,
tooltip-mode can not use custom-reevaluate-setting, because it would
load tooltip on systems where we decided it should not be loaded. So
I will undo my change to sta
> On Tue, 12 Jul 2005 13:13:35 +0900, YAMAMOTO Mitsuharu <[EMAIL
> PROTECTED]> said:
> I tried the latest CVS with Mac OS 9, which cannot dump, but it
> failed to load frame.elc with "Symbol's value as variable is void:
> no-blinking-cursor" on startup. Strangely, the rest of the similar
> On Sat, 9 Jul 2005 08:57:34 -0500 (CDT), Luc Teirlinck <[EMAIL
> PROTECTED]> said:
> The expression now gets evaluated inside a condition-case, and if an
> error occurs, the value is set to nil, without throwing an error.
> The actual value at that stage is irrelevant, it is later
> ree
Stupid question: instead of having two initialization functions that
need to replace the normal initializers for preloaded stuff, wouldn't
it be easier to simply redefine the _standard_ initialization
functions in an Emacs used for dumping?
I don't think we want to disguise unexpec
David Kastrup wrote:
Stupid question: instead of having two initialization functions that
need to replace the normal initializers for preloaded stuff, wouldn't
it be easier to simply redefine the _standard_ initialization
functions in an Emacs used for dumping?
That would disable erro
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> This is good, but
>
> + These two functions are only meant for options defined in pre-loaded
> + files, where some variables or functions used to compute the option's
> + value may not yet be defined. The option normally gets updated
This is good, but
+ These two functions are only meant for options defined in pre-loaded
+ files, where some variables or functions used to compute the option's
+ value may not yet be defined. The option normally gets updated in
+ @file{startup.el}, ignoring the previously compute
This concerns the documentation for the two new :initialize functions.
They are kind of internal and hence I believe that maybe they do not
need to be mentioned in the already very long NEWS. On the other
hand, maybe it might be useful to mention them in the Elisp manual,
for instance because peop
If the solution below looks OK I will document it in the Elisp manual.
This is a clever solution. Please install it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Eli Zaretskii wrote:
You are removing the test for display-graphic-p being fboundp, but the
ChangeLog entry for the change which introduced that test clearly says:
* tooltip.el (tooltip-mode): `emacs-quick-startup' and
`display-graphic-p' may not be bound yet.
I wa
> Date: Fri, 8 Jul 2005 22:57:19 -0500 (CDT)
> From: Luc Teirlinck <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> The following patch to tooltip.el simplifies the standard value of the
> tooltip-mode defcustom further than my original version.
You are removing the test for d
The following patch to tooltip.el simplifies the standard value of the
tooltip-mode defcustom further than my original version.
The remaining `(fboundp 'x-show-tip)' is really necessary, even after
startup.
===File ~/tooltip.el-diff===
*** tooltip.el 04 Jul 2005 1
Question: How will users see/detect/understand this behavior? What will they
see in "Show initial Lisp expression"?
They will see an expression that recomputes the standard value
based on whatever conditions are relevant.
My approach, like the one Luc's original one, avoids the need
to co
Doing this work is the only way to get the benefit, so let's do it.
If the solution below looks OK I will document it in the Elisp manual.
Other people will need to help with this, since I do not fancy
handling all 20-30 options, some of which I know nothing about, all
by myself.
I actually us
Drew Adams wrote:
Or what about just reusing keyword :initialize, perhaps redefining its
behavior to recognize this special case? After all, this is about
initializing the value. The case could be distinguished by supplying
:initialize with an argument `custom-initialize-set-runtime' (
(defvar rogue-var) ;; to silence the compiler for the next line.
(unless (default-boundp rogue-var) (setq rogue-var nil))
(defcustom rogue-var ...
...
:initialize 'custom-initialize-set
...)
Suppose we implement a keyword in defcustom that caus
(defvar rogue-var) ;; to silence the compiler for the next line.
(unless (default-boundp rogue-var) (setq rogue-var nil))
(defcustom rogue-var ...
...
:initialize 'custom-initialize-set
...)
Suppose we implement a keyword in defcustom that causes it to generate
all that.
What about my "real" question, about the tool-bar being "useless" on
MS Windows?
I do not use MS Windows, so I do not know. If you use MS Windows and
you actually can use the tool-bar, that part of the remark _must_ be
obsolete I guess. Maybe it still would turn on the tool-bar in other
si
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> This is one of between 20 and 30 (I forgot the exact number) options
> with a similar problem. Start `emacs -Q', do `M-x customize-rogue'
> and you get the list. If you choose "Erase Customization" for them in
> a Custom buffer, very unexpected things
Mathias Dahl wrote:
I found this in tool-bar.el:
;; We want to pretend the toolbar by standard is on, as this will make
;; customize consider disabling the toolbar a customization, and save
;; that. We could do this for real by setting :init-value above, but
;; tha
47 matches
Mail list logo
