date:20160824

autocommands not triggered for quickfix

2016-08-24 Fir de Conversatie Ramel Eshed

Hi Bram,

In the autocommand help it is mentioned that only few commands are triggered 
with the quickfix buffer. Is there a reason not to trigger other events? I'd 
expect that BufWinLeave, at least, would be triggered, like BufWinEnter does.

Thanks,
Ramel

-- 
-- 
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: Wish list for a more powerful search in Vim

2016-08-24 Fir de Conversatie Christian Brabandt

On Mi, 24 Aug 2016, Christian Brabandt wrote:

> Updated patch attached. This fixes the mentioned problem plus some off 
> by one error and adds some more tests

Sorry, please discard, it was the wrong patch. Correct patch attached to 
this mail.

Best,
Christian
-- 
Mann, bin ich belesen, ey.
-- Nina Hagen

-- 
-- 
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.
From 6544323e3400c04986a7538128f6983970191b81 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Tue, 26 Jul 2016 11:18:51 +0200
Subject: [PATCH] Make Ctrl-N/P jump to next/previous search match

Currently, you cannot move from one match to the next match
when doing a search '/' or '?'.
This patch adds the functionality to use 'Ctrl-N' to move the
cursor to the next match, if 'insearch' is set. Similarily 'Ctrl-P' will
move to the previous match.

Also c_CTRL-N and c_CTRL-P are already used to move within in history of
search patterns, I have for now made them something different in search
mode, when incsearch is set. This is because c_CTRL-L already does
something useful in search mode and second, because Ctrl-N and
Ctrl-P are already used to select next/previous match in completion mode
so it seems logically to also extend their use in search mode.

Bugfixes: - works correctly with Ctrl-P after ? search
  - after clearing the search command line, starts searching
back at the original position
  - works correctly, when using \? in a forward search / and
then jumping backwards using Ctrl-P
  - obey to 'wrapscan' setting
  - beep, when no further match is found
  - fix cursor moved when backspacing a character and adding
another char
  - when wrapping around and finishing the search using 
make sure, cursor is back at the match
  - Make sure, going backwards skips to the correct match
(Skip SEARCH_COL for going backwards)
  - add test_search.vim for testing
(drop modeline)

Updated enhanced search patch
---
 runtime/doc/cmdline.txt |   9 ++
 src/ex_getln.c  | 160 -
 src/testdir/Make_all.mak|   1 +
 src/testdir/test_search.vim | 242 
 4 files changed, 384 insertions(+), 28 deletions(-)
 create mode 100644 src/testdir/test_search.vim

diff --git a/runtime/doc/cmdline.txt b/runtime/doc/cmdline.txt
index 8186678..7fe2a34 100644
--- a/runtime/doc/cmdline.txt
+++ b/runtime/doc/cmdline.txt
@@ -409,11 +409,19 @@ CTRL-D		List names that match the pattern in front of the cursor.
 			*c_CTRL-N*
 CTRL-N		After using 'wildchar' which got multiple matches, go to next
 		match.  Otherwise recall more recent command-line from history.
+		*/_CTRL-N*
+		When 'incsearch' is set, entering a search pattern for "/" or
+		"?" and the current match is displayed then CTRL-N will move
+		to the next match (does not take |search-offset| into account)
 			*c_CTRL-P* *c_*
 CTRL-P		After using 'wildchar' which got multiple matches, go to
 		previous match.  Otherwise recall older command-line from
 		history.   only works with the GUI, on the Amiga and
 		with MS-DOS.
+		*/_CTRL-P*
+		When 'incsearch' is set, entering a search pattern for "/" or
+		"?" and the current match is displayed then CTRL-P will move
+		to the previous match (does not take |search-offset| into account).
 			*c_CTRL-A*
 CTRL-A		All names that match the pattern in front of the cursor are
 		inserted.
@@ -423,6 +431,7 @@ CTRL-L		A match is done on the pattern in front of the cursor.  If
 		If there are multiple matches the longest common part is
 		inserted in place of the pattern.  If the result is shorter
 		than the pattern, no completion is done.
+			*/_CTRL-L*
 		When 'incsearch' is set, entering a search pattern for "/" or
 		"?" and the current match is displayed then CTRL-L will add
 		one character from the end of the current match.  If
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 642e090..819f084 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -137,6 +137,9 @@ _RTLENTRYF
 #endif
 sort_func_compare(const void *s1, const void *s2);
 #endif
+#ifdef FEAT_SEARCH_EXTRA
+static void set_search_match(pos_T *t);
+#endif
 
 /*
  * getcmdline() - accept a command line starting with firstc.
@@ -178,6 +181,9 @@ getcmdline(
 colnr_T	old_curswant;
 colnr_T	old_leftcol;
 linenr_T	old_topline;
+pos_T

Re: Wish list for a more powerful search in Vim

2016-08-24 Fir de Conversatie Christian Brabandt

On So, 21 Aug 2016, Christian Brabandt wrote:

> On Mo, 08 Aug 2016, Yegappan Lakshmanan wrote:
> 
> > In the above line with the cursor at the beginning of the line,
> > search for "text", press  and then press .
> > The expected behavior is for the cursor to be placed at the
> > first "text". But the cursor is not moved and is still placed
> > at the second "text".
> > 
> > If the pattern appears in a different line, then the problem is
> > not seen. Example:
> > 
> > some text
> > some text
> 
> Thanks for the feedback. Will send an update later this week.

Updated patch attached. This fixes the mentioned problem plus some off 
by one error and adds some more tests

Best,
Christian
-- 
Warum sterben die allermeisten Leute genau drei Tage vor ihrer
Beerdigung, und warum tut niemand etwas gegen diese Beerdigungen?

-- 
-- 
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.
From f7e06483300fcc632414ad49afb30f4459336d78 Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Tue, 26 Jul 2016 11:18:51 +0200
Subject: [PATCH] Make Ctrl-N/P jump to next/previous search match

Currently, you cannot move from one match to the next match
when doing a search '/' or '?'.
This patch adds the functionality to use 'Ctrl-N' to move the
cursor to the next match, if 'insearch' is set. Similarily 'Ctrl-P' will
move to the previous match.

Also c_CTRL-N and c_CTRL-P are already used to move within in history of
search patterns, I have for now made them something different in search
mode, when incsearch is set. This is because c_CTRL-L already does
something useful in search mode and second, because Ctrl-N and
Ctrl-P are already used to select next/previous match in completion mode
so it seems logically to also extend their use in search mode.

Bugfixes: - works correctly with Ctrl-P after ? search
  - after clearing the search command line, starts searching
back at the original position
  - works correctly, when using \? in a forward search / and
then jumping backwards using Ctrl-P
  - obey to 'wrapscan' setting
  - beep, when no further match is found
  - fix cursor moved when backspacing a character and adding
another char
  - when wrapping around and finishing the search using 
make sure, cursor is back at the match
  - add test_search.vim for testing

Updated enhanced search patch
---
 runtime/doc/cmdline.txt |   9 ++
 src/ex_getln.c  | 163 +---
 src/testdir/Make_all.mak|   1 +
 src/testdir/test_search.vim | 198 
 4 files changed, 343 insertions(+), 28 deletions(-)
 create mode 100644 src/testdir/test_search.vim

diff --git a/runtime/doc/cmdline.txt b/runtime/doc/cmdline.txt
index 8186678..7fe2a34 100644
--- a/runtime/doc/cmdline.txt
+++ b/runtime/doc/cmdline.txt
@@ -409,11 +409,19 @@ CTRL-D		List names that match the pattern in front of the cursor.
 			*c_CTRL-N*
 CTRL-N		After using 'wildchar' which got multiple matches, go to next
 		match.  Otherwise recall more recent command-line from history.
+		*/_CTRL-N*
+		When 'incsearch' is set, entering a search pattern for "/" or
+		"?" and the current match is displayed then CTRL-N will move
+		to the next match (does not take |search-offset| into account)
 			*c_CTRL-P* *c_*
 CTRL-P		After using 'wildchar' which got multiple matches, go to
 		previous match.  Otherwise recall older command-line from
 		history.   only works with the GUI, on the Amiga and
 		with MS-DOS.
