In my vimrc I have tab mapped to % in visual mode, normal mode, and I think command mode with
:map <tab> %
"colon necessary
so that when I hit tab it acts as %. Everything works fine except that when in visual mode if I hit tab instead of jumping to the matching pair it just deletes whatever was visually selected. In normal and command mode this doesn't happen.
Even if I use
vmap <tab> %
in my vimrc it still doesn't work. But when I set it manually while editing a file with
:vmap <tab> %
then tab acts as % like it should.
I have supertab and snipmate btw. But even if the problem is with the plugins I don't understand why manually setting tab works when setting it in my vimrc doesn't.
If you've determined that overriding the default mapping doesn't do harm to the way you use the other plugin (snipMate in your case; and I think the % mapping is not a core one, just to avoid some corner cases potentially breaking it), you can either comment out the original mapping (~/.vim/after/plugin/SnipMate.vim, in your case), or (recommended, because it leaves the original plugin intact):
Create a file ~/.vim/after/plugin/zzzmappings.vim and put your vmap mapping there. The .../after/ as well as the zzz prefix part ensures that this is sourced last, and therefore overrides everything defined before. (Your .vimrc, in contrast, is sourced before any plugin.)
Related
In EMACS the default seems to be to 'copy' any text highlighted with the mouse. I'm attempting to replicate the functionality of modern text editors, where I can highlight a section of text and press 'paste' to replace it. I have so far added
(delete-selection-mode 1)
to my init.el
The problem is, if I copy something, then highlight to paste in its place, I end up pasting what I had just highlighted, changing nothing.
What do I need to change to fix that behaviour?
The most powerful element of emacs is its introspection features, lets have a look at how we can use them to try and solve this problem. We must use the power of the source.
One of the most important tools for introspection in emacs is the describe-key command which is bound to C-h k. It brings up the documentation of whatever keystroke is called after it. So in our case if we press C-h k and then click and drag we will see the documentation for <down-mouse-1> and more importantly for <drag-mouse-1>. The documentation states that "<drag-mouse-1> at that spot runs the command mouse-set-region". Below it then gives some documentation for this command. It says
Set the region to the text dragged over, and copy to kill ring.
This should be bound to a mouse drag event.
See the ‘mouse-drag-copy-region’ variable to control whether this
command alters the kill ring or not.
Now we know that somehow mouse-drag-copy-region controls whether or not the highlighted text is copied.
If we follow the link of that variable it tells us the default value and some documentation:
If non-nil, copy to kill-ring upon mouse adjustments of the region.
Now all we have to do is set the variable to be nil to get the effect that you want. Place the following code at the end of your init file and you should be all set
(setq mouse-drag-copy-region nil)
I hope that this helps you with this problem and that more importantly it helps you with further issues.
By default, selecting a region with the mouse does not copy the text to the kill ring. If your Emacs does this, you probably have set the variable mouse-drag-copy-region.
In a fresh Emacs (24.5 started using -Q), you can do the following:
Start delete-selection-mode.
Mark a region using the mouse. Copy it using M-w.
Mark a second region. Replace it with the first using C-y.
I see two alternatives, neither of which does exactly what you request. (For both, yes, turn on delete-selection-mode.)
Use the secondary selection for the text to copy, and use the primary selection (the region) for the text to be replaced.
You copy text into the secondary selection using the Meta key plus the mouse - for example, press and hold Meta (the Alt key, usually) while dragging or double-clicking mouse-1.
You paste the secondary selection using Meta plus mouse-2.
Select text with the mouse, then copy it to the kill-ring using M-w. Then select the text to replace with the mouse and use C-y to paste the copied text to replace it.
I must be stupid, but I just switched to Emacs 24, and holding Shift while moving the point no longer highlights text. Mouse selection works as before. What am I missing? Did I turn it off by chance? Or has Shift selection been deemed unergonomical so we have some other, better keyboard-based selection at hand?
Shift selection is enabled by default in Emacs 24.
You can always run emacs -Q to disable your init file and any other default libraries, in order to determine what Emacs' default behaviour is.
You can also run emacs -q which will disable only your init file (other system-wide init files can be loaded).
If the feature works without your init file and does not work with it, you can then start to narrow down what part of your init file is at fault (often by commenting out functionality until the feature starts working as expected -- note Drew's comment).
In this case I suggest that you firstly verify (using C-hv) that the shift-select-mode variable is non-nil (when running with your normal configuration), as a nil value means that shift selection is disabled.
I also found it useful to look at load-path variable, C-h v load-path, which directed me to the culprits, old elpa packages.
In Aquamacs 2.2 I could do the following:
1) Set the mark with C-SPACE
2) Click somewhere to set the point
Consequently this would define the region. Since Aquamacs-2.3 this behaviour is gone: A click sets both the mark and the point. Is there a way to customize aquamacs to have the old behaviour?
For Emacs 24, here's what worked for me (and may also apply to Aquamacs): Unset the binding for the <down-mouse-1> event, which is what is setting the mark (but not the point; the point is set by a different binding, for the up-event <mouse-1>).
That seems to provide the behavior you are asking for: clicking the mouse after setting the mark via C-space sets the point, and one can see the corresponding region highlighted.
I determined this by reading the help for the bindings above, by doing:
M-x helpkclick, and reading the *Help* text, which explains that <down-mouse-1> is bound to command mouse-drag-region (which sets the mark).
I then tested the resulting behavior by interactively disabling the binding, by doing:
M-x global-unset-key and then clicking; but it is probably much safer to do it programmatically, e.g. in the scratch buffer, by evaluating:
(global-unset-key [down-mouse-1])
If you like the behavior that results, then just copy the above line into your .emacs
Employing the solution described above does seem to cause mouse-dragging to be a little funky, in that it does not highlight the selected region during the drag (but you still get to see what the region is once you let go, and you can now fine tune its end point via single clicks, which may be useful in some circumstances.)
While trying to autocomplete a file (e.g. to open a file with C-x C-f) Emacs-helm shows a list of possible candidates.
If I then press Tab (which I would hope it would help me choose the first/closest match), I get the following in the minibuffer:
It looks like the minibuffer gets confused with escape characters, and it does not choose the file that I actually want to open (the top choice).
Helm requires this conceptual jump from the default Emacs completion, which is not so obvious:
You don't need to press a key to complete. The completion buffer refreshes
with new results after every input.
This is called "incremental" completion.
The normal tab functionality is not needed in "incremental"
completion. So tab was rebound to helm-select-action, which allows you to
choose an alternative action with the selection. But there is only one action
in read-file-name.
The error you're seeing could be clearer though, I've filed this issue on github.
Additionally, note Helm treats each space separated term as a filtering
regular expression. So, pressing space foo will filter
the current list down to those that contain foo in the name.
I have tried emacs on and off for a while now and every time I start emacs, I go through the same routine. Customizing. The first one is binding return to newline-and-indent. (g)Vim does this by default. Showing matching parenthesis is also done by default on (g)Vim. It is grea that I can customize emacs to my heart's content but why doesn't emacs have nice and easy defaults? For reference, I am now using Emacs 23 on a RHEL5 box.
Probably because RMS didn't want it, that and because changing long-standing defaults is just an issue of politics. Like vi, Emacs has a hard-core following and basic changes like these are minefields.
Note: if you saved your customizations, then you wouldn't have to re-do them every time...
To have those nice and easy defaults, install Emacs Starter Kit. It enables by default a bunch of useful and convenient features make even the advanced Emacs users more productive.
Otherwise, as TJ pointed out, Emacs Customization Mode (type M-x customize) allows you to save permanently any of the settings. You can even store them in a separate file from your dotemacs―(setq custom-file "~/.emacs-custom.el")―so you can use it in every computer you work on.
The title of your question doesn't really reflect what your question is (and has been answered by Trey and Torok), but I'll tell you why I like it being bound to just newline: useless whitespace. Say you are nested inside a conditional in a function etc. and hit return a couple times to leave a blank line. The blank line now has a bunch of space chars on it. Yes, you can (and I do) remove trailing whitespace before saving, but I also have visual whitespace mode on and I can see it there taunting me.