Re: Odd behavior of vim 8.0.1203 in a wide xterm -- solution found

2017-11-03 Fir de Conversatie Gary Johnson 
On 2017-11-03, Bram Moolenaar wrote:
> Christian Brabandt wrote:
> 
> > On Do, 02 Nov 2017, Gary Johnson wrote:
> > 
> > > On 2017-11-02, Gary Johnson wrote:
> > > 
> > > > So the funny behavior does seem related to the old addressing
> > > > style, but why is it happening on an xterm-318 with 'ttymouse'
> > > > automatically set to "sgr"?
> > > 
> > > I tried finding the problem by bisecting the repository and found
> > > that my build of 7.4.160 failed, too.  That led me to discover that
> > > my normal build was missing the mouse_sgr feature.  I added
> > > -DFEAT_MOUSE_SGR to CFLAGS and rebuilt and all is good.
> > > 
> > > Thanks to James McCoy for directing my attention to SGR.
> > 
> > So you could `:set ttymouse=sgr` but it didn't work because your vim was 
> > build without the FEAT_MOUSE_SGR feature? We should need an error 
> > message then, right? Perhaps the attached patch should be included.
> 
> Hmm, this may lead to annoying error messages.  Perhaps we can find
> something in between: When ttymouse is set to an unspported value from a
> script, set it to the nearest supported value.  When manually setting it
> to an unsupported value then give an error message.  That way we don't
> bother users who know it didn't work, and when someone manually sets
> ttymouse to try out what works, he will see the error.  Would that work?

While I was investigating the problem, I started vim as

$ vim -N -u NONE -i NONE

and 'ttymouse' was set automatically to "sgr", presumably in
response to the termresponse.  Some sort of message in that
situation would have been nice.  Maybe.  It only really matters,
though, if the terminal width is greater than 223 and 'mouse' is
set.

I suppose that if vim had automatically set 'ttymouse' to the
nearest supported value (of "xterm2"?), that would have let me know
that SGR wasn't being recognized; then giving me an error message if
I tried to manually set it to "sgr" would have alerted me to the
missing mouse_sgr feature.

I don't know what the right solution is.  This is an unusual
problem.  Solving it without a possibly annoying, in-your-face error
message requires some awareness and knowledge of 'ttymouse'.  Once
you read and understand ":help 'ttymouse'", you don't need an error
message to understand the problem and possible solutions.

I think it would be nice, though, if the connection between the
'ttymouse' values and the required features was more explicit.  That
is, instead of the one paragraph stating

The mouse handling must be enabled at compile time |+mouse_xterm|
|+mouse_dec| |+mouse_netterm| |+mouse_jsbterm| |+mouse_urxvt|
|+mouse_sgr|.

those features would be mentioned in the value descriptions, e.g.,

sgr  Mouse handling for the terminal that emits SGR-styled
 mouse reporting.  The mouse works even in columns
 beyond 223.  This option is backward compatible with
 "xterm2" because it can also decode "xterm2" style
 mouse codes.  {only available when compiled with the
 |+mouse_sgr| feature}

Regards,
Gary

-- 
-- 
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: Odd behavior of vim 8.0.1203 in a wide xterm -- solution found

2017-11-03 Fir de Conversatie Bram Moolenaar 

Christian Brabandt wrote:

> On Do, 02 Nov 2017, Gary Johnson wrote:
> 
> > On 2017-11-02, Gary Johnson wrote:
> > 
> > > So the funny behavior does seem related to the old addressing
> > > style, but why is it happening on an xterm-318 with 'ttymouse'
> > > automatically set to "sgr"?
> > 
> > I tried finding the problem by bisecting the repository and found
> > that my build of 7.4.160 failed, too.  That led me to discover that
> > my normal build was missing the mouse_sgr feature.  I added
> > -DFEAT_MOUSE_SGR to CFLAGS and rebuilt and all is good.
> > 
> > Thanks to James McCoy for directing my attention to SGR.
> 
> So you could `:set ttymouse=sgr` but it didn't work because your vim was 
> build without the FEAT_MOUSE_SGR feature? We should need an error 
> message then, right? Perhaps the attached patch should be included.

Hmm, this may lead to annoying error messages.  Perhaps we can find
something in between: When ttymouse is set to an unspported value from a
script, set it to the nearest supported value.  When manually setting it
to an unsupported value then give an error message.  That way we don't
bother users who know it didn't work, and when someone manually sets
ttymouse to try out what works, he will see the error.  Would that work?