+		*/_CTRL-P*
+		When 'incsearch' is set, entering a search pattern for "/" or
+		"?" and the current match is displayed then CTRL-P will move
+		to the previous match (does not take |search-offset| into account).
 			*c_CTRL-A*
 CTRL-A		All names that match the pattern in front of the cursor are
 		inserted.
@@ -423,6 +431,7 @@ CTRL-L		A match is done on the pattern in front of the cursor.  If
 		If there are multiple matches the longest common part is
 		inserted in place of the pattern.  If the result is shorter
 		than the pattern, no completion is done.
+			*/_CTRL-L*
 		When 'incsearch' is set, entering a search pattern for "/" or
 		"?" and the current match is displayed then CTRL-L will add
 		one character from the end of the current match.  If
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 642e090..7ce04b4 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -137,6

[patch] fixed compilation warning in syntax.c:9264

2016-08-24 Fir de Conversatie Dominique Pellé

Hi

I see these compilation warnings when compiling
vim-7.4.2250 (and older) with -Wall -Wextra:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/libpng12
-I/usr/include/harfbuzz -g -O0 -Wall -Wextra -Wshadow
-Wmissing-prototypes -Wunreachable-code -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1   -o objects/syntax.o syntax.c
In file included from syntax.c:14:0:
syntax.c: In function ‘set_hl_attr’:
vim.h:1635:6: warning: signed and unsigned type in conditional
expression [-Wsign-compare]
  : (long_u)INVALCOLOR) \
  ^
vim.h:1659:37: note: in expansion of macro ‘GUI_FUNCTION2’
 # define GUI_MCH_GET_RGB2(pixel)GUI_FUNCTION2(mch_get_rgb, (pixel))
 ^
syntax.c:9264:28: note: in expansion of macro ‘GUI_MCH_GET_RGB2’
  at_en.ae_u.cterm.fg_rgb = GUI_MCH_GET_RGB2(sgp->sg_gui_fg);
^
vim.h:1636:9: warning: signed and unsigned type in conditional
expression [-Wsign-compare]
 : termgui_##f((pixel)))
 ^
vim.h:1659:37: note: in expansion of macro ‘GUI_FUNCTION2’
 # define GUI_MCH_GET_RGB2(pixel)GUI_FUNCTION2(mch_get_rgb, (pixel))
 ^
syntax.c:9264:28: note: in expansion of macro ‘GUI_MCH_GET_RGB2’
  at_en.ae_u.cterm.fg_rgb = GUI_MCH_GET_RGB2(sgp->sg_gui_fg);
^
vim.h:1635:6: warning: signed and unsigned type in conditional
expression [-Wsign-compare]
  : (long_u)INVALCOLOR) \
  ^
vim.h:1659:37: note: in expansion of macro ‘GUI_FUNCTION2’
 # define GUI_MCH_GET_RGB2(pixel)GUI_FUNCTION2(mch_get_rgb, (pixel))
 ^
syntax.c:9265:28: note: in expansion of macro ‘GUI_MCH_GET_RGB2’
  at_en.ae_u.cterm.bg_rgb = GUI_MCH_GET_RGB2(sgp->sg_gui_bg);
^
vim.h:1636:9: warning: signed and unsigned type in conditional
expression [-Wsign-compare]
 : termgui_##f((pixel)))
 ^
vim.h:1659:37: note: in expansion of macro ‘GUI_FUNCTION2’
 # define GUI_MCH_GET_RGB2(pixel)GUI_FUNCTION2(mch_get_rgb, (pixel))
 ^
syntax.c:9265:28: note: in expansion of macro ‘GUI_MCH_GET_RGB2’
  at_en.ae_u.cterm.bg_rgb = GUI_MCH_GET_RGB2(sgp->sg_gui_bg);
^


Attached patch fixes by removing a cast.

Regards
Dominique.

-- 
-- 
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/vim.h b/src/vim.h
index 898ebb6..8d49dcd 100644
--- a/src/vim.h
+++ b/src/vim.h
@@ -1632,14 +1632,14 @@ typedef UINT32_TYPEDEF UINT32_T;
 #  define GUI_FUNCTION2(f, pixel)   (gui.in_use \
 ?  ((pixel) != INVALCOLOR \
 	? gui_##f((pixel)) \
-	: (long_u)INVALCOLOR) \
+	: INVALCOLOR) \
 : termgui_##f((pixel)))
 #  define USE_24BIT		(gui.in_use || p_tgc)
 # else
 #  define GUI_FUNCTION(f)	gui_##f
 #  define GUI_FUNCTION2(f,pixel)((pixel) != INVALCOLOR \
  ? gui_##f((pixel)) \
- : (long_u)INVALCOLOR)
+ : INVALCOLOR)
 #  define USE_24BIT		gui.in_use
 # endif
 #else

Patch 7.4.2251

2016-08-24 Fir de Conversatie Bram Moolenaar


Patch 7.4.2251
Problem:In rare cases diffing 4 buffers is not enough.
Solution:   Raise the limit to 8. (closes #1000)
Files:  src/structs.h, runtime/doc/diff.txt


*** ../vim-7.4.2250/src/structs.h   2016-08-23 23:50:06.864280017 +0200
--- src/structs.h   2016-08-24 22:31:20.192851146 +0200
***
*** 2296,2302 
  /*
   * Stuff for diff mode.
   */
! # define DB_COUNT 4   /* up to four buffers can be diff'ed */
  
  /*
   * Each diffblock defines where a block of lines starts in each of the buffers
--- 2296,2302 
  /*
   * Stuff for diff mode.
   */
! # define DB_COUNT 8   /* up to eight buffers can be diff'ed */
  
  /*
   * Each diffblock defines where a block of lines starts in each of the buffers
*** ../vim-7.4.2250/runtime/doc/diff.txt2014-10-31 13:54:21.839214469 
+0100
--- runtime/doc/diff.txt2016-08-24 22:32:38.351769893 +0200
***
*** 1,12 
! *diff.txt*  For Vim version 7.4.  Last change: 2013 Jul 07
  
  
  VIM REFERENCE MANUALby Bram Moolenaar
  
  
*diff* *vimdiff* *gvimdiff* *diff-mode*
! This file describes the |+diff| feature: Showing differences between two,
! three or four versions of the same file.
  
  The basics are explained in section |08.7| of the user manual.
  
--- 1,12 
! *diff.txt*  For Vim version 7.4.  Last change: 2016 Aug 24
  
  
  VIM REFERENCE MANUALby Bram Moolenaar
  
  
*diff* *vimdiff* *gvimdiff* *diff-mode*
! This file describes the |+diff| feature: Showing differences between two to
! eight versions of the same file.
  
  The basics are explained in section |08.7| of the user manual.
  
***
*** 117,123 
  If you always prefer a vertical split include "vertical" in 'diffopt'.
  
*E96*
! There can be up to four buffers with 'diff' set.
  
  Since the option values are remembered with the buffer, you can edit another
  file for a moment and come back to the same file and be in diff mode again.
--- 117,123 
  If you always prefer a vertical split include "vertical" in 'diffopt'.
  
*E96*
! There can be up to eight buffers with 'diff' set.
  
  Since the option values are remembered with the buffer, you can edit another
  file for a moment and come back to the same file and be in diff mode again.
***
*** 132,139 
if the current window does not have 'diff' set then no options
in it are changed.
  
! The ":diffoff" command resets the relevant options to the values they had when
! using |:diffsplit|, |:diffpatch| , |:diffthis|. or starting Vim in diff mode.
  Otherwise they are set to their default value:
  
'diff'  off
--- 132,140 
if the current window does not have 'diff' set then no options
in it are changed.
  
! The `:diffoff` command resets the relevant options to the values they had when
! using `:diffsplit`, `:diffpatch` , `:diffthis`. or starting Vim in diff mode.
! When using `:diffoff` twice the last saved values are restored.
  Otherwise they are set to their default value:
  
'diff'  off
***
*** 181,188 
  buffer.  If you don't want a buffer to remain used for the diff do ":set
  nodiff" before hiding it.
  
!   *:diffu* *:diffupdate*
! :diffu[pdate][!]  Update the diff highlighting and folds.
  
  Vim attempts to keep the differences updated when you make changes to the
  text.  This mostly takes care of inserted and deleted lines.  Changes within a
--- 182,189 
  buffer.  If you don't want a buffer to remain used for the diff do ":set
  nodiff" before hiding it.
  
!   *:dif* *:diffupdate*
! :dif[fupdate][!]  Update the diff highlighting and folds.
  
  Vim attempts to keep the differences updated when you make changes to the
  text.  This mostly takes care of inserted and deleted lines.  Changes within a
***
*** 314,319 
--- 315,333 
  
  Also see |'diffopt'| and the "diff" item of |'fillchars'|.
  
+   *diff-slow* *diff_translations*
+ For very long lines, the diff syntax highlighting might be slow, especially
+ since it tries to match all different kind of localisations. To disable
+ localisations and speed up the syntax highlighting, set the global variable
+ g:diff_translations to zero: >
+ 
+ let g:diff_translations = 0
+ <
+ After setting this variable, Reload the syntax script: >
+ 
+ set syntax=diff
+ <
+ 
  
  FINDING THE DIFFERENCES   *diff-diffexpr*
  
*** ../vim-7.4.2250/src/version.c   2016-08-24 22:11:52.337277956 +0200
--- src/version.c   2016-08-24

check for sandbox in viml?

2016-08-24 Fir de Conversatie Christian Brabandt

Hi,
now that we have the async and timer feature, wouldn't it make sense to 
have a way to check, whether Vim is in sandbox mode, so that some 
functions don't randomly trigger E48 errors and can check, whether it is 
okay to be executed?

Best,
Christian
-- 

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

2016-08-24 Fir de Conversatie Bram Moolenaar


Patch 7.4.2250
Problem:Some error message cannot be translated.
Solution:   Enclose them in _() and N_(). (Dominique Pelle)
Files:  src/channel.c, src/evalfunc.c, src/ex_cmds.c, src/spell.c,
src/window.c


*** ../vim-7.4.2249/src/channel.c   2016-08-01 15:40:24.179878441 +0200
--- src/channel.c   2016-08-24 22:10:07.810886548 +0200
***
*** 702,708 
  if ((host = gethostbyname(hostname)) == NULL)
  {
ch_error(channel, "in gethostbyname() in channel_open()");
!   PERROR("E901: gethostbyname() in channel_open()");
channel_free(channel);
return NULL;
  }
--- 702,708 
  if ((host = gethostbyname(hostname)) == NULL)
  {
ch_error(channel, "in gethostbyname() in channel_open()");
!   PERROR(_("E901: gethostbyname() in channel_open()"));
channel_free(channel);
return NULL;
  }
***
*** 729,735 
if (sd == -1)
{
ch_error(channel, "in socket() in channel_open().");
!   PERROR("E898: socket() in channel_open()");
channel_free(channel);
return NULL;
}
--- 729,735 
if (sd == -1)
{
ch_error(channel, "in socket() in channel_open().");
!   PERROR(_("E898: socket() in channel_open()"));
channel_free(channel);
return NULL;
}
***
*** 2070,2076 
  {
ch_error(channel, "received command with non-string argument");
if (p_verbose > 2)
!   EMSG("E903: received command with non-string argument");
return;
  }
  arg = argv[1].vval.v_string;
--- 2070,2076 
  {
ch_error(channel, "received command with non-string argument");
if (p_verbose > 2)
!   EMSG(_("E903: received command with non-string argument"));
return;
  }
  arg = argv[1].vval.v_string;
***
*** 2129,2141 
{
ch_error(channel, "last argument for expr/call must be a number");
if (p_verbose > 2)
!   EMSG("E904: last argument for expr/call must be a number");
}
else if (is_call && argv[2].v_type != VAR_LIST)
{
ch_error(channel, "third argument for call must be a list");
if (p_verbose > 2)
!   EMSG("E904: third argument for call must be a list");
}
else
{
--- 2129,2141 
{
ch_error(channel, "last argument for expr/call must be a number");
if (p_verbose > 2)
!   EMSG(_("E904: last argument for expr/call must be a number"));
}
else if (is_call && argv[2].v_type != VAR_LIST)
{
ch_error(channel, "third argument for call must be a list");
if (p_verbose > 2)
!   EMSG(_("E904: third argument for call must be a list"));
}
else
{
***
*** 2195,2201 
  else if (p_verbose > 2)
  {
ch_errors(channel, "Received unknown command: %s", (char *)cmd);
!   EMSG2("E905: received unknown command: %s", cmd);
  }
  }
  
--- 2195,2201 
  else if (p_verbose > 2)
  {
ch_errors(channel, "Received unknown command: %s", (char *)cmd);
!   EMSG2(_("E905: received unknown command: %s"), cmd);
  }
  }
  
***
*** 3382,3388 
if (!channel->ch_error && fun != NULL)
{
ch_errors(channel, "%s(): write while not connected", fun);
!   EMSG2("E630: %s(): write while not connected", fun);
}
channel->ch_error = TRUE;
return FAIL;
--- 3382,3388 
if (!channel->ch_error && fun != NULL)
{
ch_errors(channel, "%s(): write while not connected", fun);
!   EMSG2(_("E630: %s(): write while not connected"), fun);
}
channel->ch_error = TRUE;
return FAIL;
***
*** 3407,3413 
if (!channel->ch_error && fun != NULL)
{
ch_errors(channel, "%s(): write failed", fun);
!   EMSG2("E631: %s(): write failed", fun);
}
channel->ch_error = TRUE;
return FAIL;
--- 3407,3413 
if (!channel->ch_error && fun != NULL)
{
ch_errors(channel, "%s(): write failed", fun);
!   EMSG2(_("E631: %s(): write failed"), fun);
}
channel->ch_error = TRUE;
return FAIL;
*** ../vim-7.4.2249/src/evalfunc.c  2016-08-21 15:26:50.989702872 +0200
--- src/evalfunc.c  2016-08-24 22:08:23.480497324 +0200
***
*** 7413,7419 
return;
  if (id >= 1 && id <= 3)
  {
!   EMSGN("E798: ID is reserved for \":match\": %ld", id);
return;
  }
  
--- 7413,7419 
return;
  if (id >= 1 && id <= 3)
  {
!   EMSGN(_("E798: ID is reserved for \":match\": %ld"), id);
return;
  }
  
***
*** 7478,7484

Re: [patch] some error messages are not translated

2016-08-24 Fir de Conversatie Bram Moolenaar


Dominique wrote:

> Some error messages were not translated with gettext()
> in Vim-7.4.2243.
> 
> Fixed in attached patch.

Thanks!

I think the internal error doesn't need translation.

-- 
hundred-and-one symptoms of being an internet addict:
66. You create a homepage with the impression to cure the afflicted...but
your hidden agenda is to receive more e-mail.

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

2016-08-24 Fir de Conversatie Bram Moolenaar


Patch 7.4.2249
Problem:Missing colon in error message.
Solution:   Add the colon. (Dominique Pelle)
Files:  src/userfunc.c


*** ../vim-7.4.2248/src/userfunc.c  2016-08-11 22:51:01.641495491 +0200
--- src/userfunc.c  2016-08-24 22:03:33.964829689 +0200
***
*** 1955,1961 
p += 7;
if (current_funccal == NULL)
{
!   emsg_funcname(N_("E932 Closure function should not be at top 
level: %s"),
name == NULL ? (char_u *)"" : name);
goto erret;
}
--- 1955,1961 
p += 7;
if (current_funccal == NULL)
{
!   emsg_funcname(N_("E932: Closure function should not be at top 
level: %s"),
name == NULL ? (char_u *)"" : name);
goto erret;
}
***
*** 2738,2744 
/* A normal function (not a numbered function or lambda) has a
 * refcount of 1 for the entry in the hashtable.  When deleting
 * it and the refcount is more than one, it should be kept.
!* A numbered function and lambda snould be kept if the refcount is
 * one or more. */
if (fp->uf_refcount > (func_name_refcount(fp->uf_name) ? 0 : 1))
{
--- 2738,2744 
/* A normal function (not a numbered function or lambda) has a
 * refcount of 1 for the entry in the hashtable.  When deleting
 * it and the refcount is more than one, it should be kept.
!* A numbered function and lambda should be kept if the refcount is
 * one or more. */
if (fp->uf_refcount > (func_name_refcount(fp->uf_name) ? 0 : 1))
{
***
*** 3479,3485 
  }
  
  /*
!  * Get function call environment based on bactrace debug level
   */
  static funccall_T *
  get_funccal(void)
--- 3479,3485 
  }
  
  /*
!  * Get function call environment based on backtrace debug level
   */
  static funccall_T *
  get_funccal(void)
*** ../vim-7.4.2248/src/version.c   2016-08-24 21:21:22.572601394 +0200
--- src/version.c   2016-08-24 22:05:17.527251283 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2249,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
65. The last time you looked at the clock it was 11:30pm, and in what
seems like only a few seconds later, your sister runs past you to
catch her 7am school bus.

 /// 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] missing colon in E932

2016-08-24 Fir de Conversatie Bram Moolenaar


Dominique wrote:

> All errors numbers are followed by a colon, except E932 in evalfunc.c.
> Attached patch fixes it + fixes a couple of typos in evalfunc.c

Thanks!

-- 
hundred-and-one symptoms of being an internet addict:
64. The remote to the T.V. is missing...and you don't even care.

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

2016-08-24 Fir de Conversatie Bram Moolenaar


Christian Brabandt wrote:

> Am 2016-08-22 20:29, schrieb Bram Moolenaar:
> > Perhaps we better add a generic way to filter the output.  
> > Unfortunately
> > we can't use "command | grep /pattern/".  Not all commands accept
> > another command following.
> 
> True, but this is already documented at :h :bar and the obvious 
> workaround
> for that case would be to use :exe 'cmd' | grep /pattern/

But then you have to take care of escaping quotes.

> > We could put it in front:
> > 
> > filter /pattern/ command
> > 
> > It's like a command modifier then.  But one with an argument.
> > Note that the filtering would happen line-by-line, thus if there is an
> > item that takes several lines only matching ones would show up.
> 
> I am sorry, but this is ugly.

It's not perfect and may need to get used to, but at least you can type
it without any escaping and it works for all commands.

-- 
Time is money.  Especially if you make clocks.

 /// 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: compiler warning w/ Studio & gtk3 GUI

2016-08-24 Fir de Conversatie Bram Moolenaar


Kazunobu Kuriyama wrote:

> 2016-08-24 2:22 GMT+09:00 Danek Duvall :
> 
> > On Tue, Aug 23, 2016 at 06:01:54PM +0900, Kazunobu Kuriyama wrote:
> >
> > > Hi Danek,
> > >
> > > I think that mismatch is not our fault, either.
> >
> > Yeah, that was my thought, but I thought perhaps the Solaris setup was
> > somehow incorrect.  But it really does look like a bug in glib/gtk.  I'll
> > see if I can get a bug filed upstream.
> >
> > > That said, it would take some time to file the issue against them and
> > wait
> > > for their response to that; it would be better for us to do something
> > about
> > > that for ourselves.
> > >
> > > So I made a patch for fixing the issue, which is attached to this mail.
> > >
> > > For that, I assumed that the Solaris Studio had the predefined constant
> > > macro __SUNPRO_C.  Is that assumption OK?
> >
> > Yup, that seems reasonable.  And the patch works just fine -- no more
> > warnings, and the result seems to work just fine.
> >
> 
> Hi Danek,
> 
> Thanks!
> 
> 
> Bram, I attached an updated patch to this mail.  The previous patch has
> wrong indentation and superfluous parentheses.  The new patch fixes them.

Thanks, I'll check it out soon.

> > > If that's OK, could you try the patch to check if it works as expected?
> > >
> > > Note that the patch includes some minor fixes on coding style, too.
> > >
> > >
> > > > glib is 2.46, gtk3 is 3.18.
> > > >
> > > > I don't see this in the travis logs, but I can't tell from there what
> > > > versions of glib and gtk are in use.
> > > >
> > > > Does this look familiar to anyone?
> > >
> > > I didn't see either clang or gcc (generic one, not the one which is a
> > > symbolic link to clang) giving me any warning on the mismatch.  I didn't
> > > know about that until I read you report.
> >
> > Yeah; I wonder if gcc would show that with some more -W flags thrown in
> > there.
> 
> 
> I thought gcc had such a flag, but I've not found one in the manual yet...
> 
> 
> > I guess I'm a bit surprised that clang didn't show it; I thought it
> > did a better job of finding bad code.  I guess that's why we try to have a
> > diverse bundle of compilers.  :)
> >
> 
> Indeed.  And I envy you for the compiler :)

-- 
hundred-and-one symptoms of being an internet addict:
61. Your best friends know your e-mail address, but neither your phone number
nor the address where you live.

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

2016-08-24 Fir de Conversatie Bram Moolenaar


Patch 7.4.2248
Problem:When cancelling the :ptjump prompt a preview window is opened for
a following command.
Solution:   Reset g_do_tagpreview. (Hirohito Higashi)  Add a test.  Avoid that
the test runner gets stuck in trying to close a window.
Files:  src/tag.c, src/testdir/test_tagjump.vim, src/testdir/runtest.vim


*** ../vim-7.4.2247/src/tag.c   2016-08-20 16:56:48.250624340 +0200
--- src/tag.c   2016-08-24 21:09:24.083040384 +0200
***
*** 1078,1083 
--- 1078,1086 
curwin->w_tagstackidx = tagstackidx;
  #ifdef FEAT_WINDOWS
  postponed_split = 0;  /* don't split next time */
+ # ifdef FEAT_QUICKFIX
+ g_do_tagpreview = 0;  /* don't do tag preview next time */
+ # endif
  #endif
  
  #ifdef FEAT_CSCOPE
*** ../vim-7.4.2247/src/testdir/test_tagjump.vim2016-08-18 
23:04:44.662592810 +0200
--- src/testdir/test_tagjump.vim2016-08-24 20:57:24.142857315 +0200
***
*** 7,10 
--- 7,26 
set tagstack
  endfunc
  
+ func Test_cancel_ptjump()
+   set tags=Xtags
+   call writefile(["!_TAG_FILE_ENCODING\tutf-8\t//",
+ \ "word\tfile1\tcmd1",
+ \ "word\tfile2\tcmd2"],
+ \ 'Xtags')
+ 
+   only!
+   call feedkeys(":ptjump word\\", "xt")
+   help
+   call assert_equal(2, winnr('$'))
+ 
+   call delete('Xtags')
+   quit
+ endfunc
+ 
  " vim: shiftwidth=2 sts=2 expandtab
*** ../vim-7.4.2247/src/testdir/runtest.vim 2016-08-04 21:11:28.623170452 
+0200
--- src/testdir/runtest.vim 2016-08-24 21:05:55.838124787 +0200
***
*** 105,112 
endif
  
" Close any extra windows and make the current one not modified.
!   while winnr('$') > 1
  bwipe!
endwhile
set nomodified
  endfunc
--- 105,121 
endif
  
" Close any extra windows and make the current one not modified.
!   while 1
! let wincount = winnr('$')
! if wincount == 1
!   break
! endif
  bwipe!
+ if wincount == winnr('$')
+   " Did not manage to close a window.
+   only!
+   break
+ endif
endwhile
set nomodified
  endfunc
*** ../vim-7.4.2247/src/version.c   2016-08-24 00:39:01.421663470 +0200
--- src/version.c   2016-08-24 21:07:25.168840382 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2248,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
62. If your doorbell rings, you think that new mail has arrived.  And then
you're disappointed that it's only someone at the door.

 /// 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: [bug][patch] Unexpectedly preview window opened, after the `:ptjump` command canceled.

