Re: Strange Gnome-terminal behaviour

[Liam O'Toole]

On 2016-10-07, Mark Fletcher  wrote:
> On Sun, Sep 25, 2016 at 08:52:41PM +0100, Liam O'Toole wrote:
>> On 2016-09-25, Mark Fletcher  wrote:
>> > On Sat, Sep 24, 2016 at 05:37:14PM +0100, Joe wrote:
>> >> On Sat, 24 Sep 2016 23:29:00 +0900
>> >> Mark Fletcher  wrote:
>> >> 
>> >> > On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
>> >> > > On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:  
>> >> > > > 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. 
>> 
>> [...] 
>> 
>> FWIW, you can tell xterm to use freetype fonts, e.g.,
>> 
>>  xterm -fa "Monospace 12"
>> 
>> Alternatively, use the faceName resource in your ~/.Xresources file.
>> 
>
> Monospace 12 doesn't seem to exist on my system. 

"Monospace" is likely to be an alias. Use the command 'fc-match
Monospace' to find out what real font is subsituted.

> In fact I haven't found 
> what fonts I can use -- anything at all I put after xterm -fa results in 
> the same thing -- an entirely usable, if a little bit large, xterm 
> window with standard 80x24, which bahaves perfectly from the point of 
> view of my original post.
>
> As an example I am writing this mail in Mutt on such an xterm launched with :
>
> xterm -fa bollocks

Run 'fc-match bollocks' or 'fc-match "utter bollocks"'. :) In both cases
you'll get the system-wide fallback font, which is DejaVuSans.ttf in my
case.

>
> How can I find what fonts I can actually use and what xterm calls them?

The command fc-list will give you a list of fonts known to fontconfig.
By default, only truetype fonts are considered.

>
> Also I have no .Xresources file, is that normal?

As others have pointed out, yes.

>
> Mark
>
>

-- 

Liam

Re: Strange Gnome-terminal behaviour

[Brian]

On Fri 07 Oct 2016 at 21:47:37 +0900, Mark Fletcher wrote:

> On Sun, Sep 25, 2016 at 08:52:41PM +0100, Liam O'Toole wrote:
> > 
> > FWIW, you can tell xterm to use freetype fonts, e.g.,
> > 
> > xterm -fa "Monospace 12"
> > 
> > Alternatively, use the faceName resource in your ~/.Xresources file.
> 
> Monospace 12 doesn't seem to exist on my system. In fact I haven't found 
> what fonts I can use -- anything at all I put after xterm -fa results in 
> the same thing -- an entirely usable, if a little bit large, xterm 
> window with standard 80x24, which bahaves perfectly from the point of 
> view of my original post.

'xterm -fa "Monospace 12' might be better as

  xterm -fa "Monospace" -fs 12
 
> As an example I am writing this mail in Mutt on such an xterm launched with :
> 
> xterm -fa bollocks
> 
> How can I find what fonts I can actually use and what xterm calls them?

Any TrueType font. Examples:

  xterm -fa "freesans" -fs 16
  xterm -fa "droidsansmono" -fs 16
  xterm -fa "dejavuserifcondensed" -fs 16

See /usr/share/fonts for what you have.

> Also I have no .Xresources file, is that normal?

Perfectly normal. You have to create and populate it. Correctly done you
can be confident it will work.

-- 
Brian.

Re: Strange Gnome-terminal behaviour

[Greg Wooledge]

On Fri, Oct 07, 2016 at 09:47:37PM +0900, Mark Fletcher wrote:
> Also I have no .Xresources file, is that normal?

wooledg@wooledg:~$ ls -a /etc/skel
.  ..  .bash_logout  .bashrc  .profile

Yup.  Normal.  But the good news is, it looks like you *can* make one
and expect it to be used by the Debian X session:

wooledg@wooledg:~$ grep -r Xresources /etc/X11
/etc/X11/Xsession:SYSRESOURCES=/etc/X11/Xresources
/etc/X11/Xsession:USRRESOURCES=$HOME/.Xresources

At least, that's how it seems at first glance.  You'd have to tear apart
the shell scripts to be absolutely sure.  Or, y'know, make one and login
and see what happens.

Re: Strange Gnome-terminal behaviour

[Mark Fletcher]

On Sun, Sep 25, 2016 at 08:52:41PM +0100, Liam O'Toole wrote:
> On 2016-09-25, Mark Fletcher  wrote:
> > On Sat, Sep 24, 2016 at 05:37:14PM +0100, Joe wrote:
> >> On Sat, 24 Sep 2016 23:29:00 +0900
> >> Mark Fletcher  wrote:
> >> 
> >> > On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
> >> > > On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:  
> >> > > > 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. 
> 
> [...] 
> 
> FWIW, you can tell xterm to use freetype fonts, e.g.,
> 
>   xterm -fa "Monospace 12"
> 
> Alternatively, use the faceName resource in your ~/.Xresources file.
> 