-- 
A programmer's wife asks him: "Please run to the store and pick up a loaf of
bread.  If they have eggs, get a dozen".  The programmer comes home with 12
loafs of bread.

 /// 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 -- 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Security risk of vim swap files

2017-11-03 Fir de Conversatie Marvin Renich 
* Zdenek Dohnal  [171103 09:27]:
> On 11/03/2017 02:07 PM, Marvin Renich wrote:
> > * zdoh...@redhat.com  [171103 03:45]:
> Can other users open original file, which has .swp file belonging to
> certain user:group with permissions 0600, as read-only with your
> solution? If not, it could be change of behavior, which can make some
> people unhappy -> that' why I thought it could be configurable behavior.

Yes.  My current version (from Debian package; see below) will give the
"recovery" prompt, and then allow the user to edit it anyway (based on
the answer to the prompt).  This looks like it is working just right.

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 13 2017 22:38:50)
Included patches: 1-1144

...Marvin

-- 
-- 
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: Security risk of vim swap files

2017-11-03 Fir de Conversatie Bram Moolenaar 

Someone wrote:

> Another option would be to copy the user and other permissions from the
> original file, but reset the group permissions to 0. For example, if a
> user goes to edit a file with permissions 754, the .swp file would have
> the permissions 704. This prevents the security problem with .swp files
> while still allowing anyone to recover changes for files that were world
> readable to begin with. This might be a good compromise.

To cover the case that the user has his configuration wrong and has a
primary group that gives too many users access, we can attempt to change
the group of the swap file to that of the original file.  If that works
then we can keep using the same permissions.  If that fails, the group
is now different, we can set the group bits to zero.  We can OR them
with the world bits (some systems have the weird behavior that when the
group matches it ignores the world bits, restricting permission if you
happen to be in the lucky group).

> Still I think the least problematic solution though is to use a separate
> directory for the .swp files. Also, what happens if a user goes to edit
> a file that he has write access to in a directory that he doesn't have
> write access to? Where does the .swp file get placed then? With the
> approach separate directory approach this becomes a nonissue.

Read the docs, it's covered.

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~

 /// 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 -- 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Odd behavior of vim 8.0.1203 in a wide xterm -- solution found

2017-11-03 Fir de Conversatie Gary Johnson 
On 2017-11-03, Christian Brabandt wrote:
> 
> On Do, 02 Nov 2017, Gary Johnson wrote:
> 
> > On 2017-11-02, Gary Johnson wrote:
> > 
> > > So the funny behavior does seem related to the old addressing
> > > style, but why is it happening on an xterm-318 with 'ttymouse'
> > > automatically set to "sgr"?
> > 
> > I tried finding the problem by bisecting the repository and found
> > that my build of 7.4.160 failed, too.  That led me to discover that
> > my normal build was missing the mouse_sgr feature.  I added
> > -DFEAT_MOUSE_SGR to CFLAGS and rebuilt and all is good.
> > 
> > Thanks to James McCoy for directing my attention to SGR.
> 
> So you could `:set ttymouse=sgr` but it didn't work because your
> vim was build without the FEAT_MOUSE_SGR feature? We should need
> an error message then, right?

Right.

> Perhaps the attached patch should be included.

That would have helped.

Regards,
Gary

-- 
-- 
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: Security risk of vim swap files

