bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17497: The text-mode menu looks very broken in emacs-24


From: Eli Zaretskii
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@gnu.org>
> Cc: 17497@debbugs.gnu.org
> 
> > Date: Wed, 18 Mar 2015 17:13:13 +0000
> > From: Martin Trojer <martin.trojer@gmail.com>
> > Cc: 17497@debbugs.gnu.org
> > 
> > From bdff1ff98d02f4307659c052d0b35a40a36f0706 Mon Sep 17 00:00:00 2001
> > From: Martin Trojer <martin.trojer@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]