4:27 a.m.
I went through just now and looked through the diff of "fixup", one of my
workspaces and perhaps the largest.
Following is an approximate list of the contents:
1. Cleanup configure, redo configure and various other code so that GTK and
X support are independent and both possible at once
2. HAVE_SHLIB -> HAVE_MODULES
3. has-modeline-p -> modeline-visible-p
4. Move set-extent-* accessors to Lisp
5. Sync font-lock with FSF 21.2
6. Create a "splash frame" that pops up early, before XEmacs loads the init
file, similar to the way many modern apps work; add hackery to support this
(e.g. "no-title-bar" frame property)
7. Add code to optionally install hyper-apropos as the standard help system
8. Add define-minor-mode and other constructs to
lisp-function-and-type-regexp
9. Load custom file before init file
10. define string-to-syntax as alias for syntax-string-to-code
11. Rewrite the text property implementation for speed (possibly not
finished); also implement FSF-compatible front-sticky, rear-nonsticky, etc.
+;; We used to create one extent for each distinct property; that is, if a
+;; range of text has two text-properties on it, there would be two extents.
+;; The problem is that the extent code gets much slower in this case,
+;; especially when you have one extent that straddles the entire buffer --
+;; and this is exactly what happens with lazy-lock, which sets
+;; `lazy-lock-fontified' to t on all regions that are up-to-date.
+
+;; Therefore, we now use just one extent to track all text properties in a
+;; region, and have *NO* overlapping text-property extents (#### Not
+;; actually true if duplicable and non-duplicable properties are mixed).
+;; The value of `text-prop' is a list indicating all properties being
+;; governed.
12. Mule-ize all of GTK code
13. Factor out duplicated X/GTK event key code into event-xlike.c; likewise
for duplicated gccache code
14. Add (unimplemented) stubs for (set-)char-table-parent
15. Add weak-list, extent(+substructures) usage to memory-usage stats
16. Use LISP_STRING_TO_SIZED_EXTERNAL and friends in place of generic
TO_EXTERNAL_FORMAT in many places
17. LIST_LOOP -> OLD_LIST_LOOP
18. Correct some places in device-x.c etc. that incorrectly use Qctext
19. doprnt can now take data from lisp or C string (why?)
20. implement insert-(before-markers-)and-inherit separate from insert
21. Factor out duplicated X/MSW/GTK XBM and XFACE code
22. Add function write_string_to_lstream (used where?)
23. Type-correct rewriting in various places (int->Bytecount, char->Ascbyte,
etc.)
12:15 p.m.
Hi Ben,
thanks for the heads-up!
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> I went through just now and looked through the diff of "fixup", one of
my
Ben> workspaces and perhaps the largest.
Ben> 9. Load custom file before init file
This doesn't seem like a good idea because it will break many folks'
setups. Haven't we had plenty of discussion on this?
Ben> 15. Add weak-list, extent(+substructures) usage to memory-usage
Ben> stats
Could you route GC-related patches through Marcus Crestani
<marcus(a)crestani.de>, as he also has a large evolving workspace on this.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
4:10 p.m.
Hi Ben,
Thanks for sending this summary along. It really helps to let us see
what you have in the pipeline. Most of this stuff is _really_
exciting. See my comments inline.
"Ben Wing" <ben(a)666.com> writes:
I went through just now and looked through the diff of
"fixup", one of my
workspaces and perhaps the largest.
Following is an approximate list of the contents:
1. Cleanup configure, redo configure and various other code so that GTK and
X support are independent and both possible at once
Sounds like a good idea. Personally, I think migrating completely to
autoconf 2.59 would be fine for the 21.5 (22.0) release.
2. HAVE_SHLIB -> HAVE_MODULES
3. has-modeline-p -> modeline-visible-p
4. Move set-extent-* accessors to Lisp
5. Sync font-lock with FSF 21.2
This _sounds_ like a win, but how disruptive would this be?
6. Create a "splash frame" that pops up early, before
XEmacs loads the init
file, similar to the way many modern apps work; add hackery to support this
(e.g. "no-title-bar" frame property)
Personally, I'd rather not slow down startup at all, but I'm open to
others' thoughts.
7. Add code to optionally install hyper-apropos as the standard help
system
Great idea!
8. Add define-minor-mode and other constructs to
lisp-function-and-type-regexp
9. Load custom file before init file
As Michael has pointed out, I think we've discussed this one to death,
and I wouldn't want to see a change in this area.
10. define string-to-syntax as alias for syntax-string-to-code
11. Rewrite the text property implementation for speed (possibly not
finished); also implement FSF-compatible front-sticky, rear-nonsticky, etc.
+;; We used to create one extent for each distinct property; that is, if a
+;; range of text has two text-properties on it, there would be two extents.
+;; The problem is that the extent code gets much slower in this case,
+;; especially when you have one extent that straddles the entire buffer --
+;; and this is exactly what happens with lazy-lock, which sets
+;; `lazy-lock-fontified' to t on all regions that are up-to-date.
+
+;; Therefore, we now use just one extent to track all text properties in a
+;; region, and have *NO* overlapping text-property extents (#### Not
+;; actually true if duplicable and non-duplicable properties are mixed).
+;; The value of `text-prop' is a list indicating all properties being
+;; governed.
Sounds really good. Potentially disruptive, but the gain is probably
worth the pain. Definitely needs to be finished, though.
12. Mule-ize all of GTK code
13. Factor out duplicated X/GTK event key code into event-xlike.c; likewise
for duplicated gccache code
Yes!
14. Add (unimplemented) stubs for (set-)char-table-parent
15. Add weak-list, extent(+substructures) usage to memory-usage stats
16. Use LISP_STRING_TO_SIZED_EXTERNAL and friends in place of generic
TO_EXTERNAL_FORMAT in many places
17. LIST_LOOP -> OLD_LIST_LOOP
18. Correct some places in device-x.c etc. that incorrectly use Qctext
19. doprnt can now take data from lisp or C string (why?)
20. implement insert-(before-markers-)and-inherit separate from insert
21. Factor out duplicated X/MSW/GTK XBM and XFACE code
Yes!
22. Add function write_string_to_lstream (used where?)
23. Type-correct rewriting in various places (int->Bytecount, char->Ascbyte,
etc.)
So, my bottom line is that much of what you propose is great stuff -
big visionary changes that will help move the code base forward
(consolidating X/GTK, etc), most of the rest of it is conceptually ver
good but potentially very disruptive (perhaps buggy) stuff and the
last bit (init vs. customize) is not OK.
So, I don't think we can accept this whole-hog. If you were willing
to break out the pieces that the review board found unacceptable, I
would be grateful for you to check this in, provided:
1. You finished off the unfinished parts.
2. You posted the code (or checked it in on a branch) for a week or 2
so we could all build and experiment with it. Ideally, you'd give
us a little warning beforehand so we could clear our decks and
spend some time working with the new code. 1 or 2 weeks after you
send out the patch (or check in on a branch), I would be OK with
your checking in to 21.5,
3. This is probably the most important part - you have to promise to
stay around to work through the issues that will inevitably arise
after your checkins. You have made enormous contributions to the
XEmacs project, but when you disappear for long stretches of time,
the rest of us don't know how to proceed with the codebase. It's
as if in the evolution of the XEmacs project, we don't quite reach
the equilibrium part of the punctuated equilibrium, because you
almost deliver us to the next level but then you disappear. To be
fair, this time you have been much easier to work with and I know
that you have worked hard to get here. Also, there's no way to
tell if your RSI might act up, so you can't make promises on that
score, but I'm asking for a good faith promise that you will
attempt to stick with us and work with us as we use your code as
the basis for a revitalized XEmacs 22.0.
What do you think?
- Vin
11:44 a.m.
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
vin> "Ben Wing" <ben(a)666.com> writes:
> I went through just now and looked through the diff of
"fixup",
> one of my workspaces and perhaps the largest.
My immediate time crunch is over; if it would help discussion/
decision/integration, post this and I'll get to work on splitting it
as I did with littlefix (I think it was). It will take some time, but
I can post pieces as I go.
vin> Sounds like a good idea. Personally, I think migrating
vin> completely to autoconf 2.59 would be fine for the 21.5 (22.0)
vin> release.
+1
> 2. HAVE_SHLIB -> HAVE_MODULES
+1
> 3. has-modeline-p -> modeline-visible-p
"'tis better to be internally consistent than not, but 'tis better to
be GNU-compatible than sane." Is this variable not available in GNU?
> 4. Move set-extent-* accessors to Lisp
Why?
> 5. Sync font-lock with FSF 21.2
vin> This _sounds_ like a win, but how disruptive would this be?
It's a big win, unless you consider Gnus, AUCTeX, and JDEE little
applications. (At least, and there are plenty of posts to c.e.x
saying "I want to create a tiny mode with just syntax highlighting but
`set-font-lock-keywords' doesn't work", etc.) Unless we're going to
do the humane thing and euthanize the current font-lock implementation
entirely, this needs to be done ASAP (IMHO).
> 6. Create a "splash frame" that pops up early, before
XEmacs
> loads the init file, similar to the way many modern apps work;
> add hackery to support this (e.g. "no-title-bar" frame
> property)
vin> Personally, I'd rather not slow down startup at all, but I'm
vin> open to others' thoughts.
This doesn't need to slow things down much at all---even if there's a
big pixmap or something, it's a small number of X roundtrips, and it
would greatly simplify the working with the WM_COMMAND stuff. If X
roundtrips don't matter, then delay will be unnoticable, I think. (I
could be missing something.)
> 7. Add code to optionally install hyper-apropos as the standard
> help system
vin> Great idea!
> 8. Add define-minor-mode and other constructs to
> lisp-function-and-type-regexp
> 9. Load custom file before init file
vin> As Michael has pointed out, I think we've discussed this one
vin> to death, and I wouldn't want to see a change in this area.
The conclusion of the discussion as I recall it was that
init-before-custom is broken in theory and practice as an API and
violates POLA as a UI (users expect their customizations to be in
effect when their init files are executed, as they are when they test
them interactively). As I recall the discussion people were worried
about hypothetical breakage in init files if we switched, but all the
actual examples of breakage were due to init-before-custom (to the
extent that there are several people habitually using the device in
Ben's sample.init.el to load custom first), and all the theoretical
examples of breakage due to the change would be easily fixed without
hacking in something equivalent to reverting the change.
I agree that this is a potentially dangerous and surprising change,
and for that reason it should be done as quickly as possible.
> 10. define string-to-syntax as alias for syntax-string-to-code
Why? It's less precise.
> 11. Rewrite the text property implementation for speed
> (possibly not finished); also implement FSF-compatible
> front-sticky, rear-nonsticky, etc.
+1
> 12. Mule-ize all of GTK code
> 13. Factor out duplicated X/GTK event key code into event-xlike.c; likewise
> for duplicated gccache code
-1 on all GTK v1 work. It's a waste of time at this point---my
understanding is that many GTK v2 APIs are dramatically different.
We may very well just throw out much of this GTK code.
> 14. Add (unimplemented) stubs for (set-)char-table-parent
Are chartables used to implement syntax tables? If so, will this buy
us syntax parents which are currently hurting us in both Gnus and
AUCTeX? If yes and yes, this is high priority.
> 15. Add weak-list, extent(+substructures) usage to memory-usage
stats
> 16. Use LISP_STRING_TO_SIZED_EXTERNAL and friends in place of generic
> TO_EXTERNAL_FORMAT in many places
> 17. LIST_LOOP -> OLD_LIST_LOOP
> 18. Correct some places in device-x.c etc. that incorrectly use Qctext
> 19. doprnt can now take data from lisp or C string (why?)
> 20. implement insert-(before-markers-)and-inherit separate from
> insert
+0 (ie, yes unless htey're rskier than they look)
> 21. Factor out duplicated X/MSW/GTK XBM and XFACE code
vin> Yes!
+1 despite the comment on GTK above.
> 22. Add function write_string_to_lstream (used where?)
> 23. Type-correct rewriting in various places (int->Bytecount, char->Ascbyte,
> etc.)
As for conditionns on accepting the code ... all I can say is that if
we're going to say no to this, we're basically saying we're not going
to release anything in this calendar year, and maybe not in the next.
I can live with that (and I probably will not even leave XEmacs :-).
But IMHO that is the choice because I don't see another leader. I
can't do it this year, for sure.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
11:27 a.m.
>> 3. has-modeline-p -> modeline-visible-p
"'tis better to be internally consistent than not, but 'tis
better to be GNU-compatible than sane." Is this variable not
available in GNU?
I doubt it. I vaguely remember creating this monster myself, when for some
reason I couldn't think of the obviously better name.
>> 4. Move set-extent-* accessors to Lisp
Why?
Just to eliminate some useless C code.
>> 5. Sync font-lock with FSF 21.2
vin> This _sounds_ like a win, but how disruptive would this be?
It's a big win, unless you consider Gnus, AUCTeX, and JDEE
little applications. (At least, and there are plenty of
posts to c.e.x saying "I want to create a tiny mode with just
syntax highlighting but `set-font-lock-keywords' doesn't
work", etc.) Unless we're going to do the humane thing and
euthanize the current font-lock implementation entirely, this
needs to be done ASAP (IMHO).
>> 6. Create a "splash frame" that pops up early, before XEmacs
>> loads the init file, similar to the way many modern apps work;
>> add hackery to support this (e.g. "no-title-bar" frame
>> property)
vin> Personally, I'd rather not slow down startup at all, but I'm
vin> open to others' thoughts.
This doesn't need to slow things down much at all---even if
there's a big pixmap or something, it's a small number of X
roundtrips, and it would greatly simplify the working with
the WM_COMMAND stuff. If X roundtrips don't matter, then
delay will be unnoticable, I think. (I could be missing something.)
Currently, under Windows this frame pops up almost immediately, and then
many seconds later, after much path grinding, it goes away and the normal
frame appears. This frame could also be used for any messages prior to
popping up the first frame, and eventually for moving the creation of the
first normal frame till *after* loading the init file, which would make it
extremely easy to customize the size of the first frame. (This is an
*ooollllldddd* proposal from Arch. XEmacs.)
BTW This "splash-frame" is a normal frame of the sort used in dialog boxes,
with the added feature of having no title bar (the new `no-title-bar' frame
property; only implemented on Windows currently, I need to get docs on the
various ways of communicating with window managers under X to control the
decorations. Can all of you X-ers go look up any docs on window managers
you may have at hand and tell me what the tricks are? Also I'd like the
names of the most common Window managers out there. Alternatively, maybe
this should just be created override-redirect or something? DOes that make
sense?)
>> 7. Add code to optionally install hyper-apropos as the
standard
>> help system
vin> Great idea!
>> 8. Add define-minor-mode and other constructs to
>> lisp-function-and-type-regexp
>> 9. Load custom file before init file
vin> As Michael has pointed out, I think we've discussed this one
vin> to death, and I wouldn't want to see a change in this area.
The conclusion of the discussion as I recall it was that
init-before-custom is broken in theory and practice as an API
and violates POLA as a UI (users expect their customizations
to be in effect when their init files are executed, as they
are when they test them interactively). As I recall the
discussion people were worried about hypothetical breakage in
init files if we switched, but all the actual examples of
breakage were due to init-before-custom (to the extent that
there are several people habitually using the device in Ben's
sample.init.el to load custom first), and all the theoretical
examples of breakage due to the change would be easily fixed
without hacking in something equivalent to reverting the change.
I agree that this is a potentially dangerous and surprising
change, and for that reason it should be done as quickly as possible.
>> 10. define string-to-syntax as alias for syntax-string-to-code
Why? It's less precise.
Because it's FSF-compatible.
>> 11. Rewrite the text property implementation for speed
>> (possibly not finished); also implement FSF-compatible
>> front-sticky, rear-nonsticky, etc.
+1
>> 12. Mule-ize all of GTK code
>> 13. Factor out duplicated X/GTK event key code into
event-xlike.c; likewise
>> for duplicated gccache code
-1 on all GTK v1 work. It's a waste of time at this
point---my understanding is that many GTK v2 APIs are
dramatically different. We may very well just throw out much
of this GTK code.
1] it's already done.
2] it's probably not a waste of time. (NB In my glyphs workspace I have also
factored out much of the code shared between redisplay-x.c and
redisplay-gtk.c in the form of "xlike" input methods that implement
lower-level operations.) Most of what has been factored is stuff that's not
specific to X or GTK, with the appropriate X or GTK stuff stuck in through
ifdefs, or sometimes device methods. As long as GTK v2 is parallel to X in
its basic model, the same approach will apply, and I strongly suspect it
will be, especially at the lower level where we care about because [1] GTK
v2 will surely want to be networkable, and X is the only well-known
networking system that's built ground-up to do this; [2] GTK v2 is going to
be running on top of X much of the time, hence it would not behoove it to
have a conceptually incompatible low level; [3] people rarely completely
throw away previous conceptual models, esp. at the lower levels, and in the
cases they do, it's all the rarer (and usually suicidal) for them to start
from scratch without looking at any model at all -- so what would they
choose? Windows or MAC? Doesn't seem too likely.
But I may be putting my foot in my mouth.
>> 14. Add (unimplemented) stubs for (set-)char-table-parent
Are chartables used to implement syntax tables?
Yes
If so, will
this buy us syntax parents which are currently hurting us in
both Gnus and AUCTeX?
Most likely. But don't we already have an `inherit' syntax code, which
works fine? Presumably this is not what you're referring to?
>> 15. Add weak-list, extent(+substructures) usage to
memory-usage stats
>> 16. Use LISP_STRING_TO_SIZED_EXTERNAL and friends in
place of generic
>> TO_EXTERNAL_FORMAT in many places
>> 17. LIST_LOOP -> OLD_LIST_LOOP
>> 18. Correct some places in device-x.c etc. that
incorrectly use Qctext
>> 19. doprnt can now take data from lisp or C string (why?)
>> 20. implement insert-(before-markers-)and-inherit separate from
>> insert
+0 (ie, yes unless htey're rskier than they look)
>> 21. Factor out duplicated X/MSW/GTK XBM and XFACE code
vin> Yes!
+1 despite the comment on GTK above.
>> 22. Add function write_string_to_lstream (used where?)
>> 23. Type-correct rewriting in various places
(int->Bytecount, char->Ascbyte,
>> etc.)
As for conditionns on accepting the code ... all I can say is
that if we're going to say no to this, we're basically saying
we're not going to release anything in this calendar year,
and maybe not in the next. I can live with that (and I
probably will not even leave XEmacs :-). But IMHO that is the
choice because I don't see another leader. I can't do it
this year, for sure.
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1
Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:22 p.m.
"Ben Wing" <ben(a)666.com> writes:
[..]
> >> 6. Create a "splash frame" that pops up
early, before XEmacs
> >> loads the init file, similar to the way many modern apps work;
> >> add hackery to support this (e.g. "no-title-bar" frame
> >> property)
>
> vin> Personally, I'd rather not slow down startup at all, but I'm
> vin> open to others' thoughts.
>
> This doesn't need to slow things down much at all---even if
> there's a big pixmap or something, it's a small number of X
> roundtrips, and it would greatly simplify the working with
> the WM_COMMAND stuff. If X roundtrips don't matter, then
> delay will be unnoticable, I think. (I could be missing something.)
Currently, under Windows this frame pops up almost immediately, and then
many seconds later, after much path grinding, it goes away and the normal
frame appears. This frame could also be used for any messages prior to
popping up the first frame, and eventually for moving the creation of the
first normal frame till *after* loading the init file, which would make it
extremely easy to customize the size of the first frame. (This is an
*ooollllldddd* proposal from Arch. XEmacs.)
BTW This "splash-frame" is a normal frame of the sort used in dialog boxes,
with the added feature of having no title bar (the new `no-title-bar' frame
property; only implemented on Windows currently, I need to get docs on the
various ways of communicating with window managers under X to control the
decorations. Can all of you X-ers go look up any docs on window managers
you may have at hand and tell me what the tricks are? Also I'd like the
names of the most common Window managers out there. Alternatively, maybe
this should just be created override-redirect or something? DOes that make
sense?)
Yes i think having override-redirect is most prefferable. It lefts
window appearance and look to creator and will work with every window
manager.
NET_WM[1] has hints about window type, among supported types there is a
splash type. However there is many window managers that does not
support NET_WM.
I think emacs-like window managers are popular among XEmacs users:
such as ratpoison, ion, wmi, larswm, etc. most of them are non-NET_WM
awared window managers.
[..]
----
[1] http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html
--
lg
11:47 a.m.
My immediate time crunch is over; if it would help
discussion/ decision/integration, post this and I'll get to
work on splitting it as I did with littlefix (I think it
was). It will take some time, but I can post pieces as I go.
It was probably `lilfix' ... And that was named even *before* I moved to
Texas:)
BTW This one is called `fixup' and it's fitting since it's much bigger than
`lilfix':)
Anyway, I'm thinking of committing it on a branch. At this point it
compiles and runs on Windows, and compiles and at least builds OK under
Cygwin+X+GTK, but I need to do some more testing -- esp. on the font-lock
and new-text-property stuff -- and that will entail some code changes, so if
you're going to extract piecemeal it would be best for you to extract from
the latest code on the branch and in an order I will present you, according
to the most stable first.
I'll also need some help testing on GTK platforms, until (unless) I figure
out how to get GTK v1 working on Cygwin -- I can compile OK but can't run.
Ben
8:44 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
>> 9. Load custom file before init file
vin> As Michael has pointed out, I think we've discussed this one
vin> to death, and I wouldn't want to see a change in this area.
Stephen> The conclusion of the discussion as I recall it was that
Stephen> init-before-custom is broken in theory and practice as an API and
Stephen> violates POLA as a UI (users expect their customizations to be in
Stephen> effect when their init files are executed, as they are when they test
Stephen> them interactively). As I recall the discussion people were worried
Stephen> about hypothetical breakage in init files if we switched, but all the
Stephen> actual examples of breakage were due to init-before-custom (to the
Stephen> extent that there are several people habitually using the device in
Stephen> Ben's sample.init.el to load custom first), and all the theoretical
Stephen> examples of breakage due to the change would be easily fixed without
Stephen> hacking in something equivalent to reverting the change.
Stephen> I agree that this is a potentially dangerous and surprising change,
Stephen> and for that reason it should be done as quickly as possible.
I remember differently, mainly that it's possible to get
custom-before-init with the current setup (by loading the custom stuff
at the top of init.el), but that it's much harder to get the reverse
under the reverse setup.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
5:02 a.m.
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> I remember differently, mainly that it's possible to get
ms> custom-before-init with the current setup (by loading the
ms> custom stuff at the top of init.el), but that it's much harder
ms> to get the reverse under the reverse setup.
Huh? Name the custom file "perverse-order-custom.el", and put
(setq custom-file (expand-file-name "perverse-order-custom.el"
user-init-directory)
(load custom-file)
at the end of the init file. No? Whereas with custom-after-init, you
need to jump through hoops with `after-init-hook' to avoid loading
custom-file twice.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:38 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> I remember differently, mainly that it's possible to get
ms> custom-before-init with the current setup (by loading the
ms> custom stuff at the top of init.el), but that it's much harder
ms> to get the reverse under the reverse setup.
Stephen> Huh? Name the custom file "perverse-order-custom.el", and put
Stephen> (setq custom-file (expand-file-name "perverse-order-custom.el"
user-init-directory)
Stephen> (load custom-file)
Stephen> at the end of the init file. No? Whereas with custom-after-init, you
Stephen> need to jump through hoops with `after-init-hook' to avoid loading
Stephen> custom-file twice.
OK, I agree that the complexity is comparable. I still don't agree
with the change: it's not clear to me that one order is inherently
better than the other, and it breaks some folks' setups.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
4:14 a.m.
New subject: order of init vs custom [was: Contents of one of my workspaces]
>>>> "ms" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
ms> OK, I agree that the complexity is comparable. I still don't
ms> agree with the change: it's not clear to me that one order is
ms> inherently better than the other, and it breaks some folks'
ms> setups.
It's a POLA issue. People expect that code will work the same in
init.el as it does in the *scratch* buffer. This does come up
occasionally on c.e.x, not very much on xemacs-beta, though.
Also, it's disconcerting (to me, anyway) to have customizations take
effect suddenly after the init process, including loading of desktop
etc. This is purely cosmetic.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:52 p.m.
New subject: order of init vs custom
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> It's a POLA issue. People expect that code will work the same in
Stephen> init.el as it does in the *scratch* buffer. This does come up
Stephen> occasionally on c.e.x, not very much on xemacs-beta, though.
Stephen> Also, it's disconcerting (to me, anyway) to have customizations take
Stephen> effect suddenly after the init process, including loading of desktop
Stephen> etc. This is purely cosmetic.
OK, I'll take your word and withdraw my objection.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
7213
days inactive
7228
days old
11 comments
5 participants
participants (5)
-
Ben Wing -
Michael Sperber -
Stephen J. Turnbull -
Vin Shelton -
Zajcev Evgeny