2017-11-03 Fir de Conversatie Zdenek Dohnal 
On 11/03/2017 02:07 PM, Marvin Renich wrote:
> * zdoh...@redhat.com  [171103 03:45]:
>>> Another solution would be to always use the editing user's user:group
>>> and perm 0600.
>> I agree with this solution. And IMO the best way would be to create
>> option for configure script+create option for vimrc configuration
>> file, which can turn on/off this behavior (IMHO it's good to have
>> option for users, who doesn't want this behavior). 
> I think having this behavior configurable is overkill and unnecessary in
> practice.
Can other users open original file, which has .swp file belonging to
certain user:group with permissions 0600, as read-only with your
solution? If not, it could be change of behavior, which can make some
people unhappy -> that' why I thought it could be configurable behavior.

-- 

Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C


-- 
-- 
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.


signature.asc
Description: OpenPGP digital signature

Re: Security risk of vim swap files

2017-11-03 Fir de Conversatie Z5T1 
Another option would be to copy the user and other permissions from the
original file, but reset the group permissions to 0. For example, if a
user goes to edit a file with permissions 754, the .swp file would have
the permissions 704. This prevents the security problem with .swp files
while still allowing anyone to recover changes for files that were world
readable to begin with. This might be a good compromise.

Still I think the least problematic solution though is to use a separate
directory for the .swp files. Also, what happens if a user goes to edit
a file that he has write access to in a directory that he doesn't have
write access to? Where does the .swp file get placed then? With the
approach separate directory approach this becomes a nonissue.


On 11/03/2017 09:07 AM, Marvin Renich wrote:
> * zdoh...@redhat.com  [171103 03:45]:
>>> Another solution would be to always use the editing user's user:group
>>> and perm 0600.
>> I agree with this solution. And IMO the best way would be to create
>> option for configure script+create option for vimrc configuration
>> file, which can turn on/off this behavior (IMHO it's good to have
>> option for users, who doesn't want this behavior). 
> I think having this behavior configurable is overkill and unnecessary in
> practice.
>
> After thinking about it, I like my second solution (the one above) best.
> My first solution has the advantage that anyone who has permission to
> edit the file will be able to recover a crashed editing session.  But I
> don't see this as a real-world scenario.  The above solution is simpler
> to implement, simpler to understand, and makes it easier to identify
> security implications.
>
> I also think my first solution might cause problems if the containing
> directory has the restricted deletion flag permission bit.
>
> ...Marvin
>


-- 
-- 
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.


signature.asc
Description: OpenPGP digital signature

Re: Security risk of vim swap files

2017-11-03 Fir de Conversatie Marvin Renich 
* zdoh...@redhat.com  [171103 03:45]:
> > Another solution would be to always use the editing user's user:group
> > and perm 0600.
> 
> I agree with this solution. And IMO the best way would be to create
> option for configure script+create option for vimrc configuration
> file, which can turn on/off this behavior (IMHO it's good to have
> option for users, who doesn't want this behavior). 

I think having this behavior configurable is overkill and unnecessary in
practice.

After thinking about it, I like my second solution (the one above) best.
My first solution has the advantage that anyone who has permission to
edit the file will be able to recover a crashed editing session.  But I
don't see this as a real-world scenario.  The above solution is simpler
to implement, simpler to understand, and makes it easier to identify
security implications.

I also think my first solution might cause problems if the containing
directory has the restricted deletion flag permission bit.

...Marvin

-- 
-- 
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: Odd behavior of vim 8.0.1203 in a wide xterm -- solution found

2017-11-03 Fir de Conversatie Christian Brabandt 

On Do, 02 Nov 2017, Gary Johnson wrote:

> On 2017-11-02, Gary Johnson wrote:
> 
> > So the funny behavior does seem related to the old addressing
> > style, but why is it happening on an xterm-318 with 'ttymouse'
> > automatically set to "sgr"?
> 
> I tried finding the problem by bisecting the repository and found
> that my build of 7.4.160 failed, too.  That led me to discover that
> my normal build was missing the mouse_sgr feature.  I added
> -DFEAT_MOUSE_SGR to CFLAGS and rebuilt and all is good.
> 
> Thanks to James McCoy for directing my attention to SGR.

So you could `:set ttymouse=sgr` but it didn't work because your vim was 
build without the FEAT_MOUSE_SGR feature? We should need an error 
message then, right? Perhaps the attached patch should be included.

Christian
-- 
Zeig mir deine Uhr, und ich sage dir, wie spät es ist.

-- 
-- 
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 --git a/src/os_unix.c b/src/os_unix.c
index a39caffe4..765cbaa32 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -3567,8 +3567,8 @@ mch_setmouse(int on)
 
 xterm_mouse_vers = use_xterm_mouse();
 
-# ifdef FEAT_MOUSE_URXVT
 if (ttym_flags == TTYM_URXVT)
+# ifdef FEAT_MOUSE_URXVT
 {
 	out_str_nf((char_u *)
 		   (on
@@ -3576,10 +3576,12 @@ mch_setmouse(int on)
 		   : IF_EB("\033[?1015l", ESC_STR "[?1015l")));
 	ison = on;
 }
+# else
+	emsg((char_u *)"Exxx: Option value \"urxvt\" for 'ttymouse' not compiled in");
 # endif
 
-# ifdef FEAT_MOUSE_SGR
 if (ttym_flags == TTYM_SGR)
+# ifdef FEAT_MOUSE_SGR
 {
 	out_str_nf((char_u *)
 		   (on
@@ -3587,6 +3589,8 @@ mch_setmouse(int on)
 		   : IF_EB("\033[?1006l", ESC_STR "[?1006l")));
 	ison = on;
 }
+# else
+	emsg((char_u *)"Exxx: Option value \"sgr\" for 'ttymouse' not compiled in");
 # endif
 
 if (xterm_mouse_vers > 0)
@@ -3604,8 +3608,8 @@ mch_setmouse(int on)
 	ison = on;
 }
 
-# ifdef FEAT_MOUSE_DEC
 else if (ttym_flags == TTYM_DEC)
+# ifdef FEAT_MOUSE_DEC
 {
 	if (on)	/* enable mouse events */
 	out_str_nf((char_u *)"\033[1;2'z\033[1;3'{");
@@ -3613,6 +3617,8 @@ mch_setmouse(int on)
 	out_str_nf((char_u *)"\033['z");
 	ison = on;
 }
+# else
+	emsg((char_u *)"Exxx: Option value \"dec\" for 'ttymouse' not compiled in");
 # endif
 
 # ifdef FEAT_MOUSE_GPM
@@ -3647,8 +3653,8 @@ mch_setmouse(int on)
 }
 # endif
 
+if (ttym_flags == TTYM_JSBTERM)
 # ifdef FEAT_MOUSE_JSB
-else
 {
 	if (on)
 	{
@@ -3684,9 +3690,11 @@ mch_setmouse(int on)
 	ison = FALSE;
 	}
 }
+# else
+	emsg((char_u *)"Exxx: Option value \"jsbterm\" for 'ttymouse' not compiled in");
 # endif
+else if (ttym_flags == TTYM_PTERM)
 # ifdef FEAT_MOUSE_PTERM
-else
 {
 	/* 1 = button press, 6 = release, 7 = drag, 1h...9l = right button */
 	if (on)
@@ -3695,6 +3703,8 @@ mch_setmouse(int on)
 	out_str_nf("\033[>1l\033[>6l\033[>7l\033[>1l\033[>9h");
 	ison = on;
 }
+# else
+	emsg((char_u *)"Exxx: Option value \"pterm\" for 'ttymouse' not compiled in");
 # endif
 }

