Subject: Strange Gnome-terminal behaviour

From: Mark Fletcher <[email-masked]>
Date: Sat, 24 Sep 2016 17:02:36 +0900

Has anyone else noticed strange behaviour around scrolling in Gnome
Terminal starting (fairly) recently in Jessie?

I am using a long-standing Jessie install which is by no means a new
install, but started life I think as etch and has been upgraded
repeatedly. I use, as I assume is obvious, Gnome. The hardware is a
self-built circa 2009 Intel Core i7 920-based PC with 24GB RAM and 2x
1TB SSDs (they were HDDs, but with this list's help I upgraded them
earlier this year).

Recently, Gnome terminal's scrolling behaviour has gone strange. If I am
looking at a man page, or scrolling through a long text file with less
etc, or even just scrolling back through terminal history using
Shift-PgUp and Shift-PgDn, it sometimes gets "stuck" and doesn't scroll.
Then if I repeat the keystroke to scroll, it does it twice, skipping a
screenful. This is particularly annoying for example in Mutt, where
scrolling too far down a message causes Mutt to move to the next
message. I end up missing the end of the message and have to go back a
message to read it -- and then of course Mutt takes me back to the START
of the previous message, so I have to scroll down again, and guess what,
sod's law, it gets stuck in the same place... Picture the scene as I get
steadily more irritated... 

I have the impression that throwing in enough extra keystrokes
eventually "wakes it up" (eg scroll-up, scroll-down, scroll-up,
scroll-down), and that if I wait long enough (about a minute or so) it
eventually reacts to the "missing" keystroke. But I have not been able
to verify this in a satisfyingly scientific way, so it could just be
superstition. 

I have noticed this behaviour now and then for a while, but it seems to
have got noticeably worse in the last 2-3 days. I did a Jessie update
earlier today, the first in about 2 weeks, which updated 86 packages or
so -- the problem existed both before and after the update.

I have also noticed that the next keystroke that isn't a scrolling
command usually "wakes it up" as well, and it has obeyed the scrolling
command, just hasn't updated the window to show that. For example, in
vi, I open a large text file (large just means "bigger than the window")
and use G to scroll to the bottom. Sometimes the screen updates,
sometimes it doesn't. Then I hit i to insert text. If the screen hadn't
updated, NOW it does, and indeed I am at the bottom of the file and
inserting where I want to. But the screen didn't show me that at first
when it should have.

I suppose I should try a different terminal and see if that makes a
difference, I haven't tried that yet, any recommendations for a good
one?

Other apps are completely responsive and normal eg LibreOffice, IntelliJ
IDEA, Evolution. The machine gives no sign of being in any other form of
distress. Load is normal (hovering around 1.0 when I am running both my
Windows VMs, close to 0 when not -- problem in terminal is evidenced
both when VMs are running and when they are not).

Not sure where I should be looking for the source of the problem.
Keyboard is completely normal in other apps. (it is a Japanese keyboard,
in a British English language environment, in case that matters. That is
what I have been using all along).

Anyone else seeing similar symptoms?

Mark

---

From: Dutch Ingraham <[email-masked]>
Date: Sat, 24 Sep 2016 03:28:41 -0500

> steadily more irritated... 

I can't address the emulator's scrolling behavior in general, but in
specific to mutt, you can add:

set pager_stop = yes

to your .muttrc and that will stop the automatic flip to the next
message.  A nice work-a-round until the emulator issue is resolved,
anyway.

---

From: Mark Fletcher <[email-masked]>
Date: Sat, 24 Sep 2016 23:00:33 +0900

> message.  A nice work-a-round until the emulator issue is resolved,
Thanks for that, that will help in the meantime. But the general 
scrolling problems in the terminal history, in vi, in less etc are still 
driving me nuts!

Mark

---

From: Dutch Ingraham <[email-masked]>
Date: Sat, 24 Sep 2016 09:20:20 -0500

> scrolling problems in the terminal history, in vi, in less etc are still 

Have you tried backing out of X to a console and observing the behaviour
there?

---

From: Mark Fletcher <[email-masked]>
Date: Sat, 24 Sep 2016 23:29:00 +0900

> Have you tried backing out of X to a console and observing the behaviour

I hadn't, but I just tried it now and, like all applications except 
Gnome terminal, it works perfectly, with no problems, exactly as I would 
expect.

Mark

---

From: Joe <[email-masked]>
Date: Sat, 24 Sep 2016 17:37:14 +0100

On Sat, 24 Sep 2016 23:29:00 +0900
Mark Fletcher <[email-masked]> wrote:

> > Have you tried backing out of X to a console and observing the
> > behaviour there?
> >   
> 
> Gnome terminal, it works perfectly, with no problems, exactly as I
> would expect.
> 

Anything in /var/log/syslog when it happens? In sid, GTK is spraying
out GtkScrollBar errors...

-- 
Joe

---

From: Mark Fletcher <[email-masked]>
Date: Mon, 26 Sep 2016 00:05:44 +0900

> > > > On Sat, Sep 24, 2016 at 03:28:41AM -0500, Dutch Ingraham wrote:  

Also I just ran mutt in an X terminal instead by invoking xterm from 
Gnome-Terminal, and although the font is horrible and the window is too 
small, it does NOT display the same psychotic intermittent scrolling 
behaviour. So the problem really does seem to be confined to Gnome 
Terminal. And, it is worse than it was a few days ago -- in the last 
week or so I have been doing a lot of shell scripting work and would 
probably have broken my keyboard over my knee if I had been having the 
problems all week I've been having in the last few days... Which is 
really weird when I think about it because this is Jessie and yesterday 
was the first time I had applied any updates in 2 weeks... And I was 
seeing the problem before the update...

That suggests hardware, but the fact that no other application is 
affected suggests not... Confused.

Mark

---

From: Mark Fletcher <[email-masked]>
Date: Sun, 25 Sep 2016 23:25:36 +0900

> out GtkScrollBar errors...

I just scrolled around in Mutt, exercising the issue, for a few minutes 
while another terminal was running sudo tail -f /var/log/syslog and yet 
another was running sudo journalctl -f, and silence from both of them 
while doing the test. The only thing close was this, but it was already 
in the log when I started the test, so is probably caused by something 
else:

Sep 25 22:39:27 kazuki gnome-session[2374]: 
(gnome-settings-daemon:2482): GLib-CRITICAL **: Source ID 1714 was not 
found when attempting to remove it

Apart from that, nothing that looks likely connected and nothing at all 
while I was observing the issue in Mutt in one Gnome terminal while 
watching these logs in two others.

I have noticed since my first post that, if I wait long enough (at least 
several seconds, sometimes almost a minute) the scrolling keystroke IS 
eventually responded to. As I said before, the machine is not under load 
that is in any way abnormal -- 2 Windows 7 VMs that aren't doing 
anything if I am using a terminal because they are on other Gnome pages, 
a bunch of terminals open, and maybe a program or two more open. But the 
box is a chunky machine and all other apps are functioning completely 
normally. I am only seeing this behaviour in Gnome Terminal.

I'd be suspecting my keyboard needs fresh batteries (ASUS Bluetooth 
keyboard) if it weren't for the fact that normal typing is completely 
fine and all other apps are fine anyway. 

Mark