As far as I can tell, ace jump will only jump to items found in the visible part of the buffer. Once I activate ace jump, and matches to my selection are highlighted, I can jump to any of them, as long as they are visible. But what do I do if I want to find matches in the part of the buffer that it not visible? Attempts to scroll the buffer causes ace jump to quit.
What you want seems like a good idea, but it doesn't really work. You would need to know what keypress you need to get to an off-screen match, and you can't know what those are because they are off-screen. Ace-jump is for jumping around the visible buffer.
Other options are isearch, M-x occur or structured tools like imenu, speedbar, ecb and so on.
Related
In VSCode, is there a way to disregard cursor motion in the code navigation history? That is, when I jump into a definition, I usually move the cursor a bit (eg: up/down) to inspect the surrounding code. When I issue the "navigate back" command, it incorporates the cursor movement into the navigation history stream. That is, navigating back will just move up/down one line. I almost always want to disregard manual cursor movement when navigating code. The JetBrains IntelliJ suite of tools behaves this way. Can VSCode be configured to do the same?
Turned out to be a conflict with VSCode/VIM causing this behavior. VSCode/VIM affects the code navigation history it looks like, injecting cursor movements into the command stream so that VSCode's native "Go Back" traverses the cursor movement stream, which is generally undesirable.
The VIM jump list behaves correctly though so I've switched to using ctrl+o and ctrl+i to navigate back/forward.
When running Gnu Common Lisp in inferior-lisp mode, each time an expression is typed in to Lisp eval, the window is automatically re-positioned so that the input cursor is at the bottom of the window. Years ago, it did not do this. I would like the old behavior, where the text in the window stays in the same place until the printout goes beyond the bottom of the window, and then it puts the input cursor in the center of the window.
I have played with the scroll variables, without effect.
You probably want to play with comint-scroll-show-maximum-output.
There is an functionality in XEmacs that if the user selects a region with the mouse while holding Ctrl, the selected region will be automatically pasted at the current cursor position.
In other words, if you need to quickly copy a short block of text from some open buffer to a new spot, you put the cursor there, and then do Ctrl-mouse-select and it works.
Unfortunately, I recently had to switch from XEmacs to GNU Emacs, and I'm looking to see if there is similar functionality there, or perhaps I could provide it with a custom module (I am very bad at Lisp, unfortunately).
You sure can, the functionality is bound to mouse button 3 if I'm not mistaken.
I assume so, because clicking my mousewheel yanks what I've copied at the cursor.
And Mousewheel == mouse button 3 in most cases.
Select using your mouse
With your mouse button down, hit control
Release your mouse button
Hit mouse button 3
Profit - selection yanked at your cursor
edit:
I found this on http://www.gnu.org/software/emacs/manual/html_node/emacs/Mouse-Commands.html
Mouse-1
Move point to where you click (mouse-set-point).
Drag-Mouse-1
Activate the region around the text selected by dragging, and copy it
to the kill ring (mouse-set-region).
Mouse-2
Yank the last killed text at the click position (mouse-yank-at-click).
Mouse-3
If the region is active, move the nearer end of the region to the click position; otherwise, set mark at the current value of point and point at the click position. Save the resulting region in the kill ring; on a second click, kill it (mouse-save-then-kill).
Put the following in your init file (.emacs):
(require 'mouse-copy)
(global-set-key [C-down-mouse-1] 'mouse-drag-secondary-pasting)
Once you restart Emacs, it should work just like you're used to in XEmacs--hold down Ctrl and the left mouse button, select your text, and when you release the mouse the text will be inserted at your current cursor position.
You might want to use mouse-copy.el which comes with Emacs.
I'm using iTerm2 on my mac to ssh into a Linux box and run emacs in the terminal. On a big monitor, I like to split the window to see multiple buffers side-by-side. I'd like to be able to switch to a particular buffer by clicking the mouse in it (rather than doing C-x o).
What seems to be happening is that if I click the mouse anywhere outside the currently active buffer e.g. in the next buffer, on the mode line etc., the click is being interpreted as which is bound to (tmm-menubar-mouse EVENT).
I have disabled the menubar by doing the following in my .emacs_d/init.el:
(menu-bar-mode -1)
This seems to disable the visible display of the menu bar at the top of the window, but the mouse click behavior I described is still happening.
I think what I need is to have the click interpreted as something other than and then bind that to some function that detects which buffer the click happened in and switch to it. But, I don't know how to do that and the searching I've done hasn't yielded any clear answer. Can anyone help?
Alternatively, I looked into using windmove to enable switching between buffers with SHIFT and the arrow keys. I did (windmove-default-keybindings) but emacs then seems to respond to SHIFT left-arrow by inserting "2C" into the buffer and SHIFT-right-arrow by inserting "2D". If anyone has any tips on making this work too, I'd love to hear them.
Thanks
I ran into this problem a while ago, where clicking on column > 95 was interpreted as <menu-bar> <mouse-1>, which invokes tmm-menubar-mouse. It turned out to be a bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6594
There hasn't been a formal release since this bug was fixed, but you can get the patch here:
http://bzr.savannah.gnu.org/lh/emacs/emacs-23/revision/100618
If I recall correctly, you should be able to just drop the modified file into your existing emacs installation and byte-compile it (assuming you're running the 23.3.1, the latest release).
I'm working on an intellisense or code-completion capability for C#.
So far, so good. Right now I have basic completion working. There are 2 ways to request completion. The first cycles through all the potential matches. The second presents a popup menu of the matches. It works for types:
And also for local and instance variables:
I'm confronting two problems with x-popup-menu:
the popup menu can expand to consume all available screen space, when the number of choices is large. Literally it can consume the entire screen, and obscure everything else, including the entire emacs window and every other window.
The silly thing is, it's scrollable. First it expands to consume all available space, then it also becomes scrollable. Seems like it would make sense for it to expand to a certain point, and then become scrollable, rather than expanding to take all available space.
Is there a way I can limit the maximum size of x-popup-menu?
To specify the position of the popup menu, I pass in a position, and x-popup-menu uses that as the *middle*, not the left, of the top line of the menu. Why middle? who knows.
What this means is, if I specify (40 . 60) for the location of the menu, and the menu happens to be 100 pixels wide, the menu will extend beyond the left border of the emacs window. You can see this in the 2nd image above.
If I knew how wide the popup would be before specifying the position, I could compensate. But I don't.
Is there a workaround? Is there a way to get x-popup-menu to take its position as the LEFT rather than the middle?
Addendum: Doc for x-popup-menu
x-popup-menu is a built-in function in `C source code'.
(x-popup-menu POSITION MENU)
Pop up a deck-of-cards menu and return user's selection.
PO SITION is a position specification. This is either a mouse button
event or a list ((XOFFSET YOFFSET) WINDOW) where XOFFSET and YOFFSET
are positions in pixels from the top left corner of WINDOW's frame
(WINDOW may be a frame object instead of a window). This controls the
position of the center of the first line in the first pane of the
menu, not the top left of the menu as a whole. If POSITION is t, it
means to use the current mouse position.
Some people like Emacs because it doesn't provide popup windows (see e.g. this blog entry). The more "emacsy" way of presenting your list of possible completions is to show them in a split buffer. That way you would automatically avoid all of the above issues (screen real estate & scrolling) and would probably attract more of the die-hard Emacs users.
But that's pure speculation :-)
You can base your autocompletion backend on company or autocomplete where display of suggestions is handled for you.