in emacs evil mode ctrl-[ puts you in normal mode. but there is an irritating delay of about a .5 seconds. For instance if I'm in insert mode and want to move up 2 lines I would do ctrl-[ k k but this doesn't work cause I hit the k to quickly, emacs stays in insert mode. How can I make the transistion to normal mode instantaneous.
Please check out: https://bitbucket.org/lyro/evil/issue/69/delay-between-esc-or-c-and-modeswitch
For me the delay was caused by tmux and set -s escape-time 0 fixed the issue.
Related
If Emacs was started with "--daemon" then (frame-list) returns 2 frames when only 1 is opened
(frame-list)
(#<frame *Minibuf-1* - Emacs 24.3.50.1 0x11c7270> #<frame F1 0xb94ac8>)
If you start Emacs without daemon flag - no "F1" buffer will be there.
How to reliably determine what frames were opened by a user? Are there any specific properties?
It's a "physically invisible" frame (even though frame-visible-p says otherwise) associated with initial terminal where the daemon was started. I suspect that a sole reason for its existence is that emacs is not ready to run with no frames at all, and it's hard enough to fix it.
For filtering it out I would use this test:
(string-equal "initial_terminal" (terminal-name <frame>))
;;; => t for the "pseudo-"frame created by emacs -daemon
There might be better tests, but as far as I know this one is reliable enough: terminal-name returns something like "/dev/tty" for tty frames and the X11 display name like ":0" for X11 frames (I can't recall what it returns on other platforms, like in a Windows console window, but I believe it can't be "initial_terminal" by accident).
Is there a key binding to quit a mode and return to the previous mode in emacs?
For example suppose I entered line number mode using the following command:
Alt+x linum-mode
How can I quickly disable this mode and return to the mode which I was in before (not using the same command again)?
Why wouldn't you want to use the same command again?
M-xM-pRET
It doesn't get much simpler than that.
Edit: You can repeat M-p in that sequence to step back further in the command history, and you can search the command history with M-xC-r.
Also, when you disable a minor mode you're not "returning to the mode you were in before"; you're just disabling one (of many) minor modes which are all active at the same time.
Tangentially, the concept of "returning to the mode you were in before" could apply to major modes (as there's only ever one active major mode in a given buffer), but strictly speaking there's no notion of 'disabling' a major mode -- only of 'enabling' the one you wish to change to -- so to 'toggle' between two major modes, you would need to call them alternately.
Just repeat the same command: M-x linum-mode. Such minor-mode commands are toggles: on/off.
C-x z calls repeat - repeat last command.
Repeatedly calling a minor-mode enables/disables it.
One more way to do it is with smex: the last command
that you called with M-x kinda sticks around.
So you can enable linum-mode with smex, do a bunch of editing
with usual shortcuts and then disable linum-mode with
M-x RET.
A solution might follow the path kill-ring-save works: store the modes being active as current-modes-listing in a previous-modes-ring.
The code needed therefor exists basically inside describe-mode, see upward from "Enabled minor modes" - respective for the major mode.
Then a hook should check if this-command has "-mode" in it's name. If yes, check, if current modes-listing equals car of previous-modes-ring. If not, add new setting.
Finally write a command which sets current modes according to selected listing from previous-modes-ring.
I recently switched from vi to emacs. I like CUA mode. However, CUA mode makes C-x kill the active region. This is annoying when I want to, say, clear a rectangular selection with C-x r c.
How can I use CUA mode while having completely out-of-the-box behavior for C-x?
If you look at the help for cua-mode it gives you options for using commands which conflict with the prefix keys (like C-x):
If you really need to perform a command which starts with one of
the prefix keys even when the region is active, you have three
options:
- press the prefix key twice very quickly (within 0.2 seconds),
- press the prefix key and the following key within 0.2 seconds, or
- use the SHIFT key with the prefix key, i.e. C-S-x or C-S-c.
Use cua-selection-mode instead of cua-mode.
The former provides CUA's other configuration and facilities (for example the rectangle editing mentioned by Francesco), but it leaves C-x, C-c, C-v, and C-z alone, meaning that it's highly compatible with out-of-the-box Emacs usage.
In addition to jtahlborn's general answer, please also note that cua-mode reimplements rectangular commands (IMHO in a much fancier way than the standard C-xr commands)
Just press C-RET to enter rectangular selection mode. From there regular commands work on the rectangular selection: you can for example delete the region using DEL.
Here's my problem - hopefully I can explain this well enough:
I use Putty on Windows, and then start a gnu screen session. I may run several shell commands in putty, and then in the same screen, run emacs -nw. The problem is that when I exit emacs, the scrollback buffer (in putty) is messed up. What was on the screen when I started emacs is gone, and if I scroll upward I see various artifacts of screen (e.g. the screen "bar" at the bottom, etc.).
If I don't use screen and just open emacs -nw directly from putty, all my history is still there in the buffer when I exit emacs.
Likewise, if I do use screen, and use vi within a screen instead of emacs, when I exit vi, everything is there.
Is this just some weird interaction with putty and emacs? Is there a way to fix it?
Have you tried setting scrollback buffer size to something else than default? scrollback
In .screenrc put this line:
defscrollback 10000
Here's my config .screenrc. Tried to reproduce this problem but no luck... you can try if it fixes for you:
termcapinfo xterm* ti#:te#
startup_message off
vbell off
autodetach on
altscreen on
shelltitle "$ |bash"
defscrollback 10000
defutf8 on
nonblock on
hardstatus alwayslastline
hardstatus string '%{= kw}[ %{= kb}%H%{= kw} ][%= %{= kw}%?%-Lw%?%{= kW}%n*%f %t%?%?%{= kw}%?%+Lw%?%?%= ][ %{r}%l%{w} ]%{w}[%{r} %d/%m/%y %C %A %{w}]%{w}'
bind 'q' quit
Just at the end I would as well suggest you getting familiar with tmux -> http://tmux.sourceforge.net/
BTW. hopefully you're using newest version of PuTTy right? :) - > http://puttytray.goeswhere.com/
This sounds like Emacs and Screen are stepping on each others toes over the alternate screen feature of your terminal.
I cannot reproduce this issue, but maybe putting the following in your ~/.screenrc would help:
altscreen on
Have you considered using tmux as an alternative to GNU screen?
When I start Emacs, its windows and its minibuffer start up floating on the main frame, leaving a lot of empty space (see: here and here). Any idea of what is going on and how to fix it?
I'm using emacs version 23.1.1 on Xmonad
Thanks!
I get the same thing occasionally when doing a TAB expand in shell mode. I don't end up with an empty mini-buf, it usually has all the contents from the shell expand. The only solution I've found so far is to kill the current shell buffer
You might try C-l (recenter-top-bottom). I've used this over the years as a pretty reliable "repaint" operation that will clear up various detritus that occurs on the frame. It is even more helpful when you do not have a window system.
It looks like an odd interaction between Emacs and your window manager. It's as if Emacs is configuring itself to have a certain number of lines and columns in its active window, but the frame the window manager has allocated it is larger.
Can you try running X without Xmonad (ie. just run startX) and then run Emacs? You won't get frame decorations, but you can still use xterm to start it and see what 'natural' size it gets allocated. With the same Emacs configuration, that would narrow it down to some issue with Xmonad.
It's not obvious from the screenshots, as one is definitely in GUI mode, but the other (green on black) looks like it is in text mode. If you force it to run in text mode (emacs -nw), does it take up the same size? Within the shell, do normal commands take up the entire size of the allocated window?
Are the shell variables COLUMNS or LINES set correctly? Do they match the window dimensions? Assuming you are running bash, is shopt checkwinsize turned on? Do regular commands such as ls wrap at the expected margins and scroll to use the entire window?
It is worth ensuring that text mode is being configured correctly before getting GUI mode to work. I have a hunch the way that Xmonad is managing its window sizing may be the culprit, if it is 'forcing' windows to tile in certain arrangements, and the correct X hints aren't being sent. But - that's all just supposition for now...
This partially works (taken from here):
(defun fullscreen ()
(interactive)
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen) nil 'fullboth)))
(add-hook 'emacs-startup-hook 'fullscreen)
The windows get corrected, although the mini-buffer is still larger than the usual.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug. Try to provide a recipe starting from emacs -Q.