One tantalizing shortcoming of Emacs is its weirdly broken scrolling mechanism on 'inertia-scrolling' OSX. After a lot of digging, the real problem seems to be that Emacs only registers keys for mouse wheel scrolling in one, two or three increments, that is wheel-up|down, double-wheel-up|down and triple-wheel-up|down.
However, the Mac trackpad seems to generate far bigger scrolling increments when scrolling fast. So, is there a way to generate more accurate scrolling messages that actually reflect the amount the trackpad was scrolled?
I am running Emacs 24.0.92 from http://emacsformacosx.com/.
Relevant .emacs settings:
(setq redisplay-dont-pause t)
(setq mouse-wheel-progressive-speed nil)
Ultimately, what I would like to have is something like this:
(defun up-single () (interactive) (scroll-up 1))
(defun up-double () (interactive) (scroll-up 2))
(defun up-triple () (interactive) (scroll-up 3))
...
(global-set-key [wheel-down] 'up-single)
(global-set-key [double-wheel-down] 'up-double)
(global-set-key [triple-wheel-down] 'up-triple)
...
I do not understand clearly what you want, but while Emacs only has distinct event names for single/double/triple clicks, it actually distinguishes up to sequences of 9 clicks. The event-click-count can be used to extract this info from an event.
It seems as if Emacs does not handle scroll events like OSX does. The double- and triple- modifiers and the event-click-count function Stefan mentioned do not signify single events of fast scrolling but merely that several scroll events happend in close succession. So when you begin to scroll, you get a 'click count' of 1, then 2, then 3 and so on.
On OSX, the trackpad does not issue individual scroll events like a mouse-wheel does. Instead, each event contains a pixel increment of how far the cursor moved since the last event. Programs should move their scroll-views by a distance proportional to that increment. However, to my knowledge Emacs scroll events do not contain that increment. Therefore, Emacs in its current form can not implement inertial scrolling.
PLEASE correct me if I'm wrong!
Related
Often I have multiples windows carefully arranged within a frame.
However, certain command, say M-x man RET will grab one of the visible windows to display its own content. Sometimes this is annoying because the window that was taken away is one that I need to keep it visible.
e.g. I have 3 windows on screen, one useful source-code window and two useless windows. I want to keep the soure-code window visible while checking the man page. But very often Emacs just take away the code-window for the newly opened man page.
One way I can think of is to display the (chronological) open order of each window, so that I can focus point on n-th window and be confident that Emacs will grab (n+1)-th window for new content.
Is there a way to display such order, e.g. in the mode-line of each window?
Or is there another way for better control for displaying new window?
A little late to the party but as discussed in the comments, using dedicated windows is a good way to control where new content is displayed (+1 to #lawlist for bringing it up and to #phils for mentioning toggling!).
I'm pretty sure you'd be able to implement a command that toggles dedicatedness yourself at this point, but since I have the code for this handy I'll share it anyway:
(defun toggle-window-dedicated ()
"Control whether or not Emacs is allowed to display another
buffer in current window."
(interactive)
(message
(if (let (window (get-buffer-window (current-buffer)))
; set-window-dedicated-p returns FLAG that was passed as
; second argument, thus can be used as COND for if:
(set-window-dedicated-p window (not (window-dedicated-p window))))
"%s: Can't touch this!"
"%s is up for grabs.")
(current-buffer)))
(global-set-key (kbd "C-c d") 'toggle-window-dedicated)
Now, in a multi-window setup you can simply press C-c d in each window you would like to "protect".
I'll throw this example usage of display-buffer-alist into the mix, given that it was mentioned in the comments, and is indeed a general mechanism for controlling how and where buffers are displayed (even though, as Drew indicates, it is far from trivial).
Start with the help for the variable itself:
C-hv display-buffer-alist RET
From there you'll get to the help for display-buffer, and no doubt acquire some idea of the complexities involved :)
In any case, the following is an example of using a custom function to decide how to display buffers named *Buffer List*.
You can easily see that if you can write a function which can figure out how to display a buffer where you want it to, then you can use display-buffer-alist to make it happen.
(defun my-display-buffer-pop-up-same-width-window (buffer alist)
"A `display-buffer' ACTION forcing a vertical window split.
See `split-window-sensibly' and `display-buffer-pop-up-window'."
(let ((split-width-threshold nil)
(split-height-threshold 0))
(display-buffer-pop-up-window buffer alist)))
(add-to-list 'display-buffer-alist
'("\\*Buffer List\\*" my-display-buffer-pop-up-same-width-window))
A key quote regarding the ACTION functions is:
Each such FUNCTION should accept two arguments: the buffer to
display and an alist. Based on those arguments, it should
display the buffer and return the window.
this is my first question, so apologies for breaking any rules.
I've just started writing some functions in elisp to help me navigate certain types of text files more efficiently. To make these accessible, I've added some buttons to the tool-bar. As it's now becoming busy, I'd like to either: 1) move some of these additional buttons to a second line; or 2) instantiate a second tool-bar that could be placed somewhere else in the frame (either under the existing tool-bar, or perhaps vertically along the side where the scrollbar is).
I've searched high and low but am unable to find an existing example of this and, as I don't yet really know what I'm doing, I wonder if somebody has a code snippet from which I might start to hack a solution together.
Many thanks in advance.
System: CentOS 5/6, emacs for linux 23.1
Edit:
Thanks for the comment, William. Here's a simple example representing what my tool-bar code might do:
;
; functions used by the toolbar
;
;
(defun copy-paste-whole-line ()
"copies and pastes the whole of the current into a new line underneath"
(interactive)
(beginning-of-line)
(set-mark (point))
(end-of-line)
(setq temp (buffer-substring (region-beginning) (region-end)))
(message " copying: %s" temp )
(newline)
(insert temp))
;
;
; population of the toolbar:
;
;
(when (find-image '((:type xpm :file "copy_paste_line.xpm")))
(unless tool-bar-mode (tool-bar-mode 1))
; (setq tool-bar-map (make-sparse-keymap)) ; <- uncomment this line to have only this button present
(tool-bar-add-item
"copy_paste_line"
'copy-paste-whole-line
'copy-paste-whole-line
:help "copies and pastes the whole of the current line into a new line underneath"))
so, as you can see (actually, I'm not allowed to post images until I have 10 reputation points, so you won't be able to see), the code adds an extra button to the end of the existing tool-bar buttons. I believe this to be a reasonable way to achieve this, but I'm not an experienced elisp programmer, so if you think it's poorly written, please comment - I'd like to understand why... :)
If I only had 1 button, it would be ok like that, however, I have multiple buttons. I would, thus, like to add them to a second instance of a similar tool-bar (or, perhaps a vertical one placed where the scrollbars are).
Thanks again for any input.
Frame parameter tool-bar-lines is supposed to control this. You can, for instance, customize option default-frames-alist if you want to change the number of tool-bar rows to 2 or 3 everywhere. Or you can do this on a mode-by-mode or frame-by-frame basis. You can, for instance, use M-: (set-frame-parameter nil 'tool-bar-lines 3).
Depending on your platform (and toolkit), the behavior might be variable. See the Elisp manual, node Layout Parameters and node Tool Bars.
I believe you are out of luck. It seems to me that (at least on ubuntu and cygwin) only one row of buttons in the tool-bar is supported.
Here is what I have tried without luck on both systems:
(progn
(set-frame-parameter nil 'tool-bar-lines 3)
(loop for i from 1 upto 20 do
(setcdr tool-bar-map (cons (cadr tool-bar-map) (cdr tool-bar-map)))))
The following picture shows what I get:
The other buttons appear in a pull-down menu if you click on the little triangle at the right end of the toolbar:
You can restore the old tool-bar with the following commands:
(progn
(setq tool-bar-map (make-sparse-keymap))
(tool-bar-setup))
Finally, I have 3 rows of buttons. This is possible with emacs-w32:
So it is the gtk+ / nextstep problem.
Yasnippet has a nice "run ... after exiting a snippet".
What I would like to do is include some visual effect after each ending snippet (changing background color for, say a second, or more sophisticated stuff).
I did this by switching background colors back and forth in that hook, but it's really short and not efficient, and also ugly.
However, how can this, or something similar be done with a timer?
Optional: Suggestions for fancy effects (including a timer) are welcome.
You can change the background once and then change it again 1 second later by using run-with-timer:
(run-with-timer 1 nil 'my-fun)
where my-fun does the action you want.
My first thought would be to make Emacs "beep". I actually hate that sound, so I have it flash the frame instead.
(setq visible-bell t)
(add-hook 'yas-whatever-hook (lambda () (beep t)))
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
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.