Re: Speeding up Emacs load time

[Rustom Mody]

On Tuesday, July 16, 2013 8:08:17 AM UTC+5:30, Eli Zaretskii wrote:
> > From: Emanuel Berg 
> > Eli Zaretskii  writes:
> > > Expecting that to somehow miraculously materialize out of thin
> > > air is not very wise.
> > Are you sure that isn't, on the contrary, natural?
> Yes, I am.

This argument reminds me of Swing vs AWT (from java-land).
Which is heavyweight and lightweight; which native and non-native etc is a 
question of outlook.  And if you think Swing has won, note that SWT tries to 
partially go back from swing to awt.

The real problem is that sometimes same is different; different is same.
Illustration:
Line-endings is a simple case where emacs generally gets this right.  Start 
emacs on windows and make a C-file say.  Do the same thing on linux and get the 
'same' file.  However if we swap the files Windows will show a 'unix' and linux 
will show a 'dos' in the mode-line.

What does this illustrate?  That the right defaults on different systems are 
different and emacs needs some significant amount of extra logic to get it 
right.

I believe the question comes down to this: What does portability mean?
I studied C in the 80s (K&R 1st ed!) and remember it described C as portable!
Today -- 2013 -- this sounds like a ridiculous and I would say abusive travesty.
Sure one can avoid 'non-portable' features but then the limiting case of this 
direction is that C programs would tend to the null do-nothing program:
main() {;}

Then somewhere in the 90s there came along something called perl. I remember 
being incredulous: "The SAME language runs on dos and unix?? Cant be..."
And that set a new bar for portability.
Willy-nilly all that has followed has had to measure up -- python, ruby, 
haskell etc... including emacs.

We may call the two portabilities passive and active.
Passive portability (80s C): Avoid troublesome non-portable features
Active portability (post perl): DO what it takes for the system to run on all 
OSes.

I hear Eli as saying: Passive portability is provided. Asking for more is 
outside the domain of emacs' responsibility
And Emanuel: If its not really portable (ie actively) then its useless to me  

My own experience: I used emacs on windows for some years. It was painful.  
That may well be because I am more comfortable on linux than windows.

1. Every windows program would print OTB -- except emacs
2. Backslash forwardslash in path problems.  Yeah at a find-file prompt emacs 
would be actively portable and understand either.  However if I was careless 
and cut-pasted a path from windows-explorer the registry or some such into 
elisp... MUCH WOE.  If lucky, elisp would give a syntax error.  Mostly the 
paths would just not work.
3. The .emacs would simply not be found because $HOME does not have a central 
existence on windows as it does on unix.

There must have been a dozen such sources of grief.  In many of them, I would 
have to (unwillingly!) agree with Eli that its not emacs' problem:
If ipython or tkinter has a bug that surfaces on windows but not linux how is 
that emacs' problem?
If I dont know how to use cygwin why blame emacs?

However the entire experience puts me in Emanuel camp -- making emacs work on 
windows is much more work than on linux.

-------- OT ----------
My newest laptop comes with Windows-8.  Makes it unusable not just for emacs 
but for almost everything.  I cant even find the control-panel!!
I guess the idea is to make it look like a cell-phone.
In all fairness, gnome is copycating windows in converting my computer into a 
dysfunctional phone.  However in linux I can throw out gnome and switch to 
xfce. Dont see any such choice on windows.