I find that when I copy or delete large files with Emacs from dired, (i.e. S-c), Emacs will lock up until the operation is complete. To work-around this I fire an asynchronous shell command 'cp/mv/rm ' so that I can do other things while I'm waiting. My question is that, has anyone else encountered this issue? And if so have you managed to work around it? I'm using the latest stable GNU Emacs 23.2.
Yes, I got the same behavior. I think the reason is that Emacs is not multi-threaded. You can find more information here.
In my opinion it's one of the major drawbacks of Emacs.
Related
I use Eclipse for programming in almost any language. I also like the vim shortcuts for quick editing so I installed vrapper.
The problem is when I write a lot of code, and I just want to undo some little things. It undos a lot of chunks of code back, instead of 2 or 3 little things.
I've found some threads which seem to resolve my issue by using "set noati", but it does nothing. It doesn't matter if I use "Ctrl+Z" or "u" from vim command mode.
Can someone please help me to resolve this issue ?
The set noati seems to be the solution for that (at least was for me and other people in vrapper forums)... simply to update to the latest version of vrapper then you either specific the set noati (no ":" here!) in the ".vrapperrc" (this config file should be placed in your home directory) or you simply run the :set noati command from Eclipse vrapper.
HTH.
Here are two things that might help you.
1) Stay out of insert mode.
The way undo works is in terms of vim commands. So if you change to insert mode and type a hundred words, that counts as a single command. On the other hand, if you press escape every once in a while to get out of insert mode, undo will behave much more pleasantly.
Once you get more familiar with vim, you will want to do less and less in a single insert. So the undo problem will likely be reduced as well.
2) Temporarily disable vrapper via the toolbar icon.
This is an alternative if you absolutely need the default undo behaviour of Eclipse.
I am writing a report in LaTeX, and am using Emacs for development. Having to periodically compile manually is somewhat annoying. Is there a way to have Emacs automatically compile periodically whenever the current buffer is a LaTeX buffer?
flymake is built into Emacs, and is the classic way to do such things.
See its user-manual at: C-hig (flymake) RET
flycheck is a more recent project, with the stated aim of being "flymake done right".
Running arbitrary processes (e.g. compilation) periodically is what these libraries are all about, so either one of them suits your use-case.
I must be in the habit of leaving the mini-buffer in the middle of a command. From there I will change buffers and continue working. Later (sometimes much later) I'll notice that I had a command dangling incomplete in the mini-buffer. If I go to cancel it with a C-g, Emacs will often swap buffers in my open windows to an earlier state.
I suppose this may be a feature, but in my flow of work I find it rather annoying. Is there a way to stop this behavior or prevent it from happening, such as a warning that There is an incomplete command?
I think that the answer to another question will help you solve this. It can be an annoying behavior, but the solution limits some of the flexibility found in Emacs.
The answer is: How can I prevent the mini-buffer from displaying previous commands in Emacs? (I call it stop-using-minibuffer).
I'm not sure if this is possible, but does anyone know if I can pipe ESS commands (i.e. evaluate region) to a R process running outside of Emacs? The Emacs terminal hangs up a bit (more often than Apple's terminal) and I'd like to just ditch it, while still using ESS commands. Currently I am doing the less efficient copy and paste technique :-)
Vince
Why not just kill the underlying R process, start a new one and continue the session in the same ESS buffer?
This doesn't answer your specific question and my experience is on Windows, but assuming it's challenging in ESS, I just mention:
There are other IDE's which have no trouble doing this (e.g. Tinn-R, StatET). In particular, for one supported on multiple operating systems, have a look at the StatET plugin for Eclipse. One very nice feature of Eclipse is that not only can you run the commands on a console outside the IDE, but you can also run multiple console sessions at the same time. This allows you to easily compare results side by side.
Needless to say, that's irrelevant if you're comfortable using ESS.
I saw the the news that emacs 23.1 was released.
For a programmer, What are the big reasons to upgrade? I'm currently on 22.2.
None of the features listed really seem like must-haves for me. The most immediately interesting bit is that nXML is now integrated. I already have it though.
But I have to admit I don't know what is really behind "smarter minibuffer completion" or "per buffer text scaling".
Anyone have any tips or examples of what these things are?
For me, the biggest reason is the support for anti-aliased fonts. And the --daemon support is nice.
Emacs-fu has a nice write-up of some of the features.
M-x butterfly
No one said anything about multi-tty support? I have one long (LONG!) emacs session opened somewhere, and I ssh'ed into that machine remotely and use that particular emacs session (with all the temporary buffers, everything setup the way I liked, groups of buffers opened, etc.). The benefit of course, is that I don't need to worry about saving temporary buffers (you do use those as scratch pad, don't you?), etc. when switching machines (from school to home, for example).
Also, with multi-tty support, you can open emacs with emacsclient -nw to substitute your occasional needs for vi for quick terminal edits. emacsclient -nw will open even faster than vi, and you will have access to your opened emacs session as a bonus. (Before emacs 23, emacsclient cannot run from the terminal).
"Improved Unicode support (the internal character representation is now based on UTF-8)."
is a critical reason for me, but it no doubt depends on your work flow.
Some of the terms you are asking about were discussed in Set Emacs defaut font face per-buffer/mode and are also in the emacs wiki, e.g. http://www.emacswiki.org/emacs/SetFonts (under Changing Font Size - Buffer Text Resizing ).
While I was using the pre-releases, the most noticeable feature has been the improved font support. and some small things about smarter window splitting.
for me its font support and gnupg integration.
also its nice to read pdf's from within emacs.