2016-08-24 Fir de Conversatie Bram Moolenaar


Hirohito Higashi wrote:

> Hi Bram and developers,
> 
> How to reproduce:
> - Change directory to your local vim/src directory.
>   $ cd /path-to-your-vim-clone-dir/vim/src
> - Start vanilla Vim.
>   $ ./vim -Nu NONE
> - Do tagjump and display in the preview window. (In fact, it becomes selected 
> wait because candidates are two)
>   :ptjump cmdmod
> - Cancel the selection.
>   
> - Display the help.
>   :help
> 
> Expected behavior:
> - Open the help window and display the help document.
> 
> Actual behavior:
> - Two windows opened.
>   Top window is preview window, and displayed the help document.
>   Next one is empty window.
> 
> 
> An attached patch fix this.

Thanks.

> Sorry for without a test.
> Tell me if there is an easy way to test in the Vim script.

Well, figuring out how to write a test for this means writing the test.
While writing a test I noticed it got stuck in the test runner.  So I
fixed that as well.

-- 
hundred-and-one symptoms of being an internet addict:
60. As your car crashes through the guardrail on a mountain road, your first
instinct is to search for the "back" button.

 /// 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: Does the visual bell work in GTK+ 3?

2016-08-24 Fir de Conversatie Tony Mechelynck

On Wed, Aug 24, 2016 at 8:03 PM, Tony Mechelynck
 wrote:
> On Wed, Aug 24, 2016 at 7:17 PM, Kazunobu Kuriyama
>  wrote:
>> Beep ((sound) bell) is implemented in both GTK+ 2 and GTK +3  using
>> gdk_display_bell() (gui_gtk_x11.c:6222, gui_mch_beep()), and there's no
>> interdependency between beep and visual bell.  Accordingly, visual bell
>> setting is irrelevant to the audibility of beep at all.
>>
>> And, on X11, gdk_display_bell() is implemented using either XkbBell() or
>> XBell(), which tells us that the beep sound comes from X11.
>>
>> You probably need to check if X11 bell (beep) is enabled or not, by using,
>> say 'xset -q'.
>
> One of the lines there says:
>   bell percent:  50bell pitch:  400bell duration:  100
>
> which mean IIRC 50% intensity, about a quarter-tone above the G a
> perfect fourth below middle C (as close as I can make it at 440 Hz
> diapason), and one-tenth of a second. I'll try raising the level and
> see if it comes through my speakers.
>
>
> Best regards,
> Tony.

With 80 523 125 I still don't hear anything.

IOW, no audible bell I don't know why, no visual bell because GTK3
gvim doesn't support it, ergo, no bell.


Best regards,
Tony.

-- 
-- 
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: Does the visual bell work in GTK+ 3?

2016-08-24 Fir de Conversatie Tony Mechelynck

On Wed, Aug 24, 2016 at 7:17 PM, Kazunobu Kuriyama
 wrote:
> Beep ((sound) bell) is implemented in both GTK+ 2 and GTK +3  using
> gdk_display_bell() (gui_gtk_x11.c:6222, gui_mch_beep()), and there's no
> interdependency between beep and visual bell.  Accordingly, visual bell
> setting is irrelevant to the audibility of beep at all.
>
> And, on X11, gdk_display_bell() is implemented using either XkbBell() or
> XBell(), which tells us that the beep sound comes from X11.
>
> You probably need to check if X11 bell (beep) is enabled or not, by using,
> say 'xset -q'.

One of the lines there says:
  bell percent:  50bell pitch:  400bell duration:  100

which mean IIRC 50% intensity, about a quarter-tone above the G a
perfect fourth below middle C (as close as I can make it at 440 Hz
diapason), and one-tenth of a second. I'll try raising the level and
see if it comes through my speakers.


Best regards,
Tony.

-- 
-- 
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: Does the visual bell work in GTK+ 3?

2016-08-24 Fir de Conversatie Kazunobu Kuriyama

2016-08-25 0:54 GMT+09:00 Tony Mechelynck :

