I have Global Subword Mode enabled, but I am trying to get Ctrl+Left/Right to travel by subwords in place of the full word default of left/right-word (the default commands for those keys).
It works as expected if I simply rebind the keys, except for one case: If I try to "transient-mark" using Ctrl+Shift+Right, rather than marking the full word like right-word does, the point is moved to the next subword without creating a region.
Is this due to Subword Mode? I would like to know if I can somehow combine some of the normal features of left/right-word like marking with the movement of Subword Mode.
IMHO this is indeed a problem with subword-mode. You can fix it by doing:
(defadvice subword-backward (before handle-shift-selection activate)
(handle-shift-selection))
(defadvice subword-forward (before handle-shift-selection activate)
(handle-shift-selection))
But my advice is to do also a M-x report-emacs-bug so this can be properly fixed in next release.
Related
I'm trying to get doremi working in emacs. Specifically, at this stage, to allow me to quickly scroll through a condensed list of color-themes and see each theme as I go through it. For this I would use the 'M-x doremi-color-themes+' command.
What I've done:
Installed color-themes (successfull)
Installed doremi.el, doremi-cmd.el, ring+.el and added
(add-to-list 'loadpath "~/elisp/themes")
(add-to-list 'loadpath "~/elisp/doremi/")
(require 'color-theme)
(color-theme-initialize)
(color-theme-classic)
;; create a list of color themes to scroll through using 'doremi-cmd
(setq my-color-themes (list 'color-theme-classic
'color-theme-retro-green
'color-theme-gray30
'color-theme-subtle-hacker
'color-theme-jonadabian-slate))
(require 'doremi)
(require 'doremi-cmd)
(require 'ring+)
to the .emacs file.
What emacs does:
When I type the comand 'M-x doremi-color-themes+' into the mini-buffer it seems to accept that I've given it a valid command and tells me to use the and arrow keys to move through the list. But when I do that all that happens is the cursor moves up and down in the active window. No changing of color-themes.
Being somewhat new to emacs (and especially customising it) I'm sure I have missed a step or put something in the wrong place. Perhaps there's some sort of (setq 'bla-bla-bla (...)) I need to do?
Sorry for your trouble. Please state your Emacs version (M-x emacs-version), and your version of color-theme.el.
You do not need to require library ring+.el if you use Emacs 23 or later (its code was included in GnuEmacs 23.)
You do not need to use (color-theme-initialize) or (color-theme-classic). The former is done automatically by doremi-color-themes+.
Try starting from emacs -Q (i.e., no init file, ~/.emacs), to be sure there is no interference from stuff in your init file.
Your variable my-color-themes is not referenced anywhere. Instead of defining that variable, just customize user option doremi-color-themes. (Or leave its value nil, which means that all color themes will be cycled through.)
Feel free to contact me by email if you continue to have a problem. Or continue here, if you prefer.
[Just to be sure: you are using color-theme.el, right? There is a lot of confusion out there between Emacs "custom themes" and color themes. Do Re Mi supports both, but they are different critters.]
After a bit for back and forth with #Drew we found a solution to the problem.
It turned out the major problem was that I was using emacs in 'terminal mode' rather than as a GUI application. Bare in mind I'm using a mac.
In the context of Terminal, my arrow keys send escape sequences and so doremi cannot read the event as intended. So it just escapes and applies the message to the active buffer.
There is an answer.
By adding the following lines to my .emacs file (or whatever your init file for emacs is) I was able to redirect doremi to use two other keys. ie. not the up and down arrows.
(setq doremi-down-keys '(?n))
(setq doremi-up-keys '(?p))
Doing this tells doremi to use 'n' as the down key and 'p' as the up key. And all works just fine.
Because I am only new to the world of programming and computing I may often use incorrect terminology. If this is the case please let me know and I will edit accordingly for clarity and consistency.
I'm an evil Emacs user. However, I really only use the normal mode for fancy Vim style edits when I find them more convenient than regular Emacs commands. (Mostly fancy bulk editing/yanking/deleting). However, I'm also a huge user of the minibuffer (I do a lot of M-x with ido and flx so I can avoid remembering the more esoteric commands). When I do, evil switches to normal mode automatically after I exit. I find that very annoying/confusing. How can I get it to stop? (preferably in an elegant, non-hackish way).
Thanks,
PythonNut
EDIT:
It appears that the switch to normal mode happens in all windows and in all frames.
I cannot reproduce your issue; maybe knowing your versions could help anyone to identify your issue. Can you reproduce your issue with "emacs -q" (plus adding evil to load-path)?
Here is an approach to identify the evil (traditional English meaning) piece of code, if any, that is calling to evil-normal-state:
(defadvice evil-normal-state (before debug-issue activate)
(setq debug-on-error t)
(inexisting-function-will-fail))
Eval this just after setting a buffer in the evil-state you want it to be, then go to to the minibuffer with M-x. Is there an stacktrace?
You may reactivate evil-mode by adding whatever function you use to activate it to minibuffer-exit-hook.
Is it possible to let Emacs have the cursor be moved off-screen, like most GUI text editors work? This is one of the biggest things that bothers me when I use Emacs over any GUI editor. When I scroll down, the cursor is "pushed forward" by the top of the buffer.
I had previously thought that this was completely impossible, because this is hard-wired into the architecture of Emacs, but then I saw multiple-cursors, which does exactly this for the secondary cursors (assuming you prevent the scrolling functions from acting on the secondary cursors). Is it maybe possible to use multiple-cursors to have the main cursor in some hidden buffer, and the effective cursor being what I actually edit with? Or maybe some other clever trick? Or maybe my Googling has failed me and this is really already possible without any magic?
There is a new package available on GNU ELPA called scroll-restore that attempts to remedy this problem. So far, I have encountered a few bugs, but the package seems to work as-advertised for the most part.
You can test it out by installing it with
M-x package-install RET scroll-restore RET
After the package is installed, you can enable the minor mode with
M-x scroll-restore-mode
Personally, I am binding it to the Scroll Lock key because it seems so incredibly apropos! This is what I am adding to my init file:
(require 'scroll-restore)
(scroll-restore-mode 1)
;; Allow scroll-restore to modify the cursor face
(setq scroll-restore-handle-cursor t)
;; Make the cursor invisible while POINT is off-screen
(setq scroll-restore-cursor-type nil)
;; Jump back to the original cursor position after scrolling
(setq scroll-restore-jump-back t)
;; Toggle scroll-restore-mode with the Scroll Lock key
(global-set-key (kbd "<Scroll_Lock>") 'scroll-restore-mode)
This is a direct copy of an answer posted here: https://emacs.stackexchange.com/a/2273/93
Strictly, speaking you can't move the cursor offscreen, because the underlying C code won't let you do it.
This said, I suspect that your problem can be fixed. Basically, there are 2 aspects:
you don't like the way things look when "the cursor is pushed forward". You could work around that by (temporarily) making the cursor invisible.
you want to "jump back" to the pre-scrolling position as soon as you issue a non-scrolling command. There's probably some package out there that does it for you, but you can do it yourself with some pre-command-hook hacking.
BTW, I'd welcome patches in Emacs which provide some of that functionality. I hate the "auto jump-back" behavior of other editors, but it would be good to record the "pre-scroll" position and then offer a way to jump back to it.
Judging by the context and description of your problem, it looks like you want to browse the buffer while preserving your place of editing. There are at least two tricks for that purpose: marks/registers and splitting in two windows.
https://stackoverflow.com/a/3777598/308668 describes the Emacs' registers that act like Vim's marks. You can check in your place in the file with keying C-x r SPC a (a being a letter of your choice) and you can always come back with C-x r j a.
Some sort of automation is achieved by an external script (goto-last-change.el), described here: https://superuser.com/a/184402/49046.
Alternatively, split the window in two with C-x 2. The newly split windows both show the same location and you can use the other to explore. C-x 0 closes a window when you're done.
I am using GNU Emacs 22.3.1 on Windows.
In my Emacs I have enabled delete-selection-mode, and it's very useful to select a region and delete or replace it. But I have a drawback.
When I write or press DEL over the selection, Emacs does not only remove the text, but it kills (a.k.a. send to the clipboard*). This is very annoying for me, because I don't have control of my kill-ring (a.k.a. clipboard) and may cause unexpected effects.
There is a way that delete-selection-mode does not kill the text, just delete it? Perhaps modify the source code?
(*: I have synchronized the kill-ring and the Windows clipboard, so for me (for practical purposes) it's the same)
Edit[Jun 24, 2009]
Thanks, danielpoe. Even with the idea of Trey Jackson the selection is still killing. And I found the reason.
I discovered that the problem was not in delete-selection-mode. The problem is, when I selected the region, I did it with the mouse. And never have imagined that it was the mouse who was copying the text. Using the set-mark command and the arrow keys the text finally aren't killed, only deleted.
I disabled this behavior writing this in my .emacs:
(require 'delsel)
(setq mouse-drag-copy-region nil)
(global-unset-key (kbd "<mouse-2>"))
(global-unset-key (kbd "<mouse-3>"))
Thanks for the advice. If this method of disable this mouse behavior can cause conflicts with other options, please comment.
Have you tried starting emacs with -Q. If I do so and only enable M-x: delete-selection-mode, I can't reproduce what you describe. Nothing is killed only deleted?! Can you check?
It looks as though you just need to modify a small part of the source, namely make this change:
(defun delete-active-region (&optional killp)
(delete-region (point) (mark))
t)
The original code looked at the argument killp and used that to decide whether to add the region to the kill-ring, and you said you don't ever want that. This change forces the region to always be deleted.
Now, you don't need to actually modify the source, just place that function definition after the (require 'delsel) in your .emacs (or after the (delete-selection-mode)).
As a vim convert, I've gotten fairly used to viper mode. One issue that I've discovered, however, is that viper-auto-indent breaks all inferior modes. What happens is when I enter any sort of inferior mode (sql-mode, ess-mode, etc.) and hit Enter, the Enter key doesn't actually send the command off to the inferior process and gives the appearance of the process just hanging.
Without setting viper-auto-indent I have the problem that the Enter key doesn't automatically indent when writing code, meaning that I need to always hit tab after entering a new line, which is annoying. The workaround I've been using is to have viper-auto-indent enabled by default (since I spend most of my time programming), and then disabling it when I enter an inferior-mode buffer.
Does anyone know how to fix this problem? Alternatively, can anyone help supply me with the elisp to disable viper-auto-indent when switching to an interior mode buffer, and enabling it when in a non-inferior mode buffer? Thanks.
I think Emacs' intent is to have you use "C-j" for newline-and-indent, and let Enter be left alone.
If that is not yet acceptable to you, then this untested code may work:
(add-hook 'inferior-ess-mode-hook
'(lambda () (set (make-local-variable 'viper-auto-indent) nil))
I'm not able to reproduce your problem. I tried every level of viper-mode (1-5), and a number of inferior processes. That said, from your actual question, this code appears like it should fit the bill. If/when 'viper-autoindent is called, if the current buffer has a process, it calls the original binding for the keys just pressed. If there's no process, the original viper-autoindent is called.
(defadvice viper-autoindent (around viper-autoindent-but-not-when-buffer-has-process activate)
"work around reported user problem"
(if (and (this-command-keys)
(get-buffer-process (current-buffer)))
(let* ((viper-mode nil)
(thiskey (key-binding (this-command-keys))))
(when thiskey
(call-interactively thiskey)))
ad-do-it))