Hirohito Higashi wrote:

> Hi Bram and list!
> 
> 2015-7-9(Thu) 10:47:12 UTC+9 h_east:
> > Hi Bram!
> > 
> > 2015-7-9(Thu) 4:55:17 UTC+9 Bram Moolenaar:
> > > Hirohito Higashi wrote:
> > > 
> > > > 2015-7-8(Wed) 2:08:03 UTC+9 Bram Moolenaar:
> > > > > Hirohito Higashi wrote:
> > > > > 
> > > > > > Hi Bram, Anatol and Vim developers!
> > > > > > 
> > > > > > 2015-7-7(Tue) 8:20:43 UTC+9 Anatol Pomozov:
> > > > > > > Is HEAD vim revision still broken? Could developers loos at this
> > > > > > > bug? Many Arch developers report this issue and we would like to
> > > > > > > release working version of vim.
> > > > > > 
> > > > > > I think that is no need to correspond to the "rgba:".
> > > > > > But, Vim is not good to output garbage being displayed which could 
> > > > > > not
> > > > > > be interpreted the "Background color response".
> > > > > > 
> > > > > > So, I wrote a patch.
> > > > > > This patch is suppress to output garbage being displayed, when 
> > > > > > unknown
> > > > > > background color response received. (e.g.
> > > > > > "11;rgba:aaaa/rrrr/gggg/bbbb")
> > > > > > 
> > > > > > Please confirm this.
> > > > > 
> > > > > It's a bit tricky.
> > > > > 
> > > > > > diff -r bfc3682510d6 src/term.c
> > > > > > --- a/src/term.c    Sat Jul 04 15:05:14 2015 +0200
> > > > > > +++ b/src/term.c    Tue Jul 07 13:08:17 2015 +0900
> > > > > > @@ -4272,7 +4272,7 @@
> > > > > >  
> > > > > >         if ((*T_CRV != NUL || *T_U7 != NUL || *T_RBG != NUL)
> > > > > >                     && ((tp[0] == ESC && tp[1] == '[' && len >= 3)
> > > > > > -                       || (tp[0] == ESC && tp[1] == ']' && len >= 
> > > > > > 24)
> > > > > > +                       || (tp[0] == ESC && tp[1] == ']' && len >= 
> > > > > > 3)
> > > > > >                         || (tp[0] == CSI && len >= 2))
> > > > > >                     && (VIM_ISDIGIT(*argp) || *argp == '>' || *argp 
> > > > > > == '?'))
> > > > > >         {
> > > > > 
> > > > > I think the length check should be len >= 5, since that's what is used
> > > > > below.
> > > > 
> > > > No problem. Because it checked in src/term.c:L4414.
> > > > (Note: Line number is the after applying my patch)
> > > 
> > > But then we will search for the whole escape sequence.
> > > 
> > > > 4413                 else if (*T_RBG != NUL
> > > > 4414                         && len >= 5 - (tp[0] == CSI)
> > > > 4415                         && argp[0] == '1' && argp[1] == '1' && 
> > > > argp[2] == ';')
> > > > 4416                 {
> > > > 
> > > > > 
> > > > > 
> > > > > > +                   j = 2 - (tp[0] == CSI);
> > > > > > +                   for (i = j; i < len; ++i)
> > > > > > +                       if (tp[i] == '\007'
> > > > > > +                           || (tp[0] == CSI ? tp[i] == STERM
> > > > > > +                           : i + 1 < len && tp[i] == ESC && tp[i + 
> > > > > > 1] == '\\'))
> > > > > > +                       {
> > > > > > +                           LOG_TR("Received unknown RBG");
> > > > > > +                           key_name[0] = (int)KS_EXTRA;
> > > > > > +                           key_name[1] = (int)KE_IGNORE;
> > > > > > +                           slen = i + 1 + (tp[i] == ESC);
> > > > > > +                           break;
> > > > > > +                       }
> > > > > > +
> > > > > > +                   if (i == len)
> > > > > > +                   {
> > > > > > +                       LOG_TR("not enough characters for RB");
> > > > > > +                       return -1;          /* not enough 
> > > > > > characters */
> > > > > > +                   }
> > > > > > +               }
> > > > > 
> > > > > If the terminating character is missing, or the specific terminal uses
> > > > > another character to terminate the sequence, then this will eat
> > > > > everything.
> > > > 
> > > > This patch discard only the following pattern. ('*' is any character 
> > > > string)
> > > >   ESC]11;*BEL
> > > >   ESC]11;*ESC\
> > > >   CSI11;*BEL
> > > >   CSI11;*ST
> > > > 
> > > > So, I think the problem is less likely to occur.
> > > 
> > > But when we get ESC]11; and then no BEL or ESC\ follows, we never get
> > > out of this loop, we run into the "not enough characters" part forever.
> > 
> > Sorry. I have big mistake.
> > Patch 7.4.757 has confused the CSI(0x9b) and OSC(0x9d).
> > And, I did not notice it.
> > 
> > Please wait for a few days, because I refactor the term.c.
> 
> Done.
> 
> Changed contents:
> - Defined the OSC in the same way as CSI, DCS.
> - CSI, OSC and DCS check process was clearly separated.
> 
> Please confirm again.

Thanks, I'll look into it.

> BTW...
> > > But when we get ESC]11; and then no BEL or ESC\ follows, we never get
> > > out of this loop, we run into the "not enough characters" part forever.
> 
> This problem is also in the process of the current of CSI and DCS.
> Find and check for below string in term.c
>   "Not enough characters for CRV"
>   "not enough characters for XT"

We might need to find a generic solution.  A timeout is probably
appropriate, these escape sequences should be completely received within
a short time.  Although on a slow connection it might get split (the
"entering a tunnel" problem).

-- 
What is the difference between a professional and an amateur?
The ark was built by an amateur; professionals gave us the Titanic.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui