Speeding up Emacs load time

Speeding up Emacs load time

[Andrew Pennebaker]

I love Emacs's customizability! I regularly edit my .emacs file, and the
community has been helpful and encouraging. But I do notice that Emacs can
take several (10) seconds or longer to load.

For reference, I'm using Emacs 24.1 for Mac OS X, Windows, and Android. I
keep my .emacs synced, shared, and backed up on GitHub.
https://github.com/mcandre/dotfiles/blob/master/.emacs

Could someone help me cut down the load time while maintaining the same
behavior?

Re: Speeding up Emacs load time

[Hongxu Chen]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> I love Emacs's customizability! I regularly edit my .emacs file, and the
> community has been helpful and encouraging. But I do notice that Emacs can
> take several (10) seconds or longer to load.
It's odd that with so many "add-hook" and "autoload" the startup time is
still not that short. I guess you need a load time profiler like
`ProfileDotEmacs'(http://www.emacswiki.org/emacs/ProfileDotEmacs) and
find out what eats up the time.
>
> For reference, I'm using Emacs 24.1 for Mac OS X, Windows, and Android. I
> keep my .emacs synced, shared, and backed up on GitHub.
> https://github.com/mcandre/dotfiles/blob/master/.emacs
>
> Could someone help me cut down the load time while maintaining the same
> behavior?
Some advice:
1. use compiled elisp(elc), however there seems no problem since you are
using `package', who does compile the script files he manages.
2. try separate some of the script(those you won't need until you use
the feature) from ~/.emacs(or ~/.init.el) and put them into special
files and try to use more "eval-after-load", "autoload", "add-hook"(be
careful for the buffer-local/global variable settings and choose the
right function of the three)
3. add (server-start) at the end of ~/.emacs and run emacsclient next
time you need emacs. For my understanding, running `emacsclient -t -a
""' at the beginning would slow down the startup time for the first
time.
4. It's not a problem when the startup time is not satisfactory since
you only need to open emacs once and you stay in it until you shutdown
your computer(IIRR, there is a midnight script support that there is no
need at all to close Emacs at all since it would do the cleanup work
automatically).

-- 
Regards,
Hongxu Chen

Re: Speeding up Emacs load time

[Didier Verna]

Hongxu Chen <leftcopy.chx@gmail.com> wrote:

> 2. try separate some of the script(those you won't need until you use
> the feature) from ~/.emacs(or ~/.init.el) and put them into special
> files and try to use more "eval-after-load", "autoload", "add-hook"(be
> careful for the buffer-local/global variable settings and choose the
> right function of the three)

  Better yet, use el-rcfiles:
  http://www.lrde.epita.fr/~didier/software/elisp/#el-rcfiles

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: Speeding up Emacs load time

[J. David Boyd]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> I love Emacs's customizability! I regularly edit my .emacs file, and the
> community has been helpful and encouraging. But I do notice that Emacs can
> take several (10) seconds or longer to load.
>
> For reference, I'm using Emacs 24.1 for Mac OS X, Windows, and Android. I
> keep my .emacs synced, shared, and backed up on GitHub.
> https://github.com/mcandre/dotfiles/blob/master/.emacs
>
> Could someone help me cut down the load time while maintaining the same
> behavior?

Wow.  My emacs takes almost 2 minutes to load up.  But I only start it in the
morning, and stop it at night before I go home.

Dave

Re: Speeding up Emacs load time

[Mihamina Rakotomandimby]

On 2013-06-26 20:04, J. David Boyd wrote:
> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>> I love Emacs's customizability! I regularly edit my .emacs file, and the
>> community has been helpful and encouraging. But I do notice that Emacs can
>> take several (10) seconds or longer to load.
>> [...]
>> Could someone help me cut down the load time while maintaining the same
>> behavior?
> Wow.  My emacs takes almost 2 minutes to load up.  But I only start it in the
> morning, and stop it at night before I go home.
>

Huhuhuhu

My suspend works perfectly: no need to shutdown the laptop.
I dont stop it much. The same for Firefox, LibreOffice,...

I only reboot when much thing are upgraded.

-- 
RMA.

Re: Speeding up Emacs load time

[Ken Goldman]

On 6/26/2013 1:04 PM, J. David Boyd wrote:
> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>>
>> Could someone help me cut down the load time while maintaining the same
>> behavior?
>
> Wow.  My emacs takes almost 2 minutes to load up.  But I only start it in the
> morning, and stop it at night before I go home.

My emacs runs for months at a time.  Load time is buried in boot time.

Use the client server model.  I use gnuserv.

Re: Speeding up Emacs load time

[Andrew Pennebaker]

This does not address my problem. I can run many programs for long spans of
time, but what I'm after is faster load time.

In any case, Emacs frequently crashes in Mac and Windows, so that's not an
option.
On Jul 14, 2013 9:05 PM, "Ken Goldman" <kgoldman@us.ibm.com> wrote:

> On 6/26/2013 1:04 PM, J. David Boyd wrote:
>
>> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>>
>>>
>>> Could someone help me cut down the load time while maintaining the same
>>> behavior?
>>>
>>
>> Wow.  My emacs takes almost 2 minutes to load up.  But I only start it in
>> the
>> morning, and stop it at night before I go home.
>>
>
> My emacs runs for months at a time.  Load time is buried in boot time.
>
> Use the client server model.  I use gnuserv.
>
>
>
>

Re: Speeding up Emacs load time

[Glyn Millington]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

Post re-ordered - moved your latest to the right place :-)

> On Jul 14, 2013 9:05 PM, "Ken Goldman"
> <kgoldman@us.ibm.com> wrote:
>
>> On 6/26/2013 1:04 PM, J. David Boyd wrote:
>>
>>> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>>>
>>>> Could someone help me cut down the load time while maintaining the
>>>> same behavior?
>>>>
>>> Wow.  My emacs takes almost 2 minutes to load up.  But I only start
>>> it in the morning, and stop it at night before I go home.
>>>
>> My emacs runs for months at a time.  Load time is buried in boot
>> time.
>> Use the client server model.  I use gnuserv.

> This does not address my problem. I can run many programs for long
> spans of time, but what I'm after is faster load time.

> In any case, Emacs frequently crashes in Mac and Windows, so that's
> not an option. 

One popular technique is not to load packages until you need 'em.  That
means fewer 'requires' in your .emacs/init.el file and more autoloads. 

See tips 3-5 here!

http://a-nickels-worth.blogspot.co.uk/2007/11/effective-emacs.html

The key function is eval-after-load

Two people who have written wrappers to eval-after-load

The Milky Postman
http://milkbox.net/note/single-file-master-emacs-configuration/
Look for the 'after' macro and how he uses it.

Much more complex is John Wiegley's 'use-package', available through elpa

https://github.com/jwiegley/use-package


Good luck .......

Glyn

Re: Speeding up Emacs load time

[Rasmus]

Glyn Millington <glyn.millington@gmail.com> writes:

>> In any case, Emacs frequently crashes in Mac and Windows, so that's
>> not an option. 

> One popular technique is not to load packages until you need 'em.  That
> means fewer 'requires' in your .emacs/init.el file and more autoloads. 
>
> See tips 3-5 here!
>
> http://a-nickels-worth.blogspot.co.uk/2007/11/effective-emacs.html
>
> The key function is eval-after-load

And now with-eval-after-load which doesn't need to body to be quoted.

From the news

* Lisp Changes in Emacs 24.4
** New macro with-eval-after-load.  Like eval-after-load, but better behaved.

–Rasmus

-- 
Enough with the bla bla!

Re: Speeding up Emacs load time

[Peter Dyballa]

Am 15.07.2013 um 03:33 schrieb Andrew Pennebaker:

> Emacs frequently crashes in Mac

Which Emacs does such silly things? (OK, from time to time the NS variant of development version 24.3.50 becomes a bit unstable…)

The AppKit variant is solid.

--
Greetings

  Pete

Don't just do something, sit there.

Re: Speeding up Emacs load time

[Sebastien Vauban]

Hi Glyn and all,

Glyn Millington wrote:
> One popular technique is not to load packages until you need 'em. That means
> fewer 'requires' in your .emacs/init.el file and more autoloads.
>
> See tips 3-5 here!
>
> http://a-nickels-worth.blogspot.co.uk/2007/11/effective-emacs.html
>
> The key function is eval-after-load

I'm using GNU Emacs on Windows, and using the above, I could reduce my load
time from 10+ seconds to 3 seconds. Still 3 x over many of you, which report
sub-seconds load time.

Though, I'm a bit blocked. I don't understand how to do better, or how to
completely avoid all the require commands.

Just take a few exemple:

- `(server-start)' takes more than 200 ms to run [1]; just that one command.
  Though, I must have it in my .emacs file, right?

- diff-mode-.el must be loaded before diff-mode; hence, I must have it at
  startup.

- Helm is my tool for opening files or switching between buffers. Just
  requiring `helm-config' (almost only autoloads) -- hence, NOT `helm' (which
  is more hungry in time) -- already takes 160 ms (as it still requires
  `easy-menu' and `helm-aliases').

- `diary-lib' and co (needed for appointments notification) takes 233 ms.
  Shouldn't I be notified at startup of events occurring in less than 15
  minutes, without having to make a first call to calendar or so?

- `mic-paren' takes just 32 ms, but for just one small package, for which I
  don't have a particular trigger. Is it `find-file-hook'?  Then, I won't have
  parenthesis highlighted when directly typing text in a newly created buffer
  (or in the scratch). So, I need it in my .emacs. It's not eval'ed-after-load
  of something else.

- The same for YASnippet (loaded in 130 ms): what would be the trigger?
  Unless I have a clear one, I must require it in my .emacs file.

- Once again, the same with `recentf', which takes 92 ms. Don't I have to load
  it right at startup?

These are a couple of examples which take a lot of the time, and for which I
don't see a specific trigger that would allow me to defer their load to later.

Any comments?

Best regards,
  Seb

[1] The above are times on a very recent laptop i7, when on mains. Multiply
    times by 3.5 when on battery.

-- 
Sebastien Vauban

Re: Speeding up Emacs load time

[J. David Boyd]

"Sebastien Vauban" <sva-news@mygooglest.com> writes:

> Hi Glyn and all,
>
> Glyn Millington wrote:
>> One popular technique is not to load packages until you need 'em. That means
>> fewer 'requires' in your .emacs/init.el file and more autoloads.
>>
>> See tips 3-5 here!
>>
>> http://a-nickels-worth.blogspot.co.uk/2007/11/effective-emacs.html
>>
>> The key function is eval-after-load
>
> I'm using GNU Emacs on Windows, and using the above, I could reduce my load
> time from 10+ seconds to 3 seconds. Still 3 x over many of you, which report
> sub-seconds load time.
>
> Though, I'm a bit blocked. I don't understand how to do better, or how to
> completely avoid all the require commands.
>
> Just take a few exemple:
>
> - `(server-start)' takes more than 200 ms to run [1]; just that one command.
>   Though, I must have it in my .emacs file, right?
>
> - diff-mode-.el must be loaded before diff-mode; hence, I must have it at
>   startup.
>
> - Helm is my tool for opening files or switching between buffers. Just
>   requiring `helm-config' (almost only autoloads) -- hence, NOT `helm' (which
>   is more hungry in time) -- already takes 160 ms (as it still requires
>   `easy-menu' and `helm-aliases').
>
> - `diary-lib' and co (needed for appointments notification) takes 233 ms.
>   Shouldn't I be notified at startup of events occurring in less than 15
>   minutes, without having to make a first call to calendar or so?
>
> - `mic-paren' takes just 32 ms, but for just one small package, for which I
>   don't have a particular trigger. Is it `find-file-hook'?  Then, I won't have
>   parenthesis highlighted when directly typing text in a newly created buffer
>   (or in the scratch). So, I need it in my .emacs. It's not eval'ed-after-load
>   of something else.
>
> - The same for YASnippet (loaded in 130 ms): what would be the trigger?
>   Unless I have a clear one, I must require it in my .emacs file.
>
> - Once again, the same with `recentf', which takes 92 ms. Don't I have to load
>   it right at startup?
>
> These are a couple of examples which take a lot of the time, and for which I
> don't see a specific trigger that would allow me to defer their load to later.
>
> Any comments?
>
> Best regards,
>   Seb
>
> [1] The above are times on a very recent laptop i7, when on mains. Multiply
>     times by 3.5 when on battery.


Are you using Cygwin?  And the X11 binary, or the Ming-W binary?

Re: Speeding up Emacs load time

[Sebastien Vauban]

Hi J. David,

J. David Boyd wrote:
> "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>> Glyn Millington wrote:
>>> One popular technique is not to load packages until you need 'em. That means
>>> fewer 'requires' in your .emacs/init.el file and more autoloads.
>>>
>>> See tips 3-5 here!
>>>
>>> http://a-nickels-worth.blogspot.co.uk/2007/11/effective-emacs.html
>>>
>>> The key function is eval-after-load
>>
>> I'm using GNU Emacs on Windows, and using the above, I could reduce my load
>> time from 10+ seconds to 3 seconds. Still 3 x over many of you, which report
>> sub-seconds load time.
>>
>> Though, I'm a bit blocked. I don't understand how to do better, or how to
>> completely avoid all the require commands.
>>
>> Just take a few exemple:
>>
>> - `(server-start)' takes more than 200 ms to run [1]; just that one command.
>>   Though, I must have it in my .emacs file, right?
>>
>> - diff-mode-.el must be loaded before diff-mode; hence, I must have it at
>>   startup.
>>
>> - Helm is my tool for opening files or switching between buffers. Just
>>   requiring `helm-config' (almost only autoloads) -- hence, NOT `helm' (which
>>   is more hungry in time) -- already takes 160 ms (as it still requires
>>   `easy-menu' and `helm-aliases').
>>
>> - `diary-lib' and co (needed for appointments notification) takes 233 ms.
>>   Shouldn't I be notified at startup of events occurring in less than 15
>>   minutes, without having to make a first call to calendar or so?
>>
>> - `mic-paren' takes just 32 ms, but for just one small package, for which I
>>   don't have a particular trigger. Is it `find-file-hook'?  Then, I won't have
>>   parenthesis highlighted when directly typing text in a newly created buffer
>>   (or in the scratch). So, I need it in my .emacs. It's not eval'ed-after-load
>>   of something else.
>>
>> - The same for YASnippet (loaded in 130 ms): what would be the trigger?
>>   Unless I have a clear one, I must require it in my .emacs file.
>>
>> - Once again, the same with `recentf', which takes 92 ms. Don't I have to load
>>   it right at startup?
>>
>> These are a couple of examples which take a lot of the time, and for which I
>> don't see a specific trigger that would allow me to defer their load to later.
>>
>> Any comments?
>>
>> Best regards,
>>   Seb
>>
>> [1] The above are times on a very recent laptop i7, when on mains. Multiply
>>     times by 3.5 when on battery.
>
> Are you using Cygwin?  And the X11 binary, or the Ming-W binary?

I'm using

    GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-07-07 on LEG570

(compiled W32 binary from DropBox in this case, by Dani Moncayo) -- but I
indifferently use the (older, I mean for Emacs 24.3) binaries as well from the
FSF Web site. So, I never (try to) compile Emacs by myself.

I do have Cygwin installed on my machine.

I don't use Ming-W nor X11.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Speeding up Emacs load time

[J. David Boyd]

"Sebastien Vauban" <sva-news@mygooglest.com> writes:

>
> - `(server-start)' takes more than 200 ms to run [1]; just that one command.
>   Though, I must have it in my .emacs file, right?
>
> - diff-mode-.el must be loaded before diff-mode; hence, I must have it at
>   startup.
>
> - Helm is my tool for opening files or switching between buffers. Just
>   requiring `helm-config' (almost only autoloads) -- hence, NOT `helm' (which
>   is more hungry in time) -- already takes 160 ms (as it still requires
>   `easy-menu' and `helm-aliases').
>
> - `diary-lib' and co (needed for appointments notification) takes 233 ms.
>   Shouldn't I be notified at startup of events occurring in less than 15
>   minutes, without having to make a first call to calendar or so?
>
> - `mic-paren' takes just 32 ms, but for just one small package, for which I
>   don't have a particular trigger. Is it `find-file-hook'?  Then, I won't have
>   parenthesis highlighted when directly typing text in a newly created buffer
>   (or in the scratch). So, I need it in my .emacs. It's not eval'ed-after-load
>   of something else.
>
> - The same for YASnippet (loaded in 130 ms): what would be the trigger?
>   Unless I have a clear one, I must require it in my .emacs file.
>
> - Once again, the same with `recentf', which takes 92 ms. Don't I have to load
>   it right at startup?
>
> These are a couple of examples which take a lot of the time, and for which I
> don't see a specific trigger that would allow me to defer their load to later.


How did you time those sections?  Could you share, please?

Dave

Re: Speeding up Emacs load time

[Sebastien Vauban]

J. David Boyd wrote:
> "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>> - `(server-start)' takes more than 200 ms to run [1]; just that one command.
>>   Though, I must have it in my .emacs file, right?
>>
>> - diff-mode-.el must be loaded before diff-mode; hence, I must have it at
>>   startup.
>>
>> - Helm is my tool for opening files or switching between buffers. Just
>>   requiring `helm-config' (almost only autoloads) -- hence, NOT `helm' (which
>>   is more hungry in time) -- already takes 160 ms (as it still requires
>>   `easy-menu' and `helm-aliases').
>>
>> - `diary-lib' and co (needed for appointments notification) takes 233 ms.
>>   Shouldn't I be notified at startup of events occurring in less than 15
>>   minutes, without having to make a first call to calendar or so?
>>
>> - `mic-paren' takes just 32 ms, but for just one small package, for which I
>>   don't have a particular trigger. Is it `find-file-hook'?  Then, I won't have
>>   parenthesis highlighted when directly typing text in a newly created buffer
>>   (or in the scratch). So, I need it in my .emacs. It's not eval'ed-after-load
>>   of something else.
>>
>> - The same for YASnippet (loaded in 130 ms): what would be the trigger?
>>   Unless I have a clear one, I must require it in my .emacs file.
>>
>> - Once again, the same with `recentf', which takes 92 ms. Don't I have to load
>>   it right at startup?
>>
>> These are a couple of examples which take a lot of the time, and for which I
>> don't see a specific trigger that would allow me to defer their load to later.
>
> How did you time those sections?  Could you share, please?

The config file that I'm using is publicly available at
https://github.com/fniessen/emacs-leuven.

    Note -- Put (setq leuven-load-verbose t) before loading it, and you'll get
    load times, and call tree of the packages.

In summary, to time a package is done this way:

--8<---------------cut here---------------start------------->8---
  ;; make loaded files give a message
  (defadvice load (around leuven-load activate)
    "Execute a file of Lisp code named FILE and report time spent."
    (let ((filename (ad-get-arg 0))
          (find-file-time-start (float-time)))
      (message "(info) Loading %s..." filename)
      ad-do-it
      (message "(info) Loaded %s in %.3f s." filename
               (- (float-time) find-file-time-start))))

  (defadvice require (around leuven-require activate)
    "Leave a trace of packages being loaded."
    (let* ((feature (ad-get-arg 0))
           (require-depth (or (and (boundp 'require-depth) require-depth)
                              0))
           (prefix (concat (make-string (* 2 require-depth) ? ) "+-> ")))
      (cond ((featurep feature)
             (message "(info) %sRequiring `%s'... already loaded"
                      prefix feature)
             ;; in the case `ad-do-it' is not called, you have to set the
             ;; return value yourself!
             (setq ad-return-value feature))
            (t
             (let ((time-start))
               (message "(info) %sRequiring `%s'... %s"
                        prefix feature
                        (locate-library (symbol-name feature)))
               (setq time-start (float-time))
               (let ((require-depth (1+ require-depth)))
                 ad-do-it)
               (message "(info) %sRequiring `%s'... loaded in %.3f s"
                        prefix feature
                        (- (float-time) time-start)))))))
