GNU bug report logs - #17497
24.4.50; TTY menu glitches

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin.trojer <at> gmail.com
Cc: 17497 <at> debbugs.gnu.org
Subject: bug#17497: The text-mode menu looks very broken in emacs-24
Date: Sat, 07 Oct 2017 14:41:08 +0300

> Date: Sat, 07 Oct 2017 12:38:58 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 17497 <at> debbugs.gnu.org
> 
> > Date: Wed, 18 Mar 2015 17:13:13 +0000
> > From: Martin Trojer <martin.trojer <at> gmail.com>
> > Cc: 17497 <at> debbugs.gnu.org
> > 
> > From bdff1ff98d02f4307659c052d0b35a40a36f0706 Mon Sep 17 00:00:00 2001
> > From: Martin Trojer <martin.trojer <at> gmail.com>
> > Date: Wed, 18 Mar 2015 11:44:02 +0000
> > Subject: [PATCH] emacs bug #17497 fix
> > 
> > ---
> >  src/cm.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/src/cm.c b/src/cm.c
> > index 474f280..ed17447 100644
> > --- a/src/cm.c
> > +++ b/src/cm.c
> > @@ -371,6 +371,16 @@ cmgoto (struct tty_display_info *tty, int row, int col)
> >        dcm = tty->Wcm->cm_abs;
> >      }
> >  
> > +    /* only use direct moves */
> > +    cost = 0;
> > +    p = (dcm == tty->Wcm->cm_habs
> > +         ? tgoto (dcm, row, col)
> > +         : tgoto (dcm, col, row));
> > +    emacs_tputs (tty, p, 1, evalcost);
> > +    emacs_tputs (tty, p, 1, cmputc);
> > +    curY (tty) = row, curX (tty) = col;
> > +    return;
> > +
> >    /*
> >     * In the following comparison, the = in <= is because when the costs
> >     * are the same, it looks nicer (I think) to move directly there.
> 
> I now do see this problem on a GNU/Linux system to which I have
> access, but applying this patch didn't solve the problem...

Some debugging indicates that somehow the cursor is sometimes moved
behind our backs, when a frame with a TTY menu is being updated.  So I
installed a semi-kludgey workaround that seems to fix 99% of the
glitches.  Since I don't really understand why this change is needed,
and because of the 1% of glitches that still happen, I'm not closing
the bug, and will continue looking into this.

If someone knows which display ops could move the cursor without going
through cursor_to, please tell.

I hope the solution is not limited to the one system where I see this
problem.  People who experienced the problem are encouraged to try the
latest release branch and report the results here.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.