Discussion:
Hardware cursor and console colours resetting when starting mutt
David Woodfall
2018-09-28 21:26:31 UTC
Permalink
Hi

In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.

Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?

In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.

The cursor code I use is:

printf '\e[?3c'

Any ideas?

--
Dave

In Ohio, if you ignore an orator on Decoration day to such an extent as
to publicly play croquet or pitch horseshoes within one mile of the
speaker's stand, you can be fined $25.00.

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Patrick Shanahan
2018-09-28 21:44:22 UTC
Permalink
Post by David Woodfall
Hi
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.

you have pretty well removed mutt from the equasion using "-F /dev/null".
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Registered Linux User #207535 @ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
David Woodfall
2018-09-28 22:06:41 UTC
Permalink
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
Hi
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.

--
Dave

You should tip the waiter $10, minus $2 if he tells you his name,
another $2 if he claims it will be His Pleasure to serve you and
another $2 for each "special" he describes involving confusing terms
such as "shallots," and $4 if the menu contains the word "fixin's." In
many restaurants, this means the waiter will actually owe you money.
If you are traveling with a child aged six months to three years, you
should leave an additional amount equal to twice the bill to compensate
for the fact that they will have to take the banquette out and burn it
because the cracks are wedged solid with gobbets made of partially
chewed former restaurant rolls saturated with baby spit.

In New York, tip the taxicab driver $40 if he does not mention his
hemorrhoids.
-- Dave Barry, "The Stuff of Etiquette"

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Cameron Simpson
2018-09-29 22:17:11 UTC
Permalink
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's
terminal management is reseting your cursor change.

Conversely, does the behaviour occur if you use screen but don't use mutt (but
_do_ use some other curses programme like vim inside screen)?

Just trying to isolate where the reset is coming from. And I don't have a
convenient linux framebuffer console to test against (though I should set one
up).

When we know where the reset comes from maybe we can devise a workaround.

Cheers,
Cameron Simpson <***@cskk.id.au>
David Woodfall
2018-09-29 22:33:59 UTC
Permalink
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
It's worse without screen:

console: both colours and cursor reset
screen: only cursor resets

Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.

Vim also resets the cursor, but the colours are fine, both in and out
of screen.

Cheers

--
Dave

With a gentleman I try to be a gentleman and a half, and with a fraud I
try to be a fraud and a half.
-- Otto von Bismark

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
David Woodfall
2018-09-29 23:49:40 UTC
Permalink
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
A little more info on other applications: lynx and elinks seem to
work fine too. So far only mutt and vim seem to reset things,
although I can set an autocmd in vim to set the cursor back to mine
when it exits. I guess that is probably beyond the scope of an email
client though.

--
Dave

"He was so narrow minded he could see through a keyhole with both
eyes ..."

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Patrick Shanahan
2018-09-30 02:16:01 UTC
Permalink
Post by David Woodfall
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
A little more info on other applications: lynx and elinks seem to
work fine too. So far only mutt and vim seem to reset things,
although I can set an autocmd in vim to set the cursor back to mine
when it exits. I guess that is probably beyond the scope of an email
client though.
you could alias or script mutt to reset the cursor back when exiting mutt,
similarly to your vim autocmd
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Registered Linux User #207535 @ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
David Woodfall
2018-09-30 02:38:08 UTC
Permalink
On Saturday 29 September 2018 22:16,
Post by Patrick Shanahan
Post by David Woodfall
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
A little more info on other applications: lynx and elinks seem to
work fine too. So far only mutt and vim seem to reset things,
although I can set an autocmd in vim to set the cursor back to mine
when it exits. I guess that is probably beyond the scope of an email
client though.
you could alias or script mutt to reset the cursor back when exiting mutt,
similarly to your vim autocmd
I tend to leave it running though. My new mail command sends a BEL so
that screen picks it up and shows it while I'm working in another
window.

--
Dave