Monospace 12 doesn't seem to exist on my system. In fact I haven't found 
what fonts I can use -- anything at all I put after xterm -fa results in 
the same thing -- an entirely usable, if a little bit large, xterm 
window with standard 80x24, which bahaves perfectly from the point of 
view of my original post.

As an example I am writing this mail in Mutt on such an xterm launched with :

xterm -fa bollocks

How can I find what fonts I can actually use and what xterm calls them?

Also I have no .Xresources file, is that normal?

Mark

Re: Strange Gnome-terminal behaviour

[Michael Biebl]

Am 24.09.2016 um 10:02 schrieb Mark Fletcher:
> 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).

Maybe create a fresh test user account and see if you can reproduce the
problem there. If not, this would suggest that it has something to do
with your current user configuration.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Strange Gnome-terminal behaviour

[Liam O'Toole]

On 2016-09-25, Mark Fletcher  wrote:
> On Sat, Sep 24, 2016 at 05:37:14PM +0100, Joe wrote:
>> On Sat, 24 Sep 2016 23:29:00 +0900
>> Mark Fletcher  wrote:
>> 
>> > On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
>> > > On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:  
>> > > > 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. 

[...] 

FWIW, you can tell xterm to use freetype fonts, e.g.,

xterm -fa "Monospace 12"

Alternatively, use the faceName resource in your ~/.Xresources file.

-- 

Liam

Re: Strange Gnome-terminal behaviour

[Dutch Ingraham]

On Mon, Sep 26, 2016 at 12:05:44AM +0900, Mark Fletcher 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.

I don't use gnome terminal, but for lack of anyone throwing anything else 
against 
the wall, the next two things I would try are:

1. If there is an application cache, clear it; and
2. If the application uses profiles of any kind, try a new, blank one.  

Related to those, you could create a new regular user, and log in as him/her, 
which
should give a "blank slate" to test from.  Lastly, purge the application and all
config files and re-install (or just install Terminator or some such
replacement).

Re: Strange Gnome-terminal behaviour

[Mark Fletcher]

On Sat, Sep 24, 2016 at 05:37:14PM +0100, Joe wrote:
> On Sat, 24 Sep 2016 23:29:00 +0900
> Mark Fletcher  wrote:
> 
> > On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
> > > On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:  
> > > > 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

Re: Strange Gnome-terminal behaviour

[Mark Fletcher]

On Sat, Sep 24, 2016 at 05:37:14PM +0100, Joe wrote:
> On Sat, 24 Sep 2016 23:29:00 +0900
> Mark Fletcher  wrote:
> 
> > On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
> > 
> 
> Anything in /var/log/syslog when it happens? In sid, GTK is spraying
> 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

Re: Strange Gnome-terminal behaviour

[Joe]

On Sat, 24 Sep 2016 23:29:00 +0900
Mark Fletcher  wrote:

> On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
> > On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:  
> > > On Sat, Sep 24, 2016 at 03:28:41AM -0500, Dutch Ingraham wrote:  
> > > >   
> > 
> > Have you tried backing out of X to a console and observing the
> > behaviour there?
> >   
> 
> 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.
> 

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

-- 
Joe

Re: Strange Gnome-terminal behaviour

[Mark Fletcher]

On Sat, Sep 24, 2016 at 09:20:20AM -0500, Dutch Ingraham wrote:
> On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:
> > On Sat, Sep 24, 2016 at 03:28:41AM -0500, Dutch Ingraham wrote:
> > > 
> 
> Have you tried backing out of X to a console and observing the behaviour
> there?
> 

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

Re: Strange Gnome-terminal behaviour

[Dutch Ingraham]

On Sat, Sep 24, 2016 at 11:00:33PM +0900, Mark Fletcher wrote:
> On Sat, Sep 24, 2016 at 03:28:41AM -0500, Dutch Ingraham wrote:
> > 
> > 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.
> > 
> 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!

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

Re: Strange Gnome-terminal behaviour

[Mark Fletcher]

On Sat, Sep 24, 2016 at 03:28:41AM -0500, Dutch Ingraham wrote:
> 
> 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.
> 
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

Re: Strange Gnome-terminal behaviour

[Dutch Ingraham]

On Sat, Sep 24, 2016 at 05:02:36PM +0900, Mark Fletcher wrote:
> 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 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.

Strange Gnome-terminal behaviour

[Mark Fletcher]

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