[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Speeding up Emacs load time
From: |
Emanuel Berg |
Subject: |
Re: Speeding up Emacs load time |
Date: |
Sun, 30 Jun 2013 14:36:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) |
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, (continued)
- Re: Speeding up Emacs load time, Bob Proulx, 2013/06/29
- Message not available
- Re: Speeding up Emacs load time, Rustom Mody, 2013/06/29
- Re: Speeding up Emacs load time, Eric Abrahamsen, 2013/06/29
- Re: Speeding up Emacs load time, Emanuel Berg, 2013/06/30
- Re: Speeding up Emacs load time, Eric Abrahamsen, 2013/06/30
- Re: Speeding up Emacs load time, Rustom Mody, 2013/06/30
- Re: Speeding up Emacs load time, Emanuel Berg, 2013/06/30
- Message not available
- Re: Speeding up Emacs load time, Rustom Mody, 2013/06/30
- Re: Speeding up Emacs load time, Emanuel Berg, 2013/06/30
- Message not available
- Re: Speeding up Emacs load time, Emanuel Berg, 2013/06/30
- Message not available
- Re: Speeding up Emacs load time,
Emanuel Berg <=
Re: Speeding up Emacs load time, Dan Espen, 2013/06/25
Re: Speeding up Emacs load time, Emanuel Berg, 2013/06/27