I'm using Emacs on windows 10.
When i use Dired I can open (C-x C-f) files without any problems.
But when I use helm or ivy for opening files, it gets really slow and takes more than 10 sec to change a directory. And when I want to change partition, it freezes.
This is what i get when I profile for CPU and memory:
cpu and memory profiling
This is my Emacs config, maybe there is something wrong that I don't see.
emacs config emacs config
I dont know how to go on from there. Maybe you guys can offer some help?
Related
Can someone help me make sense of list-buffer (aka Ctrlx - Ctrlb) behavior in emacs 25?
The behavior I'm used to seeing is that it opens the buffer list in another Emacs window (virtual Emacs window), splitting out a second window to do so, if necessary. In some versions it hasn't always been very deterministic which other window it used (if I had more than 2 up), but I could at least count on it not using the one the cursor was in.
I recently installed 25.0.50.1 to get around a remote file open bug (worked!), and now it isn't always doing this. Very often it opens the buffer list in the same window my cursor was in. Often it works the way it used to. I can't figure out any rhyme or reason behind which it choses to do.
Can someone enlighten me as to the algorithm it is using now? It makes managing multiple emacs Windows for reference viewing nearly impossible when I can't predict which window gets replaced.
I would guess your primary concern is to have a convenient way to switch buffer, not to understand the emacs' source code, so I would strongly recommend to check helm package out: http://tuhdo.github.io/helm-intro.html
It will take about 10 to 20 minutes to install and follow the tutorial, and it is well worth. I promise.
After installing helm and enabling it, the key sequence for you is Ctrl-x b: Shows open buffers, recently opened files
You will get a power pack of many other tools to work in emacs. I had the same problem with switching buffers, and seemingly 'chaotic' buffer popup. After helm installation, the problem is minimized to invisible because it is so easy to switch to the buffers you want.
Update:
To deal package installation errors and package compatibility:
M-x list-load-path-shadows to see if there is any conflicting packages. And since you may not have many external packages, I suggest backup ~/.emacs.d and have a new empty one. Also, most of the case when install packages, I try to use emacs package manager. Benefits of using package manger:
help check dependencies
avoid to manual download and unpack.
can do batch update of installed packages
Following is a workflow of enabling melpa repo and installing packages
M-x customize-group RET package
# Click or move cursor to and enter: Package Archives
# Insert the melpa repository.
Archive name: melpa
URL or directory name: http://stable.melpa.org/packages/
#Save above settings and then you can use the following to install packages:
M-x list-packages RET
f to filer package names
i to mark for installation
x for execution of installation
u for unmark package at cursor.
# to avoid using load-path repeatedly,
# I have this in my .emacs before any 'require' command:
; Set path recursively to one folder
(let ((default-directory "~/.emacs.d/elpa/"))(normal-top-level-add-subdirs-to-load-path))
Normally I am able to use tramp just fine to edit files and browse through the remote file system through SSH. Though at seemingly random times I would lose the ability to browse remote folders in emacs.
I get the error message:
Wrong type argument: number-or-marker-p, //DIRED-OPTIONS//
I've tried doing a clean reinstall of emacs without any customizations and the error still happens.
Also sometimes the error happens after browsing 1 or 2 directories while other times I'm able to do five or six directories before the error will appear.
Edit:
I'm using Emacs 23.3 running on OS X 10.6.8
Edit 2:
While I'm still going through the tramp debug log A couple of other pieces of information.
After the error I'm still able to use tramp of open and save files, just not view directory listings.
It seems to happen only when I save to a directory that is version controlled using git.
In the debug log the directory contents are listed out but it is not being outputted to the user
The directory listing inside the debug log show ^M (I usually notice this in the emacs info bar when editing files that have been versioned in git) even when I try to access a non-version controlled directory
The message is useless by itself. You should try to obtain more traces on the tramp behavior in order to find where is the issue. See the Traces and Profiles Section of the TRAMP User Manual.
Sorry to not help more but with another release on another platform…
Update:
Put the following in your emacs file
(require 'tramp)
(setq tramp-verbose 10)
(setq tramp-debug-buffer t)
Then, use tramp. Now, You should have a *debug tramp/method hostname* buffer.
I found out that this happens when I enable:
(setq-default dired-omit-mode t)
But for now I don't know how to make it work with this mode
With packages loading such as orgmode, nxhtml, yasnippet, I see that the loading of emacs slowed down pretty much.
I expect I can speed it up with the compilation of the packages.
I can I do that with emacs?
Normally, how much speed up can I expect?
Yes, you can do it: M-x byte-compile-file on each .el that you want to compile. It won't speed things up as much, though, as will using "autoload" and "eval-when-require".
Generally everything that comes with the Emacs installation is byte compiled and every package you installed via a Linux distribution package management system is compiled as well. If you're using ELPA - it byte compiles the packages after downloading them. That said, byte-compilation will not bring you any significant performance gains.
If we assume that the greatest bottleneck with Emacs performance is its startup time, you'd do a lot better to start a single Emacs instance as a daemon(emacs --daemon) and share it between multiple emacsclient processes that will start instantly once the daemon is running.
The easiest way to get a speedup in your .emacs file doesn't have much to do with byte compilation, though you should always byte compile new packages you install.
Instead, if you know you do this in your .emacs:
(require 'some-pkg)
and then later you might do this:
`M-x command-in-pkg'
you are better off adding this to your .emacs file.
(autoload 'command-in-pkg "some-pkg" "A command in some package" t)
which will load much faster at startup than the original require. Many packages have installation setups that have a file full of autoloads that you require in your .emacs file which will already be optimized as best that maintainer can get it.
I'm using some plugins and I byte-compiled my .emacs but the start up still slow. Do I hava to byte-compile my prlugins too? (for instance, yasnippet.el -> yasnippet.elc)?
Byte compiled files load up faster so I'd recommend that you byte compile everything as Pascal suggested. I also keep this in my init file so automatically byte compile all the emacs lisp files I edit and save.
(add-hook 'emacs-lisp-mode-hook '(lambda ()
(add-hook 'after-save-hook 'emacs-lisp-byte-compile t t))) ;; Automatically byte-compile emacs-lisp files upon save
Emacs can feel slow to start up even without any .emacs or plugins :)
It is a good idea to compile plug-ins, that's as much time shaved from start-up. Compiling the .emacs configuration file is less usual (because it changes more often and is typically small anyway), but why not?
You probably already know this, but .el files can be byte-compiled using: M-x byte-compile-file or M-x byte-recompile-directory .
You can use emacs server to speed things up, then it only takes time to start the server the first time.
The way to start an Emacs server is to run Emacs as a daemon, using the ‘--daemon’ command-line option. When Emacs is started this way, it calls server-start after initialization, and returns control to the calling terminal instead of opening an initial frame; it then waits in the background, listening for edit requests.
Once an Emacs server is set up, you can use a shell command called emacsclient to connect to the existing Emacs process and tell it to visit a file. If you set the EDITOR environment variable to ‘emacsclient’, programs such as mail will use the existing Emacs process for editing.
From: http://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html
You'll likely find something use here: http://www.emacswiki.org/emacs/AutoRecompile
A great selection of tips for automatically byte-compiling files, when you save them or when you load them, and even caching the compiled files in a certain directory.
I have decided to check out Emacs, and I liked it very much. Now, I'm using the Emacs Starter Kit, which sort of provides better defaults and some nice customizations to default install of Emacs.
I have customized it a little, added some stuff like yasnippet, color-themes, unbound, and other stuff. I've set up a github repository where I keep all of the customizations so I can access them from multiple places or in case something goes bad and I lose my .emacs.d directory.
All of this is very nice, but there is a problem: Emacs takes about 1-2 seconds to load. AFAIK I can compile individual .el files with M-x byte-compile-file to .elc, and it works. But there are a lot of .el files, and I wonder if there is a way to compile them all with a simple command or something, to speed up the loading of Emacs. My Emacs is not always open, and I open and close it quite frequently, especially after I've set it up as a default editor for edit command in Total Commander to get used to it faster (yeah, windows xp here).
My Emacs version is 22.3. And yes, the default Emacs installation without any customizations fires up instantly.
I am not sure which version is preferred when loading, the .el or compiled .elc one by the way O.o
So, is there an elisp command or Emacs command line switch to make Emacs byte-compile everything in .emacs.d directory?
C-u 0 M-x byte-recompile-directory
will compile all the .el files in the directory and in all subdirectories below.
The C-u 0 part is to make it not ask about every .el file that does not have a .elc counterpart.
To automatically byte compile everything that needs byte compiling each time I start emacs, I put the following after my changes to load-path at the top of my .emacs file:
(byte-recompile-directory (expand-file-name "~/.emacs.d") 0)
Surprisingly, it doesn't add much to my startup time (unless something needs to be compiled).
To speed up my emacs, I first identified the slow parts using profile-dotemacs.el and then replaced them with autoloads.
You can use the --batch flag to recompile from the command line.
To recompile all, do
emacs --batch --eval '(byte-recompile-directory "~/.emacs.d")'
or to recompile a single file as from a Makefile,
emacs --batch --eval '(byte-compile-file "your-elisp-file.el")'
This is swaying a bit from the question, but to solve the problem of loading slowly you can use the new daemon feature in Emacs 23.
"If you have a lot of support packages,
emacs startup can be a bit slow.
However, emacs 23 brings emacs
--daemon, which enables you to start emacs in the background (for example
when you log in). You can instantly
pop up new emacs windows (frames) with
emacsclient. Of course, you could
already have an emacs 'server' in
older versions, but being able to
start it in the background makes this
a much nicer solution"
From http://emacs-fu.blogspot.com/2009/07/emacs-23-is-very-near.html
The command I use is M-x byte-force-recompile RET, it then asks the directory so, for example, I give it ~/.emacs.d/elpa/. It then recompiles everything in there, usually no need to delete .elc files first or mess with it in other ways.
For my using spacemacs, the command is spacemacs/recompile-elpa. The command byte-recompile-directory does not compile any file.