> On Wed, Aug 24, 2016 at 12:08 PM, Kazunobu Kuriyama
>  wrote:
> > 2016-08-24 4:45 GMT+09:00 Tony Mechelynck 
> :
> >>
> >> With the following settings:
> >>
> >> :verbose set eb? vb? bo? t_vb?
> >>   errorbells
> >> Last set from ~/.vimrc
> >>   visualbell
> >> Last set from ~/.vimrc
> >> belloff=
> >> t_vb=^[|1000f
> >> Last set from ~/.vimrc
> >>
> >> (the latter is set in a GUIEnter autocommand, the rest in the .vimrc
> >> mainline code)
> >>
> >> when I hit  repeatedly, I hear no sound and I see no visual bell.
> >> This is for gvim 7.4.2243 with GTK3 GUI.
> >>
> >> With the visual bell time set at a full second, it ought not to be too
> >> fast for me to see it, don't you think? I have tested other values,
> >> including the default, with the same result, or lack of one; and I
> >> know about |option-backslash| to enter the vertical bar into the
> >> option value.
> >
> >
> > Hi Tony,
> >
> > As noted in gui_gtk_x11.c:6246--6249, that's not implemented yet.
> > (Actually, it was once implemented in an early stage of the development.)
> >
> > Needless to say, the purpose of visual bell is to notify the user that
> > something goes wrong with the editor, urging him to do something about
> that
> > (I mean this in a broad sense, including 'stop doing something').
> >
> > Its effect is, however, to keep flashing the whole editor screen until
> the
> > problem causing visual bell is fixed, which prevents what he is typing to
> > the editor from being legible on the screen.
> >
> > That deteriorates its purpose; while urging the user to do something,
> visual
> > bell interferes with what he does.
> >
> > Arguably, visual bell might be still useful for some simple use cases
> where
> > a problem causing annoying flash is gone once the user stops doing what
> he's
> > trying to do.
> >
> > But now that Vim supports asynchronous jobs.  We need to take into
> > consideration that visual bell may interfere with smooth interaction
> between
> > the user, Vim and a single or more external processes because visual bell
> > exclusively occupies CPU cycles for drawing flash if we naively port the
> > GTK+ 2 implementation to GTK+ 3.
> >
> > Best regards,
> > Kazunobu
> >
> >>
> >>
> >> Best regards,
> >> Tony.
> >>
> >> --
> >> --
> >> 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.
>
> I have a problem though: With or without 'visualbell', I don't hear
> the beep. I had thought that a visible one would at least make it
> noticeable, but if it isn't implemented...
>

Beep ((sound) bell) is implemented in both GTK+ 2 and GTK +3  using
gdk_display_bell() (gui_gtk_x11.c:6222, gui_mch_beep()), and there's no
interdependency between beep and visual bell.  Accordingly, visual bell
setting is irrelevant to the audibility of beep at all.

And, on X11, gdk_display_bell() is implemented using either XkbBell() or
XBell(), which tells us that the beep sound comes from X11.

You probably need to check if X11 bell (beep) is enabled or not, by using,
say 'xset -q'.


> AFAICR, the GTK2 visual bell inverted the screen once, then after a
> presettable delay it went back to normal. I never saw the Vim screen
> flashing forever until the user had done something.
>

What if an external asynchronous process causes flash?  To stop flash, the
user must do something, and then, flash surely gets in the way.

>
>
> Best regards,
> Tony.
>
> --
> --
> 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/vim] Changed DB_COUNT to 16 (#1000)

2016-08-24 Fir de Conversatie Charles E Campbell

Marius Gedminas wrote:
>
> I once needed to diff more files than vim would support (IIRC I was
> comparing lists of installed packages across five servers). Having to
> recompile vim for that was a pain.
>
> Forgetting that you set diff on for a buffer is already possible when
> you're diffing just two buffers -- I used to do that all the time.
> Increasing the number of diff'able buffers is not going to affect this
> one way or another.
>
>
Seems that this would be a case where one ought to be able to show
something in the status line -- and the 'diff' setting seems to be
useful in this regard.

So, may I suggest using something like:   set stl="... %{? "[DIFF]"
: ""} ..."  where the dots is your choice controlling whatever else you
might like to have in your statusline.  Maybe a %d (for [diff]) and %D
(for [DIFF]) would be useful for new statusline modifiers?  (presumably
would expand to nothing when  is false)

Regards,
Chip Campbell

-- 
-- 
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: Does the visual bell work in GTK+ 3?

2016-08-24 Fir de Conversatie Tony Mechelynck

On Wed, Aug 24, 2016 at 12:08 PM, Kazunobu Kuriyama
 wrote:
> 2016-08-24 4:45 GMT+09:00 Tony Mechelynck :
>>
>> With the following settings:
>>
>> :verbose set eb? vb? bo? t_vb?
>>   errorbells
>> Last set from ~/.vimrc
>>   visualbell
>> Last set from ~/.vimrc
>> belloff=
>> t_vb=^[|1000f
>> Last set from ~/.vimrc
>>
>> (the latter is set in a GUIEnter autocommand, the rest in the .vimrc
>> mainline code)
>>
>> when I hit  repeatedly, I hear no sound and I see no visual bell.
>> This is for gvim 7.4.2243 with GTK3 GUI.
>>
>> With the visual bell time set at a full second, it ought not to be too
>> fast for me to see it, don't you think? I have tested other values,
>> including the default, with the same result, or lack of one; and I
>> know about |option-backslash| to enter the vertical bar into the
>> option value.
>
>
> Hi Tony,
>
> As noted in gui_gtk_x11.c:6246--6249, that's not implemented yet.
> (Actually, it was once implemented in an early stage of the development.)
>
> Needless to say, the purpose of visual bell is to notify the user that
> something goes wrong with the editor, urging him to do something about that
> (I mean this in a broad sense, including 'stop doing something').
>
> Its effect is, however, to keep flashing the whole editor screen until the
> problem causing visual bell is fixed, which prevents what he is typing to
> the editor from being legible on the screen.
>
> That deteriorates its purpose; while urging the user to do something, visual
> bell interferes with what he does.
>
> Arguably, visual bell might be still useful for some simple use cases where
> a problem causing annoying flash is gone once the user stops doing what he's
> trying to do.
>
> But now that Vim supports asynchronous jobs.  We need to take into
> consideration that visual bell may interfere with smooth interaction between
> the user, Vim and a single or more external processes because visual bell
> exclusively occupies CPU cycles for drawing flash if we naively port the
> GTK+ 2 implementation to GTK+ 3.
>
> Best regards,
> Kazunobu
>
>>
>>
>> Best regards,
>> Tony.
>>
>> --
>> --
>> 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.

I have a problem though: With or without 'visualbell', I don't hear
the beep. I had thought that a visible one would at least make it
noticeable, but if it isn't implemented...

AFAICR, the GTK2 visual bell inverted the screen once, then after a
presettable delay it went back to normal. I never saw the Vim screen
flashing forever until the user had done something.


Best regards,
Tony.

-- 
-- 
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: compiler warning w/ Studio & gtk3 GUI

2016-08-24 Fir de Conversatie Danek Duvall

On Wed, Aug 24, 2016 at 07:09:01PM +0900, Kazunobu Kuriyama wrote:

> > I guess I'm a bit surprised that clang didn't show it; I thought it did
> > a better job of finding bad code.  I guess that's why we try to have a
> > diverse bundle of compilers.  :)
> 
> Indeed.  And I envy you for the compiler :)

It's available for free for production use on Linux, too:


http://www.oracle.com/technetwork/server-storage/developerstudio/downloads/index.html

though AFAIK you don't get any support whatsoever, not even patches.

Danek

-- 
-- 
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: compiler warning w/ Studio & gtk3 GUI

2016-08-24 Fir de Conversatie Kazunobu Kuriyama

2016-08-24 2:22 GMT+09:00 Danek Duvall :

> On Tue, Aug 23, 2016 at 06:01:54PM +0900, Kazunobu Kuriyama wrote:
>
> > Hi Danek,
> >
> > I think that mismatch is not our fault, either.
>
> Yeah, that was my thought, but I thought perhaps the Solaris setup was
> somehow incorrect.  But it really does look like a bug in glib/gtk.  I'll
> see if I can get a bug filed upstream.
>
> > That said, it would take some time to file the issue against them and
> wait
> > for their response to that; it would be better for us to do something
> about
> > that for ourselves.
> >
> > So I made a patch for fixing the issue, which is attached to this mail.
> >
> > For that, I assumed that the Solaris Studio had the predefined constant
> > macro __SUNPRO_C.  Is that assumption OK?
>
> Yup, that seems reasonable.  And the patch works just fine -- no more
> warnings, and the result seems to work just fine.
>

