I've been using a copy of emacs (in a Debian VM I ssh to with putty) at work for a couple of months now, and up until now everything has been working brilliantly... but this morning I'm trying to edit a file in shell-script-mode, and am seeing some weird behavior with text around the cursor.
Basically, when I type the following ( [ ] represents my cursor):
export DATABASE[]
After I've typed the first few characters of the variable name the export statement disappears and the variable name aligns to the left margin, and all I end up seeing is (with the cursor out in the wilderness):
DATABASE []
If I then hit CTRL-L, the screen refreshes, and I see the text as it should be displayed... until I start typing, and then the buffer start acting strangly again (characters disappearing, moving, cursor ending up in the wrong place, etc)
I've not, to my knowledge, added anything to my .emacs file since this last worked as I expect it to, so I'm at a loss as to what could be happening here. It doesn't seem specific to sh-mode either - I've tested a few other file types and observed similar strange behavior. Are there any emacs afficianados out there who might be able to point me in the right direction to figure out what's wrong here?
Thanks in advance
I'm not sure what to suggest, but this sounds awfully like an issue with the terminal: I suspect that Emacs redraws the current line whenever it changes and I guess it tries to do so incrementally. If something's got out of whack with your terminal, then it seems quite plausible that the current word would get written at the start of the line (all Emacs sent) and your cursor would get abandoned "out in the wilderness" :-)
Obviously, this is a new change. Since it doesn't sound like the sort of issue that would be caused by Elisp configurations in your .emacs, you should check whether you've recently upgraded one of
PuTTY
Emacs version
SSH version (unlikely...)
Then maybe the relevant tool will have something in the changelog (which maybe you can disable via a config?)
One thing you could check: you say this isn't just SH-mode. Is it "any mode with syntax highlighting"? Maybe Emacs just sends over the wire the text with the current colour?
I had a similar problem of disappearing text using PuTTY / Emacs / Remote AWS Ubuntu when running ABCL LISP in a shell window.
The solution was: I had changed my foreground and background font colors (essentially reversed) in PuTTY but had neglected to change the bold fonts, so they were disappearing into the background.
Related
I am using Eclipse and I am coding java. I really like the "Smart Caret" option for the Home and End buttons since it allows you to go the start and end of a line but not past any whitespaces. Also the Home key will take you to the start of a comment, rather than the start of the line. And you can cycle through different positions with these keys. And this is how the editor was by default, from installation.
However one thing that has happened a few times now is that when I am writing code in the editor, this functionality just vanishes. It is seemingly random when it happens and the weirdest part, I think, is that it is file specific. So all of a sudden when I am writing, the Home and End keys start taking me to the very start and end of the line I am on. It is as if I am accidentally pressing some hotkey to disable these Smart Carets for the specific file.
It does not help to disable and re-enable the Smart Caret option in Preferences. And beyond that I do not really know what to do. Is this a bug? It is incredibly annoying when it happens. Being used to things working one way, then having them spontaneously change and then again having them back to the default when I am editing a different file.
Frequently when debugging backtraces pop up in Emacs, the minibuffer stops working properly. Specifically, anything I try typing in it 'types backward'. See the following screenshot (I was trying to type 'haskell' in the minibuffer):
When I quit out of the debug pane, the minibuffer starts typing normally again.
What's causing this? Any suggestions on how I can make it stop?
As nmichaels says, this is possibly related to the bidi-display-reordering setting (which is true by default, see: https://www.gnu.org/software/emacs/manual/html_node/emacs/Bidirectional-Editing.html
Could it be that the abbrev-insert or any other part of your code inserts one of the Unicode characters that change the direction of your text?
The root cause of this is that something makes it so that after inserting a character, Emacs moves point back to before that character. Why? I'm not completely sure, but I have a hunch:
Emacs is very smart, so it probably noticed you're coding in a pure language and figures you probably don't want to change "point" with those nasty side effects, so it resets it back to its initial value for you.
I am using GDB with emacs and sometimes use GDB with DDD.
Starting version 22 (???) Emacs provides a tool-bar-mode, where you can do
the most important commands like run, next, step, up/down of stack frames in the emacs UI.
As such , I have moved away from DDD, since anyways I run most commands through command line and the sometime through the limited UI given in the tool-bar-mode.
However, the ability to hover your mouse over a variable and make the value to pop-up still seems to be missing. Does anyone know about some mode in emacs or some .el file that would allow Emacs to do the same.
This kinda goes against emacs not being a gui-ide. I can still use watchpoints/local variable buffer; but I really would like the ability to hover my mouse over some variable and see the value. Any help would be much appreciated.
gud-tooltip-mode is supposed to give you just that, I think.
I'm wondering if I'm the only one struggling (i.e. failing) to keep the emacs key bindings working in Eclipse.
I set them. It works fine. The it stops working fine. Some keys still work, others don't. I find myself in a kind of weird quantum state of uncertain key-binding setup superposition. Some key bindings from the standard set work, some from the emacs set work, some things I can achieve with neither set of bindings.
I'm the only one to experience this? I've seen this on at least 4 computers in the past few months.
I set key bindings back to standard set. Sometimes it works. I use the reset to defaults button. Try to set it back to emacs. Doesn't work. Pressing the apply button between the different steps or not... Drives me crazy.
On some computers, the bindings are just whatever. Can only save using the mouse, C-d and C-k don't work to delete/cut lines, most emacs keys still work but back to C-space for auto-completion, etc.
Anyone knows what can cause this? How to prevent it? Am I pressing some key binding key-bindings by mistake?
I had a similar problem with the Ctl-K, Ctl-D commands: after doing an upgrade (I forget whether it was Eclipse itself or the Android plugin) I saw Eclipse offering a little pop up menu on both these keys, offering to do either the correct Emacs command or some completely unrelated command. So, for example, Ctl-D offered to either delete the next character (correct) or delete the line (incorrect).
After some poking around in the key bindings (Windows>Preferences>General>Keys), I discovered that sure enough, someons in the Eclipse project supplied these wrong bindings in addition to the correct ones. So I deleted the incorrect bindings and left the correct ones.
So I thought I would be out of the woods at this point. But I also discovered that I had to add the correct binding back in a couple of times before it would stick.
Look for Cut to End of Line under the Command column and make sure it has Ctl-K when Editing Text and in the Text Editing Category. The same for Delete Next (which means next character). But make sure Ctl-D does NOT show up for the Delete Line Command.
Test it out in an editor window; if it fails, go edit the bindings again, test again, repeat until it sticks, making sure you click Apply after editing the bindings.
I would like to attach screen or tmux inside emacs, in shell mode. I often find myself running emacs with inferior processes inside screen on remote servers; it would be nice if I could shift the workflow to local emacs + TRAMP; ability to reattach persistent sessions is a must, however. (Such workflow is particularly useful for analysis in R [1])
Shell-mode is rather desirable because I keep encountering miscellaneous glitches and even crashes when using the combination of M-x term or M-x ansi-term + screen + R. However, I can't seem to get rid of ansi colored rendered as escape codes in screen when run under M-x shell. When I use ansi-color-for-comint-mode-on, they are fine -- but as soon as screen comes on, it becomes a horrible mess.
Has anyone figured out the set of conditions for proper interpretation of ansi color with shell + screen or tmux? What about getting rid of color altogether?.. Are there any other alternatives in terms of running persistent remote processes and attaching them to local emacs?..
[1] http://blog.nguyenvq.com/2010/07/11/using-r-ess-remote-with-screen-in-emacs/
As far as I can tell, Screen requires features of your terminal that Emacs' shell mode simply does not and cannot provide, simply because it is not a traditional character terminal like VT100. So the issue is not about getting rid of or trying to interpret color codes -- there are more terminal capabilities that Screen requires to function correctly.
By default Screen does not even start in Emacs' shell mode, as far as I can tell (it errors out saying it needs clear screen capability). Some posts around the web seem to suggest setting TERM=xterm to work around this, but it is just fooling Screen into thinking the terminal has the capabilities of XTerm, which it doesn't have.
The term and ansi-term modes of Emacs would provide the terminal capabilities required by Screen, but unfortunately you seem to have had troubles with those modes.
What I would suggest instead would be to have a look at the "emacsclient -t" command (part of Emacs), which allows you to open a local frame connected to an existing Emacs instance in a similar way as Screen allows you to reconnect to a previously created Screen instance. That way you could perhaps configure a emacsclient on you local computer to reconnect over TCP to a persistent remote Emacs instance.
I don't use screen, but maybe you can fix this from your .bashrc. I've got a bunch of conditional code in there, turning color on for xterm windows, but leaving it off for other terminals that don't support it. M-x shell sets the TERM variable to dumb, so you can test for that and set the color accordingly.
case "$TERM" in
dumb)
## non-color settings here
;;
xterm)
## color settings here
;;
*)
## default (maybe you want non-color here?)
;;
esac