For perfect happiness, remember two things:
(1) Be content with what you've got.
(2) Be sure you've got plenty.

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Patrick Shanahan
2018-09-30 02:53:59 UTC
Permalink
Post by David Woodfall
On Saturday 29 September 2018 22:16,
Post by Patrick Shanahan
Post by David Woodfall
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
A little more info on other applications: lynx and elinks seem to
work fine too. So far only mutt and vim seem to reset things,
although I can set an autocmd in vim to set the cursor back to mine
when it exits. I guess that is probably beyond the scope of an email
client though.
you could alias or script mutt to reset the cursor back when exiting mutt,
similarly to your vim autocmd
I tend to leave it running though. My new mail command sends a BEL so
that screen picks it up and shows it while I'm working in another
window.
and how does that make a difference? it would still correctly set your
cursor when ever you did decide to leave mutt. you did say that the only
remaining problem was the cursor after leaving mutt.
--
(paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
Registered Linux User #207535 @ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
David Woodfall
2018-09-30 03:27:00 UTC
Permalink
On Saturday 29 September 2018 22:53,
Post by Patrick Shanahan
Post by David Woodfall
On Saturday 29 September 2018 22:16,
Post by Patrick Shanahan
Post by David Woodfall
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
A little more info on other applications: lynx and elinks seem to
work fine too. So far only mutt and vim seem to reset things,
although I can set an autocmd in vim to set the cursor back to mine
when it exits. I guess that is probably beyond the scope of an email
client though.
you could alias or script mutt to reset the cursor back when exiting mutt,
similarly to your vim autocmd
I tend to leave it running though. My new mail command sends a BEL so
that screen picks it up and shows it while I'm working in another
window.
and how does that make a difference? it would still correctly set your
cursor when ever you did decide to leave mutt. you did say that the only
remaining problem was the cursor after leaving mutt.
--
http://en.opensuse.org openSUSE Community Member facebook/ptilopteri
As I stated, it happens when mutt starts and it affects everything
else running in screen. If I switch screen windows (i.e. Ctrl-A
Post by Patrick Shanahan
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
Thanks

--
Dave

If there are epigrams, there must be meta-epigrams.

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
David Woodfall
2018-09-30 04:32:39 UTC
Permalink
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
I have found a kind of workaround now:

TERM=xterm-color mutt

However this means that the cursor is visible in menus and such. Not
really a big problem. I'd rather that than have to keep applying my
cursor settings every so often.

--
Dave

Life is like an onion: you peel off layer after layer, then you find
there is nothing in it.

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
David Woodfall
2018-09-30 04:43:49 UTC
Permalink
On Sunday 30 September 2018 05:32,
Post by David Woodfall
On Saturday 29 September 2018 23:33,
Post by David Woodfall
On Sunday 30 September 2018 08:17,
Post by David Woodfall
On Friday 28 September 2018 17:44,
Post by Patrick Shanahan
Post by David Woodfall
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
your chosen terminal is undoubted the cause. I run a tmux session on my
server and attach to it remotely usually via yakuake(konsole) but have not
made any effort to change the cursor.
you have pretty well removed mutt from the equasion using "-F /dev/null".
I'm using the vanilla linux console (i.e. no X and 16 colours) plus screen.
Don't really have a lot of choice.
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
When we know where the reset comes from maybe we can devise a workaround.
Cheers,
console: both colours and cursor reset
screen: only cursor resets
Screen on its own is fine with my cursor and colours. I'm using
screen 99% of the time.
Vim also resets the cursor, but the colours are fine, both in and out
of screen.
TERM=xterm-color mutt
However this means that the cursor is visible in menus and such. Not
really a big problem. I'd rather that than have to keep applying my
cursor settings every so often.
Spoke a bit too soon there. Now mutt doesn't recognise my home, end
and delete keys, probably because of reading a different terminfo I
guess.

I tried entering raw mappings in the config with vim's Ctrl-V method,
but it doesn't see those either. Is there a way around that?

--
Dave

Mathematicians are like Frenchmen: whatever you say to them they
translate into their own language, and forthwith it is something
entirely different.
-- Johann Wolfgang von Goethe

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
David Woodfall
2018-10-01 01:52:16 UTC
Permalink
On Sunday 30 September 2018 08:17,
Does the behaviour persist if you don't use screen? I'm wondering if screen's terminal management is
reseting your cursor change.
Conversely, does the behaviour occur if you use screen but don't use mutt (but _do_ use some other curses
programme like vim inside screen)?
Just trying to isolate where the reset is coming from. And I don't have a convenient linux framebuffer
console to test against (though I should set one up).
I just tried to boot with just a plain VGA console to see if there was any
difference and it automatically created a framebuffer anyway. Maybe that's
normal with recent kernels?

[ +0.177830] fbcon: inteldrmfb (fb0) is primary device
[ +0.074936] Console: switching to colour frame buffer device 200x56
[ +0.024963] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Cheers,
--
Dave

Velilind's Laws of Experimentation:
(1) If reproducibility may be a problem, conduct the test only
once.
(2) If a straight line fit is required, obtain only two data
points.

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Jon LaBadie
2018-09-30 21:19:06 UTC
Permalink
Post by David Woodfall
Hi
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
Programs that use the ncurses library will run initializations
defined in their terminfo entries. According to "man terminfo"
there are 6 or 7, like initialization_string_1 or _2 or _3.

Check your terminfo entry (infocmp) and see if any are defined
that would modify your desired settings.

Jon
--
Jon H. LaBadie ***@jgcomp.com
11226 South Shore Rd. (703) 787-0688 (H)
Reston, VA 20190 (703) 935-6720 (C)
David Woodfall
2018-09-30 22:40:08 UTC
Permalink
On Sunday 30 September 2018 17:19,
Post by Jon LaBadie
Post by David Woodfall
Hi
In the (framebuffer) console I've used the standard escape codes to
set a small 1/3 block cursor to make it more visible, and softened
the colours to not be so stark. They were a bit of a headache
before, and the normal cursor is very hard to see.
Unfortunately, when I start mutt everything resets back to the
defaults. I only see a couple of settings regarding the cursor, but
they don't seem to help. I've tried running with a -F /dev/null so
it doesn't seem to be something in my config. Is there any way of
avoiding this?
In screen it's not so bad, but the cursor resets even just switching
to the window where mutt is running. The colours remain as they were
though.
printf '\e[?3c'
Any ideas?
Programs that use the ncurses library will run initializations
defined in their terminfo entries. According to "man terminfo"
there are 6 or 7, like initialization_string_1 or _2 or _3.
Check your terminfo entry (infocmp) and see if any are defined
that would modify your desired settings.
Jon
--
11226 South Shore Rd. (703) 787-0688 (H)
Reston, VA 20190 (703) 935-6720 (C)
Quite a few differences:

infocmp -i linux

rs1: {RIS}\E]R