Hi Danek,

Thanks!


Bram, I attached an updated patch to this mail.  The previous patch has
wrong indentation and superfluous parentheses.  The new patch fixes them.


> > If that's OK, could you try the patch to check if it works as expected?
> >
> > Note that the patch includes some minor fixes on coding style, too.
> >
> >
> > > glib is 2.46, gtk3 is 3.18.
> > >
> > > I don't see this in the travis logs, but I can't tell from there what
> > > versions of glib and gtk are in use.
> > >
> > > Does this look familiar to anyone?
> >
> > I didn't see either clang or gcc (generic one, not the one which is a
> > symbolic link to clang) giving me any warning on the mismatch.  I didn't
> > know about that until I read you report.
>
> Yeah; I wonder if gcc would show that with some more -W flags thrown in
> there.


I thought gcc had such a flag, but I've not found one in the manual yet...


> I guess I'm a bit surprised that clang didn't show it; I thought it
> did a better job of finding bad code.  I guess that's why we try to have a
> diverse bundle of compilers.  :)
>

Indeed.  And I envy you for the compiler :)

>
> Thanks,
> Danek
>

Best regards,
Kazunobu

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


solaris-studio-gtk3-warning-updated.patch
Description: Binary data

Re: Does the visual bell work in GTK+ 3?

2016-08-24 Fir de Conversatie Kazunobu Kuriyama

2016-08-24 4:45 GMT+09:00 Tony Mechelynck :

> With the following settings:
>
> :verbose set eb? vb? bo? t_vb?
>   errorbells
> Last set from ~/.vimrc
>   visualbell
> Last set from ~/.vimrc
> belloff=
> t_vb=^[|1000f
> Last set from ~/.vimrc
>
> (the latter is set in a GUIEnter autocommand, the rest in the .vimrc
> mainline code)
>
> when I hit  repeatedly, I hear no sound and I see no visual bell.
> This is for gvim 7.4.2243 with GTK3 GUI.
>
> With the visual bell time set at a full second, it ought not to be too
> fast for me to see it, don't you think? I have tested other values,
> including the default, with the same result, or lack of one; and I
> know about |option-backslash| to enter the vertical bar into the
> option value.
>

Hi Tony,

As noted in gui_gtk_x11.c:6246--6249, that's not implemented yet.
 (Actually, it was once implemented in an early stage of the development.)

Needless to say, the purpose of visual bell is to notify the user that
something goes wrong with the editor, urging him to do something about that
(I mean this in a broad sense, including 'stop doing something').

Its effect is, however, to keep flashing the whole editor screen until the
problem causing visual bell is fixed, which prevents what he is typing to
the editor from being legible on the screen.

That deteriorates its purpose; while urging the user to do something,
visual bell interferes with what he does.

Arguably, visual bell might be still useful for some simple use cases where
a problem causing annoying flash is gone once the user stops doing what
he's trying to do.

But now that Vim supports asynchronous jobs.  We need to take into
consideration that visual bell may interfere with smooth interaction
between the user, Vim and a single or more external processes because
visual bell exclusively occupies CPU cycles for drawing flash if we naively
port the GTK+ 2 implementation to GTK+ 3.

Best regards,
Kazunobu


>
> Best regards,
> Tony.
>
> --
> --
> 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.2231

2016-08-24 Fir de Conversatie Marcin Szamotulski

On 08:04 Wed 24 Aug , Christian Brabandt wrote:
> Am 2016-08-22 20:29, schrieb Bram Moolenaar:
> > Perhaps we better add a generic way to filter the output.  
> > Unfortunately
> > we can't use "command | grep /pattern/".  Not all commands accept
> > another command following.
> 
> True, but this is already documented at :h :bar and the obvious 
> workaround
> for that case would be to use :exe 'cmd' | grep /pattern/
> 
> > We could put it in front:
> > 
> > filter /pattern/ command
> > 
> > It's like a command modifier then.  But one with an argument.
> > Note that the filtering would happen line-by-line, thus if there is an
> > item that takes several lines only matching ones would show up.
> 
> I am sorry, but this is ugly.

I agree.  Can I use `filter /{pat}/ browse oldfiles`?

Best Marcin

> 
> Best,
> Christian
> 
> -- 
> -- 
> 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.


signature.asc
Description: Digital signature

Re: Patch 7.4.2231

2016-08-24 Fir de Conversatie Christian Brabandt


Am 2016-08-22 20:29, schrieb Bram Moolenaar:
Perhaps we better add a generic way to filter the output.  
Unfortunately

we can't use "command | grep /pattern/".  Not all commands accept
another command following.


True, but this is already documented at :h :bar and the obvious 
workaround

for that case would be to use :exe 'cmd' | grep /pattern/


We could put it in front:

filter /pattern/ command

It's like a command modifier then.  But one with an argument.
Note that the filtering would happen line-by-line, thus if there is an
item that takes several lines only matching ones would show up.


I am sorry, but this is ugly.

Best,
Christian

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

autocommands not triggered for quickfix

Re: Wish list for a more powerful search in Vim

Re: Wish list for a more powerful search in Vim

[patch] fixed compilation warning in syntax.c:9264

Patch 7.4.2251

check for sandbox in viml?

Patch 7.4.2250

Re: [patch] some error messages are not translated

Patch 7.4.2249

Re: [patch] missing colon in E932

Re: Patch 7.4.2231

Re: compiler warning w/ Studio & gtk3 GUI

Patch 7.4.2248

Re: [bug][patch] Unexpectedly preview window opened, after the `:ptjump` command canceled.

Re: Does the visual bell work in GTK+ 3?

Re: Does the visual bell work in GTK+ 3?

Re: Does the visual bell work in GTK+ 3?

Re: [vim/vim] Changed DB_COUNT to 16 (#1000)

Re: Does the visual bell work in GTK+ 3?

Re: compiler warning w/ Studio & gtk3 GUI

Re: compiler warning w/ Studio & gtk3 GUI

Re: Does the visual bell work in GTK+ 3?

Re: Patch 7.4.2231

Re: Patch 7.4.2231

24 matches

Site Navigation

Mail list logo

Footer information