--8<---------------cut here---------------end--------------->8---

Though, do you have ideas for not being forced the above packages at startup
time?  To which event (such as load of package "x") to which hook could I tie
them?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Speeding up Emacs load time

[Emanuel Berg]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> In any case, Emacs frequently crashes in Mac and Windows

Well, obviously you can't have *that*. Perhaps you should put your
energy at solving that rather than to reduce the impact by
shortening the load time?

I agree with the other poster - integrate the startup of Emacs
with the general system boot process, then don't shut Emacs
down. (But I'm not entirely as cool as he because I have to
"mount" my my computer physically each time I use it at my
school... To have an "always on" system would be so cool - you
know the `uptime' command, solely there so you can brag how long
your system was running like a Swiss watch.)

But back to Windows, a couple of years back, I actually deluded
myself that I could work in Windows, "I just need a shell
emulator, and Emacs", and I believed that, right until the moment
that I tried it. Emacs on Windows is *not* the same.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Peter Dyballa]

Am 15.07.2013 um 16:06 schrieb Emanuel Berg:

> a couple of years back, I actually deluded
> myself that I could work in Windows, "I just need a shell
> emulator, and Emacs", and I believed that, right until the moment
> that I tried it. Emacs on Windows is *not* the same.

Depending on what you want to achieve, GNU Emacs and Firefox can make you forget that MS Losedos exists below…

--
Greetings

  Pete

It's not the valleys in life I dread so much as the dips.
				– Garfield

Re: Speeding up Emacs load time

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Mon, 15 Jul 2013 16:06:45 +0200
> 
> Emacs on Windows is *not* the same.

Yes, it is.  I'm guessing that the above is due to the fact that you
missed many external programs that Emacs invokes to provide some of
its features.  Those programs exist in Windows ports, but you need to
install them first (they are not part of the Emacs binary distro).

Re: Speeding up Emacs load time

[J. David Boyd]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Emanuel Berg <embe8573@student.uu.se>
>> Date: Mon, 15 Jul 2013 16:06:45 +0200
>> 
>> Emacs on Windows is *not* the same.
>
> Yes, it is.  I'm guessing that the above is due to the fact that you
> missed many external programs that Emacs invokes to provide some of
> its features.  Those programs exist in Windows ports, but you need to
> install them first (they are not part of the Emacs binary distro).

RIght, emacs and cygwin, working together, running in an Xwindow, feels just
like being on my Ubunutu box.

First thing I do at every new job is install a copy of cygwin, so I can
pretend I'm in linux.   Have to have my bash shell and Emacs.

Re: Speeding up Emacs load time

[Emanuel Berg]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, it is.  I'm guessing that the above is due to the fact that
> you missed many external programs that Emacs invokes to provide
> some of its features.  Those programs exist in Windows ports ...

I'm sure they do, but when I run a command, I don't think in which
module that is, to me it is all Emacs.

Perhaps my statement should be specified into: Emacs AND Linux is
not the same as Emacs AND Windows. It doesn't matter if Emacs is
the same, if it doesn't play the same in a new environment -
perhaps Emacs should *not* be the same to make it work the same?

My .emacs broke on a dozen plus places - and the only thing I ever
installed separately on Debian is some LaTeX stuff (that I
remember).

But, even if I were to give you half a point here, there were so
many other details that I noticed. I use Emacs all the time so
there is not a single char on any screen that can change color
unnoticed. Just to give you an example: big files. I *never* had a
problem editing, scrolling (browsing), etc., big files in
Linux. In Windows, it started to lag like crazy.

The whole thing was so frustrating I decided never to do it again,
after putting a considerable effort to make it work (on the same
computer). I believe that you got it to work, but I don't believe
I could do the same.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Mon, 15 Jul 2013 19:00:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, it is.  I'm guessing that the above is due to the fact that
> > you missed many external programs that Emacs invokes to provide
> > some of its features.  Those programs exist in Windows ports ...
> 
> I'm sure they do, but when I run a command, I don't think in which
> module that is, to me it is all Emacs.

If you want "M-x grep" and "M-x compile" and "M-x flyspell-mode" and
LaTeX and whatnot, you need to set that up.  No Bob will do that for
you.  You want a working development environment, you need to install
its parts -- Grep, GCC, ispell/hunspell, you name it.  Expecting that
to somehow miraculously materialize out of thin air is not very wise.
Assigning the blame to Emacs is misdirected.

> Perhaps my statement should be specified into: Emacs AND Linux is
> not the same as Emacs AND Windows.

That goes both ways.

> It doesn't matter if Emacs is
> the same, if it doesn't play the same in a new environment -
> perhaps Emacs should *not* be the same to make it work the same?

It _is_ the same.  Whether or not this is right is another issue and
another argument.

> My .emacs broke on a dozen plus places - and the only thing I ever
> installed separately on Debian is some LaTeX stuff (that I
> remember).

See above.  My .emacs works on Windows and GNU/Linux alike, has done
that for the last 10 years if not more.

> Just to give you an example: big files. I *never* had a
> problem editing, scrolling (browsing), etc., big files in
> Linux. In Windows, it started to lag like crazy.

That's outdated.  Even on 32-bit Windows, Emacs can edit 1.7 GB files,
if you have enough VM.  And, just to give you a counter-example, Emacs
on 64-bit GNU/Linux would crash and burn with files larger than 2GB
until a few versions back.

> The whole thing was so frustrating I decided never to do it again,
> after putting a considerable effort to make it work (on the same
> computer). I believe that you got it to work, but I don't believe
> I could do the same.

Life is strange, you might yet find yourself some day in the need to
do it again.  Maybe you should save this message for then.

Re: Speeding up Emacs load time

[Emanuel Berg]

Eli Zaretskii <eliz@gnu.org> 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? I'm using a
piece of software in one system, software that I installed "from
the shelf". Isn't it natural to think that if I do the same on
another system - because the software is on both - that I should
get more or less the same UX? Well, I didn't. But I trust your
experience and knowledge to be true as well, and there is no
contradiction.

> Assigning the blame to Emacs is misdirected.

I know I didn't do that because I don't deal with blame (or
guilt).

> It _is_ the same.

In isolation perhaps. But it wasn't the same when I had Emacs on
my old, dual-boot laptop, one on Windows, one on Linux, the most
recent versions I could find. (Speaking of that: I remember the
installation process was a pain in Windows, too. Compare that to
sweet aptitude...)

> See above.  My .emacs works on Windows and GNU/Linux alike, has
> done that for the last 10 years if not more.

Yes, you obviously had a different experience altogether, and that
happens all the time. But how can my experience be true *at all*,
if it is the same, working seamlessly like a sandboxed applet? It
didn't. Perhaps it is better, now.

But come to think of it, even moving between Linux distros - not
with Emacs, but in general - can be a pain. So why is it
surprising that it takes an effort to move from Debian to Windows?

> Life is strange, you might yet find yourself some day in the
> need to do it again.  Maybe you should save this message for
> then.

Life *is* strange, and I remember everything people say to me, but
unless I'm on a sinking ship, I'm *never* using *anything* but my
Debian :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Mon, 15 Jul 2013 21:49:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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.

> I remember the installation process was a pain in Windows, too.

You mean, download a single zip archive and unzip it wherever you
want?  We must have very different thresholds of pain.

> But come to think of it, even moving between Linux distros - not
> with Emacs, but in general - can be a pain. So why is it
> surprising that it takes an effort to move from Debian to Windows?

It is not surprising.  The issue here is different: you said Emacs
wasn't working the same on Windows as on Unix, and that's simply not
true.

Re: Speeding up Emacs load time

[Ken Goldman]

On 7/15/2013 10:38 PM, Eli Zaretskii wrote:
>
>> But come to think of it, even moving between Linux distros - not
>> with Emacs, but in general - can be a pain. So why is it
>> surprising that it takes an effort to move from Debian to Windows?
>
> It is not surprising.  The issue here is different: you said Emacs
> wasn't working the same on Windows as on Unix, and that's simply not
> true.

For me, one of the many selling points for emacs is that it DOES work 
the same everywhere.  I flip between Unix'es and Windows many times a day.

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.

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody:

Well, what do you say? "I couldn't have said it better myself" :)

Seriously, I couldn't - not by a long-shot.

Man, those C and Perl days must have been exciting! Still, I'm not
giving up on acquiring the big picture - just keep on digging,
every day...

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Rustom Mody]

I would like to point out that your two statements:

On Tuesday, July 16, 2013 3:12:04 PM UTC+5:30, Emanuel Berg wrote:
> Man, those C and Perl days must have been exciting! Still, I'm not
> giving up on acquiring the big picture - just keep on digging,
> every day...

and then 

> I'm going to customize *everything* down to the last
> detail. Emacs, the shell, the mail client, the web browser, even
> the kernel process scheduler, when I get there! That's the whole
> point with everything I do with computing. This is how I
> communicate with technology - because that's who I am. 

are not exactly compatible.

When I spend my time on perfecting the details, I tend to miss out the big picture.
You can take it from me -- learnt by hard painful experience -- that perfectionism is not a virtue but a disease. IOW Jambunathan's advice is very good advice.

And especially when I hear the tone of voice in this:

> Do you know why it looks like that, and not like some stinking,
> bloodsucking Windows MS Access with a white background, a blinking
> cursor, a minimal font, constant popups, and lack of shortcuts and
> cursor movement functionality that will have you reach for the
> mouse, type, type again, type ten, twenty times as much as I've
> been able to minimize it to, through years of customization,
> setting up zsh and Emacs shorthands in absurdum never to have to
> strike a single key that is not necessary?
>  
> I suspect you probably don't get any of this, because if you did,
> you would never say what you said with zero information about the
> other person, accept that you disagreed over some silly issue.
>  
> But, ... just for the record, I know I'm far from the only guy who
> suffered physically because of love for computers. 

I am reminded of Erik Naggum.
[Run a search and ask how far you want to go that-a-way]

Re: Speeding up Emacs load time

[Rustom Mody]

I would like to point out that your two statements:

On Tuesday, July 16, 2013 3:12:04 PM UTC+5:30, Emanuel Berg wrote:
> Man, those C and Perl days must have been exciting! Still, I'm not
> giving up on acquiring the big picture - just keep on digging,
> every day...

and then 

> I'm going to customize *everything* down to the last
> detail. Emacs, the shell, the mail client, the web browser, even
> the kernel process scheduler, when I get there! That's the whole
> point with everything I do with computing. This is how I
> communicate with technology - because that's who I am. 

are not exactly compatible.

When I spend my time on perfecting the details, I tend to miss out the big picture.
You can take it from me -- learnt by hard painful experience -- that perfectionism is not a virtue but a disease. IOW Jambunathan's advice is very good advice.

And especially when I hear the tone of voice in this:

> Do you know why it looks like that, and not like some stinking,
> bloodsucking Windows MS Access with a white background, a blinking
> cursor, a minimal font, constant popups, and lack of shortcuts and
> cursor movement functionality that will have you reach for the
> mouse, type, type again, type ten, twenty times as much as I've
> been able to minimize it to, through years of customization,
> setting up zsh and Emacs shorthands in absurdum never to have to
> strike a single key that is not necessary?
>  
> I suspect you probably don't get any of this, because if you did,
> you would never say what you said with zero information about the
> other person, accept that you disagreed over some silly issue.
>  
> But, ... just for the record, I know I'm far from the only guy who
> suffered physically because of love for computers. 

I am reminded of Erik Naggum.
[Run a search and ask how far you want to go that-a-way]

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

>> Man, those C and Perl days must have been exciting! Still, I'm
>> not giving up on acquiring the big picture - just keep on
>> digging, every day...
>
> and then 
>
>> I'm going to customize *everything* down to the last
>> detail. Emacs, the shell, the mail client, the web browser,
>> even the kernel process scheduler, when I get there! That's the
>> whole point with everything I do with computing. This is how I
>> communicate with technology - because that's who I am.
>
> are not exactly compatible.
>
> When I spend my time on perfecting the details, I tend to miss
> out the big picture.

That's you, not me. I've spent 3-4 years getting a CS degree. I'm
done drawing UML diagrams, writing pseudo-code, etc. While I did
that, I spent as much time "digging" (and no time sleeping). While
both (theory and digging) were helpful, and in retrospect, it's
different to say what gave what - did Linear Algebra help for
Lisp? - I'm done with theory, but I'll *never* be done digging.

> You can take it from me -- learnt by hard painful experience --
> that perfectionism is not a virtue but a disease. IOW
> Jambunathan's advice is very good advice.

I don't believe that. But I've heard that before, many times. I
think there might be some truth to it. Still, those people have
always been - in lack of a better word - "normal". They are not
warriors, because they never had to be. And normal people tend
only to understand other people that are normal. It is like seeing
a punch in boxing that you never saw before - do you know how it
looks? - it is *invisible*! Only the second time you see someone
throw it, you can (barely) make it out.

> And especially when I hear the tone of voice in this

If you read my reply perhaps you understand my reaction.

> I am reminded of Erik Naggum.
> [Run a search and ask how far you want to go that-a-way]

OK.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> I am reminded of Erik Naggum.
> [Run a search and ask how far you want to go that-a-way]

OK, I've read the Wikipedia article.

https://en.wikipedia.org/w/index.php?title=Erik%20Naggum&printable=yes

How about you do the same (it is short) to see if that was what
you wanted to communicate. Because - I really didn't get it (? -
or some, but not quite). Interesting material, though.

Quotes from the article:

> He believed that Lisp was more or less the only valuable
> programming language and that XML was an insane thing to use.

On the contrary, PLs are not that important. In general, all
programming is the same. On a particular platform, for a
particular task - the importance of the PL grows. (But not that
much, in most of the cases.)

> He ignored traditional grammar when he saw functional reasons
> for doing so; he began sentences with small letters to make them
> easier to read and faster to type. He often used pictures and
> metaphors ...

In general, I agree, but not in the particular case of small
letters. I think that *reduces* readability and it is not slower
to type with the occasional case switch, at least not in any
amounts that make it worthwhile. But that kind of thinking
(including the metaphors), I'm *very* familiar with. On the other
hand - is that really that - radical?

> Erik Naggum hated Perl with a passion ...

I don't hate anything, and especially not Perl. I think Perl is
classy. But, compared to C and Lisp, it is very difficult to
*read*, and especially what some other Joe Hacker around the
planet wrote. I read C the best.

> He disliked C++, though not as much as he hated Perl, but he
> generally thought that C++ was too difficult to understand to
> such a degree that only about 5 people on the planet truly
> understood it ...

What?! C++ is straightforward. Not as C, but making C OO wasn't
easy, especially not the first time around (although some people
say OO was in Smalltalk and even Simula 67). I'm not a fan of OO
in general because I'm not a fan of modeling. But, without
bragging, I have a pretty clear view of C++ :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Tue, Jul 16, 2013 at 11:02 PM, Emanuel Berg <embe8573@student.uu.se> wrote:

> What?! C++ is straightforward.

Yes, so straightforward, that I remember, some years ago, reading
"Exceptional C++", by Herb Sutter (an acknowledged C++ expert), and
some short examples in the book had errata that had been corrected (in
subsequent prints) three, five, eight times, because even him was in
fact unable to grasp all the implications of the C++ exception model.
So...

> But, without
> bragging, I have a pretty clear view of C++ :)

...yes, this seems a bit of bragging. But hey, perhaps I'm wrong and
you are a prominent member from the C++11 design committee, for all I
know...

   Juanma

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> Yes, so straightforward, that I remember, some years ago,
> reading "Exceptional C++", by Herb Sutter (an acknowledged C++
> expert), and some short examples in the book had errata that had
> been corrected (in subsequent prints) three, five, eight times,
> because even him was in fact unable to grasp all the
> implications of the C++ exception model.

Like I said, I think C++ had some child diseases that were partly
due to the particularities of the development process, but
possible a bit inevitable as well, because of the task at hand,
which wasn't easy.

Anyway, I'm not basing my reasoning on the numbers of "errata"
corrections of some book.

C++ is straightforward because C is very straightforward, and OO
is more or less straightforward, and C++ is C with OO language
support. And, my experience from C++ confirms this.

> this seems a bit of bragging. But hey, perhaps I'm wrong and you
> are a prominent member from the C++11 design committee, for all
> I know

Are you saying, if you are not a member of that committee, you
cant understand C++?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 3:41 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Are you saying, if you are not a member of that committee, you
> cant understand C++?

No, I'm pretty sure even members of that committee don't entirely
understand C++.

   Juanma

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> I'm pretty sure even members of that committee don't entirely
> understand C++.

I you are supposed to understand stuff entirely then I admit I
don't understand anything.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 4:24 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

> I you are supposed to understand stuff entirely then I admit I
> don't understand anything.

If something cannot be understood entirely, then "straightforward" is
not a good way to describe it.

https://www.google.com/search?q=define+straightforward

   J

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> If something cannot be understood entirely, then
> "straightforward" is not a good way to describe it.

Yes, it is. Chess is straightforward but no one knows everything
about chess. (I don't play chess.)

C++ is C and OO. C is straightforward. OO is straightforward
unless you make it complicated with insane levels of inheritance,
overloading, etc. If you don't, and I think you shouldn't, OO is
straightforward.

That only C++ is understood by five people around the globe (you
didn't say this, I know) is lunacy. C++ was the big thing in the
90's, and it is still huge. They rewrote fully functional C
programs in C++, just to be able to tell "it's C++, it's
OO". While that was silly, more than five people were *not* silly
at the same time, I *triple guarantee* all readers of this post.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Wed, Jul 17, 2013 at 10:30 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Yes, it is. Chess is straightforward but no one knows everything
> about chess. (I don't play chess.)

Chess *rules* are straightforward. Go rules even more. You can learn
the rules in five minutes. They lead to non-trivial complexity.

C++ "rules" are not straightforward. No one can learn its "rules"
without many hours of careful reading of the standard, and even so,
it's likely you'll have to go back and re-read many fragments. And
then you'll have to experiment with different implementations to see
whether they did interpret the standard in exactly the same way
(usually that's not the case). Not to mention things that are
explicitly left undefined or up to the implementor.

That happens with all programming languages, of course. But not all
programming languages are equally complex. I love Ada, and I think it
is a much better language than C++ (no language flamewars, please, I'm
just stating my opinion but I have no desire to defend it), but I
wouldn't call Ada "straightforward". Looking at defect reports (of C++
or Ada) destroys that illusion quite fast.

> C++ is C and OO. C is straightforward. OO is straightforward
> unless you make it complicated with insane levels of inheritance,
> overloading, etc. If you don't, and I think you shouldn't, OO is
> straightforward.

That's not an argument in favor of C++, which does make inheritance
model complicated by insisting in having multiple inheritance of
implementation (as opposed to interface).

And you leave out the infamous C++ template system, so complex and
bizarre that it is, by itself, a Turing-complete functional language.

> That only C++ is understood by five people around the globe (you
> didn't say this, I know) is lunacy. C++ was the big thing in the
> 90's, and it is still huge. They rewrote fully functional C
> programs in C++, just to be able to tell "it's C++, it's
> OO". While that was silly, more than five people were *not* silly
> at the same time, I *triple guarantee* all readers of this post.

You're right, that's not what I'm saying. I'm saying that C++ is not
straightforward, not that it cannot be used for real, successful
projects. Of course it can. But the kind of bugs that appear in C++
programs (many of them related to exceptions, for example),
demonstrate how easy is to fall victim of C++ pitfalls and complexity.

    J

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> Chess *rules* are straightforward. Go rules even more. You can
> learn the rules in five minutes. They lead to non-trivial
> complexity.

You don't say :)

> C++ "rules" are not straightforward. No one can learn its
> "rules" without many hours of careful reading of the standard,
> and even so, it's likely you'll have to go back and re-read many
> fragments.

And this is the case with all PLs, to various degrees. It is not
really a matter of intelligence. Memory, perhaps. I always have to
look up a number of things when switching languages, and even when
it is to a language that I've known very well in the past. On the
other hand, for each time I switch to that language, the process
of recovery gets faster. In this sense, I agree that switching
back to C++ after some absence is probably worse than to many
other PLs.

> That happens with all programming languages, of course. But not
> all programming languages are equally complex. I love Ada, and I
> think it is a much better language than C++

I like Ada a lot! Great for concurrent and/or RT programming. Not
a lot of people know Ada, though. And I know why: it was developed
by the US military :)

> no language flamewars, please

I'm not into that. I think all programming is the same: regardless
of language, platform, and even what it is that you program.

> I'm just stating my opinion but I have no desire to defend it),
> but I wouldn't call Ada "straightforward".

I have much less experience with Ada than with C++, but what I saw
with Ada was straightforward.

> Looking at defect reports (of C++ or Ada) destroys that illusion
> quite fast.

I'm looking to my experience. You can't do the same (look to *my*
experience), so I hold you at a disadvantage here. But I trust my
experience much more than defect reports and errata lists, which,
by the way, I consider natural. No one said designing and
implementing a PL is an easy task.

> And you leave out the infamous C++ template system, so complex
> and bizarre

If that makes it not straightforward, and you want it to be, why
don't you just not use those features?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Fri, Jul 19, 2013 at 12:18 PM, Emanuel Berg <embe8573@student.uu.se> wrote:

> And this is the case with all PLs, to various degrees. It is not
> really a matter of intelligence.

I don't think I've ever mentioned intelligence in this thread...

> I like Ada a lot! Great for concurrent and/or RT programming. Not
> a lot of people know Ada, though. And I know why: it was developed
> by the US military :)

Not really. Its development was sponsored by the DoD, but the team(s)
that created it (CII Honeywell Bull for Ada 80/83, Intermetrics for
Ada 95) were from the industry.

> I have much less experience with Ada than with C++, but what I saw
> with Ada was straightforward.

At this point, it is clear that I don't understand your definition of
"straightforward", so there's not much point in continue arguing. For
the definition of "straightforward" that I'm using, not even the
designers and maintainers of Ada would call it so.

> I'm looking to my experience. You can't do the same (look to *my*
> experience), so I hold you at a disadvantage here.

True.

> If that makes it not straightforward, and you want it to be, why
> don't you just not use those features?

Believe me, I use C++ as little as possible. In my list of preferred
"modern" languages, the only one that would score even worse is Java.

    J

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

>> And this is the case with all PLs, to various degrees. It is
>> not really a matter of intelligence.
>
> I don't think I've ever mentioned intelligence in this thread...

Juan Manuel is free of blame in this case, although I didn't know
bringing up intelligence was frown upon :)

> Not really. Its development was sponsored by the DoD, but the
> team(s) that created it (CII Honeywell Bull for Ada 80/83,
> Intermetrics for Ada 95) were from the industry.

Cool facts, but isn't that always the case? If the warlords
themselves were to develop computer systems, those systems
wouldn't do any warfare any good.

> Believe me, I use C++ as little as possible. In my list of
> preferred "modern" languages, the only one that would score even
> worse is Java.

Yes, Java is a joke.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Fri, Jul 19, 2013 at 6:02 PM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Juan Manuel is free of blame in this case

"Juan Manuel"?

> Cool facts, but isn't that always the case? If the warlords
> themselves were to develop computer systems, those systems
> wouldn't do any warfare any good.

Well, DoD sponsored Ada, but Ada was never meant to be a military-only
language, and in fact today is more likely used in high-security
non-military settings (cars, avionics, trains, rockets, medical
equipment, etc.).

   J

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> "Juan Manuel"?

Sorry, Juanma it is.

> Well, DoD sponsored Ada, but Ada was never meant to be a
> military-only language, and in fact today is more likely used in
> high-security non-military settings (cars, avionics, trains,
> rockets, medical equipment, etc.).

Yes, and it was in this setting - real time systems - that I had
my rendezvous with Ada.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

>> "Juan Manuel"?
>
> Sorry, Juanma it is.

You type really fast.

Even if you make a spelling mistake, it still makes sense.  That's an
amazing feat.

Re: Speeding up Emacs load time

[Emanuel Berg]

Juanma Barranquero <lekktu@gmail.com> writes:

> Well, DoD sponsored Ada, but Ada was never meant to be a
> military-only language, and in fact today is more likely used in
> high-security non-military settings (cars, avionics, trains,
> rockets, medical equipment, etc.)

I stumbled upon a book in my school's library on RTSs, and I found
some interesting material on Ada. Apparently, the DoD wanted it
because there were massive "reinvention of the wheel" all around
the US military. Software solving the same tasks were developed
over and over, in different languages. The army preferred FORTRAN,
the navy CMS-2, and the air force JOVIAL (of those, I've only
heard of FORTRAN). So, the people at the DoD wanted to put an end
to this, because the DoD was the biggest buyer of software in the
world. After a competition what language to pick, they went for
Ada. Ada was (is) great, but perhaps too much so: early compilers
did not create fast executables, and programmers were not used to
think in the lines of the Ada task model. For simple tasks, Ada
was too bulky.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eli Zaretskii]

> Date: Mon, 15 Jul 2013 21:13:03 -0700 (PDT)
> From: Rustom Mody <rustompmody@gmail.com>
> 
> 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.

Yes, but all that happens internally and (mostly, as much as is
practically possible) transparently to users.

> 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

No, I think I'm saying that Emacs is very much into the active
portability business.

> 1. Every windows program would print OTB -- except emacs

Emacs doesn't print OTB on Unix as well, you need to configure the
printing.

> 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.

My solution is to use Emacs for almost everything, and use ported GNU
software for everything else.  Puff! the problem's gone.

> 3. The .emacs would simply not be found because $HOME does not have a central existence on windows as it does on unix.

That's outdated: there _is_ the equivalent of $HOME on modern Windows
systems, has been since Windows 2000.  And Emacs uses that if you
don't set HOME in the environment.

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

I never contradicted that.  I said that once set up, it works the
same, but that's all.

> 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!!

Google for it, and you will find it.

Re: Speeding up Emacs load time

[Emanuel Berg]

Eli Zaretskii <eliz@gnu.org> writes:

> We must have very different thresholds of pain.

You have no idea what you're talking about.

Take a look at this dump:

http://user.it.uu.se/~embe8573/gnus/dumps/write_article.png

Do you know why it looks like that, and not like some stinking,
bloodsucking Windows MS Access with a white background, a blinking
cursor, a minimal font, constant popups, and lack of shortcuts and
cursor movement functionality that will have you reach for the
mouse, type, type again, type ten, twenty times as much as I've
been able to minimize it to, through years of customization,
setting up zsh and Emacs shorthands in absurdum never to have to
strike a single key that is not necessary?

I suspect you probably don't get any of this, because if you did,
you would never say what you said with zero information about the
other person, accept that you disagreed over some silly issue.

But, ... just for the record, I know I'm far from the only guy who
suffered physically because of love for computers.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Tue, 16 Jul 2013 12:07:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We must have very different thresholds of pain.
> 
> You have no idea what you're talking about.
> 
> Take a look at this dump:
> 
> http://user.it.uu.se/~embe8573/gnus/dumps/write_article.png

Mine looks very similar.  And your point is?..

> Do you know why it looks like that, and not like some stinking,
> bloodsucking Windows MS Access with a white background, a blinking
> cursor, a minimal font, constant popups, and lack of shortcuts and
> cursor movement functionality that will have you reach for the
> mouse, type, type again, type ten, twenty times as much as I've
> been able to minimize it to, through years of customization,
> setting up zsh and Emacs shorthands in absurdum never to have to
> strike a single key that is not necessary?
> 
> I suspect you probably don't get any of this, because if you did,
> you would never say what you said with zero information about the
> other person, accept that you disagreed over some silly issue.

I can agree that it was silly to say that installing Emacs on Windows,
which boils down to unzipping a single zip file, is painful.

If you meant to say anything else, I'm sorry, but I didn't get it.

Re: Speeding up Emacs load time

[Emanuel Berg]

Eli Zaretskii <eliz@gnu.org> writes:

> Mine looks very similar.  And your point is?

The black background - *much* less light enters your eyes. But it
is not like the light from (for example) the sun, because the
light from the monitor (projector in my case) holds information
that must be decoded, and, at a fixed distance, while maintaining
a high degree of concentration, it makes your eyes not blink -
which makes for *dry* eyes. The black background really, really
helps.

Different faces - seeing, rather than reading, to comprehend -
navigating in a file - like, to qualitatively different things,
next to each other, should never have the same face - makes it
much easier to debug, to.

Blinking cursor - popups - nothing should happen unless you do
something, because the eye/brain decoder is unprepared (sort of, I
know this after years of trial-and-error, I don't pretend to know
exactly how it works). In general, being relaxed helps a lot,
which is the same for martial arts, boxing, etc. - easier said
than done, though.

Reaching for the mouse, but even reaching on the keyboard - say,
for the F1 etc. keys or the numpad - is a potential *killer*, and
I've spent weeks on eradicating that entire situation - because
whenever you reach, and fail to get back, you must look down to
correct - and when you look *up*, the visual "reorient" can be
painful beyond belief.

As for typing - lots of great guys had to retire from the game
because their fingers for various reasons couldn't take it. The
"word on the street" is that poor blood circulation leads to cold
fingers, that get stiff, ..., I guess *that* is no more
complicated than why you do warm-up before you do something
physical.

But there is also the eye aspect of typing - if typing is fast,
and shortcuts are close, then obviously less *time* is spent using
your eyes to solve your task.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Peter Dyballa]

Am 16.07.2013 um 21:58 schrieb Emanuel Berg:

> The black background - *much* less light enters your eyes. But it
> is not like the light from (for example) the sun, because the
> light from the monitor (projector in my case) holds information
> that must be decoded, and, at a fixed distance, while maintaining
> a high degree of concentration, it makes your eyes not blink -
> which makes for *dry* eyes. The black background really, really
> helps.

I think I must thank a possibly higher being that I'm not that normal, maybe the cause is just that I'm from the same nationality as the guy (he actually lived only a few km away from me) who invented the trouser press, ehh, no, not that (although it's a very fine song of the Bonzo Dog Doo-Dah Band), but the letterpress (printing machine). I'm so glad that he started to blacken only small parts of the bright paper. And that computers can look like books instead of ancient CRTs.

--
Greetings

  Pete

If the majority of cooking accidents happen in the kitchen, then why don't we just cook in other rooms?

Re: Speeding up Emacs load time

[Emanuel Berg]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> I think I must thank a possibly higher being that I'm not that
> normal

That's always the case. Only Cipher was fool enough dreaming of
re-entering the Matrix.

> maybe the cause is just that I'm from the same nationality as
> the guy (he actually lived only a few km away from me) who
> invented the trouser press, ehh, no, not that (although it's a
> very fine song of the Bonzo Dog Doo-Dah Band), but the
> letterpress (printing machine). I'm so glad that he started to
> blacken only small parts of the bright paper. And that computers
> can look like books instead of ancient CRTs.

Computers can look any way you want them to, that is the beauty,
and bottom line truth to it all.

As for books, I love them to. And with sunglasses, I read them
every day (and night). Only modern magazines are a bit
painful. When I get rich, I'll hire a dancing girl to read them
aloud for me.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Thien-Thi Nguyen]

() Emanuel Berg <embe8573@student.uu.se>
() Tue, 16 Jul 2013 23:11:22 +0200

   When I get rich, I'll hire a dancing girl
   to read them aloud for me.

three hands, live, to trace cycles in still air,
last one, wide, thumb deep in gutenberg's heir.
 lips quietly droning,
 hips please-please-me-zoning,
dark-limmed kali prances in fool king's lair.

thi

Re: Speeding up Emacs load time

[Dmitry Gutov]

Emanuel Berg <embe8573@student.uu.se> writes:

> The black background - *much* less light enters your eyes. But it
> is not like the light from (for example) the sun, because the
> light from the monitor (projector in my case) holds information
> that must be decoded, and, at a fixed distance, while maintaining
> a high degree of concentration, it makes your eyes not blink -
> which makes for *dry* eyes. The black background really, really
> helps.

It only works if you're sitting in a darkly-lit room, using dark desktop
theme, and don't routinely switch to e.g. web browser, wherein most of
the websites are dark-on-light.

Otherwise, the switching between levels of contrast will put even more
strain on the eyes. I'm sure you'll notice that when you get a few more
years sitting before a computer under your belt. I'm 26, and I've
started paying attention to this 2-3 years ago.

> Blinking cursor - popups - nothing should happen unless you do
> something

I agree, the cursor shouldn't blink by default.

Re: Speeding up Emacs load time

[Juanma Barranquero]

On Tue, Jul 16, 2013 at 11:25 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> It only works if you're sitting in a darkly-lit room, using dark desktop
> theme, and don't routinely switch to e.g. web browser, wherein most of
> the websites are dark-on-light.
>
> Otherwise, the switching between levels of contrast will put even more
> strain on the eyes.

Agreed. I used a dark background in Emacs for years. I recently (in
the last couple of years) had to switch to black over a white
background because my eyes had a hard time adapting every time I
switched from Emacs to a browser tab and back.

    J

Re: Speeding up Emacs load time

[Dan Espen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> The black background - *much* less light enters your eyes. But it
>> is not like the light from (for example) the sun, because the
>> light from the monitor (projector in my case) holds information
>> that must be decoded, and, at a fixed distance, while maintaining
>> a high degree of concentration, it makes your eyes not blink -
>> which makes for *dry* eyes. The black background really, really
>> helps.
>
> It only works if you're sitting in a darkly-lit room, using dark desktop
> theme, and don't routinely switch to e.g. web browser, wherein most of
> the websites are dark-on-light.
>
> Otherwise, the switching between levels of contrast will put even more
> strain on the eyes. I'm sure you'll notice that when you get a few more
> years sitting before a computer under your belt. I'm 26, and I've
> started paying attention to this 2-3 years ago.

I'm 67 and I say nope.

-- 
Dan Espen

Re: Speeding up Emacs load time

[Dmitry Gutov]

Dan Espen <despen@verizon.net> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> It only works if you're sitting in a darkly-lit room, using dark desktop
>> theme, and don't routinely switch to e.g. web browser, wherein most of
>> the websites are dark-on-light.
>>
>> Otherwise, the switching between levels of contrast will put even more
>> strain on the eyes. I'm sure you'll notice that when you get a few more
>> years sitting before a computer under your belt. I'm 26, and I've
>> started paying attention to this 2-3 years ago.
>
> I'm 67 and I say nope.

I take it you've been using dark terminals, themes, etc, while switching
to applications with different levels of contrast and back, for quite a
few years now. Right?

How are your eyes these days? No glasses?

Re: Speeding up Emacs load time

[Dan Espen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> It only works if you're sitting in a darkly-lit room, using dark desktop
>>> theme, and don't routinely switch to e.g. web browser, wherein most of
>>> the websites are dark-on-light.
>>>
>>> Otherwise, the switching between levels of contrast will put even more
>>> strain on the eyes. I'm sure you'll notice that when you get a few more
>>> years sitting before a computer under your belt. I'm 26, and I've
>>> started paying attention to this 2-3 years ago.
>>
>> I'm 67 and I say nope.
>
> I take it you've been using dark terminals, themes, etc, while switching
> to applications with different levels of contrast and back, for quite a
> few years now. Right?

Yep, long, long time.

> How are your eyes these days? No glasses?

You're kidding right?  Everyone needs glasses at my age.
I wear 1.25/1.25 for reading and looking at the screen only,
otherwise my vision is perfect.

On a good day I can get by without the glasses.

-- 
Dan Espen

Re: Speeding up Emacs load time

[Dmitry Gutov]

Dan Espen <despen@verizon.net> writes:

>> I take it you've been using dark terminals, themes, etc, while switching
>> to applications with different levels of contrast and back, for quite a
>> few years now. Right?
>
> Yep, long, long time.
>
>> How are your eyes these days? No glasses?
>
> You're kidding right?  Everyone needs glasses at my age.
> I wear 1.25/1.25 for reading and looking at the screen only,
> otherwise my vision is perfect.

I know I'm being unreasonable, but if you didn't need glasses, it
would've been a strong argument against. As it is, though, I can't make
a good guess whether you vision is worse or better than if you made an
effort to keep levels of contrast constant.

The fact that you didn't notice your eyes being tired doesn't mean they
weren't. Maybe it was accompanied by a headache, and the latter was more
pronounced. Or maybe you kept a healthy lifestyle, took necessary pauses
every X minutes and limited work with computers to 6-8 hours a day.

Most days, I'm behind monitor 12+ hours, and so I've found I have to pay
attention to posture, wrist placement, neck and the eyes. And exercise,
of course.

Re: Speeding up Emacs load time

[Emanuel Berg]

Dmitry Gutov <dgutov@yandex.ru> writes:

> The fact that you didn't notice your eyes being tired doesn't
> mean they weren't. Maybe it was accompanied by a headache, and
> the latter was more pronounced. Or maybe you kept a healthy
> lifestyle, took necessary pauses every X minutes and limited
> work with computers to 6-8 hours a day.

That, but people are very different. Not all people get all
problems, no matter what they do. The human body is a biochemical
machine, and it is not exactly "real time" in terms of
predictability. Your reasoning holds *in general* but there is
nothing to say it must hold for every single person or pair of
eyes.

> Most days, I'm behind monitor 12+ hours, and so I've found I
> have to pay attention to posture, wrist placement, neck and the
> eyes. And exercise, of course.

If you can, try a projector. That way, you must keep your spine
straight, and head up. This will also benefit your posture
AFK. But twelve hours - that's a lot.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Eye strain and ergonomics

[Dmitry Gutov]

Emanuel Berg <embe8573@student.uu.se> writes:

> That, but people are very different. Not all people get all
> problems, no matter what they do. The human body is a biochemical
> machine, and it is not exactly "real time" in terms of
> predictability. Your reasoning holds *in general* but there is
> nothing to say it must hold for every single person or pair of
> eyes.

Yes, naturally. But a person would do well not to deny that such a
tendency exists.

> If you can, try a projector. That way, you must keep your spine
> straight, and head up. This will also benefit your posture
> AFK. But twelve hours - that's a lot.

I don't think I'll be able to, in the near future. For the time being, I
try to make up for it with a large monitor, placed on the same level as
my head.

Re: Eye strain and ergonomics

[James Freer]

On Wed, Jul 17, 2013 at 1:24 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> That, but people are very different. Not all people get all
>> problems, no matter what they do. The human body is a biochemical
>> machine, and it is not exactly "real time" in terms of
>> predictability. Your reasoning holds *in general* but there is
>> nothing to say it must hold for every single person or pair of
>> eyes.
>
> Yes, naturally. But a person would do well not to deny that such a
> tendency exists.
>
>> If you can, try a projector. That way, you must keep your spine
>> straight, and head up. This will also benefit your posture
>> AFK. But twelve hours - that's a lot.
>
> I don't think I'll be able to, in the near future. For the time being, I
> try to make up for it with a large monitor, placed on the same level as
> my head.

FWIW
I have used computers for 8 hours per day plus for over 20 years now.
I have had no problems with eye strain or otherwise, and have always
had the monitor at head height. I have ALWAYS used a CRT monitor as
laptops i am sure do cause eye strain problems. Both my brother and
sister use computers and have had to wear glasses for sometime now.

james

Re: Eye strain and ergonomics

[Emanuel Berg]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Yes, naturally. But a person would do well not to deny that such
> a tendency exists.

Aha, he did? I saw only that he said that he didn't have it.

> I don't think I'll be able to, in the near future. For the time
> being, I try to make up for it with a large monitor, placed on
> the same level as my head.

OK, but remember it, at least. Might come handy.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Dan Espen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Dan Espen <despen@verizon.net> writes:
>
>>> I take it you've been using dark terminals, themes, etc, while switching
>>> to applications with different levels of contrast and back, for quite a
>>> few years now. Right?
>>
>> Yep, long, long time.
>>
>>> How are your eyes these days? No glasses?
>>
>> You're kidding right?  Everyone needs glasses at my age.
>> I wear 1.25/1.25 for reading and looking at the screen only,
>> otherwise my vision is perfect.
>
> I know I'm being unreasonable, but if you didn't need glasses, it
> would've been a strong argument against. As it is, though, I can't make
> a good guess whether you vision is worse or better than if you made an
> effort to keep levels of contrast constant.
>
> The fact that you didn't notice your eyes being tired doesn't mean they
> weren't. Maybe it was accompanied by a headache, and the latter was more
> pronounced. Or maybe you kept a healthy lifestyle, took necessary pauses
> every X minutes and limited work with computers to 6-8 hours a day.
>
> Most days, I'm behind monitor 12+ hours, and so I've found I have to pay
> attention to posture, wrist placement, neck and the eyes. And exercise,
> of course.

Keep trying.

I don't get headaches, ever.
I use the computer for work (programmer), and recreation.

Ever think that looking at bright things and dark things might
be pupil exercise?

Of course I prefer light on dark, that's why I have Emacs that way.
Firefox, I can't do much about, but the white background doesn't
bother me much.

By the way, I pound on the keyboard.
No problem there either.

What's the phrase, if it doesn't kill you, it will make you stronger.

-- 
Dan Espen

Re: Speeding up Emacs load time

[Emanuel Berg]

Dmitry Gutov <dgutov@yandex.ru> writes:

> It only works if you're sitting in a darkly-lit room, using dark
> desktop theme, and don't routinely switch to e.g. web browser,
> wherein most of the websites are dark-on-light.

100% correct - a dark room, or even a dark room, *and*
sunglasses... Man, I'm happy you understand me!

The web browser issue - well, you could configure Firefox but
incompletely so. I use Emacs-w3m. That's not optimal, either,
because all the webpages are designed to be used in a GUI setting
(with different font sizes etc. to convey information). It doesn't
matter how "good" Emacs-w3m gets. But it is still much
better. (And the integration and configurability on to of
that. Dropping the mouse and FF/Iceweasel improved my life a lot.)

> Otherwise, the switching between levels of contrast ...

I *know*, this is what a said - the visual reorient. Why do you
think this is news for me? It is not.

> I'm sure you'll notice that when you get a few more years
> sitting before a computer under your belt. I'm 26, and I've
> started paying attention to this 2-3 years ago.

:) I'm 30! And I've had this for ages. But I take it as a
compliment, don't worry.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Dmitry Gutov]

Emanuel Berg <embe8573@student.uu.se> writes:

> 100% correct - a dark room, or even a dark room, *and*
> sunglasses... Man, I'm happy you understand me!

Sunglasses in a dark room is overdoing it. Just a bit. :)

> The web browser issue - well, you could configure Firefox but
> incompletely so. I use Emacs-w3m. That's not optimal, either,
> because all the webpages are designed to be used in a GUI setting
> (with different font sizes etc. to convey information). It doesn't
> matter how "good" Emacs-w3m gets. But it is still much
> better. (And the integration and configurability on to of
> that. Dropping the mouse and FF/Iceweasel improved my life a lot.)

Mouse is fine for "just reading", which I spend a fair amount of my time
doing. And, yeah, "dark" browser themes with light pieces sticking out
are even more painful.

IME, the main point is to keep contrast level more or less
unchanging. Eyes adapt to the lighting level relatively easily.

Lowering the monitor brightness level a bit never hurts, though.

>> Otherwise, the switching between levels of contrast ...
>
> I *know*, this is what a said - the visual reorient. Why do you
> think this is news for me? It is not.

Ah, ok. But overall, your whole workflow description likely means that
you have a *lower* pain threshold than Eli, which was his point.

Re: Speeding up Emacs load time

[Emanuel Berg]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Sunglasses in a dark room is overdoing it. Just a bit. :)

On the contrary, that's great. There is no such thing as
"overdoing" when solving a problem. If you solve a problem 100%
what does it hurt to solve it 120%?

But that's not even relevant because this is not overdoing. I
never solved a single problem in my life 100% - I reduced them,
built support around them, rolled with them ...

> Mouse is fine for "just reading"

I think the mouse is a killer. It is not productive, it is not
ergonomic. Perhaps some "wheel" on the keyboard for just reading,
so your arms are at least resting, if you want a more "analogue"
UX. Perhaps in as GIS application the mouse is motivated, but
actually even then, I doubt it.

> And, yeah, "dark" browser themes with light pieces sticking out
> are even more painful.

I'm way beyond themes. I setup everything face by face. That
wasn't possible in FF/Iceweasel, which was part of why I switched
to Emacs-w3m (but not the sole reason).

If you talk a look at the dump I posted, the *colors* are not
dark. (Without sunglasses, I would make everything dark.)

Check out this HP I put together on colors I while back. I don't
use X anymore, but I thought it would be a waste of effort not to
publish the work I put into it. There are lots of Emacs stuff, and
screenshots, to.

http://user.it.uu.se/~embe8573/cols/www/index.html

> IME, the main point is to keep contrast level more or less
> unchanging. Eyes adapt to the lighting level relatively easily.

In a brightly lit room, with monitors (not projectors), with -
well, basically everything I described earlier, that I didn't like
- I'd go *blind*.

> Lowering the monitor brightness level a bit never hurts, though.

I tried that, but I never got a solid conclusion - sometimes, not
*seeing* made for a problem just as big - I dropped monitors
altogether, I'm exclusively using the projectors at my school. I
don't watch TV (never), but sometimes I got to the cinema, with
less strain. I suppose it is the same principle - distance,
relaxation, those things I mentioned...

> Ah, ok. But overall, your whole workflow description likely
> means that you have a *lower* pain threshold than Eli, which was
> his point.

*Lower* what? (What does that mean?) As for pain management, I
have practitioned boxing and Muay Thai (kickboxing), and I have
been productive with computers while at the same time experiencing
severe hand and eye pain. I don't know what more there is to
it. Reality.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Drew Adams]

> I think the mouse is a killer. It is not productive, it is not
> ergonomic.

Any pointer device, and a mouse is one (among other things it can
be), has this feature: you look at something, anywhere, you point
to it to do something with it or to it.  End of story.

Nothing beats that eye-hand direct-manipulation thing for what it
offers.  Neither text completion/search nor a command/key to go
directly to the thing by name, number, description, whatever.  Nada.

When you want to do something interactively with or to a particular
pixel you see somewhere, you typically do not want to refer to it
by name or number.  You want to point to it directly.  QED.  CQFD.

This should have been clear to everyone since their first experience
with a pointer device, typically their index finger.  But some will
never get it, it seems.  Never.

"Gimme that.  That over there.  Two feet from the door, on the right,
four feet up, against the wall.  No, just to the left of that thing
... three objects over.  No, the blue one.  That's it.  Thanks."

Of course, if all you know is a hammer (or a mouse, for that matter)
then everything looks like a nail.  Keyboard keys are great for what
they offer.  A pointer device is better for, uh, ... pointing.
That's all.

Next time, try picking your nose using a keyboard.  (Might make an
interesting GSOC project...)

Re: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

> Next time, try picking your nose using a keyboard.

Tried imagining it.  Had a good hearty laugh.

Re: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> I think the mouse is a killer. It is not productive, it is not
>> ergonomic.
>
> Any pointer device, and a mouse is one (among other things it can
> be), has this feature: you look at something, anywhere, you point
> to it to do something with it or to it.  End of story.

I beg to differ. A counterexample is ace-jump-mode. You look at the word
you wish to jump, press the hotkey (Space in my case, with evil-mode),
press the first letter of that word, which is replaced by some other
letter, you press that letter and the cursor jumps. The whole process is
faster than moving the hand from the keyboard to the mouse, and much
faster than moving the mouse pointer to that position on the screen and
clicking.

> Nothing beats that eye-hand direct-manipulation thing for what it
> offers.  Neither text completion/search nor a command/key to go
> directly to the thing by name, number, description, whatever.  Nada.

ace-jump consists on eye-hand manipulation using a keyboard, so maybe we
are in agreement after all :-)

RE: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Drew Adams]

> >> I think the mouse is a killer. It is not productive, it is not
> >> ergonomic.
> >
> > Any pointer device, and a mouse is one (among other things it can
> > be), has this feature: you look at something, anywhere, you point
                                       ^^^^^^^^^^^^^^^^^^^
I should have said "anything", not "something", to be even clearer.
Anything you can see, that is.

> > to it to do something with it or to it.  End of story.
> 
> I beg to differ. A counterexample is ace-jump-mode. You look at the
> word you wish to jump,

A word is not just "anything".  But it is certainly one kind of thing,
so OK, even if what you say does not apply generally.

> press the hotkey (Space in my case, with evil-mode),
> press the first letter of that word,

Which means you are NOT just pointing to something.  You are analyzing
what it is that you are seeing, and finding something about it that
you can use to distinguish it, and then specifying that distinguishing
property.

This is no different in principle from describing the thing you want
as "the third blue one to the left of the orange, square one".

The fact that your interaction might be rapid is irrelevant to the
point (my point).  You are going to extra trouble to distinguish the
thing you want, beyond just locating it directly by pointing to what
you see.  You might as well be giving its GPS coordinates.

The only ambiguity in pointing is the precision of the pointer (and
your eye & hand).  If you do something other than point then you need
to narrow things down in some other way until you have characterized
the object you want uniquely.  That's a lot more complex in principle,
and often in practice too.

> which is replaced by some other letter, you press that letter and the
> cursor jumps. The whole process is faster than moving the hand from
> the keyboard to the mouse, and much faster than moving the mouse
> pointer to that position on the screen and clicking.

Whether you can do something fast is irrelevant to the point I am
making.  Some people can type a whole paragraph before some other
people can manage to get their mouse out of its holster and aim and
shoot it and hit the target.  Irrelevant.  (That doesn't mean it is
irrelevant to your personal choice of interaction.)

> > Nothing beats that eye-hand direct-manipulation thing for what it
> > offers.  Neither text completion/search nor a command/key to go
> > directly to the thing by name, number, description, whatever.  Nada.
> 
> ace-jump consists on eye-hand manipulation using a keyboard, so maybe we
> are in agreement after all :-)

No, we are not in agreement, I'm afraid.  The point is about directly
pointing to something.  Direct is the keyword.  The time to execute the
interaction is not relevant to my point.

There are all kinds of keyboard interactions and shortcuts, including
single-key go-to actions that take you directly to a particular
object, where the distinguishing takes place in (a) the choice of
which key to hit and (b) the code behind that key, which does the
object locating.

None of that invalidates my point.  You must (consciously or not so
consciously) (a) choose the shortcut (or in your case locate and
analyze the target word and figure out its distinguishing prefix)
and (b) effect it (hit a key or type some text to be completed etc.)

That is not the same thing as locating the object visually and just
pointing to it.  Not at all.  Regardless of which you might find
faster to do in practice.  It's about direct and simple and natural.
It is not necessarily about speed.

In particular, no one is arguing that pointing is always the best
way to communicate.  That would be equivalent to wishing us to drop
language of any kind beyond the most rudimentary gestures.

A baby pointing at an object is one way to interact, but not the
only one.  And in particular, there is the question of associating
different actions and intentions with the object pointed to (want,
don't want, eat, gimme, scares me, what is it?...).

My point is simply that pointing devices can be useful, and a mouse
is a handy pointing device.  My second point is that there is more
than one useful tool in life's tool chest.  Nothing limits you to
just a mouse or just a keyboard.

Re: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

> My point is simply that pointing devices can be useful, and a
> mouse is a handy pointing device.  My second point is that there
> is more than one useful tool in life's tool chest.  Nothing
> limits you to just a mouse or just a keyboard.

Yes. When I started this whole discussion I didn't consider all
scenarios. And I've mentioned applications (and games) where
pointing makes sense. But when typing in Emacs - programming - I
don't think the mouse makes sense. And, in many applications that
have GUIs (buttons, fields, etc.) I *still* don't think the mouse
makes sense. All that functionality should be assigned shortcuts
and commands (and why use a GUI at all?). The mouse makes sense
with drawing (GFX), GIS, navigation (perhaps, I have never seen
such an application), and so on.

But - typically, is mouse use restricted to areas where it makes
sense? With users, *and* with computer people? My impression is -
no, not at all. My impression is that people use the mouse all the
time. Like I mentioned in another thread, I studied CS for several
years. Perhaps one third of my classmates used Linux or some other
Unix-like OS, but the rest used Windows or even Mac OS!

So I can absolutely not say that people do the conscious choice
(the "tool chest" pick), and without that your reasoning is -
utopia. People use the mouse *all the time*, and not only stupid
consumers of Internet fast food. They just click around like kids,
high on sugar, and it is pain just to witness.

> The time to execute the interaction is not relevant to my point.

To me, speed is *always* one of the top properties of
anything. But in this case, precision, and a non-interrupted
workflow, as well as ergonomics, are even more important.

By the way, I read the Wikipedia article on the mouse's inventor
that you recommended. There were some cool facts in that article,
but not a lot on the pros and cons on the mouse, in
particular. But for the record: just because I don't like the
mouse doesn't mean I don't have respect for the people who
developed it.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Emanuel Berg]

Óscar Fuentes <ofv@wanadoo.es> writes:

> A counterexample is ace-jump-mode. You look at the word you wish
> to jump, press the hotkey ...

I have never seen that. Isn't that what fighter pilots do, with
their HUDs? Intuitively, I don't like it at all. I want to be able
to relax my eyes and just let my fingers type.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Highway Musophobia Revisited

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

You seem to be in favour of the mouse, but what you write is part
of why I don't like it:

> "Gimme that.  That over there.  Two feet from the door, on the
> right, four feet up, against the wall.  No, just to the left of
> that thing ... three objects over.  No, the blue one.  That's
> it.  Thanks."
>
> A pointer device is better for, uh, ... pointing.

You point when you *can't* express your wish. It is a last,
style-less resort. "You [point] do (something)" (like some moron)
"What, me? Him?". Compared to *knowing* (which is always better):
"Carl, take care of (something)."

With pixels, it is more difficult, *but not that much*. With
training, everything is possible to express.

If you go to the forest, and call you friends "There are bunch of
trees - uh...". But do it ten times, and you will be able to
describe the scene so precisely they will know instantly where
you are. (If they underwent the same training, that is.)

There is a book - an e-book, at least - called "tmux: Productive
Mouse-Free Development" - I haven't read it, yet, but the title is
very promising.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

RE: Highway Musophobia Revisited

[Drew Adams]

> You seem to be in favour of the mouse

You seem to be grasping at straws.

I am in favor of the spoon.  And the knife.  And chopsticks.
And fingers.  And a straw.  And...

The keyword is `and', not `xor'.

> it is more difficult, *but not that much*. With training, 
> everything is possible to express.

You are apparently trying to make a virtue of self-imposed
necessity.

If you have only a spoon you will make do with a spoon to
cut your crust of bread.  If you have only a straw you will
suck up your soft-boiled egg with it.  Bravo.  Look ma, no
hands!  M'as-tu vu !?

> do it ten times, and you will be able to describe the
> scene precisely

Hair shirt.

Sure, you can blindfold yourself and learn to get around
pretty well with enough blind practice.  Practice hard and
you can learn to walk only on your hands or keyboard only
with your toes.  And you can rightfully be proud of the
accomplishment.

But if are lucky enough to have functioning eyes, legs, and
hands then you can also choose to use them.  There are lots
of tools in life's tool chest.  Drop the hammer occasionally
and see beyond the nails.

Re: Highway Musophobia Revisited

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

> But if are lucky enough to have functioning eyes, legs, and
> hands then you can also choose to use them.  There are lots of
> tools in life's tool chest.

I agree, but I did not say you should dispose of any tools (at
least not any good tools). I said you should master *the best*
tools. But the best tools are not always those who are the easiest
to master, or the most obvious to notice.

But if you are persistent in you efforts and acquire the new skill
- have you ever heard a person say, "I shouldn't have done that. I
should have stuck to the lousy tool?"

The mouse *is* a lousy tool - with the exception of FPS games,
perhaps RTS games (I don't play games), and (perhaps) some
GIS/navigation/etc. applications.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Highway Musophobia Revisited

[Jambunathan K]

This thread is about how to help "Andrew Pennebaker" to help speed up
his Emacs load time.  Do you - or others - any useful tips or questions
to Mr. Andrew?

Re: Highway Musophobia Revisited

[Jambunathan K]

This thread is about how to help "Andrew Pennebaker" to help speed up
his Emacs load time.  Do you - or others - have any useful tips or
questions to help Mr. Andrew out?

RE: Highway Musophobia Revisited

[Drew Adams]

> The mouse *is* a lousy tool - with the exception of FPS games,
> perhaps RTS games (I don't play games), and (perhaps) some
> GIS/navigation/etc. applications.

Two words that might help you in your ongoing quest for humility:
Douglas Engelbart.

http://www.dougengelbart.org/firsts/mouse.html

http://en.wikipedia.org/wiki/Douglas_Engelbart

https://www.youtube.com/watch?v=yJDv-zdhzMY&t=33m37s

Re: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Rustom Mody]

On Wednesday, July 17, 2013 5:18:42 AM UTC+5:30, Drew Adams wrote:
> 
> Any pointer device, and a mouse is one (among other things it can
> be), has this feature: you look at something, anywhere, you point
> to it to do something with it or to it.  End of story.

> This should have been clear to everyone since their first experience
> with a pointer device, typically their index finger.  But some will
> never get it, it seems.  Never.
>
> "Gimme that.  That over there.  Two feet from the door, on the right,
> four feet up, against the wall.  No, just to the left of that thing
> ... three objects over.  No, the blue one.  That's it.  Thanks."
> 
> Next time, try picking your nose using a keyboard.  (Might make an
> interesting GSOC project...)

Ha! Beautiful! <applause>
Just to add to what you are saying:  Why are apple and samsung raking in billions?  Quite simply because touch-devices are to the mouse what the mouse is to the keyboard.
With a keyboard one needs to know a command-line/keybindings etc, all the makings of nerdiness to become a user.
A mouse allows a non-nerd to become a user. It yet needs some analogizing between the pointing and the pointed.
Unify the two into a single touch-device and now 4-year-olds become users.

Having said that I need to make a frank admission (to Emanuel):
In the last 24 hours Ive gone through a struggle to upgrade my Samsung touch phone.  The unpleasantness of poor software from samsung combined with having to get into the rude/exploitative behavior of microsoft -- at one point it said my laptop is being updated and it would take 2 days!! -- makes Emanuel's diatribes against microsoft seem gentlemanly!

Re: Highway Musophobia Revisited [was: Speeding up Emacs load time]

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> Just to add to what you are saying: Why are apple and samsung
> raking in billions?  Quite simply because touch-devices are to
> the mouse what the mouse is to the keyboard.  With a keyboard
> one needs to know a command-line/keybindings etc, all the
> makings of nerdiness to become a user.  A mouse allows a
> non-nerd to become a user. It yet needs some analogizing between
> the pointing and the pointed.  Unify the two into a single
> touch-device and now 4-year-olds become users.

Right. But as you might have guessed, I'm not talking about
users. Users want to know as little as possible, but still be
users (the lower bound, or the rule of least resistance). I want
to know as *much* as possible, and not be a users at all, but a
creator.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Yes, it is.  I'm guessing that the above is due to the fact that
>> you missed many external programs that Emacs invokes to provide
>> some of its features.  Those programs exist in Windows ports ...
>
> I'm sure they do, but when I run a command, I don't think in which
> module that is, to me it is all Emacs.
>
> Perhaps my statement should be specified into: Emacs AND Linux is
> not the same as Emacs AND Windows. It doesn't matter if Emacs is
> the same, if it doesn't play the same in a new environment -
> perhaps Emacs should *not* be the same to make it work the same?

I have used Emacs on both Windows and Linux.  It is my observation that
when I am on my Emacs or Windows, I can pretty much forget the platform
altogether.

The main "issues" are in configuration and setup.  Once that is
surmounted, it is all easy.

> My .emacs broke on a dozen plus places - and the only thing I ever
> installed separately on Debian is some LaTeX stuff (that I
> remember).

You should tell us what exactly broke.  If you are sure that Emacs can
be improved or repaired, file bug reports with M-x report-emacs-bugs
RET.

A few words:

1. Don't rely on Third Party libraries particularly from Emacswiki.
2. Emacswiki is a great resource, but it is a big time-waster.
3. Don't try to customize too much.  I told you so already.

Re: Speeding up Emacs load time

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> You should tell us what exactly broke.  If you are sure that
> Emacs can be improved or repaired, file bug reports with M-x
> report-emacs-bugs RET.

No, like I said, I'm not going to try it again. I don't remember
what broke several years back. I mentioned the example with big
files and the initialization, and the installation. I don't care
if that's Emacs "fault" or not because I don't reason like that -
I care only what *is*, and what *is not*.

> 1. Don't rely on Third Party libraries particularly from Emacswiki.
> 2. Emacswiki is a great resource, but it is a big time-waster.

OK. Actually I never searched that place actively but probably
ended up there tons of time indirectly from Google.

> 3. Don't try to customize too much.

I'm going to customize *everything* down to the last
detail. Emacs, the shell, the mail client, the web browser, even
the kernel process scheduler, when I get there! That's the whole
point with everything I do with computing. This is how I
communicate with technology - because that's who I am.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> No, like I said, I'm not going to try it again. I don't remember
> what broke several years back. I mentioned the example with big
> files and the initialization, and the installation. I don't care
> if that's Emacs "fault" or not because I don't reason like that -
> I care only what *is*, and what *is not*.

*If* you run into problems, please report it.

Re: Speeding up Emacs load time

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> *If* you run into problems, please report it.

Sure, and I have done that several times. But this was a story
from several years back (perhaps that didn't come across), and the
past is the past.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Bob Proulx]

Andrew Pennebaker wrote:
> I love Emacs's customizability! I regularly edit my .emacs file, and the
> community has been helpful and encouraging. But I do notice that Emacs can
> take several (10) seconds or longer to load.

My .emacs used to take a while to load as well.  But eventually I made
an effort to speed it up and now it is sub-second.

> For reference, I'm using Emacs 24.1 for Mac OS X, Windows, and Android. I
> keep my .emacs synced, shared, and backed up on GitHub.
> https://github.com/mcandre/dotfiles/blob/master/.emacs
>
> Could someone help me cut down the load time while maintaining the same
> behavior?

I looked at your .emacs file.  It is rather extensive.  Time consuming
parts are usually anytime you (require 'foo) or (load "foo").  Do you
really need all of those executed each and every time you start emacs?
Probably not.

Walk through every one of those in your .emacs file and make sure that
they are placed within an appropriate (eval-after-load "foo" ...)
wrapping like you have for the "grep" case so that they don't take
place at load time but take place only when that particular feature is
used.  If there is confusion then pick one and ask about it.  And then
another.  And continue until all of them are only loaded when that
feature is used.

When timing your startup time how long does it take to start emacs
when not loading anything?  When loading the system startup only?

Timings from my system after much optimization.

  $ time emacs -f kill-emacs
  real    0m0.157s
  user    0m0.140s
  sys     0m0.012s
  $ time emacs -q -f kill-emacs
  real    0m0.137s
  user    0m0.116s
  sys     0m0.016s
  $ time emacs -Q -f kill-emacs
  real    0m0.051s
  user    0m0.028s
  sys     0m0.020s

Bob

Re: Speeding up Emacs load time

[Hongxu Chen]

Bob Proulx <bob@proulx.com> writes:

> Andrew Pennebaker wrote:
>> I love Emacs's customizability! I regularly edit my .emacs file, and the
>> community has been helpful and encouraging. But I do notice that Emacs can
>> take several (10) seconds or longer to load.
>
> My .emacs used to take a while to load as well.  But eventually I made
> an effort to speed it up and now it is sub-second.
>
>> For reference, I'm using Emacs 24.1 for Mac OS X, Windows, and Android. I
>> keep my .emacs synced, shared, and backed up on GitHub.
>> https://github.com/mcandre/dotfiles/blob/master/.emacs>
>> Could someone help me cut down the load time while maintaining the same
>> behavior?
>
> I looked at your .emacs file.  It is rather extensive.  Time consuming
> parts are usually anytime you (require 'foo) or (load "foo").  Do you
> really need all of those executed each and every time you start emacs?
> Probably not.
>
> Walk through every one of those in your .emacs file and make sure that
> they are placed within an appropriate (eval-after-load "foo" ...)
> wrapping like you have for the "grep" case so that they don't take
> place at load time but take place only when that particular feature is
> used.  If there is confusion then pick one and ask about it.  And then
> another.  And continue until all of them are only loaded when that
> feature is used.
>
> When timing your startup time how long does it take to start emacs
> when not loading anything?  When loading the system startup only?
>
> Timings from my system after much optimization.
>
>   $ time emacs -f kill-emacs
>   real    0m0.157s
>   user    0m0.140s
>   sys     0m0.012s
>   $ time emacs -q -f kill-emacs
>   real    0m0.137s
>   user    0m0.116s
>   sys     0m0.016s
>   $ time emacs -Q -f kill-emacs
>   real    0m0.051s
>   user    0m0.028s
>   sys     0m0.020s

Hey Bob, would you mind sharing your .emacs settings(pastebin/gist/github or
something like that)?

Thanks.

>
> Bob

-- 
Regards,
Hongxu Chen

Re: Speeding up Emacs load time

[Bob Proulx]

Hongxu Chen wrote:
> Hey Bob, would you mind sharing your .emacs settings(pastebin/gist/github or
> something like that)?

I don't know how useful it will be to other people.  The .emacs
customization file is by definition to customize it for personal
tastes.  My tastes are going to be different from yours.  But okay.  I
am probably doing twenty things sub-optimally so don't take it
verbatim.

The biggest thing for me was to throw away a lot of lint that had been
collecting for years.  Much of my file contained vestiges that were no
longer needed.  I cleaned brutally and removing as much as possible.
If I didn't use it then I removed it.  That reduced the file to
something much smaller and faster and yet I still have all of the
functionality that I need and use.  If you need a lot of customization
then your load time will be slower.  My question would then be to ask
if you really do need all of the customization?  Clean brutally!

The next biggest thing was to avoid loading or requiring any other
file at load time.  Avoid stat(2)'ing any other file at load time.
(For example file-directory-p stats the file.)  File operations are
slow.  If $HOME is on NFS then file operations are *very* slow.  Make
all of those do "lazy loading" where they only load if the code is
going to be used.  In my case I wrapped them in eval-after-load calls
so that they did not trigger at emacs start but only when I triggered
the associated buffer mode.  YMMV and all of that.  In the end I
removed most of those customizations that I had carried from years ago
and my .emacs is now quite small.

Usually when I share my .emacs someone posts that I should use fboundp
instead of keying off of emacs-major-version.  No I shouldn't.  I want
to leave the trail behind as documentation as to when emacs took its
dark turns and emacs-major-version is self-documenting while fboundp
is not.  Remember that the .emacs is a personal customization file and
this is to my personal taste.  YMMV.

Bob


(message "[reading file ~/.emacs]")     ; -*-emacs-lisp-*-

(if (>= emacs-major-version 20)
    (menu-bar-mode -1))

(if (>= emacs-major-version 21)
    (if window-system
	(tool-bar-mode -1)))

(if (>= emacs-major-version 22)
    (progn
      (setq inhibit-startup-screen t)
      (setq write-region-inhibit-fsync t)
      ;; Have *Buffer List* use old-style header.
      (setq Buffer-menu-use-header-line nil)
      ;; Disable dark blue on dark background in minibuffer.
      (set-face-foreground 'minibuffer-prompt nil)))

(if (>= emacs-major-version 23)
    (progn
      (setq transient-mark-mode nil)
      (setq line-move-visual nil)
      (setq search-whitespace-regexp nil)
      (setq split-width-threshold nil)
      (setq kill-buffer-query-functions nil)))

(if (>= emacs-major-version 24)
    (progn
      ;; C-s changed in 24.  But I use the previous behavior.
      (define-key isearch-mode-map (kbd "C-y") 'isearch-yank-line)))

(if window-system
    (setq mouse-yank-at-point t))

(autoload 'highlight-80+-mode "highlight-80+"
  "Highlight the portions of lines longer than 80 characters." t)

;; Disable nasty highlighting in electric-buffer-mode.
;; We use eval-after-load to make this happen after ebuf-menu is loaded
;; as that's where the "bad" definition of electric-buffer-mode is located.
(eval-after-load "ebuff-menu" '(defun electric-buffer-update-highlight ()))

(eval-after-load 'shell
  '(add-hook 'comint-exec-hook
	     (lambda ()
	       (setq comint-scroll-show-maximum-output nil)
	       ;; Stop the annoying question about exiting with shell
	       ;; processes still running.
	       (set-process-query-on-exit-flag (get-process "shell") nil))))

(add-hook 'text-mode-hook
	  (lambda ()
	    (abbrev-mode 1)
	    (auto-fill-mode 1)))

(add-hook 'c-mode-hook
	  (lambda ()
	    ;; Set '_' to be part of word for dynamic abbreviation
	    ;; expansion and for word movement.
	    (modify-syntax-entry ?_ "w" c-mode-syntax-table)))

(eval-after-load 'ruby-mode
  (and (file-directory-p (expand-file-name "~/emacs/rinari"))
       (add-to-list 'load-path "~/emacs/rinari")
       (autoload 'rinari-web-server "rinari" "Rinari" t)
       (add-hook 'ruby-mode
		 (lambda ()
		   (require 'rinari)))))

(setq w3m-use-cookies t)               ; off by default, but mostly required
(add-hook 'w3m-mode-hook
	  (lambda ()
	    ;; I like the cursor keys to behave normally, not jumping
	    ;; from link to link.
	    (local-set-key '[up] 'previous-line)
	    (local-set-key '[down] 'next-line)))

;; Turn off emacs file~ backups.
(setq make-backup-files nil)

(setq sh-indent-comment t)
(setq executable-prefix "#!")
(setq sh-basic-offset 2)	; originally 4, set my preference
(setq apache-indent-level '8)	; originally 4, match upstream
(setq Man-notify-method 'pushy)

(global-set-key [home] 'beginning-of-buffer) ; orig beginning-of-buffer, now move-end-of-line
(global-set-key [S-home] 'end-of-buffer)
(global-set-key [end] 'end-of-buffer) ; orig end-of-buffer, now move-beginning-of-line
(global-set-key [S-end] 'beginning-of-buffer)

(global-set-key "\C-x\C-b" 'electric-buffer-list) ; originally list-buffers
(global-set-key "\M-r" 'replace-regexp) ; orig 'move-to-window-line
(global-set-key "\M-\C-r" 'query-replace-regexp) ; originally undefined, now isearch-backward-regexp
(global-set-key "\C-l" 'recenter) ; originally recenter, now recent-top-bottom
(global-set-key "\C-z" 'scroll-down)    ; originally suspend-frame

(put 'dired-find-alternate-file 'disabled nil)
(put 'narrow-to-region 'disabled nil)
(put 'downcase-region 'disabled nil)

(setq confirm-kill-emacs 'yes-or-no-p)

(setq auto-mode-alist    ; Note: RE matches full pathname, so
      (append            ; '^' matches / in /dir/dir/filename
       '(
	 ("^\\(/var\\)?/tmp/mutt" . text-mode)
	 )
       auto-mode-alist))

(display-time)

(message "done")

Re: Speeding up Emacs load time

[J. David Boyd]

Bob Proulx <bob@proulx.com> writes:

>
> Timings from my system after much optimization.
>
>   $ time emacs -f kill-emacs
>   real    0m0.157s
>   user    0m0.140s
>   sys     0m0.012s
>   $ time emacs -q -f kill-emacs
>   real    0m0.137s
>   user    0m0.116s
>   sys     0m0.016s
>   $ time emacs -Q -f kill-emacs
>   real    0m0.051s
>   user    0m0.028s
>   sys     0m0.020s
>
> Bob


Here's mine at present.  I'll have to work at it and see if I can approach
your times...


$ time emacs -f kill-emacs

real    0m23.400s
user    0m7.199s
sys     0m9.500s

$ time emacs -q -f kill-emacs

real    0m1.710s
user    0m1.170s
sys     0m0.249s

$ time emacs -Q -f kill-emacs

real    0m1.680s
user    0m1.201s
sys     0m0.217s

Re: Speeding up Emacs load time

[J. David Boyd]

david@adboyd.com (J. David Boyd) writes:

> Bob Proulx <bob@proulx.com> writes:
>
>>
>> Timings from my system after much optimization.
>>
>>   $ time emacs -f kill-emacs
>>   real    0m0.157s
>>   user    0m0.140s
>>   sys     0m0.012s
>>   $ time emacs -q -f kill-emacs
>>   real    0m0.137s
>>   user    0m0.116s
>>   sys     0m0.016s
>>   $ time emacs -Q -f kill-emacs
>>   real    0m0.051s
>>   user    0m0.028s
>>   sys     0m0.020s
>>
>> Bob
>
>
> Here's mine at present.  I'll have to work at it and see if I can approach
> your times...
>
>
> $ time emacs -f kill-emacs
>
> real    0m23.400s
> user    0m7.199s
> sys     0m9.500s
>
> $ time emacs -q -f kill-emacs
>
> real    0m1.710s
> user    0m1.170s
> sys     0m0.249s
>
> $ time emacs -Q -f kill-emacs
>
> real    0m1.680s
> user    0m1.201s
> sys     0m0.217s


After some minor tweaking, I got it down to

real    0m11.623s
user    0m5.439s
sys     0m4.451s


I can live with that for a while.   Getting it any faster would take a lot of
tweaking that I don't have time for right now.

Thanks for the thread.  11 seconds is much better than 24!

Re: Speeding up Emacs load time

[Dan Espen]

david@adboyd.com (J. David Boyd) writes:

> david@adboyd.com (J. David Boyd) writes:
>
>> Bob Proulx <bob@proulx.com> writes:
>>
>>>
>>> Timings from my system after much optimization.
>>>
>>>   $ time emacs -f kill-emacs
>>>   real    0m0.157s
>>>   user    0m0.140s
>>>   sys     0m0.012s
>>>   $ time emacs -q -f kill-emacs
>>>   real    0m0.137s
>>>   user    0m0.116s
>>>   sys     0m0.016s
>>>   $ time emacs -Q -f kill-emacs
>>>   real    0m0.051s
>>>   user    0m0.028s
>>>   sys     0m0.020s
>>>
>>> Bob
>>
>>
>> Here's mine at present.  I'll have to work at it and see if I can approach
>> your times...
>>
>>
>> $ time emacs -f kill-emacs
>>
>> real    0m23.400s
>> user    0m7.199s
>> sys     0m9.500s
>>
>> $ time emacs -q -f kill-emacs
>>
>> real    0m1.710s
>> user    0m1.170s
>> sys     0m0.249s
>>
>> $ time emacs -Q -f kill-emacs
>>
>> real    0m1.680s
>> user    0m1.201s
>> sys     0m0.217s
>
>
> After some minor tweaking, I got it down to
>
> real    0m11.623s
> user    0m5.439s
> sys     0m4.451s
>
>
> I can live with that for a while.   Getting it any faster would take a lot of
> tweaking that I don't have time for right now.
>
> Thanks for the thread.  11 seconds is much better than 24!

Don't know if anyone has pointed out that your first test is going to be
dramatically slower than subsequent tests:

home> time emacs -Q -f kill-emacs

real    0m6.582s
user    0m0.409s
sys     0m0.109s
home> time emacs -Q -f kill-emacs

real    0m0.500s
user    0m0.385s
sys     0m0.062s


-- 
Dan Espen

Re: Speeding up Emacs load time

[Bob Proulx]

Dan Espen wrote:
> Don't know if anyone has pointed out that your first test is going to be
> dramatically slower than subsequent tests:
> 
> home> time emacs -Q -f kill-emacs
> 
> real    0m6.582s
> user    0m0.409s
> sys     0m0.109s
> home> time emacs -Q -f kill-emacs
> 
> real    0m0.500s
> user    0m0.385s
> sys     0m0.062s

Yes!  I should have mentioned the cold-cache hot-cache issue.  Thanks
for pointing that out.  I will go ahead and show my cold cache start
up times.  But I am hoping not to turn this into a session about my
desktop being slower/faster than another.  The point I was trying to
make was about the relative difference between the various startup
times with and without the local customizations.

  # echo 3 > /proc/sys/vm/drop_caches
  $ time emacs -Q -f kill-emacs
  real    0m4.849s
  user    0m0.048s
  sys     0m0.032s

  # echo 3 > /proc/sys/vm/drop_caches
  $ time emacs -q -f kill-emacs
  real    0m5.198s
  user    0m0.148s
  sys     0m0.028s

  # echo 3 > /proc/sys/vm/drop_caches
  $ time emacs -f kill-emacs
  real    0m6.283s
  user    0m0.144s
  sys     0m0.052s

Here adding my local .emacs adds a second and a half to the startup.

Bob

Re: Speeding up Emacs load time

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> I looked at your .emacs file.  It is rather extensive.  Time
> consuming parts are usually anytime you (require 'foo) or (load
> "foo").  Do you really need all of those executed each and every
> time you start emacs?  Probably not.

OK, this is one way to think. There is another way to think. The
other way to think is: one second at x does not equal one second
at y. When you start Emacs, you are not in a rush. You make sure
you work place is organized. You fetch water, books. You relax you
shoulders. Whatever. Here, you do have time to wait. However, when
you are attentively at work, and you have one million thoughts in
your head at once, you just need to bring up some Emacs
functionality with a minimal delay. Here, time is much more
important. It is like the super-focused people playing ice hockey
or sparring for a boxing fight - for them, 10 seconds is like an
eternity. When you, as a programmer, reaches that highest peak of
productivity/focus, you don't want to load any modules, possible
creating havoc, that (at worst) could take you from what you were
doing. Super-focus, once lost, cannot easily be recovered. So, my
piece of advice: be safe, first load everything safe and sound,
then do your worst to the actual problem you try so solve, with
minimal interference.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eric Abrahamsen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Bob Proulx <bob@proulx.com> writes:
>
>> I looked at your .emacs file.  It is rather extensive.  Time
>> consuming parts are usually anytime you (require 'foo) or (load
>> "foo").  Do you really need all of those executed each and every
>> time you start emacs?  Probably not.
>
> OK, this is one way to think. There is another way to think. The
> other way to think is: one second at x does not equal one second
> at y. When you start Emacs, you are not in a rush. You make sure
> you work place is organized. You fetch water, books. You relax you
> shoulders. Whatever. Here, you do have time to wait. However, when
> you are attentively at work, and you have one million thoughts in
> your head at once, you just need to bring up some Emacs
> functionality with a minimal delay. Here, time is much more
> important. It is like the super-focused people playing ice hockey
> or sparring for a boxing fight - for them, 10 seconds is like an
> eternity. When you, as a programmer, reaches that highest peak of
> productivity/focus, you don't want to load any modules, possible
> creating havoc, that (at worst) could take you from what you were
> doing. Super-focus, once lost, cannot easily be recovered. So, my
> piece of advice: be safe, first load everything safe and sound,
> then do your worst to the actual problem you try so solve, with
> minimal interference.

+1 -- I used to do a bunch of autoload/eval-after-load stuff, but later
came to the same conclusion.

Re: Speeding up Emacs load time

[Rustom Mody]

On Saturday, June 29, 2013 10:34:05 AM UTC+5:30, Eric Abrahamsen wrote:
> Emanuel Berg  writes:
> > Bob Proulx  writes:
> >> I looked at your .emacs file.  It is rather extensive.  Time
> >> consuming parts are usually anytime you (require 'foo) or (load
> >> "foo").  Do you really need all of those executed each and every
> >> time you start emacs?  Probably not.
> >
> 
> > OK, this is one way to think. There is another way to think. The
> > other way to think is: one second at x does not equal one second
> > at y. When you start Emacs, you are not in a rush. 

> +1 -- I used to do a bunch of autoload/eval-after-load stuff, but later
> came to the same conclusion.

I agree with both these viewpoints -- One second of x is not the same at y.
But not repeatedly restarting emacs is not an option.

The problem is that emacs invites tinkering with my elisp settings.
And elisp is such an imperative language that I habitually get silly things wrong. eg

I am hacking an elisp function called foo
For some reason I change its name to bar
I change (what I think are) all refs to foo to bar.
It (seems to) run
The next time I start emacs it does not run because I find that I had not renamed all foo-references to bar.

So the only remedy (I know) is that first check if the elisp works and if it seems to then check again after restarting emacs.

And that means that elisp-hacking means frequent restarts of emacs.

Re: Speeding up Emacs load time

[Eric Abrahamsen]

Rustom Mody <rustompmody@gmail.com> writes:

> On Saturday, June 29, 2013 10:34:05 AM UTC+5:30, Eric Abrahamsen wrote:
>> Emanuel Berg  writes:
>> > Bob Proulx  writes:
>> >> I looked at your .emacs file.  It is rather extensive.  Time
>> >> consuming parts are usually anytime you (require 'foo) or (load
>> >> "foo").  Do you really need all of those executed each and every
>> >> time you start emacs?  Probably not.
>> >
>> 
>> > OK, this is one way to think. There is another way to think. The
>> > other way to think is: one second at x does not equal one second
>> > at y. When you start Emacs, you are not in a rush. 
>
>> +1 -- I used to do a bunch of autoload/eval-after-load stuff, but later
>> came to the same conclusion.
>
> I agree with both these viewpoints -- One second of x is not the same at y.
> But not repeatedly restarting emacs is not an option.
>
> The problem is that emacs invites tinkering with my elisp settings.
> And elisp is such an imperative language that I habitually get silly things wrong. eg
>
> I am hacking an elisp function called foo
> For some reason I change its name to bar
> I change (what I think are) all refs to foo to bar.
> It (seems to) run
> The next time I start emacs it does not run because I find that I had not renamed all foo-references to bar.
>
> So the only remedy (I know) is that first check if the elisp works and if it seems to then check again after restarting emacs.
>
> And that means that elisp-hacking means frequent restarts of emacs.

Very true! I have to admit that my "solution" to this problem is knowing
which few blocks of code in my init take the longest to load, and
manually commenting them out when I know I'm in for multiple restarts.
Not very wizardy.

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> The problem is that Emacs invites tinkering with my Elisp
> settings.  And Elisp is such an imperative language
> ...
> And that means that Elisp-hacking means frequent restarts of
> Emacs.

Say what?! I do Elisp all the time and I *never* restart Emacs.

Why do you have to restart it?

You know about `eval-defun', `eval-last-sexp`, `load-file`, etc.?

For hooks and the like you can simply set them to certain things
instead of adding (which implies there are stuff there to begin
with). You can comment out those sections and still eval them when
needed, so they won't be evaled on init. (This is the only case I
can think of when writing Elisp would benefit from restarting
Emacs. I don't know if I'm missing something here.)

And, although Lisp (and Elisp) are a bit "everything goes", not
really adhering to any paradigm (at least not consistently so),
which I think is a *good* thing, I still would say Elisp is (if
anything) functional - imperative/procedural, that's like Basic or
C (although C obviously is much better, for example the shunned
goto - what about continue and break in C? Isn't that sort of a
goto?).

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Rustom Mody]

On Sunday, June 30, 2013 6:16:41 PM UTC+5:30, Emanuel Berg wrote:
> Rustom Mody  writes:
> > And that means that Elisp-hacking means frequent restarts of
> > Emacs.
> 
> Say what?! I do Elisp all the time and I *never* restart Emacs.
> Why do you have to restart it?
> You know about `eval-defun', `eval-last-sexp`, `load-file`, etc.?

Yeah I know about those.  What's missing is un-defun unload etc.

What happens in a functional language is that before each load from file to interpreter, the interpreter slate is wiped clean. So there is no cruft.

Yeah there is unload-feature. For that you need to be using require/provide

Let me repeat the scenario again (which has bitten me quite a few times):

I am hacking an elisp function called foo
I keep hacking on it till I get it right
Now I am satisfied and change its name to long-proper-name-for-foo
I change (what I think are) all refs to foo to long-proper-name-for-foo.

Note that at this point the lisp namespace contains two names foo and long-proper-name-for-foo defined to the same function.

It (seems to) run
The next time I start emacs it does not run because I find that I had not renamed all foo-references to long-proper-name-for-foo.

As for being a functional language: this is a moving target.
In the 1960 Lisp (and maybe APL) were THE functional languages.
By 1980s it was clear that there were two major mistakes in lisp 
- lambda not first class
- double name space for functions and variables

Scheme cleaned up both these errors, CL cleaned up only the first.
And scheme became the benchmark for being an FPL

Likewise today its haskell.

At the other end of the spectrum, FORTRAN, if you open up the acronym, shows that its inventors imagined it to be something like a functional language.
A fair evaluation of that viewpoint is that it was right in 1958 but became wrong (obsolete) in 1960 when lisp came
 

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> ... the next time I start Emacs it does not run because I find
> that I had not renamed all foo-references to
> long-proper-name-for-foo.

This renaming habit is perhaps not a good one. Still, it should be
possible to do with `replace-string' - in particular if you tweak
it to be case sensitive, and only replace whole words (i.e., not
substrings).

This is probably the best thing to do! But, otherwise, you could
possibly benefit from

(put 'not-a-function-anymore 'disabled t)

Another solution if you think it is tedious to work with long
function names, but still want them because they tell a lot, and
you want it to be consistent with the Emacs style, you could do
use `defalias' as in:

(defun kill-line-number-at-point ()
  "Kill the line number at point,
   according to `line-number-at-pos'."
  (interactive)
  (kill-new (format "%d" (line-number-at-pos))) )
(defalias 'kl 'kill-line-number-at-point)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eric Abrahamsen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Rustom Mody <rustompmody@gmail.com> writes:
>
>> The problem is that Emacs invites tinkering with my Elisp
>> settings.  And Elisp is such an imperative language
>> ...
>> And that means that Elisp-hacking means frequent restarts of
>> Emacs.
>
> Say what?! I do Elisp all the time and I *never* restart Emacs.
>
> Why do you have to restart it?
>
> You know about `eval-defun', `eval-last-sexp`, `load-file`, etc.?

Ideally, this works fine. Mostly, it works for smaller libraries you've
written yourself. But try hacking on something larger (org-mode or, god
help you, gnus), and it becomes very, very difficult to make sure you've
cleaned up the run-time. Some vars are read at load time only (so
re-evaling base vars does nothing), and often you succeed only in
eval-ing yourself to a non-working environment. Especially if you're
planning on pushing your changes to some poor unsuspecting group of
users, you need to start from a clean slate.

> For hooks and the like you can simply set them to certain things
> instead of adding (which implies there are stuff there to begin
> with). You can comment out those sections and still eval them when
> needed, so they won't be evaled on init. (This is the only case I
> can think of when writing Elisp would benefit from restarting
> Emacs. I don't know if I'm missing something here.)
>
> And, although Lisp (and Elisp) are a bit "everything goes", not
> really adhering to any paradigm (at least not consistently so),
> which I think is a *good* thing, I still would say Elisp is (if
> anything) functional - imperative/procedural, that's like Basic or
> C (although C obviously is much better, for example the shunned
> goto - what about continue and break in C? Isn't that sort of a
> goto?).

Re: Speeding up Emacs load time

[Rustom Mody]

On Sunday, June 30, 2013 8:30:16 PM UTC+5:30, Eric Abrahamsen wrote:
> Ideally, this works fine. Mostly, it works for smaller libraries you've
> written yourself. But try hacking on something larger (org-mode or, god
> help you, gnus), and it becomes very, very difficult to make sure you've
> cleaned up the run-time. Some vars are read at load time only (so
> re-evaling base vars does nothing), and often you succeed only in
> eval-ing yourself to a non-working environment. Especially if you're
> planning on pushing your changes to some poor unsuspecting group of
> users, you need to start from a clean slate.

I believe its the other way round.
With significant libraries following the require/provide protocol one can somewhat rely on unload-feature.  Its the tiny pieces of code that slips through the cracks

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> I believe its the other way round.  With significant libraries
> following the require/provide protocol one can somewhat rely on
> unload-feature.  Its the tiny pieces of code that slips through
> the cracks.

So: your own code is fine, the professional code is fine - yeah,
what code *is* it that you hack exactly? :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Emanuel Berg]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Some vars are read at load time only (so re-evaling base vars
> does nothing) ...

Good point, I forgot about that! Yeah, I have run into that as
well. And I think ... *drumroll* ... that what I did, was
restarting Emacs :) But even then, I think there is a way to get
around that, without a restart. What about "shadowing" those vars
with new vars, only closer than those original from their point of
usage?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Eric Abrahamsen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Some vars are read at load time only (so re-evaling base vars
>> does nothing) ...
>
> Good point, I forgot about that! Yeah, I have run into that as
> well. And I think ... *drumroll* ... that what I did, was
> restarting Emacs :) But even then, I think there is a way to get
> around that, without a restart. What about "shadowing" those vars
> with new vars, only closer than those original from their point of
> usage?

I'm sure you could figure something out... and in the case of both Org
and Gnus, they each provide reload/restart functions that promise to get
you a 90% clean slate :)

But I'm just a fair-weather tinkerer -- the issue has never annoyed me
enough to want to come up with another solution beyond restarting. It's
also the reason I never started using emacs as a daemon, attractive as
that sounds.

E

Re: Speeding up Emacs load time

[Bob Proulx]

Emanuel Berg wrote:
> OK, this is one way to think. There is another way to think. The
> other way to think is: one second at x does not equal one second
> at y. When you start Emacs, you are not in a rush. You make sure
> you work place is organized. You fetch water, books. You relax you
> shoulders. Whatever. Here, you do have time to wait.

This may be your work flow.  Which is great.  But it is not my work
flow.  I routinely log into one server or another one.  I need to edit
a file.  This type of workflow has been discussed extensively here
before.  I launch emacs there.  I am blocked waiting for emacs to load
before I can go to the next step.  When emacs took too long to load
then I would always use vi for those edits.  For short edits vi is
okay.  But often I would find myself missing a feature of emacs.

Now I can log in, edit with emacs, and not be disrupted.  Using tramp
from some central location is also much too slow and disruptive.  And
not just during the startup but every time it saves and at other sync
points in the flow.  Plus there are some times when I cannot easily
use tramp from a central desktop because the network topology is
designed to prevent it.  (Not my choice.)

> However, when you are attentively at work, and you have one million
> thoughts in your head at once, you just need to bring up some Emacs
> functionality with a minimal delay. Here, time is much more
> important. It is like the super-focused people playing ice hockey or
> sparring for a boxing fight - for them, 10 seconds is like an
> eternity. When you, as a programmer, reaches that highest peak of
> productivity/focus, you don't want to load any modules, possible
> creating havoc, that (at worst) could take you from what you were
> doing. Super-focus, once lost, cannot easily be recovered. So, my
> piece of advice: be safe, first load everything safe and sound, then
> do your worst to the actual problem you try so solve, with minimal
> interference.

And that is exactly how I feel when emacs takes a long time to load.
And why for me it has become important that it start up with a
reasonable amount of speed.

I also have a desktop and I always have an emacs running there.  I use
it for tasks around the desktop in the same way as you do.  But
depending upon what I am needing to do that is either 10% or 90% of my
work.  When it is 90% that is great.  But when it is 10% then it is
not so great.

There isn't always one size that fits everyone.  And it is a tragedy
when there is only one size available and it doesn't fit.

Bob

Re: Speeding up Emacs load time

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

>> OK, this is one way to think. There is another way to think. The
>> other way to think is: one second at x does not equal one second
>> at y. When you start Emacs, you are not in a rush. You make sure
>> you work place is organized. You fetch water, books. You relax you
>> shoulders. Whatever. Here, you do have time to wait.
>
> This may be your work flow.  Which is great.  But it is not my
> work flow.  I routinely log into one server or another one.  I
> need to edit a file.  This type of workflow has been discussed
> extensively here before.  I launch emacs there.  I am blocked
> waiting for emacs to load before I can go to the next step.
> When emacs took too long to load then I would always use vi for
> those edits.  For short edits vi is okay.  But often I would
> find myself missing a feature of emacs.
>
> Now I can log in, edit with emacs, and not be disrupted.  Using
> tramp from some central location is also much too slow and
> disruptive.  And not just during the startup but every time it
> saves and at other sync points in the flow.  Plus there are some
> times when I cannot easily use tramp from a central desktop
> because the network topology is designed to prevent it.  (Not my
> choice.)
>
>> However, when you are attentively at work, and you have one
>> million thoughts in your head at once, you just need to bring
>> up some Emacs functionality with a minimal delay. Here, time is
>> much more important. It is like the super-focused people
>> playing ice hockey or sparring for a boxing fight - for them,
>> 10 seconds is like an eternity. When you, as a programmer,
>> reaches that highest peak of productivity/focus, you don't want
>> to load any modules, possible creating havoc, that (at worst)
>> could take you from what you were doing. Super-focus, once
>> lost, cannot easily be recovered. So, my piece of advice: be
>> safe, first load everything safe and sound, then do your worst
>> to the actual problem you try so solve, with minimal
>> interference.
>
> And that is exactly how I feel when emacs takes a long time to
> load.  And why for me it has become important that it start up
> with a reasonable amount of speed.
>
> I also have a desktop and I always have an emacs running there.
> I use it for tasks around the desktop in the same way as you do.
> But depending upon what I am needing to do that is either 10% or
> 90% of my work.  When it is 90% that is great.  But when it is
> 10% then it is not so great.
>
> There isn't always one size that fits everyone.  And it is a
> tragedy when there is only one size available and it doesn't
> fit.

True that. I have no experience from using Emacs over a network or
otherwise distributed system, and I can barely visualize how that
would work.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Dan Espen]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> I love Emacs's customizability! I regularly edit my .emacs file, and the
> community has been helpful and encouraging. But I do notice that Emacs can
> take several (10) seconds or longer to load.
>
> For reference, I'm using Emacs 24.1 for Mac OS X, Windows, and Android. I
> keep my .emacs synced, shared, and backed up on GitHub.
> https://github.com/mcandre/dotfiles/blob/master/.emacs
>
> Could someone help me cut down the load time while maintaining the same
> behavior?

The "best" solution to the start up time issue is simple.

NEVER shut down emacs.

There's seldom a good reason to, especially if you are a programmer,
do your compile/edit/test cycle completely within emacs.

Other than that, emacs can run as a daemon process and you can use
emacsclient to connect to it very quickly.


-- 
Dan Espen

Re: Speeding up Emacs load time

[Emanuel Berg]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> I love Emacs's customizability! I regularly edit my .emacs file,
> and the community has been helpful and encouraging. But I do
> notice that Emacs can take several (10) seconds or longer to load.

I did so much fancy things once in .emacs I noticed it took some
seconds to load Emacs. But, I configured one of my many ttys to
automatically start Emacs when I start my computer, so starting
Emacs is really part of my boot time - and then, as everyone else
has told you, use different buffers and modes for everything,
within a single instance of Emacs, and shut Emacs down, not as a
program (although in practice, possible so) but as the final step
of your productive cycle, when you shut down you system.

But, to give you something concrete, I have a lot of files like
.emacs-message etc. which I load from Emacs - check out the URL
below, and search for "Emacs" and "conf" - and I did that to get a
modular, overviewable design so I never had to "look" for anything
- just open the correct file, and make a search - not for
searching, but for *navigating* - and I noticed that this solution
was a bit slower than doing everything in one file (as for
startup) - so I put it back to one file - only to very quickly
realizing that that extra few seconds once in a while was totally
worth it, compared to having to browse one monster file that
included everything I ever did in Emacs.

Remember, time is not a quantity that is straightforward to
measure. It is like beer - it is not how much you drink, it is
how you feel when you drink it, and how you feel the couple of
days after that. Wait the extra second now, and don't be stressed
tomorrow.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[J. David Boyd]

Emanuel Berg <embe8573@student.uu.se> writes:

> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>
>> I love Emacs's customizability! I regularly edit my .emacs file,
>> and the community has been helpful and encouraging. But I do
>> notice that Emacs can take several (10) seconds or longer to load.
>
> I did so much fancy things once in .emacs I noticed it took some
> seconds to load Emacs. But, I configured one of my many ttys to
> automatically start Emacs when I start my computer, so starting
> Emacs is really part of my boot time - and then, as everyone else
> has told you, use different buffers and modes for everything,
> within a single instance of Emacs, and shut Emacs down, not as a
> program (although in practice, possible so) but as the final step
> of your productive cycle, when you shut down you system.
>
> But, to give you something concrete, I have a lot of files like
> .emacs-message etc. which I load from Emacs - check out the URL
> below, and search for "Emacs" and "conf" - and I did that to get a
> modular, overviewable design so I never had to "look" for anything
> - just open the correct file, and make a search - not for
> searching, but for *navigating* - and I noticed that this solution
> was a bit slower than doing everything in one file (as for
> startup) - so I put it back to one file - only to very quickly
> realizing that that extra few seconds once in a while was totally
> worth it, compared to having to browse one monster file that
> included everything I ever did in Emacs.
>
> Remember, time is not a quantity that is straightforward to
> measure. It is like beer - it is not how much you drink, it is
> how you feel when you drink it, and how you feel the couple of
> days after that. Wait the extra second now, and don't be stressed
> tomorrow.

Right.  Wouldn't really bother me if it took 5 minutes to start, since I
normally only start it once a day, at the most....

Re: Speeding up Emacs load time

[Rustom Mody]

On Friday, July 19, 2013 10:54:21 PM UTC+5:30, Drew Adams wrote:
> The only ambiguity in pointing is the precision of the pointer (and
> your eye & hand).  If you do something other than point then you need
> to narrow things down in some other way until you have characterized
> the object you want uniquely.  That's a lot more complex in principle,
> and often in practice too.

And the lack of precision can be a bigger or smaller deal: replace mouse by gun and click by shoot.
If I were in William Tell's shoes I would prefer 10 decimal GPS coordinates to trusting my sharp-shooting skills :-)

Personally I find that the mouse hurts my hand and with a laptop touchpad I have terrible precision.

Of course all this does not change your basic point that 'direct' has a certain well directness that inference/thinking/calculation cannot compare with.

I believe that this argument has got somewhat derailed by the polemic: "mouse is stupid, keyboard is intelligent"

Leaving aside the fact that in real life mice are more intelligent than keyboards, I believe the real division here is between functional and OO interface rather than keyboard vs mouse.
A unix command-line or an interactive language prompt are examples of functional interfaces.
Conversely in windows when one points at something and the system magically opens with word or excel or whatever, that is an OO interface.

However clever emacs is, its unreasonable to ask it to know which file I want to edit.  Invert the order of file and program and encode some info into the extension and a system like windows gets it right... at least in the easy cases.

Not so for the not easy cases: If one is looking at a matrix M in some math software like mathematica, it again becomes unreasonable to demand that one can point to it and command DTRT!  Because we may be wanting inversion, or eigenvalues, or multiply by something else or a dozen other reasonably likely options.

IOW OO interfaces are intrinsically more dumbed-down than functional ones. Sometimes we need the intelligent interface, sometimes the dumb one.

tl;dr
Point-n-click by default with power-user command-line available on call seems a sensible option.  Starting an editor in lisp-interaction mode is perhaps natural only if your name spells 'rms' :-) 

Re: Speeding up Emacs load time

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> Leaving aside the fact that in real life mice are more
> intelligent than keyboards

:)

> I believe the real division here is between functional and OO
> interface rather than keyboard vs mouse.

Rather than "rather than", _as much as_, because those two
physical devices are what make those interfaces possible.

> A Unix command-line or an interactive language prompt are
> examples of functional interfaces.  Conversely in windows when
> one points at something and the system magically opens with word
> or excel or whatever, that is an OO interface. ...

Very good point, and I'm fascinated it took so long to float to
the surface. And yes, I think the CLI is much better in almost
every aspect than the Windows/Mac OS way, including GNOME, KDE,
etc. At least for general usage, there is no doubt in my mind.

I've never heard "functional/OO" with respect to
*interfaces*. Those are programming paradigms, for the most
part. I would say CLI/GUI to denote the same thing.

Regardless of what you call it, I'm very happy you brought this
up. I wouldn't have thought of it, perhaps because it is so
implicit (close) to the whole keyboard/mouse discussion. It is
like looking for a rope, and you can't find it, because you have
it in your belt.

> IOW OO interfaces are intrinsically more dumbed-down than
> functional ones.

Yes, except for very specific cases.

> Sometimes we need the intelligent interface ...

Sometimes as in "almost all the time" :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Speeding up Emacs load time

[Rustom Mody]

On Sunday, July 21, 2013 7:48:32 PM UTC+5:30, Emanuel Berg wrote:
> I've never heard "functional/OO" with respect to
> *interfaces*. Those are programming paradigms, for the most
> part. I would say CLI/GUI to denote the same thing.

http://en.wikipedia.org/wiki/Object-oriented_user_interface
Historically smalltalk made OO *programming* popular because its OO *interface* was so compelling.

So they say... Ive never used smalltalk and my own views on OO tend to the opposite direction:  http://blog.languager.org/search/label/OOP