date:20160911

Re: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

2016-09-11 Fir de Conversatie Nikolay Aleksandrovich Pavlov

2016-09-11 19:23 GMT+03:00 Björn Linse :
> What is wrong with just using CODEC_ERROR_HANDLER directly?

AFAIR this is because Python-2 may need "surrogateescape" argument in
the Python->Vim direction (to make writing cross-Python scripts), but
it definitely does not need it when converting from Vim to Python.
That commit does nothing like this, it is a minimal required change to
fix the issue.

>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
> --
> --
> 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: Vim periodically trashes the start of a file

2016-09-11 Fir de Conversatie Ingo Karkat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11-Sep-2016 03:27 +0200, Sholto Douglas wrote:

> I have used VIM for many years and am an aficionado. However I
> find it has a VERY annoying habit of occasionally truncating the
> start of a file when I save it. Usually I can get back the missing
> bits by going to the backup file e.g. file.cpp~ But today I find
> that even the backup file has been trashed.  I have lost a heap of
> work, which will set me back hours on a tight timetable. Here is
> the start of the trashed file:
> 
> g`"& kDisableSkipFolders) == kDisableSkipFolders);
> 
> CloseCurrentKey(); return m_vecPath.size() > 0; }
> 
> As you can see, it doesn't look like the start of a C++ source 
> file. Has anyone else had this?  google didn't return any 
> references to it, but I can't imagine I am the only one to suffer 
> this given it has happened many times over the years. Is there a 
> fix for this blight on an otherwise excellent tool?

It looks like a plugin applied commands in the wrong mode, and so some
text got lost, and g`" (a non-jumplist jump to the position when last
exiting the buffer) inserted instead. Which plugins do you use?

Try searching for g`" (or maybe g`) in your ~/.vim directory (and
maybe your ~/.vimrc as well). That might give you the culprit, or at
least narrow it down to a few plugins. You can then try disabling the
plugin (set g:loaded_ in your .vimrc usually works).
Plugin bugs should be reported to its author, naturally.

I don't think this is an issue with Vim itself.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJX1aQXAAoJEA7ziXlAzQ/vpz0H/jCnFLoC37tUNGGaQ/L4PZKH
G8ZJ3zi0S++W1jNrpWBY7Fmx4A61o8Z2vGqF83cI5ebeB6j5R++w4X9JhG1Z/7HQ
tFGO+zZjEY1HLIUr6Bz4enTLobZBjodY3ZEiPdUE9uvZYCbRF3XGIOXYT+56Zze+
IRGCmyKsiEjHFAc7v4RHee732HiGRULtUwY9aHPY3ozKk+qI0z6rjD2KAsr4cSKZ
fRc2bd+3gqjIAUusWwlVLzjO9ek0XokP1sKPgBmcHfm7a+p6xA3Ev18utuGhiUa6
DZzVeR6dzKM6IJmyoz4WhwaHXvFJYzJzzlccF0BNDvMMAfMfGsSB4lXAavfqNZc=
=BlRQ
-END PGP SIGNATURE-