infocmp -i screen.linux

is2: {ISO DEC G1}
rs2: {RIS}{DEC-1000}{DEC+25}
smcup: {DEC+1049}
rmcup: {DEC-1049}

infocmp -i screen

is2: {ISO DEC G1}
rs2: {RIS}
smcup: {DEC+1049}
rmcup: {DEC-1049}

infocmp -i xterm-color

is2: {sgr0}{DEC+AWM}{rmir}{DECPNM}{SC}{RSR}{DEC-CKM;COLM;SCLM;OM}{RC}
rs2: {sgr0}{DEC+AWM}{rmir}{DECPNM}{SC}{RSR}{DEC-CKM;COLM;SCLM;OM}{RC}
smcup: {sc}{DEC+47}
rmcup: {ED2}{DEC-47}{rc}

Perhaps I could add terminfo entry in screenrc especially for mutt
that removes the init and reset strings. Not sure if it's possible on
an app-by-app basis though.

Thanks for the clue.

--
Dave

"Acting is an art which consists of keeping the audience from
coughing."

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Cameron Simpson
2018-10-05 22:43:58 UTC
Permalink
Post by David Woodfall
Perhaps I could add terminfo entry in screenrc especially for mutt
that removes the init and reset strings. Not sure if it's possible on
an app-by-app basis though.
You can certainly make customised terminfo entries; I keep a few around myself.
As with termcap, you can make entries based on other entries, so it would be
trivial to make a special one like your console terminfo but with modified init
strings.

You have 2 routes for per-app use of these: give your terminfo a special name
and set $TERM, or change the value of $TERMINFO to find your entry in
preference to the system default.

"man 5 terminfo" has useful information in the "Fetching Compiled Descriptions"
section.

You could invoke mutt via a wrapper which modified the terminfo envars if it
know it was running on the Linux console. (Not so easy from within screen of
course.) Or of course just routinely use a particular terminfo entry inside
screen, since it is entriely divorced from the physical terminal screen is
using as a display.

Cheers,
Cameron Simpson <***@cskk.id.au>
David Woodfall
2018-10-05 23:27:42 UTC
Permalink
On Saturday 6 October 2018 08:43,
Post by David Woodfall
Perhaps I could add terminfo entry in screenrc especially for mutt
that removes the init and reset strings. Not sure if it's possible on
an app-by-app basis though.
You can certainly make customised terminfo entries; I keep a few around myself. As with
termcap, you can make entries based on other entries, so it would be trivial to make a
special one like your console terminfo but with modified init strings.
You have 2 routes for per-app use of these: give your terminfo a special name and set
$TERM, or change the value of $TERMINFO to find your entry in preference to the system
default.
"man 5 terminfo" has useful information in the "Fetching Compiled Descriptions" section.
You could invoke mutt via a wrapper which modified the terminfo envars if it know it was
running on the Linux console. (Not so easy from within screen of course.) Or of course
just routinely use a particular terminfo entry inside screen, since it is entriely
divorced from the physical terminal screen is using as a display.
Cheers,
Thanks for the ideas.

I tried adding some entries in screen last week via the termcapinfo
setting. I changed a few of the strings such as the init and reset
strings. There was no effect so I ended up copying the entire
xterm-color string and it still had no effect.

I'll stick with changing $TERM in a shell function for now. When I
get some time I'll have another look.

--
Dave

What I want is all of the power and none of the responsibility.

.--. oo
(____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'
Loading...