When I am writing code in nano, the cursor bugs after some time. The cursor moves further to the right than the actual position. This makes it really difficult to debug when writing long lines.
By the way, I am using zsh on a mac, but I had the same problem with bash. It is also not specific for any programming language or file type, but happens always when I use nano.
Here are two images to illustrate the problem:
According to the cursor, hitting del should delete d, but it actually deletes n. However, when I go at the beginning of the line:
hitting del correctly deletes u.
Can anyone help me out here?
I've been using Vim for a long time an unfortunately I've got very used to using <S-Space> to exit insert mode. Old habits die hard.
It seems when I put
imap <S-Space> <Esc>
in my .xvimrc it ignores the Shift part as interprets it as just Space. I think some time ago I read somewhere that that's an issue with OSX (they just didn't think anybody will ever need to type a 'capital space').
The way I solved that with Vim in iTerm2 is just map a character I'll never use (✠) to <S-Space> in iTerm2 and then use that in my .vimrc.
Any idea how I can make <S-Space> work in XVim?
Never having thought about it, I just found out that I am used to Shift-Space doing the same thing as Space. But now it doesn't any more: my typing started looking like this a couple of days ago:
a[x +1]= b
where I wanted to write
a[x + 1] = b
I suppose I let go of Shift too slowly. It never used to be a problem, until I installed Yosemite, and now Shift-Space does not register at all any more. I tried :imap <S-Space> <Space>, but that too does not trigger.
It does not happen in Terminal Vim, nor does it happen in any other application I own.
EDIT: I am on a Japanese keyboard, using Kotoeri (Apple's Japanese IME).
This seems to be an incompatibility introduced in Yosemite's Kotoeri (Japanese IME). For the time being, switching to Google Japanese IME as an alternative (or not using Japanese input in the first place, if that is an option) circumvents the issue. See this discussion for details.
When setting my text-scale-mode-amount to -2 i.e C-xC--C-- and using follow-mode alongside I get this annoying large amounts(20 lines) of text spillover in the next buffer which almost defeats the main purpose of using follow-mode. The spillover increases when the text-scale-mode-amount is further decreased(further decreasing the size of the text).
Any solutions to this?
Update 1:
Just tested this on my Emacs running on Ubuntu(Linux) and nothing of that sort happens. No spillovers. Its the Windows Emacs that is causing the problem.
Update 2:
Its a bug that is occurring in GNU Emacs 24.2.1 (i386-mingw-nt6.1.7600) of 2012-08-29 on MARVIN and seems to have been fixed in Emacs 24.3 since I am not facing the problem after upgrading to it. Therefore this question is specific to the above mentioned version of Emacs and others facing the same.
Simple solution:
Like phils suggested, upgrade the Emacs.
Not so simple solution:
Replace Emacs_installation_dir/lisp/follow.el with this and delete follow.elc in the same directory. Or force Emacs to use the above package instead of the built-in one(overriding it).
I think it's a bug in follow-mode which doesn't really pay attention to the actual text displayed. I'd recommend a report-emacs-bug to get a bug-number for that issue.
Relative Emacs newbie here, just trying to adapt my programming workflow to fit with emacs. So far I've discovered shell-pop and I'm quite enjoying on-demand terminals that pop up when needed for banging out the odd commands.
What I understand so far about Emacs is that shell is a "dumb" terminal that doesn't support any ansi control codes, and that makes it incompatible with things like ncurses that attempt to draw complex UI's on a terminal emulator. This is why you can't use less or top or similar in shell-mode.
However, I seem to be having trouble with ansi-term, it's not the be-all, end-all that it's cracked up to be. Sure, it has no problems running less or git log or even nano, but there are a few things that can't quite seem to display properly when they're running in an ansi-term, such as apt-get and nosetests. I'm not sure quite what the name is for it, but apt-get's output is characterised by live-updating what is displayed on the very last line, and then having unchanging lines of text scroll out above that line. It seems to be halfway between something like less and something dumber, like cat. Somehow ansi-term doesn't like this at all, and I get very garbled output, where it seems to output everything on one line only or just generally lose it's place and output things all over, randomly. In the case of nosetests, it starts off ok, but if any libraries spew out any STDERR, the output all goes to hell in a similar way.
With some fiddling it seems possible to fix this by mashing C-l and RET, but it's not always reliable.
Does anybody know what's going on here? Is there some way to fix ansi-term so that it can display everything properly? Or is there perhaps some other mode that I don't know about that is way better? Ideally I'd like something that "just works" as effortlessly as, eg, Gnome Terminal, which can run all of the above mentioned programs without a single hiccup.
Thanks!
I resolved this issue by commenting out my entire .emacs.el and then uncommenting and restarting emacs for every single line in the file. I discovered that the following line alone was responsible for the issue:
'(fringe-mode 0 nil (fringe))
(this line disables the fringes from inside custom-set-variables).
I guess this is a bug in Emacs, that disabling the fringe causes term-mode to garble it's output really badly whenever any output line exceeds $COLUMN columns.
Anyway, I don't really like the fringes much at all, and it seems I was able to at least disable the left fringe without triggering this issue:
(set-fringe-mode (cons 0 8))
Maybe apt-get does different things based on the $TERM environment variable. What happens if you set TERM=dumb? If that makes things work, then you can experiment with different values until you find one that supports enough features but still works.
Note that git 2.0.1 (June 25th, 2014) now better detects dumb terminal when displaying verbose messages.
That might help Emacs better display some of the messages received from git, but the fringe-mode bug reported above is certainly the main cause.
See commit 38de156 by Michael Naumov (mnaoumov)
sideband.c: do not use ANSI control sequence on non-terminal
Diagnostic messages received on the sideband #2 from the server side are sent to the standard error with ANSI terminal control sequence "\033[K" that erases to the end of line appended at the end of each line.
However, some programs (e.g. GitExtensions for Windows) read and interpret and/or show the message without understanding the terminal control sequences, resulting them to be shown to their end users.
To help these programs, squelch the control sequence when the standard error stream is not being sent to a tty.