-- 
-- 
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: [vim/vim] Static analysis report (#1049)

2016-09-11 Fir de Conversatie Christian Brabandt

Hi Yegappan!

On Fr, 09 Sep 2016, Yegappan Lakshmanan wrote:

> Hi Christian,
> 
> On Fri, Sep 9, 2016 at 12:08 AM, Christian Brabandt
>  wrote:
> > How did you create that report?
> >
> 
> I use the following steps to run static analysis using the clang
> static analyzer (http://clang-analyzer.llvm.org/)
> 
> $ scan-build -o /tmp/vim_report ./configure --with-features=huge
> $ scan-build -o /tmp/vim_report make

Would it make sense, to run something like this regularly?

Best,
Christian
-- 
Wichtigtuer sind Leute, die nie etwas Wichtiges tun.
-- Henri Nannen

-- 
-- 
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: test popupmenu question

2016-09-11 Fir de Conversatie Christian Brabandt

On So, 11 Sep 2016, h_east wrote:

> Hi ChrisBra, Bram and list,
> 2016-7-24(Sun) 0:36:14 UTC+9 Christian Brabandt:
> > On Sa, 23 Jul 2016, Bram Moolenaar wrote:
> > > Christian Brabandt wrote:
> > I think I also found a bug, and this makes the test currently fail.
> > Take this example from the test:
> > 
> > (The popupmenu is the one from the help for all months)
> > The initial state of the buffer is this:
> > ,
> > | D
> > | December2015
> > `
> 
> I have investigated this behavior.
> 
> Related vim_dev threads:
> - Patch 7.4.2146
>   https://groups.google.com/d/msg/vim_dev/75ZXlRlBzl4/DDnqvSn9BgAJ
> - [vim/vim] VIM 7.4: Possible regression via patch 2146? (#972)
>   https://groups.google.com/d/msg/vim_dev/mQ2YacpOKvo/vOsgkU-2AQAJ
> - Patch 7.4.2188
>   https://groups.google.com/d/msg/vim_dev/e2Rr8Px3qkQ/1XWiAQ0LAgAJ
> 
> I think the series of  behavior is correct.

okay.

> > ,
> > | Dece
> > | 
> > | December2015
> > `
> > (because after inserting the match  is still in popupmenu mode and
> > "ends completion and goes back to what was there before selecting a 
> > match")
> > 
> > However, a total mystery is to me, when the test is run, it will 
> > complete to 
> > 
> > ,
> > | December2015
> > | December2015
> > | December2015
> > `
> 
> Hmm?, I got the following result. (make test_popup in 7.4.2358)
> 
> 1 FAILED:
> Found errors in Test_popup_complete2():
> function RunTheTest[9]..Test_popup_complete2 line 10: Expected 
> ['December2015', '', 'December2015'] but got ['Dece', '', 'December2015']
> 
> I think `['Dece', '', 'December2015']` is right.

Okay then we can enable the test again and need to change the test 
assert.

Best,
Christian
-- 
Alles was man will, kostet etwas mehr als es wert ist.
  (Das zweite Gesetz der Thermodynamik)

-- 
-- 
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: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

2016-09-11 Fir de Conversatie Christian Brabandt

Hi Björn!

On So, 11 Sep 2016, Björn Linse wrote:

> On Sunday, September 11, 2016 at 6:14:14 PM UTC+2, Björn Linse wrote:
> > 615351832d75df3dfbc3f22694e675583e0b325d
> BTW, something is wrong with the github <-> vim-dev bridge, this comment (and 
> the edited version with the correct link below) is really by ZyX-I, but 
> posted by the bridge on vim-dev under my name (Björn Linse).

I received the same mail with the wrong From header from github.

Best,
Christian
-- 
Willst du dir den Tag versauen, mußt du in den Spiegel schauen.

-- 
-- 
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: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

2016-09-11 Fir de Conversatie Björn Linse

On Sunday, September 11, 2016 at 6:14:14 PM UTC+2, Björn Linse wrote:
> 615351832d75df3dfbc3f22694e675583e0b325d
> 
> 
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub

BTW, something is wrong with the github <-> vim-dev bridge, this comment (and 
the edited version with the correct link below) is really by ZyX-I, but posted 
by the bridge on vim-dev under my name (Björn Linse).

-- 
-- 
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: test popupmenu question

2016-09-11 Fir de Conversatie h_east

Hi ChrisBra, Bram and list,

2016-7-24(Sun) 0:36:14 UTC+9 Christian Brabandt:
> Hi Bram!
> 
> On Sa, 23 Jul 2016, Bram Moolenaar wrote:
> 
> > 
> > Christian Brabandt wrote:
> > 
> > > Bram,
> > > I am writing a test for the popupmenu and the different keys, that can 
> > > be used there (:h popupmenu-keys)
> > 
> > Thanks, that is useful.
> > 
> > > And I have some questions.
> > > 1)
> > > 
> > > ,
> > > | In the first state these keys have a special meaning:
> > > |  and CTRL-H   Delete one character, find the matches for the word 
> > > before
> > > |   the cursor.  This reduces the list of matches, often 
> > > to one
> > > |   entry, and switches to the second state.
> > > `
> > > 
> > > I fail to understand what this does, especially in difference to the 
> > > second state:
> > 
> > For example, if you type "compl" then you get a list of matches,
> > and the first one is used for the text.  That could be "completion".
> > Still the matches for "compl" are shown.
> > Then typing BS changes it to "completio" and only matches for that are
> > shown.
> 
> Hm, that works when using , but not when using, e.g.
> calling the completion menu like this:
> 
> inoremap  =ListMonths()
> 
> Then  will always end the completion menu and remove the last 
> letter.
> 
> I did not think, that there is a difference depending on how the 
> completion menu is called. This might be a bug.
> 
> > > ,
> > > | In the second and third state these keys have a special meaning:
> > > |  and CTRL-H   Delete one character, find the matches for the 
> > > shorter word
> > > |   before the cursor.  This may find more matches.
> > > `
> > > 
> > > And whatever I do, using  will always end the completion menu and 
> > > remove one character. Either from the last typed char or from the 
> > > inserted char. I can't seem to figure out, how to use  to adjust the 
> > > number of entries in the completion menu.
> > 
> > The main difference is that in the second state the highlighted item
> > differs from what the current text is.
> 
> Oh yes. Emphasis on "Cursor Key". Basically, that happens only then. Now 
> I understand.
> 
> > 
> > > 2) The behaviour of the enter key
> > > 
> > > ,
> > > | The behavior of the  key depends on the state you are in:
> > > | first state:  Use the text as it is and insert a line break.
> > > | second state: Insert the currently selected match.
> > > | third state:  Use the text as it is and insert a line break.
> > > `
> > > 
> > > For me the  Key will always insert a line break.
> > 
> > Not for me.  Probably depends on 'completeopt'.  My value is
> > menu,preview
> 
> Yeah, once i figured, that I need to use the cursor keys to select the 
> match, it works as expected.
> 
> > It's possible that the help is not correct for all possible ways
> > completion works.  The code is very complicated and there are many
> > corner cases.
> 
> Well, here is an updated patch for the popupmenu.
> 
> I think I also found a bug, and this makes the test currently fail.
> Take this example from the test:
> 
> (The popupmenu is the one from the help for all months)
> The initial state of the buffer is this:
> ,
> | D
> | December2015
> `

I have investigated this behavior.

Related vim_dev threads:
- Patch 7.4.2146
  https://groups.google.com/d/msg/vim_dev/75ZXlRlBzl4/DDnqvSn9BgAJ
- [vim/vim] VIM 7.4: Possible regression via patch 2146? (#972)
  https://groups.google.com/d/msg/vim_dev/mQ2YacpOKvo/vOsgkU-2AQAJ
- Patch 7.4.2188
  https://groups.google.com/d/msg/vim_dev/e2Rr8Px3qkQ/1XWiAQ0LAgAJ

I think the series of  behavior is correct.

> 
> (cursor at D, press )
> 
> Now if you want to complete the letter D this should only complete to 
> December, since all other values do not match it and therefore it should 
> be completed immediately to December and no menu shown. Therefore, 
> pressing  afterwards should select the letter from below the 
> cursors line, so it should complete to "December2015" if you press  
> 4 times, then there should be a new line because of the enter and then 
> the "December2015" should be shown. So in the end, the buffer should 
> look like this:
> 
> ,
> | December2015
> | 
> | December2015
> `

"the popup menu is not visible" is not equivalent to  "the completion mode is 
not active".
After the type , Vim still stay in the first state of the completion mode.
It is not related to the visible of popup menu.
Check on the gdb.

(gdb) p compl_started
$4 = 1
(gdb) p pum_visible()
$5 = 0

So that, the first  behavior `complete_CTRL-E` is correct.
Of course, the second and more  is `i_CTRL_E`.

> 
> For whatever reason, doing it interactively, this results in:
> 
> ,
> | Dece
> | 
> | December2015
> `
> (because after inserting the match  is still in popupmenu mode and
> "ends completion and goes back to what was there before selecting a 
> match")
> 
> However, a total mystery is to me,

Re: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

2016-09-11 Fir de Conversatie Nikolay Aleksandrovich Pavlov

I would suggest something like below, but I have no tests.

commit 615351832d75df3dfbc3f22694e675583e0b325d
Author: ZyX 
Date:   Tue Aug 16 21:42:24 2016 +0300

Use surrogateescape when appropriate

diff --git a/src/if_py_both.h b/src/if_py_both.h
index 35ad5d0..6709300 100644
--- a/src/if_py_both.h
+++ b/src/if_py_both.h
@@ -134,7 +134,8 @@ StringToChars(PyObject *obj, PyObject **todecref)
 {
  PyObject *bytes;

- if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, NULL)))
+ if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT,
+ ERRORS_ENCODE_ARG)))
 return NULL;

  if(PyBytes_AsStringAndSize(bytes, (char **) , NULL) == -1
@@ -4117,7 +4118,8 @@ StringToLine(PyObject *obj)
 }
 else if (PyUnicode_Check(obj))
 {
- if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, NULL)))
+ if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT,
+ ERRORS_ENCODE_ARG)))
 return NULL;

  if (PyBytes_AsStringAndSize(bytes, , ) == -1
@@ -6197,7 +6199,7 @@ _ConvertFromPyObject(PyObject *obj, typval_T
*tv, PyObject *lookup_dict)
  PyObject *bytes;
  char_u *str;

- bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, NULL);
+ bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, ERRORS_ENCODE_ARG);
  if (bytes == NULL)
 return -1;

diff --git a/src/if_python.c b/src/if_python.c
index 622634d..1cafe34 100644
--- a/src/if_python.c
+++ b/src/if_python.c
@@ -70,6 +70,9 @@
 # undef PY_SSIZE_T_CLEAN
 #endif

+#define ERRORS_DECODE_ARG NULL
+#define ERRORS_ENCODE_ARG ERRORS_DECODE_ARG
+
 #if defined(MACOS) && !defined(MACOS_X_UNIX)
 # include "macglue.h"
 # include 
diff --git a/src/if_python3.c b/src/if_python3.c
index 10984cd..9085c3c 100644
--- a/src/if_python3.c
+++ b/src/if_python3.c
@@ -91,12 +91,15 @@
 /* Python 3 does not support CObjects, always use Capsules */
 #define PY_USE_CAPSULE

+#define ERRORS_DECODE_ARG CODEC_ERROR_HANDLER
+#define ERRORS_ENCODE_ARG ERRORS_DECODE_ARG
+
 #define PyInt Py_ssize_t
 #ifndef PyString_Check
 # define PyString_Check(obj) PyUnicode_Check(obj)
 #endif
 #define PyString_FromString(repr) \
-PyUnicode_Decode(repr, STRLEN(repr), ENC_OPT, NULL)
+PyUnicode_Decode(repr, STRLEN(repr), ENC_OPT, ERRORS_DECODE_ARG)
 #define PyString_FromFormat PyUnicode_FromFormat
 #ifndef PyInt_Check
 # define PyInt_Check(obj) PyLong_Check(obj)
@@ -969,8 +972,8 @@ DoPyCommand(const char *cmd, rangeinitializer
init_range, runner run, void *arg)
 /* PyRun_SimpleString expects a UTF-8 string. Wrong encoding may cause
  * SyntaxError (unicode error). */
 cmdstr = PyUnicode_Decode(cmd, strlen(cmd),
- (char *)ENC_OPT, CODEC_ERROR_HANDLER);
-cmdbytes = PyUnicode_AsEncodedString(cmdstr, "utf-8", CODEC_ERROR_HANDLER);
+ (char *)ENC_OPT, ERRORS_DECODE_ARG);
+cmdbytes = PyUnicode_AsEncodedString(cmdstr, "utf-8", ERRORS_ENCODE_ARG);
 Py_XDECREF(cmdstr);

 run(PyBytes_AsString(cmdbytes), arg, );
@@ -1642,7 +1645,7 @@ LineToString(const char *str)
 }
 *p = '\0';

-result = PyUnicode_Decode(tmp, len, (char *)ENC_OPT, CODEC_ERROR_HANDLER);
+result = PyUnicode_Decode(tmp, len, (char *)ENC_OPT, ERRORS_DECODE_ARG);

 vim_free(tmp);
 return result;

-- 
-- 
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.
commit 615351832d75df3dfbc3f22694e675583e0b325d
Author: ZyX 
Date:   Tue Aug 16 21:42:24 2016 +0300

Use surrogateescape when appropriate

diff --git a/src/if_py_both.h b/src/if_py_both.h
index 35ad5d0..6709300 100644
--- a/src/if_py_both.h
+++ b/src/if_py_both.h
@@ -134,7 +134,8 @@ StringToChars(PyObject *obj, PyObject **todecref)
 {
PyObject*bytes;
 
-   if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, NULL)))
+   if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT,
+   ERRORS_ENCODE_ARG)))
return NULL;
 
if(PyBytes_AsStringAndSize(bytes, (char **) , NULL) == -1
@@ -4117,7 +4118,8 @@ StringToLine(PyObject *obj)
 }
 else if (PyUnicode_Check(obj))
 {
-   if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, NULL)))
+   if (!(bytes = PyUnicode_AsEncodedString(obj, ENC_OPT,
+   ERRORS_ENCODE_ARG)))
return NULL;
 
if (PyBytes_AsStringAndSize(bytes, , ) == -1
@@ -6197,7 +6199,7 @@ _ConvertFromPyObject(PyObject *obj, typval_T *tv, 
PyObject *lookup_dict)
PyObject*bytes;
char_u  *str;
 
-   bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, NULL);
+   bytes = PyUnicode_AsEncodedString(obj, ENC_OPT, ERRORS_ENCODE_ARG);
if (bytes == NULL)

Patch 7.4.2364

2016-09-11 Fir de Conversatie Bram Moolenaar


Patch 7.4.2364
Problem:Sort test sometimes fails.
Solution:   Add it to the list of flaky tests.
Files:  src/testdir/runtest.vim


*** ../vim-7.4.2363/src/testdir/runtest.vim 2016-09-03 22:35:02.396409822 
+0200
--- src/testdir/runtest.vim 2016-09-11 16:48:17.244419871 +0200
***
*** 144,150 
  endif
  
  " Names of flaky tests.
! let s:flaky = ['Test_reltime()', 'Test_nb_basic()', 'Test_communicate()']
  
  " Locate Test_ functions and execute them.
  set nomore
--- 144,155 
  endif
  
  " Names of flaky tests.
! let s:flaky = [
!   \ 'Test_reltime()',
!   \ 'Test_nb_basic()',
!   \ 'Test_communicate()'
!   \ 'Test_pipe_through_sort_some()'
!   \ ]
  
  " Locate Test_ functions and execute them.
  set nomore
*** ../vim-7.4.2363/src/version.c   2016-09-11 15:08:53.116083890 +0200
--- src/version.c   2016-09-11 16:46:45.805697578 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2364,
  /**/

-- 
You are Dead.  Do you wish to restart, load, or quit?

 /// 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: Patch 7.4.2200

2016-09-11 Fir de Conversatie LCD 47

On 11 September 2016, Bram Moolenaar  wrote:
> 
> Lcd wrote:
> 
> > On 12 August 2016, Bram Moolenaar  wrote:
> > > 
> > > Patch 7.4.2200
> > > Problem:Cannot get all information about a quickfix list.
> > > Solution:   Add an optional argument to get/set loc/qf list(). (Yegappan
> > > Lakshmanan)
> > [...]
> > > + If the optional {what} dictionary argument is supplied, 
> > > then
> > > + returns only the items listed in {what} as a 
> > > dictionary. The
> > > + following string items are supported in {what}:
> > > + nr  get information for this quickfix list
> > > + title   get list title
> > > + winid   get window id (if opened)
> > > + all all of the above quickfix properties
> > > + Non-string items in {what} are ignored.
> > > + If "nr" is not present then the current quickfix list 
> > > is used.
> > [...]
> > 
> > I'm trying to make sure a plugin is not messing with some other
> > plugin's loclists.  Towards that purpose, being able to set and get
> > a loclist's title is useful but not enough.
> >
> > One possible solution would be for loclists (and quickfix lists)
> > to have globally unique IDs.  This ID could be as simple as a
> > global, always increasing sequence number that would be assigned to
> > loclists upon their creation, independently of the starting window.
> > Of course, getloclist() should be able to return this number upon
> > request.
> >
> > Another possible solution would be to track the current loclist
> > using the "nr" above, which is essentially the index of the current
> > loclist in the loclist stack.  This is more problematic, as the
> > current interface is incomplete.  It isn't possible to get the
> > current depth of the stack, and the only way to get the "nr" for
> > the current loclist is to query for "all" and ignore the irrelevant
> > fields in the result.  These could be addressed by adding a new
> > field, say "max", that would return the current stack depth, and by
> > making a query for { "nr": 0 } return (just) the "nr" of the current
> > loclist.
> >
> > More seriously however, there is no way to tell when the stack
> > is full, and when some older loclists have been recycled.  I also
> > don't think there is any way to explicitly discard a specific
> > loclist.  Doing something like
> >
> > call setloclist(0, [], 'r')
> >
> > might have that effect (I haven't checked), but some more direct
> > cleanup mechanism that would free() all structures involved would be
> > nice.
> >
> > Yet another possible solution would be to add to loclists (and
> > quickfix lists) a field named, say, "owner" that would be get-able
> > and set-able.  I think an unique ID would be preferrable though.
>
> Makes sense.  For the same reason we added the window ID.  So next to
> the title we can have a unique ID.
>
> I suppose we should then also have a function to get the list of IDs.
> In a way it maps to the index number.

A function to manipulate the stack could handle that.  Christian
Brabandt posted something like that a while ago, but had a number of
bugs, and it tried to return the contents of the loclists, which could
be potentially huge.  I think something that would just dump the list of
IDs, move the stack pointer around would be enough for most uses.  Pop
would be nice too, but push probably doesn't make complete sense.

That would solve the problem of finding out when some loclists have
been recycled.

/lcd

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

Patch 7.4.2363

2016-09-11 Fir de Conversatie Bram Moolenaar


Patch 7.4.2363
Problem:Superfluous function prototypes.
Solution:   Remove them.
Files:  src/regexp.c


*** ../vim-7.4.2362/src/regexp.c2016-08-29 22:48:12.165106045 +0200
--- src/regexp.c2016-09-09 20:20:20.692773353 +0200
***
*** 255,263 
  #define un_Magic(x)   ((x) + 256)
  #define is_Magic(x)   ((x) < 0)
  
- static int no_Magic(int x);
- static int toggle_Magic(int x);
- 
  static int
  no_Magic(int x)
  {
--- 255,260 
*** ../vim-7.4.2362/src/version.c   2016-09-11 14:39:50.076156942 +0200
--- src/version.c   2016-09-11 15:08:18.628560596 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2363,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
235. You start naming your kids Pascal, COBOL, Algol and Fortran.

 /// 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: Update Japanese translations for Vim 7.4.2358

2016-09-11 Fir de Conversatie MURAOKA Taro

> Thanks.  It looks like only the translations in src/po have changed.

Yes, you are right.
Sorry for forgetting to mention it.

2016-09-11 21:48 GMT+09:00 Bram Moolenaar <b...@moolenaar.net>:
>
> Taro Muraoka wrote:
>
>> I and vim-jp members have released updated Japanese files for Vim as 
>> attached.
>> You can see its details at
>> https://github.com/vim-jp/lang-ja/releases/tag/20160911
>
> Thanks.  It looks like only the translations in src/po have changed.
>
>
> --
> hundred-and-one symptoms of being an internet addict:
> 234. You started college as a chemistry major, and walk out four years
>  later as an Internet provider.
>
>  /// 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///



-- 
MURAOKA Taro <koron.kaor...@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.

Re: Update Japanese translations for Vim 7.4.2358

2016-09-11 Fir de Conversatie Bram Moolenaar


Taro Muraoka wrote:

> I and vim-jp members have released updated Japanese files for Vim as attached.
> You can see its details at
> https://github.com/vim-jp/lang-ja/releases/tag/20160911

Thanks.  It looks like only the translations in src/po have changed.


-- 
hundred-and-one symptoms of being an internet addict:
234. You started college as a chemistry major, and walk out four years
 later as an Internet provider.

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

Patch 7.4.2362

2016-09-11 Fir de Conversatie Bram Moolenaar


Patch 7.4.2362
Problem:Illegal memory access with ":1@". (Dominique Pelle)
Solution:   Correct cursor column after setting the line number.  Also avoid
calling end_visual_mode() when not in Visual mode.
Files:  src/ex_docmd.c, src/buffer.c


*** ../vim-7.4.2361/src/ex_docmd.c  2016-09-04 19:50:50.520985732 +0200
--- src/ex_docmd.c  2016-09-11 14:36:00.751311436 +0200
***
*** 9388,9393 
--- 9388,9394 
  int   prev_len = typebuf.tb_len;
  
  curwin->w_cursor.lnum = eap->line2;
+ check_cursor_col();
  
  #ifdef USE_ON_FLY_SCROLL
  dont_scroll = TRUE;   /* disallow scrolling here */
*** ../vim-7.4.2361/src/buffer.c2016-09-09 12:57:05.665313092 +0200
--- src/buffer.c2016-09-11 14:36:14.627120529 +0200
***
*** 580,586 
  
  /* When closing the current buffer stop Visual mode before freeing
   * anything. */
! if (buf == curbuf
  #if defined(EXITFREE)
&& !entered_free_all_mem
  #endif
--- 580,586 
  
  /* When closing the current buffer stop Visual mode before freeing
   * anything. */
! if (buf == curbuf && VIsual_active
  #if defined(EXITFREE)
&& !entered_free_all_mem
  #endif
***
*** 1389,1395 
}
  
/* When closing the current buffer stop Visual mode. */
!   if (buf == curbuf)
end_visual_mode();
  
/*
--- 1389,1395 
}
  
/* When closing the current buffer stop Visual mode. */
!   if (buf == curbuf && VIsual_active)
end_visual_mode();
  
/*
*** ../vim-7.4.2361/src/version.c   2016-09-10 19:17:37.703773521 +0200
--- src/version.c   2016-09-11 14:39:29.000446795 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2362,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
233. You start dreaming about web pages...in html.

 /// 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: Patch 7.4.2347

2016-09-11 Fir de Conversatie Bram Moolenaar


Dominique Pellé wrote:

> Bram Moolenaar wrote:
> >
> > Patch 7.4.2347
> > Problem:Crash when closing a buffer while Visual mode is active.
> > (Dominique Pelle)
> > Solution:   Adjust the position before computing the number of lines.
> > When closing the current buffer stop Visual mode.
> > Files:  src/buffer.c, src/normal.c, src/testdir/test_normal.vim
> 
> Hi
> 
> Using vim-7.4.2361, I see the following bug discovered using
> afl-fuzz and which is a regression introduced by patch 7.4.2347:
> 
> $ cat  call setline(1, ['', 'a b', '', ''])
> call feedkeys("/b\", 'x')
> 1@
> bw!
> EOF
> 
> $ valgrind vim -u NONE -i NONE -S bug.vim -cq 2> log
> 
> ==15099== Memcheck, a memory error detector
> ==15099== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==15099== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==15099== Command: vim -u NONE -N -S bug.vim -cq
> ==15099==
> ==15099== Invalid read of size 1
> ==15099==at 0x4C97F0: utf_ptr2char (mbyte.c:1761)
> ==15099==by 0x4E0046: adjust_cursor_eol (ops.c:3984)
> ==15099==by 0x4116C0: do_buffer (buffer.c:1393)
> ==15099==by 0x4119F2: do_bufdel (buffer.c:1089)
> ==15099==by 0x45FA4F: ex_bunload (ex_docmd.c:5514)
> ==15099==by 0x46808C: do_one_cmd (ex_docmd.c:2962)
> ==15099==by 0x46808C: do_cmdline (ex_docmd.c:1110)
> ==15099==by 0x45C651: do_source (ex_cmds2.c:4111)
> ==15099==by 0x45D0BB: cmd_source (ex_cmds2.c:3724)
> ==15099==by 0x46808C: do_one_cmd (ex_docmd.c:2962)
> ==15099==by 0x46808C: do_cmdline (ex_docmd.c:1110)
> ==15099==by 0x59B09B: exe_commands (main.c:2896)
> ==15099==by 0x59B09B: vim_main2 (main.c:781)
> ==15099==by 0x407B05: main (main.c:415)
> ==15099==  Address 0x76da9f1 is 1 bytes after a block of size 4,096 alloc'd
> ==15099==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==15099==by 0x4C242B: lalloc (misc2.c:942)
> ==15099==by 0x59BC10: mf_alloc_bhdr.isra.3 (memfile.c:907)
> ==15099==by 0x59C926: mf_new (memfile.c:381)
> ==15099==by 0x4A87FF: ml_new_data (memline.c:3513)
> ==15099==by 0x4AB1FC: ml_open (memline.c:400)
> ==15099==by 0x4103E6: open_buffer (buffer.c:160)
> ==15099==by 0x59AD01: create_windows (main.c:2668)
> ==15099==by 0x59AD01: vim_main2 (main.c:704)
> ==15099==by 0x407B05: main (main.c:415)
> ...snip...

Thanks.  It's not really a regression, but uncovering another problem.
The ":1@" changes the line number without correcting the column.

I tried writing a test, but since the "1@" command fails, and I can't
find another way of triggering the problem, I gave up on that.

-- 
The term "free software" is defined by Richard M. Stallman as
being software that isn't necessarily for free.  Confusing?
Let's call it "Stallman software" then!
-- Bram Moolenaar

 /// 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: Patch 7.4.2200

2016-09-11 Fir de Conversatie Bram Moolenaar


Lcd wrote:

> On 12 August 2016, Bram Moolenaar  wrote:
> > 
> > Patch 7.4.2200
> > Problem:Cannot get all information about a quickfix list.
> > Solution:   Add an optional argument to get/set loc/qf list(). (Yegappan
> > Lakshmanan)
> [...]
> > +   If the optional {what} dictionary argument is supplied, then
> > +   returns only the items listed in {what} as a dictionary. The
> > +   following string items are supported in {what}:
> > +   nr  get information for this quickfix list
> > +   title   get list title
> > +   winid   get window id (if opened)
> > +   all all of the above quickfix properties
> > +   Non-string items in {what} are ignored.
> > +   If "nr" is not present then the current quickfix list is used.
> [...]
> 
> I'm trying to make sure a plugin is not messing with some other
> plugin's loclists.  Towards that purpose, being able to set and get a
> loclist's title is useful but not enough.
> 
> One possible solution would be for loclists (and quickfix lists)
> to have globally unique IDs.  This ID could be as simple as a global,
> always increasing sequence number that would be assigned to loclists
> upon their creation, independently of the starting window.  Of course,
> getloclist() should be able to return this number upon request.
> 
> Another possible solution would be to track the current loclist
> using the "nr" above, which is essentially the index of the current
> loclist in the loclist stack.  This is more problematic, as the current
> interface is incomplete.  It isn't possible to get the current depth of
> the stack, and the only way to get the "nr" for the current loclist is
> to query for "all" and ignore the irrelevant fields in the result.
> These could be addressed by adding a new field, say "max", that would
> return the current stack depth, and by making a query for { "nr": 0 }
> return (just) the "nr" of the current loclist.
> 
> More seriously however, there is no way to tell when the stack is
> full, and when some older loclists have been recycled.  I also don't
> think there is any way to explicitly discard a specific loclist.  Doing
> something like
> 
> call setloclist(0, [], 'r')
> 
> might have that effect (I haven't checked), but some more direct cleanup
> mechanism that would free() all structures involved would be nice.
> 
> Yet another possible solution would be to add to loclists (and
> quickfix lists) a field named, say, "owner" that would be get-able and
> set-able.  I think an unique ID would be preferrable though.

Makes sense.  For the same reason we added the window ID.  So next to
the title we can have a unique ID.

I suppose we should then also have a function to get the list of IDs.
In a way it maps to the index number.

-- 
hundred-and-one symptoms of being an internet addict:
232. You start conversations with, "Have you gotten an ISDN line?"

 /// 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: sprintf()

2016-09-11 Fir de Conversatie Bram Moolenaar

John Marriott wrote:

> I notice that there are a large number of calls to sprintf() sprinkled 
> throughout the code (329 in the src directory in version 7.4.2361).
> 
> Would it be worth changing these calls to vim_snprint() (or snprintf())?

vim_snprintf() is slower than sprintf().  And in the end it uses
sprintf() to do its work.

There might be a few more places where there is no guarantee that the
buffer size is always sufficient, in those cases switching to
vim_snprintf() is useful.  But I would not blindly change all calls.

Also, I can't remember when we had an actual buffer overflow in
sprintf().  It appears to be uncommon (compared to other illegal memory
access that were reported).

-- 
hundred-and-one symptoms of being an internet addict:
230. You spend your Friday nights typing away at your keyboard

 /// 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: Patch 7.4.2200

2016-09-11 Fir de Conversatie LCD 47

On 12 August 2016, Bram Moolenaar  wrote:
> 
> Patch 7.4.2200
> Problem:Cannot get all information about a quickfix list.
> Solution:   Add an optional argument to get/set loc/qf list(). (Yegappan
> Lakshmanan)
[...]
> + If the optional {what} dictionary argument is supplied, then
> + returns only the items listed in {what} as a dictionary. The
> + following string items are supported in {what}:
> + nr  get information for this quickfix list
> + title   get list title
> + winid   get window id (if opened)
> + all all of the above quickfix properties
> + Non-string items in {what} are ignored.
> + If "nr" is not present then the current quickfix list is used.
[...]

I'm trying to make sure a plugin is not messing with some other
plugin's loclists.  Towards that purpose, being able to set and get a
loclist's title is useful but not enough.

One possible solution would be for loclists (and quickfix lists)
to have globally unique IDs.  This ID could be as simple as a global,
always increasing sequence number that would be assigned to loclists
upon their creation, independently of the starting window.  Of course,
getloclist() should be able to return this number upon request.

Another possible solution would be to track the current loclist
using the "nr" above, which is essentially the index of the current
loclist in the loclist stack.  This is more problematic, as the current
interface is incomplete.  It isn't possible to get the current depth of
the stack, and the only way to get the "nr" for the current loclist is
to query for "all" and ignore the irrelevant fields in the result.
These could be addressed by adding a new field, say "max", that would
return the current stack depth, and by making a query for { "nr": 0 }
return (just) the "nr" of the current loclist.

More seriously however, there is no way to tell when the stack is
full, and when some older loclists have been recycled.  I also don't
think there is any way to explicitly discard a specific loclist.  Doing
something like

call setloclist(0, [], 'r')

might have that effect (I haven't checked), but some more direct cleanup
mechanism that would free() all structures involved would be nice.

Yet another possible solution would be to add to loclists (and
quickfix lists) a field named, say, "owner" that would be get-able and
set-able.  I think an unique ID would be preferrable though.

/lcd

-- 
-- 
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: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

Re: Vim periodically trashes the start of a file

Re: [vim/vim] Static analysis report (#1049)

Re: test popupmenu question

Re: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

Re: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

Re: test popupmenu question

Re: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

Patch 7.4.2364

Re: Patch 7.4.2200

Patch 7.4.2363

Re: Update Japanese translations for Vim 7.4.2358

Re: Update Japanese translations for Vim 7.4.2358

Patch 7.4.2362

Re: Patch 7.4.2347

Re: Patch 7.4.2200

Re: sprintf()

Re: Patch 7.4.2200

18 matches

Site Navigation

Mail list logo

Footer information