Thank you so much Carl, that fixed it! Amazing.

Now I might just patch back the date/time escape codes that were removed in
2015 and I'll be a happy camper.

Thanks for your help,
János


On Mon, Mar 7, 2022 at 3:47 PM Carl Drougge <bear...@longhaired.org> wrote:

> On Mon, Mar 07, 2022 at 12:05:49 -0500, János Barbero wrote:
>
> > I recently updated from screen-4.0.2 which I had my own patches against
> to
> > the latest development branch. I love most of the changes but one thing
> is
> > incredibly annoying. Anything rendered as reverse video outside of screen
> > renders as blinking text inside of screen. E.g. when I run cal, the
> current
> > date blinks. When I search for something in less, the highlights blink.
> >
> > In older versions of screen, I could have used attrcolor to remap this
> new
> > behavior away, but that command was removed in 2015. Is there anything I
> > can do with current versions? As it is, it's spectacularly annoying.
>
> I don't know why attrcolor was removed, but I can offer termcapinfo as a
> workaround. Assuming you use xterm, put
>
> termcapinfo xterm* mb=\E[7m
>
> in your screenrc and sanity will be restored. ("mb" is termcap-speak for
> blink, and "\E[7m" is reverse video on most terminals.)
>
> That said, I don't get this particular problem.
>
> > I also noticed that screen now prompts for a password whenever I try to
> > reattach and that this is a known issue with plans to make the behavior
> > configurable again. No password I try to enter works, and "password" is
> no
> > longer recognized as a command. I had to patch CheckPassword in socket.c
> to
> > finally be able to reattach to screen. Is this on the roadmap for being
> > made configurable?
>
> This problem I have. It was one of two that made me decide the development
> branch was not intended for use when I tried it a while ago. (The other
> being my hardstatus line breaking and the docs not matching the new
> behaviour in some way I forget.)
>
> In my case passwords work on Debian but don't work on FreeBSD. (I don't
> consider asking for them unconditionally acceptable even when they work
> though.)
>

Reply via email to