2:33 p.m.
I retransmit a kind of bug report posted to local newsgroup:
Suppose there is a
(desktop-read)
in init.el, and
(custom-set-variables '(user-mail-address "morozov(a)novosoft.ru")),
in custom.el. Now if desktop being read contains .html file then
html-mode asks again and again: "Your mail address: alex＠localhost" or
something like that, because it is not yet customized.
Surely one can move (setq user-mail-address "") to init.el, before
(desktop-read), but there must be a more generic way to address that
issue, what do you think?
There probably exists a reason not to simply swap the order of
execution of init.el and custom.el...
Probably there could appear something like "phase3.el"?
--alexm
10:03 a.m.
Alexey Mahotkin <alexm(a)hsys.msk.ru> wrote:
Suppose there is a
(desktop-read)
in init.el, and
(custom-set-variables '(user-mail-address "morozov(a)novosoft.ru")),
in custom.el. Now if desktop being read contains .html file then
html-mode asks again and again: "Your mail address: alex＠localhost" or
something like that, because it is not yet customized.
Surely one can move (setq user-mail-address "") to init.el, before
(desktop-read), but there must be a more generic way to address that
issue, what do you think?
You can try to swap the order of custom / init files reading. That's
what I do at the top of my init file:
,----
| (let ((real-custom-file custom-file))
| (setq custom-file "nonsense")
| (load real-custom-file)
| (add-hook 'after-init-hook
| `(lambda () (setq custom-file ,real-custom-file)))
| )
`-----
Note that depending on the XEmacs version you use, the variable
`custom-file' might not exist at the time of evaluating this form (this is a
recent feature of 21.5). If you're not using a 21.5 version, you must replace
`custom-file' by the explicit file name instead. Stephen might have applied
the corresponding patch to the gamma series, but I don't know.
There probably exists a reason not to simply swap the order of
execution of
init.el and custom.el...
Probably... actually, I can't remember what it is and I had planned to
search in the archives, but it's quite a long time ago.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org
10:59 a.m.
>>>> "drv" == Didier Verna
<didier(a)xemacs.org> writes:
drv> Note that depending on the XEmacs version you use, the
drv> variable `custom-file' might not exist at the time of
drv> evaluating this form (this is a recent feature of 21.5). If
drv> you're not using a 21.5 version, you must replace
drv> `custom-file' by the explicit file name instead. Stephen
drv> might have applied the corresponding patch to the gamma
drv> series, but I don't know.
No, I'm waiting on further comment (none until today, no help yet) and
screams of pain from 21.5 users (none so far, I'm leaning to applying
since it gives a way to fix the no-way-to-set-mule-fonts-in-init.el
bug). Also, I want a look at the thread about why not to switch the
order of custom.el and init.el.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
5:11 a.m.
Didier Verna wrote:
Alexey Mahotkin <alexm(a)hsys.msk.ru> wrote:
> Suppose there is a
>
> (desktop-read)
>
> in init.el, and
>
> (custom-set-variables '(user-mail-address "morozov(a)novosoft.ru")),
>
> in custom.el. Now if desktop being read contains .html file then
> html-mode asks again and again: "Your mail address: alex＠localhost" or
> something like that, because it is not yet customized.
>
> Surely one can move (setq user-mail-address "") to init.el, before
> (desktop-read), but there must be a more generic way to address that
> issue, what do you think?
You can try to swap the order of custom / init files reading. That's
what I do at the top of my init file:
,----
| (let ((real-custom-file custom-file))
| (setq custom-file "nonsense")
| (load real-custom-file)
| (add-hook 'after-init-hook
| `(lambda () (setq custom-file ,real-custom-file)))
| )
`-----
Note that depending on the XEmacs version you use, the variable
`custom-file' might not exist at the time of evaluating this form (this is a
recent feature of 21.5). If you're not using a 21.5 version, you must replace
`custom-file' by the explicit file name instead. Stephen might have applied
the corresponding patch to the gamma series, but I don't know.
> There probably exists a reason not to simply swap the order of execution of
> init.el and custom.el...
Probably... actually, I can't remember what it is and I had planned to
search in the archives, but it's quite a long time ago.
the reason is called "hystery".
btw in Arch XEmacs, written years ago [!], it says in
http://www.xemacs.org/Architecting-XEmacs/init-files.html:
The custom init file is where the custom package writes its options. This
obviously needs to be a separate file from the standard init file. It should
also be loaded before the init file rather than after, as is usually done
currently, so that the init file can override these options if it wants to.
imo we should just change the order and see what happens.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
7:22 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> btw in Arch XEmacs, written years ago [!], it says in
Ben> http://www.xemacs.org/Architecting-XEmacs/init-files.html:
Ben> The custom init file is where the custom package writes its options. This
Ben> obviously needs to be a separate file from the standard init file. It should
Ben> also be loaded before the init file rather than after, as is usually done
Ben> currently, so that the init file can override these options if it wants to.
Ben> imo we should just change the order and see what happens.
I have no objections, given Didier's testing. When I split the files,
I was merely trying to preserve the historical order.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
10:31 a.m.
Ben Wing <ben(a)666.com> writes:
The custom init file is where the custom package writes its options.
This
obviously needs to be a separate file from the standard init file. It should
also be loaded before the init file rather than after, as is usually done
currently, so that the init file can override these options if it
wants to.
Please don't change the order.
Init file can override Custom options although custom is loaded later.
Custom is much smarter than it looks. I can elaborate if you want.
10:43 a.m.
Hrvoje Niksic wrote:
Ben Wing <ben(a)666.com> writes:
> The custom init file is where the custom package writes its options. This
> obviously needs to be a separate file from the standard init file. It
> should also be loaded before the init file rather than after, as is
> usually done currently, so that the init file can override these options
> if it wants to.
Please don't change the order.
Init file can override Custom options although custom is loaded later.
True, but that doesn't make it a good argument *not* to change the
order. There are more important problems, like starting packages from the init
files, resulting in customizations not being set up when the package is run.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org
10:51 a.m.
Didier Verna <didier(a)xemacs.org> writes:
True, but that doesn't make it a good argument *not* to change
the
order.
Of course. I just wanted to prevent changing something that works for
frivolous reasons. However:
There are more important problems, like starting packages from the
init files, resulting in customizations not being set up when the
package is run.
I agree that it is a good reason. Maybe we should, for additional
safety, ask Per Abrahamsen what he thinks about the ordering change?
11:10 a.m.
Hrvoje Niksic wrote:
Didier Verna <didier(a)xemacs.org> writes:
> True, but that doesn't make it a good argument *not* to change the
> order.
Of course. I just wanted to prevent changing something that works for
frivolous reasons. However:
> There are more important problems, like starting packages from the
> init files, resulting in customizations not being set up when the
> package is run.
I agree that it is a good reason. Maybe we should, for additional
safety, ask Per Abrahamsen what he thinks about the ordering change?
Yup. I still can see an argument one could raise against changing the
order:
- with the current order, you can 1/ change the custom file name and 2/ load
it before (the rest of) the init file (in order words, swap the order).
- with the opposite order, you can do neither of these.
Actually, you probably could, if we provided command line options for doing
that.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org
11:18 a.m.
Didier Verna <didier(a)xemacs.org> writes:
- with the current order, you can 1/ change the custom file name and
2/ load
it before (the rest of) the init file (in order words, swap the
order).
3/ choose to not load it at all, dependent on the phase of the moon
(and without having to use a command-line option.)
12:11 p.m.
you guys should read my
http://www.xemacs.org/Architecting-XEmacs/init-files.html.
i talk about rearranging things to fix a whole lot of problems [e.g. loading the
init file *before* mapping the first frame], and allow for many things that are
currently impossible.
but as for your arguments below, the fact that you *can* rearrange to fix
problems doesn't change the fact that the default is wrong for 99% of the
users. the rest can use a command-line argument [or my pre-init mechanism,
mentioned in that file above -- if and when it ever gets implemented].
furthermore, your args aren't even correct.
you can always put your own elisp in custom.el -- custom will preserve it no
problem when saving out its values.
so with the switched order, you can 1/ force the init file to be loaded first,
2/ change its name, or 3/ not load it at all -- something you can't currently do
except with command-line args.
[sorry, i had to do it :-]
Didier Verna wrote:
Hrvoje Niksic wrote:
> Didier Verna <didier(a)xemacs.org> writes:
>
> > True, but that doesn't make it a good argument *not* to change the
> > order.
>
> Of course. I just wanted to prevent changing something that works for
> frivolous reasons. However:
>
> > There are more important problems, like starting packages from the
> > init files, resulting in customizations not being set up when the
> > package is run.
>
> I agree that it is a good reason. Maybe we should, for additional
> safety, ask Per Abrahamsen what he thinks about the ordering change?
Yup. I still can see an argument one could raise against changing the
order:
- with the current order, you can 1/ change the custom file name and 2/ load
it before (the rest of) the init file (in order words, swap the order).
- with the opposite order, you can do neither of these.
Actually, you probably could, if we provided command line options for doing
that.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
10:26 a.m.
re: Reading the init file before mapping the first frame...
I run XEmacs from a shell script that starts it with -unmapped -f
gnuserv-start, and then only after XEmacs is all the way up does it
use gnuclient to bring up the first frame.
It works a lot better this way. On my laptop, I've got the color
scheme and faces set up to give me a light on black color scheme and
smaller frames for the old 800x600 laptop's screen. Without the
-unmapped start up, though, the initial frame is standard grey and
standard size, and only when I use `C-x 5 2' do I get light on black
with the smaller frame size.
10:58 a.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> Ben Wing <ben(a)666.com> writes:
> The custom init file is where the custom package writes its
options. This
> obviously needs to be a separate file from the standard init file. It should
> also be loaded before the init file rather than after, as is usually done
> currently, so that the init file can override these options if it
> wants to.
Hrvoje> Please don't change the order.
Hrvoje> Init file can override Custom options although custom is loaded later.
Hrvoje> Custom is much smarter than it looks. I can elaborate if you want.
I'd appreciate it.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11:12 a.m.
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hrvoje> Init file can override Custom options although custom is
loaded later.
Hrvoje> Custom is much smarter than it looks. I can elaborate if you want.
I'd appreciate it.
The following explanation only elaborates on why it is OK for
custom-set-variables to be executed after .emacs. It does not argue
that it shouldn't be executed before.
custom-set-variables differs from an ordinary `setq' in your .emacs in
that it doesn't set the value of any of the variables. They merely
store the Lisp expression that is to calculate the value into a
property of the symbol.
Only when the `defcustom' form is evaluated, this property gets
evaluated too, and stored to the symbol's value slot. This is
important because it allows "dependent" things to work. For instance,
if you have:
(defcustom foo 3
...)
(defcustom bar (* foo 5) ; default
...)
Then, if you customize `foo' to 4 and don't touch bar, `bar' will be
correctly set to 20.
Regardless of all this, `defcustom' retains the important property of
`defvar' which is that it doesn't touch the value of variables which
are bound (already have a value). So if you say:
(setq foo 132)
then the custom-set-variables will still set the property, but
defcustom will *not* change the value. That's how the Customize
buffer knows that a value has been "modified outside customize".
12:38 p.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> The following explanation only elaborates on why it is OK
Hrvoje> for custom-set-variables to be executed after .emacs. It
Hrvoje> does not argue that it shouldn't be executed before.
Unfortunately, custom-set-faces is not so polite. I've never
understood why custom-set-faces considers it OK to automatically and
silently reset, that is, clear, specifiers, especially for the default
face. In 21.4.2 it _still_ trashes any setting the user makes for
Asian fonts in the init file unless the incantation is exactly right
(and this is nowhere documented as of three months ago, and changes
occasionally).
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
12:59 p.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Unfortunately, custom-set-faces is not so polite.
I know. :-(
I've never understood why custom-set-faces considers it OK to
automatically and silently reset, that is, clear, specifiers,
especially for the default face.
Because it's buggy. Even worse, it resets the properties that it
doesn't even know about.
3:29 p.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Only when the `defcustom' form is evaluated, this property gets evaluated
too, and stored to the symbol's value slot. This is important because it
allows "dependent" things to work. For instance, if you have:
(defcustom foo 3
...)
(defcustom bar (* foo 5) ; default
...)
Then, if you customize `foo' to 4 and don't touch bar,
`bar' will be
correctly set to 20.
I must be dense, because it seems to me that it would work just as well
with `setq'. I.e. if I do (setq foo 4), the above piece of code will
first not-do-anything with foo and then set bar to 20.
So in what situation does the order really matter ?
Of course, it matters if you do (custom-set-variables '((bar (* foo 6)))),
but I don't think I've ever seen anyone do that, and I'm not even sure
if custom could generate such a statement (as opposed to someone writing it
manually).
Stefan
3:37 p.m.
"Stefan Monnier" <monnier+lists.xemacs.beta/news/(a)RUM.cs.yale.edu>
writes:
So in what situation does the order really matter ?
Of course, it matters if you do (custom-set-variables '((bar (* foo 6)))),
but I don't think I've ever seen anyone do that, and I'm not even sure
if custom could generate such a statement
State->Edit as Lisp Expression
8400
days inactive
8407
days old
17 comments
8 participants
participants (8)
-
Alexey Mahotkin -
Ben Wing -
Didier Verna -
Hrvoje Niksic -
Karl M. Hegbloom -
Michael Sperber -
Stefan Monnier -
Stephen J. Turnbull