Re: Security risk of vim swap files

2017-11-03 Fir de Conversatie zdohnal 
On Friday, November 3, 2017 at 8:44:51 AM UTC+1, zdo...@redhat.com wrote:
> > Another solution would be to always use the editing user's user:group
> > and perm 0600.
> 
> I agree with this solution. And IMO the best way would be to create option 
> for configure script+create option for vimrc configuration file, which can

If that's possible.

> turn on/off this behavior (IMHO it's good to have option for users, who 
> doesn't want this behavior). 
>  
> Zdenek

-- 
-- 
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: Security risk of vim swap files

2017-11-03 Fir de Conversatie zdohnal 
> Another solution would be to always use the editing user's user:group
> and perm 0600.

I agree with this solution. And IMO the best way would be to create option for 
configure script+create option for vimrc configuration file, which can turn 
on/off this behavior (IMHO it's good to have option for users, who doesn't want 
this behavior). 
 
Zdenek

-- 
-- 
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 with build-in omni func

2017-11-03 Fir de Conversatie Christian Brabandt 

On Fr, 03 Nov 2017, 世东 王 wrote:

> Hi. here is an issue about omnifunc
> 
> https://github.com/neovim/neovim/issues/7471
> 
> I am not sure why I can not  login my github account, so here is the old link 
> I just post.

That has just been fixed as mentioned in the github issue.

Christian
-- 
Selbst wenn alle Fachleute einer Meinung sind, können sie sehr wohl im
Irrtum sein.
-- Bertrand A. W. Russell

-- 
-- 
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: How about add a new key to setqflist()

2017-11-03 Fir de Conversatie Shidong Wang 
在 2017年10月18日星期三 UTC+8上午12:07:36，Shidong Wang写道：
> when using quickfix list, if the filename is too long, it is hard to read the 
> `text` of each item of the list. I think we should add a new key, such as 
> `abbr`, this will be deplayed if it is not a empty string instead of 
> `filename` or `bufnr`.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Shidong Wang 
> 
> wsd...@outlook.com

Looks nice, Thanks for your work.

-- 
-- 
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.

issue with build-in omni func

2017-11-03 Fir de Conversatie 世东 王 
Hi. here is an issue about omnifunc

https://github.com/neovim/neovim/issues/7471

I am not sure why I can not  login my github account, so here is the old link I 
just post.


Shidong Wang

-- 
-- 
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.