Re: Speeding up Emacs load time

[Rustom Mody <rustompmody@gmail.com>]

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.