Any movement commands cause the eldoc-message in the minibuffer to flicker. Disabling evil-mode eliminates the flicker.
From the eldoc documentation, I found this relevant snippet.
;; This function goes on pre-command-hook for XEmacs or when using idle
;; timers in Emacs. Motion commands clear the echo area for some reason,
;; which make eldoc messages flicker or disappear just before motion
;; begins. This function reprints the last eldoc message immediately
;; before the next command executes, which does away with the flicker.
;; This doesn't seem to be required for Emacs 19.28 and earlier.
(defun eldoc-pre-command-refresh-echo-area ()
(and eldoc-last-message
(if (eldoc-display-message-no-interference-p)
(eldoc-message eldoc-last-message)
(setq eldoc-last-message nil))))
How do I prevent the flicker with evil-mode enabled?
So, evil-mode is innocent. The culprit is key-chord.el.
The display flickers when a key is pressed that was present in key-chord-define. I had "jk" bound to keyboard-quit, so every time I pressed j or k, eldoc would flicker.
(key-chord-define-global "jk" 'keyboard-quit)
This isn't a bug in evil-mode. It's just more noticeable in evil-mode because of the single letter commands like h and j.
I patched key-chord at https://github.com/jschaf/key-chord to fix the flicker. See commit a2f6c61 for the actual fix.
Related
Is there a way to disable the beep in Emacs when trying to move the cursor beyond the beginning or end of a document? I normally wouldn't mind, but the momentum scrolling on my trackpad makes it so that it beeps a dozen times whenever I scroll to the top or bottom of a document.
I'd rather not disable the bell for other things, if that's possible.
Put
(setq ring-bell-function 'ignore)
in your .emacs. This will disable the bell entirely, which might not be what you want.
This works pretty well for me to disable the bell just when scrolling to limits (add the following to your .emacs or other init file) :
(defun my-bell-function ()
(unless (memq this-command
'(isearch-abort abort-recursive-edit exit-minibuffer
keyboard-quit mwheel-scroll down up next-line previous-line
backward-char forward-char))
(ding)))
(setq ring-bell-function 'my-bell-function)
Source
EDIT: Perhaps (in original post) I used the term "transient" incorrectly (I'm not familiar enough with the jargon yet). What I really mean is that the highlighted region will disappear immediately when the user presses a navigation keys eg. arrow-keys... (2nd EDIT: I've removed the word "transient")
The particular issue of selecting a region so the user gets "cursor-key movement will make highlighting disappear" has been the bane of my existance recently. I get differnt results depending on how I run the following script.
Why does it give different results, and more specifically, is there a way to make it produce "cursor-keys make highlighting disappear" regardless of which mode is running, or whether it is being evaluated while testing? .. CUA mode has this behaviour, but I really need that non CUA mode does it too (and eval, if possible)...
Here are the results, followed by the code. (GNU Emacs 23.1.1)
CUA mode enabled
Evaluate via C-x C-e — both (call-trans-hi) and (trans-hi)
NO-GO: Both set mark and move point to EOL, but nothing is highlighted.
Execute M-x call-trans-hi
ok: Works fine; the region is highlighted and then disappears the first time a key is pressed.
Via key binding C-f1
ok: Works fine; the region is highlighted and then disappears the first time a key is pressed.
no CUA mode (pretty much std emacs)
Evaluate via C-x C-e
NO-GO: Same as 1. when CUA is enabled.
Execute M-x call-trans-hi
NO-GO: The line is highlighted, but it is sticky! and requires C-g (keyboard-quit) to clear it.
Via key binding C-f1
NO-GO: The line is highlighted, but it is sticky! and requires C-g (keyboard-quit) to clear it.
;test (trans-hi) EOL
(defun trans-hi ()
"transient highlight"
(beginning-of-line)
(push-mark (point))
(end-of-line)
(activate-mark))
;test (call-trans-hi) EOL
(defun call-trans-hi ()
"call transient highlight"
(interactive)
(trans-hi))
(global-set-key [C-f1] 'call-trans-hi)
When you look at the source of activate-mark, you can see that it's just setting some variables. I suppose that's why you don't see the mark in both 1., because the actual highlighting happens in some stuff that's done when executing functions interactively instead of just calling them.
In the other cases of no CUA-mode, that just how transient highlighting works outside of CUA-mode. If you want the CUA-mode behaviour, use CUA-mode resp. that part of it.
EDIT:
Does this change (the addition of the setq line) to trans-hi make the highlighting work the way you want?
(defun trans-hi ()
"transient highlight"
(beginning-of-line)
(push-mark (point))
(end-of-line)
(setq transient-mark-mode (cons 'only transient-mark-mode))
(activate-mark))
If you want to see the region highlighted when you mark it, you need
to activate the minor mode transient-mark-mode.
When a region is highlighted and a character insterted the default is
to disable the highlighting and insert the character at the cursor.
If you wish you can delete the selected region by activating the minor
mode delete-selection-mode.
I've decided to get my toes wet with a bit of lisp, since I want to make emacs behave a little better when I hit TAB. My command works fine. It just performs indent-for-tab-command and if nothing happens, it performs tab-to-tab-stop, on the assumption that it's unlikely I was hitting TAB just to have the point refuse to budge when I'm inside a multi-line string or some such. After the first TAB press, it continues to do tab-to-tab-stop until either editing resumes, or the point is moved elsewhere. AFAIK, my logic is ok, though my lisp code probably isn't!
Originally I just hacked this into my emacs dot files by doing (local-set-key (kbd "TAB") 'tab-dwim) for major modes where I wanted this behaviour. That worked as expected.
Then I decided that what I was doing was basically a minor mode, so I tried to move the key-binding into a minor-mode. For some reason, even though the minor mode is enabled (as indicated in the mode line, and just from toggling it on and off), my tab-dwim function isn't being invoked when I hit the TAB key. I can still invoke it with M-x as expected.
What am I doing wrong with my minor mode's :keymap?
;;;
;; TAB DWIM
; buffer-local before/after point tracking
(setq point-before-tab nil)
(setq point-after-tab nil)
(make-local-variable 'point-before-tab)
(make-local-variable 'point-after-tab)
(defun tab-dwim ()
"Indents normally once, then switches to tab-to-tab-stop if invoked again.
tab-dwim will always perform tab-to-tab-stop if the first TAB press does not
cause the point to move."
(interactive)
(print "in tab-dwim now") ; THIS LINE IS NEVER INVOKED ON TAB?
(setq point-before-tab (point))
(if (eq point-before-tab point-after-tab) ; pressed TAB again
(tab-to-tab-stop)
(indent-for-tab-command))
(if (eq (point) point-before-tab) ; point didn't move
(tab-to-tab-stop))
(setq point-after-tab (point)))
(define-minor-mode tab-dwim-mode
"Toggle tab-dwim-mode.
With a non-nil argument, turns on tab-dwim-mode. With a nil argument, turns it
off.
When tab-dwim-mode is enabled, pressing the TAB key once will behave as normal,
but pressing it subsequent times, will continue to indent, using
tab-to-tab-stop.
If tab-dwim determines that the first TAB key press resulted in no movement of
the point, it will indent according to tab-to-tab-stop instead."
:init-value nil
:lighter " DWIM"
:keymap
'(([TAB] . tab-dwim)))
(provide 'tab-dwim)
Cheers,
Chris
I think you are very close.
Try this for your keymap:
'(("\t" . tab-dwim)))
Yes, use "\t" or the vector format "[(tab)]".
Some additional notes for your elisp development:
Avoid making global variables as much as possible. In this case, I think dynamically binding with let is appropriate. Also have a look at let*.
Understand the difference between make-local-variable and make-variable-buffer-local. The way you've written your code, the buffer-local variable would only exist in the buffer that loads your package.
As Nemo mentioned, it's extemely extremely extremely recommended that you use a common prefix for all variables/functions related to each package. Emacs has only one namespace, this is the "hacky" way to keep it somewhat organized.
I am getting problem with autoscrolling with next-line in emacs. When i get to the edge of the screen
http://i.stack.imgur.com/lfqEL.png
and making next-line sometimes I am not scrolled, and pointer aims to the center of the CURRENT screen, not the NEXT screen. http://i.stack.imgur.com/FPbuC.png
(so if i hold C-n pointer will run endlessly through this screen)
I am getting same things with forward-line, sometimes with forward-page. I am not getting the same with previous-line autoscrolling, it works fine.
I don't know why. I only noticed, that when I have more long lines, and screen is splited vertically, this thing happens very fast(C-x 3 C-x 3, scrolling from the beginning of my 1000-lines .emasc file is a fast way to reproduce this bug).
Emacs -Q, (setq truncate-lines nil) doesn't have it. Emacs, (setq truncate-lines t) doesn't have it too.
If you know anything about what can cause this troubles, please reply.
One potential source for this issue seems to be setting the scroll-conservatively variable.
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/0a7a9c730c037d57
I noticed that when moving down through big files, sometimes the
cursor will jump from bottom of screen to middle.
Any idea why this would happen only some of the time?
Because Emacs' redisplay is unable to keep with the scrolling. Before
23.1, with scroll-conservatively set to a large value, Emacs never
jumped; now it tries no to do it, but sometimes it fails. I think the
relevant ChangeLog entry is this one:
2008-10-27 Chong Yidong
* xdisp.c (try_scrolling): When computing the distance from the
scroll margin to PT, try moving some distance past the window
bottom before giving up.
Juanma
After 2-hour using eval-region (this problem wasn't easy to reproduce, macro/elisp with (next-line) (sit-for 0.01) didn't give any effect, so I tested it each time by holding C-n, using binary search method for eval-region)
So the answer is:
http://www.emacswiki.org/emacs/HighlightParentheses
Evaluating this in a *scratch*, starting emacs with emacs -Q
(setq-default truncate-lines nil)
(setq truncate-partial-width-windows nil)
(add-to-list 'load-path "~/my_path_to_highlight-parentheses_script/")
(require 'highlight-parentheses)
Make some buffer with long lines and narrow it with C-x 3 C-u 5 0 C-x } then C-x o M-x highlight-parentheses-mode and hold C-n is a way to reproduce the bug.
I commented out all thing relative with highlight-parentheses, and bug gone away. I think, I should find a way to tell developers about this bug.
I converted from Visual Studio to Emacs for most of my development (mainly due to switching programming languages). However, there is one cool feature of Visual Studio that I truly miss: Ctrl-Tab between "buffers".
The ctrl-tab that in Visual Studio is not the same as C-x b in Emacs. So, it's not just a keyboard mapping issue. Here are the features of my ideal Ctrl-Tab:
Hold down ctrl hit tab, you see the next buffer before you let go of ctrl.
There is no need to hit enter.
If this is not the buffer you want, hit tab again until you see the buffer you want.
The moment that ctrl is released, the buffer ring is updated. The next buffer in the ring is the buffer where you first pressed ctrl.
I've seen some Emacs plugins that try to simulate this behavior, but #4 is the most difficult. It seems like Emacs is unable to detect when the ctrl key is released. Instead, the code waits for the user to be in the buffer for a certain time or waits for a buffer to change..and then the buffer is added to the ring. It's different enough to really frustrate me and just never use my beloved ctrl-tab again. For now I just deal with C-x b. ido-mode makes C-x b more tolerable, but I still dream of a day when I can ctrl-tab in emacs.
Has anyone out there found a way to configure Ctrl-Tab in Emacs to work like Visual Studio?
I was searching for exactly the behavior that you describe and came across
the iflipb package: http://www.emacswiki.org/emacs/iflipb and bound it to C-tab, C-S-tab.
Unfortunately it doesn't restart the cycling either after releasing the ctrl key, so in that regard is the same as the my-switch-buffer in the answer above. Any new insights into this issue are highly appreciated.
If you are using GNU Emacs 22.1 or more recent releases, \C-x<Right> fires M-x next-buffer and \C-x<Left> fires M-x previous-buffer. This page on EmacsWiki has a link to C-TAB Windows style buffer cycling. The page also talks about how to bring this behavior on older releases of Emacsen.
This question from yesterday looks very similar to what you want to achieve, except that the question talks about Notepad++ instead of Visual Studio.
I think this is close to what you want. As you mentioned, Emacs doesn't receive events for the control key, so you can't quite get the functionality you want. However, this will not record the buffer switch until you do something other than press C-tab (i.e. scroll, type something, click the mouse, use a command M-x ...):
(global-set-key (kbd "<C-tab>") 'my-switch-buffer)
(defun my-switch-buffer ()
"Switch buffers, but don't record the change until the last one."
(interactive)
(let ((blist (copy-sequence (buffer-list)))
current
(key-for-this (this-command-keys))
(key-for-this-string (format-kbd-macro (this-command-keys)))
done)
(while (not done)
(setq current (car blist))
(setq blist (append (cdr blist) (list current)))
(when (and (not (get-buffer-window current))
(not (minibufferp current)))
(switch-to-buffer current t)
(message "Type %s to continue cycling" key-for-this-string)
(when (setq done (not (equal key-for-this (make-vector 1 (read-event)))))
(switch-to-buffer current)
(clear-this-command-keys t)
(setq unread-command-events (list last-input-event)))))))
I like the cycling and toggling behavior of iflipb too, it's very much like Windows Alt-Tab behavior. However, as previously pointed out, Emacs doesn't make it easy to notice when you release the control key. This makes toggling between the top two buffers imperfect: if you press C-Tab (and release) and then C-Tab (and release), you haven't toggled between the top two. Instead, iflipb just marches further down the buffer list. But if you perform any other Emacs command between the two C-Tab events, then iflipb recognizes that it is starting over in the buffer march, so it does the toggle.
On Windows, AutoHotKey can come to the rescue and send Emacs a keystroke when you release the control key. Here's my script:
#if WinActive("ahk_class Emacs")
^Tab::
Send {Blind}^{Tab}
SetTimer, WaitForCtrlUp, 10
return
WaitForCtrlUp:
if(!GetKeyState("LControl", "P") and !GetKeyState("RControl","P"))
{
if WinActive("ahk_class Emacs")
Send ^c:
SetTimer, WaitForCtrlUp, Off
}
return
Whenever C-Tab is pressed in emacs, the script starts polling the state of the control key. When the key is released, it sends Emacs the C-c : key sequence. I have that key bound to a "null" command, which is enough to get iflipb to notice what's going on.
Here's the relevant .emacs excerpt:
; see http://www.emacswiki.org/emacs/iflipb
(require 'iflipb)
(global-set-key (kbd "<C-tab>") 'iflipb-next-buffer)
(global-set-key
(if (featurep 'xemacs) (kbd "<C-iso-left-tab>") (kbd "<C-S-tab>"))
'iflipb-previous-buffer)
(defun null-command ()
"Do nothing (other than standard command processing such as remembering this was the last command executed)"
(interactive))
(global-set-key "\C-c:" 'null-command)
So, it's kind of hacky, but it does work. Thanks to the posters at http://www.autohotkey.com/board/topic/72433-controltab/, who were trying to solve a similar problem.
Add the following to your .emacs file:
(global-set-key (kbd "<C-tab>") 'next-buffer)