2

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!

Antti Haapala -- Слава Україні
  • 129,958
  • 22
  • 279
  • 321
robru
  • 2,313
  • 2
  • 29
  • 38
  • It seems like `term` behaves slightly better than `ansi-term` but it's not clear to me what the differences are between these two. – robru Sep 08 '12 at 03:17

3 Answers3

3

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))
robru
  • 2,313
  • 2
  • 29
  • 38
  • I don't know if fringe-mode is a global mode or a buffer-local one, but if it is buffer-local you can probably enable it only in term buffers. – Ryan C. Thompson Sep 09 '12 at 22:06
1

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.

Ryan C. Thompson
  • 40,856
  • 28
  • 97
  • 159
  • I've been fiddling with this some more, changing various emacs settings, and what it actually seems like is that inside a `term`, any command that outputs lines longer than the width of the terminal will cause this problem. That's why `apt-get` would only do it intermittently, because it's line lengths are inconsistent between sessions, depending on how fast the internet can download what it's downloading. I found a text file where `cat foo.txt` causes this issue 100% reliably, but only if the terminal buffer is narrower than it's longest line. make it wider and it's fine. Any ideas? – robru Sep 08 '12 at 18:31
  • More fiddling, it seems like the specific combination of setting `truncate-lines` to nil, `truncate-partial-width-windows` to nil, and `word-wrap` to t seems to stop the garbling issue, giving me a workable shell, however it causes goofy-looking wrapping where the shell and emacs can't seem to agree how to wrap. Eg, a very long line will show emacs wrapping on the word boundary, but then the terminal wraps again partway through the word, and then the line continues onto a third line below... very odd. – robru Sep 08 '12 at 18:52
  • Yeah, near as I can figure, any terminal output beyond the width of the window will cause this garbling, and `word-wrap` mode just prevents it from happening by forcing wrapping before the lines get too long, even if it is a bit of an ugly solution. Not sure why this is happening. – robru Sep 08 '12 at 19:02
  • After an *exhaustive* line by line audit of my .emacs.el, I've discovered that this issue is triggered by disabling the fringe. All that `word-wrap` stuff was just a red herring. Commenting out the line `'(fringe-mode 0 nil (fringe))` (from inside `custom-set-variables`) has resolved the issue, and allows `cat` to work in my terminal correctly. Now I wonder if it's possible to disable the fringe everywhere but the terminal... – robru Sep 08 '12 at 20:21
  • Hah, ok. I've given you some upvotes for being the only responder. Thanks for trying! – robru Sep 09 '12 at 18:03
0

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250