When I hit Space on doom emacs it shows only two suggestions:
How to fix missing keys?
Related
This is probably a very obvious question, but I seem to have missed something. When I first started using emacs about a month ago, pressing C-v would scroll down and leave two line at the top of the screen, à la tutorial. Somewhere along the line I must have upgraded packages, and it now places the cursor at the top of the screen - no context lines.
Running C-u -2 C-v works as expected, so I tried M-x set-variable RET next-screen-context-lines RET 2, which had absolutely no effect. According to C-h v RET next-screen-context-lines, I can set the variable to any positive or negative number I choose, but pressing C-v always results in the cursor moving to the top of the screen and now context lines. Incidentally, M-v has the same problem. I can't find a relevant setting in my .emacs, but I tried mv .emacs .emacs.bak and noticed no difference.
I'm running GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.22) of 2013-12-22 on binet, modified by Debian according to C-h C-a
Other than that, emacs is an amazing program I wish I'd used before, and which has now all but replaced libreoffice for me (with the help of RST). Now to learn to touch type...
Many thanks in advance for your time.
[EDIT]: I was wrong, the point moves as well and I hadn't noticed (see below). The variables suggested below are useful, however.
Check your value of user option scroll-margin: C-h v RET scroll-margin RET. The default value is 0. Try setting it to 2.
There are also other scrolling-related options whose values you can check. Try M-x apropos-option RET ^scroll RET. (Ignore any hits for scroll-bar.)
I am using Emacs 24.1 on windows XP/7.
TAB/RET key works for auto-completing in elisp mode,
scratch and even ESS mode.
When I write tex file using Auctex, hitting TAB key
jumps to the next line and doesn't auto-complete the
input. C-i could auto-complete the input in Auctex.
but it takes two keys. Any suggestions to solve this?
I'm currently rebinding almost all of my Emacs bindings to fit my new keyboard layout, bépo, a french equivalent of dvorak.
I'm having trouble mapping my ^ key. The ^ key is a dead key but not at a material level.
I'd like to be able to to map C-^ but currently, it don't work. Because "dead-circumflex" and "circumflex" are two different keys.
If I do:
(global-set-key "C-^" 'next-line)
Then, pressing control key with "^" key does the following:
<C-dead-circumflex> is undefined
We have the proof emacs see the dead-circumflex. But I still can't manage to map it.
I know that I can do
(global-set-key "^" 'next-line)
, and that it will work by pressing ^ twice, but it's not the workaround I'm searching for.
I just had the same annoying error, but only when using the emacs GUI, not from the terminal.
The problem with the proposed solution is that ^ isn't the only character not working. For me it was at least ` and ' as well.
From this thread: https://bugzilla.redhat.com/show_bug.cgi?id=918740 I found that changing XMODIFIERS from "#im=ibus" to "" solved the issue. While searching where XMODIFIERS where set I stubled across the following issue: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1125944
It turns out that by removing ~/.config/ibus/bus which solves that issue also solves the issue in emacs with dead keys
rm -rf ~/.config/ibus/bus
The error message tells you what name Emacs uses for the key. You can pass that string to the kbd function to bind it.
(global-set-key (kbd "<C-dead-circumflex>") 'next-line)
Add the following to your ~/.emacs:
(require 'iso-transl)
This takes care of the problem with undefined dead keys.
Is there anything I can add to my .emacs file to keep emacs from adding new lines when I scroll past the end of the buffer with my mouse or the scrollbar? I already have
(setq next-line-add-newlines nil)
but that seems to only be applying to when I am moving with the keyboard. I've done quite a few searches on the subject to no avail.
Any tips are greatly appreciated! Thank you.
Check the value of the the variable next-line-add-newlines in the buffers/modes that it's misbehaving. You can do so by: C-h v next-line-add-newlines (or M-x describe-variable).
It could be something in the major/minor mode that's enabling it.
Have you checked whether this also happens in standard emacs (i.e. have you tested this behaviour when running emacs with --no-init-file) ?
If it doesn't, then the cause for this problem has to lie somewhere in your dotfiles.
I load GNU emacs in it's own window by typing emacs in the terminal.
I like to use the keybindings from pc-selection-mode, which allows you to highlight characters using shift-right or shift-left, or entire lines by pressing shift-up or shift-down.
The problem is that when I run emacs in the terminal by typing emacs -nw, the latter 2 keybindings don't work. I can highlight characters using shift-left and shift-right, but pressing shift-up and shift-down doesn't do anything. The cursor stays where it is.
How do I fix this problem? Why is it even occurring? I'm using GNU Emacs 23.1.1, and I've confirmed that the same version is being used both when emacs is in it's own window and when emacs is running inside the terminal.
Thanks for any help
A lot of times the bindings just aren't listed, or are mapped wrong. You can try M-x show-lossage (or C-h l) to see if the escape sequences reach emacs or not. If they do, you might want to try xterm-extras -- it's always worked even as I migrate between different versions of linux and solaris, and as I ssh between them (which is often a source of problems).