search('multi-byte char', 'bce') does not match at cursor position.
search('multi-byte char', 'bce') does not match at cursor position.
Steps to reproduce:
$ vim -u NONE
:set encoding=utf-8
:call setline(1, \uff21)
:echo search(\uff21, bceW) no wrap scan
0
Expected:
1
I think that the attached patch fixes this problem. Please check it.
For search(\uff21, bce), Vim checks if matched position is before the
start
position with this expression:
regmatch.endpos[0].col - 1 + extra_col = start_pos.col
(extra_col = SEARCH_START ? 0 : 1)
normal boundary
| SEARCH_START boundary
-| -|
|0|1|2|3|
| A |
^ ^ ^
| | regmatch.endpos[0].col
| | LHS: regmatch.endpos[0].col - 1 + extra_col(1)
| LHS: regmatch.endpos[0].col - 1 + extra_col(0) (LHS=RHS = false)
RHS: start_pos.col
This patch change it to:
regmatch.endpos[0].col - 1 start_pos.col + extra_col
(extra_col = SEARCH_START ? len(A) : 0)
normal boundary
| SEARCH_START boundary
-| -|
|0|1|2|3|
| A |
^ ^ ^
| | regmatch.endpos[0].col
| | RHS: start_pos.col + extra_col(len(A)) (LHSRHS = true)
| LHS: regmatch.endpos[0].col - 1
start_pos.col
RHS: start_pos.col + extra_col(0)
--
Yukihiro Nakadaira - yukihiro.nakada...@gmail.com
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff -r bfc3682510d6 src/search.c
--- a/src/search.c Sat Jul 04 15:05:14 2015 +0200
+++ b/src/search.c Thu Jul 09 21:28:34 2015 +0900
@@ -548,6 +548,7 @@
pos_T start_pos;
intat_first_line;
intextra_col;
+intstart_char_len;
intmatch_ok;
long nmatched;
intsubmatch = 0;
@@ -574,23 +575,37 @@
/* When not accepting a match at the start position set extra_col to
* a non-zero value. Don't do that when starting at MAXCOL, since
* MAXCOL + 1 is zero. */
- if ((options SEARCH_START) || pos-col == MAXCOL)
- extra_col = 0;
+ if (pos-col == MAXCOL)
+ start_char_len = 0;
#ifdef FEAT_MBYTE
/* Watch out for the col being MAXCOL - 2, used in a closed fold. */
- else if (dir != BACKWARD has_mbyte
- pos-lnum = 1 pos-lnum = buf-b_ml.ml_line_count
- pos-col MAXCOL - 2)
+ else if (has_mbyte
+pos-lnum = 1 pos-lnum = buf-b_ml.ml_line_count
+pos-col MAXCOL - 2)
{
ptr = ml_get_buf(buf, pos-lnum, FALSE) + pos-col;
if (*ptr == NUL)
- extra_col = 1;
+ start_char_len = 1;
else
- extra_col = (*mb_ptr2len)(ptr);
+ start_char_len = (*mb_ptr2len)(ptr);
}
#endif
else
- extra_col = 1;
+ start_char_len = 1;
+ if (dir == FORWARD)
+ {
+ if (options SEARCH_START)
+ extra_col = 0;
+ else
+ extra_col = start_char_len;
+ }
+ else
+ {
+ if (options SEARCH_START)
+ extra_col = start_char_len;
+ else
+ extra_col = 0;
+ }
start_pos = *pos; /* remember start pos for detecting no match */
found = 0; /* default: not found */
@@ -779,15 +794,15 @@
|| (lnum + regmatch.endpos[0].lnum
== start_pos.lnum
(int)regmatch.endpos[0].col - 1
- + extra_col
- = (int)start_pos.col))
+(int)start_pos.col
+ + extra_col))
: (lnum + regmatch.startpos[0].lnum
start_pos.lnum
|| (lnum + regmatch.startpos[0].lnum
== start_pos.lnum
(int)regmatch.startpos[0].col
- + extra_col
- = (int)start_pos.col
+ (int)start_pos.col
+
Possible bug: Unicode characters in [g]vim -S file name on Windows 8.1
Not sure if this is the right place to report a bug, but here it comes... How to reproduce: 1. Start Command Prompt. 2. Create an empty test directory anywhere and cd into it. 3. Create a subdirectory with a Unicode character in it, e.g. mkdir α 4. Create a file named Session.vim in the Unicode directory. You can use vim/gvim for this. The contents don't really matter, although I used echo 'Session.vim sourced!' just to provide some feedback if the file is successfully sourced. 5. Ensuring your pwd is *outside* the Unicode directory, try to pass the Session.vim file as the argument to gvim -S. In other words, run either of the following two commands (assuming the vim installation directory, e.g. C:\Program Files (x86)\Vim\vim74, is in your %PATH%): vim -S α\Session.vim gvim -S α\Session.vim The result (at least for me, using [g]vim 7.4.0 on Windows 8.1) is this error message: Error detected while processing command line: E484: Can't open file a\Session.vim The α (U+03B1) became an a (U+0061). I also tried a fraction slash (U+2044) and it became a normal forward slash (U+002F). Thus, it looks like there's some kind of compatibility normalization thing going on, or maybe some kind of munging due to code pages. In any case, the command should not be failing. It is also noteworthy that just editing the file via the command-line works fine. IOW, the following works: vim α\Session.vim gvim α\Session.vim Thus, I really don't think this should be failing. I also tried using the latest MacVim and console vim on Mac OS X 10.9, and I also tried Cygwin console vim on the same Windows 8.1 system, and none of those failed. Thanks! Ben -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 381 in vim: 'nocompatible' in vimrc causes the first char changed to 'g'
Comment #3 on issue 381 by h.east@gmail.com: 'nocompatible' in vimrc causes the first char changed to 'g' https://code.google.com/p/vim/issues/detail?id=381 This problem occurs in vim 7.4.757 to 7.4.765. (fixed by 7.4.766) If you use urxvt and using transparency, check below thread and try local patch rbg_fix4.patch https://groups.google.com/d/topic/vim_dev/LLGjKaEzNUY/discussion If we want to urgently resolved, try out the following method. 1. 't_RB' cleard in your .vimrc. set t_RB= 2. 'bg' set to 'dark' or 'light' in your .vimrc set bg=dark 3. Disable transparency. Please see https://bbs.archlinux.org/viewtopic.php?pid=1541962#p1541962 Thank you -- Best regards, Hirohito Higashi -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
how to detect ins-completion mode?
Hi! I'm trying to implement starting omni completion with Tab and then looping over completion variants also with Tab. I've map Tab to function which returns \c-x\c-o to start omni completion, but next Tab should return \c-n and I've no idea how to detect is user already in ins-completion mode. pumvisible() doesn't helps because there is no menu on screen (only --- Omni… (^O^N^P) … line at bottom of screen). mode() also doesn't helps because it report i all of time. Vim 7.4.738 -- WBR, Alex. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 381 in vim: 'nocompatible' in vimrc causes the first char changed to 'g'
Comment #2 on issue 381 by odabr...@gmail.com: 'nocompatible' in vimrc causes the first char changed to 'g' https://code.google.com/p/vim/issues/detail?id=381 I cannot reproduce this. File test.vim contains set nocompatible Testing with vim -u test.vim -U NONE --noplugin test.vim shows the contents of test.vim without g, as shown above. Tested with vim 7.4.000 and vim 7.4.769. Could you try to reproduce it with the file and command line above? If it does not reproduce the problem, then something in your ~/.vimrc or in a plugin is likely the reason for the problem. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] Respect file's EOL/NOEOL settings
On 08-Jul-15, Pavel Samarkin wrote: Hi, If you use git, then in “git help attributes” the example mentioning *.vcproj files might be useful for you. Possibly the end-of-line normalization offered by git includes the case where just the last line needs normalization. Roland - thank you, I did not know about that feature of git, it might be useful for my *.csproj situation, but generally I don't want my files to be normalized in any way, I want them to be left intact. 1. 'norespecteol' (default) means that an EOL is always added unless 'eol' + 'bin' are set, i.e. Vim's existing behavior. 2. Opening an existing file when 'respecteol' is set honors the current state of the EOL on the last line, and should set 'eol' accordingly. 3. If a user wishes a new, unsaved buffer to not have an EOL on the last line, she can set 'respecteol' and 'noeol'. James - I think in #1 you meant 'noeol' + 'bin' - if yes, then 1-3 is exactly what my patch adds. I believe the final EOL in a file should be made visible and editable. Olaf - James is right, according to the POSIX standard, EOL means EOL, not 'newline', regardless of how it's treated by some other text editors. According to the POSIX standard you cited, 3.206 Line A sequence of zero or more non- newline characters plus a terminating newline character. a line is terminated by a newline character. It does not mention EOL. In the other mail I tried to hint at the different meanings and interpretations. They can be confusing. As a small overview: Unicode says LF / NL and EOL are the same, at codepoint 0x000A: http://unicode.org/charts/PDF/U.pdf. This extends the meaning of 0x0A from the source character set ISO 646 / ECMA-6 and ISO 6429 / ECMA-48, which defines this as LF. Unicode invented a different code point for line separator LS at 0x2028 to represent this semantic unambiguously: http://unicode.org/charts/PDF/U2000.pdf Note that there is also NEL (next line) at 0x0085, invented by ISO 6429 / ECMA-48. See the Unicode Newline Guidelines at http://unicode.org/standard/reports/tr13/tr13-5.html for a discussion and recommendations around newline / EOL etc. treatment. The original definitions of characters like NL and CR are operational (e.g. move to the next line, or to the beginning of the line, see ISO 6429 / ECMA-48). But EOL is the concept of a line terminator, which needs to be represented by one or more codes. A standard like POSIX simply adopted NL as the code for a line terminator. Others have adopted NL, CR+NL or CR as line terminators or as line separators. Have a look at https://en.wikipedia.org/wiki/Newline to find more representations for next line, line terminator or line separator, both historic and current. The reason why in vim we can conveniently use the concept of EOL is that vim does such a good job of converting the different representations into a single internal representation (lines terminated by NUL '\0'). But the problem here is not the different representations for EOL, but that there is software that uses the concept of a line separator rather than a line terminator like EOL, yet represents this with a similar selection of codes (NL, CR+NL, maybe even CR). Besides, I don't want to break the existing Vim functionality, I just want to expand the horizons of its usage beyond the Unix world it has been originally created for. Fully agreed. I do not think that a suggestion like '(no)addeol' breaks vim. It is quite comparable to your approach, but IMHO even simpler, and more visible and editable to the user: When saving a file, do not append EOL (or in this case line separator) representation characters to the last line. To make the file end on a line separator, an empty line must be at the end of the buffer. This behavior can be turned on or off with a single option. Only when switching this option on or off, an empty last line is converted to 'eol' or back, and if the last line is not empty, 'noeol' is set or no empty line is appended to the buffer when converting backwards. And when a file is read, then the setting of the option determines if the state of the last EOL will show up in 'eol' or in the buffer. That's it. The main advantage of my approach, as I see it, is that when a file uses the line separator concept instead of the EOL concept, it does not hide the empty line at the end in an option. Instead, it makes that line visible and malleable in a very natural way inside the buffer. This makes the user see what she gets, and she can manipulate it easily. I may not have convinced you, so maybe it helps if we could compare the two approaches side-by-side. But I will be very busy with other things in the next days, so I am not sure if I will get around to write an implementation
Re: Patch 7.4.757
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:///)
Please confirm this.
It's a bit tricky.
diff -r bfc3682510d6 src/term.c
--- a/src/term.cSat Jul 04 15:05:14 2015 +0200
+++ b/src/term.cTue 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 -- b...@moolenaar.net -- 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
Issue 381 in vim: 'nocompatible' in vimrc causes the first char changed to 'g'
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 381 by expro...@gmail.com: 'nocompatible' in vimrc causes the first char changed to 'g' https://code.google.com/p/vim/issues/detail?id=381 What steps will reproduce the problem? 1. find a text file with non-empty first line, like foo.txt 2. add 'set nocompatible' to ~/.vimrc 3. run 'vim foo.txt' What is the expected output? What do you see instead? - The first char of first line of foo.txt will always be 'g' regardless what the file contains. What version of the product are you using? On what operating system? - VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 29 2015 10:20:34) - Linux 4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 08:04:42 UTC 2015 i686 GNU/Linux -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 381 in vim: 'nocompatible' in vimrc causes the first char changed to 'g'
Comment #1 on issue 381 by expro...@gmail.com: 'nocompatible' in vimrc causes the first char changed to 'g' https://code.google.com/p/vim/issues/detail?id=381 correction: - The first char of first line of **the buffer** will always be 'g' regardless what the file contains. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Possible bug: Unicode characters in [g]vim -S file name on Windows 8.1
2015-07-09 6:47 GMT+03:00 ben bgol...@gmail.com: Not sure if this is the right place to report a bug, but here it comes... How to reproduce: 1. Start Command Prompt. 2. Create an empty test directory anywhere and cd into it. 3. Create a subdirectory with a Unicode character in it, e.g. mkdir α 4. Create a file named Session.vim in the Unicode directory. You can use vim/gvim for this. The contents don't really matter, although I used echo 'Session.vim sourced!' just to provide some feedback if the file is successfully sourced. 5. Ensuring your pwd is *outside* the Unicode directory, try to pass the Session.vim file as the argument to gvim -S. In other words, run either of the following two commands (assuming the vim installation directory, e.g. C:\Program Files (x86)\Vim\vim74, is in your %PATH%): vim -S α\Session.vim gvim -S α\Session.vim The result (at least for me, using [g]vim 7.4.0 on Windows 8.1) is this error message: Error detected while processing command line: E484: Can't open file a\Session.vim The α (U+03B1) became an a (U+0061). I also tried a fraction slash (U+2044) and it became a normal forward slash (U+002F). Thus, it looks like there's some kind of compatibility normalization thing going on, or maybe some kind of munging due to code pages. In any case, the command should not be failing. It is also noteworthy that just editing the file via the command-line works fine. IOW, the following works: vim α\Session.vim gvim α\Session.vim Thus, I really don't think this should be failing. Try out `:source α\Session.vim` from inside gvim. -S switch is a *complete* equivalent to using `-c so α\Session.vim`: internally in main.c vim simply converts -S to the latter. Behaviour in this case should give some hints regarding what part of gvim is responsible for this. Also check `gvim -c so α\Session.vim` just in case. I also tried using the latest MacVim and console vim on Mac OS X 10.9, and I also tried Cygwin console vim on the same Windows 8.1 system, and none of those failed. Thanks! Ben -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.757
Hi Bram,
2015-7-9(Thu) 18:30:55 UTC+9 Bram Moolenaar:
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:///)
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).
Sure.
This matter is corresponding later.
I updated a patch. (BELL termination check were missing for RBG)
And I received a review from Hayaki Saito.
He says:
- 8-bit response can not received. (Contains mouse input)
- may_req_bg_color() call timing is too
