Re: quickfix information

[Yegappan Lakshmanan]

Hi,

On Wed, Jul 27, 2016 at 7:35 AM, LCD 47  wrote:
>> >> > >
>> >> > > On Mon, Jul 25, 2016 at 12:27 AM, LCD 47  wrote:
>> >> > > > On 24 July 2016, Yegappan Lakshmanan 
>> >> > > > wrote:
>> >> > > >> I am attaching a patch to enhance the getqflist/getloclist()
>> >> > > >> functions to return the title string and the
>> >> > > >> setqflist()/setloclist() functions to set the title string.
>> >> > > >>
>> >> > > >> After this patch is incorporated, it will be easy to add the
>> >> > > >> additional items (e.g. context, items, number, stack, etc.).
>> >> > > >>
>> >> > > >> The getqflist/setqflist functions now accept an optional
>> >> > > >> dictionary parameter. The dictionary parameter specifies
>> >> > > >> which items to get or set.  If the {dict} argument is
>> >> > > >> specified, then the getqflist function returns a dictionary.
>> >> > > >
>> >> > > > Why a dictionary (where values are ignored), rather than
>> >> > > > a list, or a string of, say, comma-separated names?  Or both?
>> >> > > >
>> >> > >
>> >> > > This is to be consistent between the getqflist()/getloclist()
>> >> > > and the setqflist()/setloclist() functions. In the setqflist()
>> >> > > function, the value of a dictionary key specifies the value
>> >> > > to set. In the getqflist() function, it specifies the value
>> >> > > to return. For example, the following call sets the quickfix
>> >> > > title:
>> >> > >
>> >> > > call setqflist([], 'a', {'title' : 'example'})
>> >> > >
>> >> > > The following call returns the quickfix title:
>> >> > >
>> >> > > call getqflist({'title' : 1})
>> >> >
>> >> > The arguments of setqflist() are already different from those
>> >> > of getqflist(), so why does an extra argument has to be the same?
>> >> > Why not something like this:
>> >> >
>> >> > call getqflist('title,context,nr')
>> >> > or
>> >> > call getqflist(['title', 'context', 'nr'])
>> >> >
>> >> > vs.
>> >> >
>> >> > call setqflist(errors, 'r',
>> >> > \ { 'title': 'My preciousss', 'context': ctx, 'nr': -1 })
>> >> >
>> >> > (BTW, { 'nr': -1 } could mean last).
>> >>
>> >> Although we can probably do a lot with a list of strings, there
>> >> is a tendency for builtin-functions to use a dictionary to
>> >> pass optional extra argumens through a dict.  A list can only
>> >> use "present" flags, a dictionary can also use values for the
>> >> arguments.
>> >
>> > So basically you want all plugins daring enough to use the new
>> > features to carry along dicts with useless values, just because some
>> > of these values might become useful at some unspecified point in the
>> > future?  Vim can nicely deal with changing the type of an argument,
>> > so why not use lists for now, and add dict arguments when and if
>> > there is an actual use for those?
>> >
>>
>> I did make the changes to use a list argument for the getqflist()
>> function.  Then realized that with a list, you cannot specify the
>> quickfix list number (to pick a specific list in the stack). With a
>> dict, you can modify a specific quickfix list in the stack.
>
> After pondering about this for a while, I believe the stack pointer
> is the only one that needs a value in both getqflist() and setqflist(),
> so you could in principle encode it as simply a number.  That is, a
> number in the list would refer to the stack pointer, as opposed to the
> other names that would be alphabetic.  But that would be even worse than
> having a dict with dummy values.  So yes, this is probably a good reason
> for using dicts.
>

An updated patch is attached. The getqflist() and setqflist() functions take
a dict argument which specifies the things to get or set.

- Yegappan

-- 
-- 
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/runtime/doc/eval.txt b/runtime/doc/eval.txt
index 7b421aa..38fde85 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -2079,11 +2079,11 @@ getftime({fname})   Number  last 
modification time of file
 getftype({fname})  String  description of type of file {fname}
 getline({lnum})String  line {lnum} of current buffer
 getline({lnum}, {end}) Listlines {lnum} to {end} of current buffer
-getloclist({nr})   Listlist of location list items
+getloclist({nr}[, {what}]) Listlist of location list items
 getmatches()   Listlist of current matches
 getpid()   Number  process ID of Vim
 getpos({expr})  

Re: Got E121: Undefined variable in lambda function

[Ken Takata]

Hi,

2016/7/28 Thu 0:57:53 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2016/7/25 Mon 23:02:25 UTC+9 Ken Takata wrote:
> > > Hi,
> > > 
> > > 2016/7/25 Mon 3:47:51 UTC+9 Ken Takata wrote:
> > > > Hi,
> > > > 
> > > > 2016/7/22 Fri 22:29:33 UTC+9 Ken Takata wrote:
> > > > > Hi ZyX,
> > > > > 
> > > > > 2016/7/22 Fri 20:15:33 UTC+9 ZyX wrote:
> > > > > > >> I was wrong regarding the consequences and why you should alter 
> > > > > > >> the
> > > > > > >> GC: it is not memory leak because cycle is not GC’d. It is 
> > > > > > >> *crash*
> > > > > > >> because Vim does not know that dictionary is referenced:
> > > > > > >>
> > > > > > >> ```VimL
> > > > > > >> function F()
> > > > > > >> let d = {}
> > > > > > >> return {-> d}
> > > > > > >> endfunction
> > > > > > >> let L = F()
> > > > > > >> call garbagecollect(1)
> > > > > > >> call feedkeys(":echo L()\n", 'n')
> > > > > > >> ```
> > > > > > >>
> > > > > > >> Save to `test.vim` and run as `vim -u NONE -i NONE -N -S 
> > > > > > >> test.vim`.
> > > > > > >> When I use it in Vim with optimizations it crashes immediately:
> > > > > 
> > > > > Yes, I also noticed this. I tested with the following script:
> > > > > 
> > > > >   function! Test_lambda_closure()
> > > > > function! s:foo()
> > > > >   let x = [0]
> > > > >   return {-> [execute("let x[0] += 1"), x[0]][-1]}
> > > > > endfunction
> > > > >   
> > > > > let l:F = s:foo()
> > > > > call test_garbagecollect_now()
> > > > > call assert_equal(1, l:F())
> > > > > call assert_equal(2, l:F())
> > > > > call assert_equal(3, l:F())
> > > > > call assert_equal(4, l:F())
> > > > >   endfunction
> > > > > 
> > > > > I have updated the patch:
> > > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/52c8d4fd0af2dd8bd2c79204dbbedd9ded874439/lambda-update.patch?at=default
> > > > > 
> > > > > Now it deals with GC. Also add some tests, reduce memory when local 
> > > > > variables
> > > > > or arguments are not used.
> > > > 
> > > > I have slightly updated the tests:
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/5f8f4f212a09b1fa58a939f34559c7b3c88bb616/lambda-update.patch?at=default
> > > > 
> > > > It seems work well. BTW, I'm thinking the implementation again.
> > > > I thought that capture by value is easier to implement, but it is 
> > > > harder to
> > > > apply to normal functions inside a function. Capture by reference seems 
> > > > easier
> > > > to apply to normal functions.
> > > > 
> > > > I read the comment for mattn's implementation by Bram again:
> > > > 
> > > > > In the implementation it seems the dictionary storing the 
> > > > > function-local
> > > > > variables is kept for a very long time. This relies on the garbage
> > > > > collector. It's better to use reference counting to be able to free 
> > > > > the
> > > > > dictionary as soon as it's unused.
> > > > > 
> > > > > Also, the lambda always keeps the function-local variable dict, even
> > > > > when it's not actually used. That makes lambdas a expensive.
> > > > > It would be better to explicitly state the lambda is using its 
> > > > > context.
> > > > > Then we can also do that with ":function", so that we are not forced 
> > > > > to
> > > > > use a lambda if we want a closure.
> > > > 
> > > > Checking if a lambda is a closure is now available with my patch.
> > > > So I tried to implement reference counting based on mattn's patch.
> > > > Unfortunately it doesn't work well yet. I need help for this.
> > > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/5f8f4f212a09b1fa58a939f34559c7b3c88bb616/lambda-capture_by_reference-temp.patch?at=default
> > > > (This patch should be applied after the above patch 
> > > > (lambda-update.patch).)
> > > > Test_circular_reference() in test_lambda.vim doesn't work well.
> > > > 
> > > > Which is better, capture by value or by reference?
> > > 
> > > I have updated the patches.
> > > 
> > > Capture by value:
> > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/05cb2721d17d4b1c52b603037e3ec65e523b472d/lambda-update.patch?at=default
> > > 
> > > Capture by reference:
> > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/05cb2721d17d4b1c52b603037e3ec65e523b472d/lambda-capture_by_reference.patch?at=default
> > > (Apply on top of lambda-update.patch)
> > > 
> > > Now both seem to work almost good.
> > > And I wrote another patch to support closure with normal functions:
> > > https://bitbucket.org/k_takata/vim-ktakata-mq/src/cf0cce51b390335d5ed5a5dffa933e10f16d3aab/closure.patch?at=default
> > > (Apply on top of lambda-capture_by_reference.patch)
> > > 
> > > The :function command supports [closure] argument now:
> > > 
> > >   function! Foo()
> > > let x = 0
> > > function! Bar() closure
> > >   let x += 1
> > >   return x
> > > endfunction
> > > return function('Bar')
> > >   endfunction
> > >   
> > >   let F = Foo()
> > >   echo F() " 1
> > >   echo F() " 2
> > >   echo F() " 3
> > >   echo F() " 4

Re: Patch 7.4.2108

[Hisashi T Fujinaka]

On Wed, 27 Jul 2016, Bram Moolenaar wrote:


Patch 7.4.2108
Problem:Netbeans test is flaky.
Solution:   Wait for the cursor to be positioned.
Files:  src/testdir/test_netbeans.vim


*** ../vim-7.4.2107/src/testdir/test_netbeans.vim   2016-07-20 
00:03:14.212934385 +0200
--- src/testdir/test_netbeans.vim   2016-07-27 22:54:40.188107077 +0200
***
*** 27,32 
--- 27,33 

   " Opening Makefile will result in a setDot command
   call WaitFor('len(readfile("Xnetbeans")) > 4')
+   call WaitFor('getcurpos()[1] == 2')
   let pos = getcurpos()
   call assert_equal(2, pos[1])
   call assert_equal(20, pos[2])
*** ../vim-7.4.2107/src/version.c   2016-07-26 22:14:04.457444251 +0200
--- src/version.c   2016-07-27 22:55:40.279533966 +0200
***
*** 760,761 
--- 760,763 
 {   /* Add new patch number below this line */
+ /**/
+ 2108,
 /**/


Thanks Bram! This works on OSX for me.

--
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee

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

[Bram Moolenaar]

Patch 7.4.2109
Problem:Setting 'display' to "lastline" is a drastic change, while
omitting it results in lots of "@" lines.
Solution:   Add "truncate" to show "@@@" for a truncated line.
Files:  src/option.h, src/screen.c, runtime/doc/options.txt


*** ../vim-7.4.2108/src/option.h2016-07-16 14:46:51.131240585 +0200
--- src/option.h2016-07-27 23:08:37.760127050 +0200
***
*** 454,463 
  EXTERN char_u *p_dy;  /* 'display' */
  EXTERN unsigned   dy_flags;
  #ifdef IN_OPTION_C
! static char *(p_dy_values[]) = {"lastline", "uhex", NULL};
  #endif
  #define DY_LASTLINE   0x001
! #define DY_UHEX   0x002
  EXTERN intp_ed;   /* 'edcompatible' */
  #ifdef FEAT_WINDOWS
  EXTERN char_u *p_ead; /* 'eadirection' */
--- 454,464 
  EXTERN char_u *p_dy;  /* 'display' */
  EXTERN unsigned   dy_flags;
  #ifdef IN_OPTION_C
! static char *(p_dy_values[]) = {"lastline", "truncate", "uhex", NULL};
  #endif
  #define DY_LASTLINE   0x001
! #define DY_TRUNCATE   0x002
! #define DY_UHEX   0x004
  EXTERN intp_ed;   /* 'edcompatible' */
  #ifdef FEAT_WINDOWS
  EXTERN char_u *p_ead; /* 'eadirection' */
*** ../vim-7.4.2108/src/screen.c2016-07-24 21:58:39.716057524 +0200
--- src/screen.c2016-07-27 23:15:56.959956353 +0200
***
*** 2018,2024 
&& wp->w_lines[idx].wl_valid
&& wp->w_lines[idx].wl_lnum == lnum
&& lnum > wp->w_topline
!   && !(dy_flags & DY_LASTLINE)
&& srow + wp->w_lines[idx].wl_size > wp->w_height
  #ifdef FEAT_DIFF
&& diff_check_fill(wp, lnum) == 0
--- 2018,2024 
&& wp->w_lines[idx].wl_valid
&& wp->w_lines[idx].wl_lnum == lnum
&& lnum > wp->w_topline
!   && !(dy_flags & (DY_LASTLINE | DY_TRUNCATE))
&& srow + wp->w_lines[idx].wl_size > wp->w_height
  #ifdef FEAT_DIFF
&& diff_check_fill(wp, lnum) == 0
***
*** 2139,2144 
--- 2139,2159 
wp->w_filler_rows = wp->w_height - srow;
}
  #endif
+   else if (dy_flags & DY_TRUNCATE)/* 'display' has "truncate" */
+   {
+   int scr_row = W_WINROW(wp) + wp->w_height - 1;
+ 
+   /*
+* Last line isn't finished: Display "@@@" in the last screen line.
+*/
+   screen_puts_len((char_u *)"@@", 2, scr_row, W_WINCOL(wp),
+ hl_attr(HLF_AT));
+   screen_fill(scr_row, scr_row + 1,
+   (int)W_WINCOL(wp) + 2, (int)W_ENDCOL(wp),
+   '@', ' ', hl_attr(HLF_AT));
+   set_empty_rows(wp, srow);
+   wp->w_botline = lnum;
+   }
else if (dy_flags & DY_LASTLINE)/* 'display' has "lastline" */
{
/*
*** ../vim-7.4.2108/runtime/doc/options.txt 2016-05-24 10:46:41.659541832 
+0200
--- runtime/doc/options.txt 2016-07-27 23:21:41.968680055 +0200
***
*** 2617,2627 
Change the way text is displayed.  This is comma separated list of
flags:
lastlineWhen included, as much as possible of the last line
!   in a window will be displayed.  When not included, a
!   last line that doesn't fit is replaced with "@" lines.
uhexShow unprintable characters hexadecimal as 
instead of using ^C and ~C.
  
*'eadirection'* *'ead'*
  'eadirection' 'ead'   string  (default "both")
global
--- 2623,2639 
Change the way text is displayed.  This is comma separated list of
flags:
lastlineWhen included, as much as possible of the last line
!   in a window will be displayed.  "@@@" is put in the
!   last columns of the last screen line to indicate the
!   rest of the line is not displayed.
!   truncateLike "lastline", but "@@@" is displayed in the first
!   column of the last screen line.  Overrules "lastline".
uhexShow unprintable characters hexadecimal as 
instead of using ^C and ~C.
  
+   When neither "lastline" or "truncate" is included, a last line that
+   doesn't fit is replaced with "@" lines.
+ 
*'eadirection'* *'ead'*
  'eadirection' 'ead'   string  (default "both")
global
*** ../vim-7.4.2108/src/version.c   2016-07-27 22:56:43.734928810 +0200
--- src/version.c   2016-07-27 23:22:22.896291392 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number 

Patch 7.4.2108

[Bram Moolenaar]

Patch 7.4.2108
Problem:Netbeans test is flaky.
Solution:   Wait for the cursor to be positioned.
Files:  src/testdir/test_netbeans.vim


*** ../vim-7.4.2107/src/testdir/test_netbeans.vim   2016-07-20 
00:03:14.212934385 +0200
--- src/testdir/test_netbeans.vim   2016-07-27 22:54:40.188107077 +0200
***
*** 27,32 
--- 27,33 
  
" Opening Makefile will result in a setDot command
call WaitFor('len(readfile("Xnetbeans")) > 4')
+   call WaitFor('getcurpos()[1] == 2')
let pos = getcurpos()
call assert_equal(2, pos[1])
call assert_equal(20, pos[2])
*** ../vim-7.4.2107/src/version.c   2016-07-26 22:14:04.457444251 +0200
--- src/version.c   2016-07-27 22:55:40.279533966 +0200
***
*** 760,761 
--- 760,763 
  {   /* Add new patch number below this line */
+ /**/
+ 2108,
  /**/

-- 
SIGFUN -- signature too funny (core dumped)

 /// 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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:31 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

>
> It may be true that setting go+=M will reduce memory usage and make
> startup faster.  But I would say the benefit gained by doing that is quite
> marginal.
>

It makes a noticeable difference to me.  That's part of why I do it.


> Hence, in comparison with those heavy tasks, what is gained by go+=M is
> negligible.
>

That's not the only reason someone would want to disable the system menus.
Some users just don't want to stare at all that garbage.  It's the *same*
justification for the existence of *tons* of other options.

I disable the system menu.vim so that I can source my own custom version
that's very bare-bones.  It doesn't cause a noticeable speedup and my
screen is uncluttered.  Thus the gain by having go+=M is not negligible.


> I don't understand why go+=M is so important for some people.
>

I don't understand why suddenly having a system vimrc after years with none
is so important for some people.  Nor do I understand why, if we're going
to have one, some people are so desperate that "syntax on" and "filetype
blah" be in it.  Is it that important to be able to delete one or two lines
that are proably already in your vimrc?

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Bram Moolenaar]

Gary Johnson wrote:

> [...]
> 
> Not all of those would be my preference, but they seem reasonable,
> and as long as all of that is in a file and the compile-time
> defaults aren't changed, I'm fine with it.
> 
> I was surprised by this:
> 
> > " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
> > " let  = substitute(, "t", "", "g")
> 
> Why substitute() instead of just -=?
> 
> set guioptions-=t

Yeah, and why is it commented out?  Actually, why don't we make this the
default?  I don't think anybody on MS-Windows wants tear-off menus,
unless you know them from Unix perhaps.

-- 
ROBIN:  (warily) And if you get a question wrong?
ARTHUR: You are cast into the Gorge of Eternal Peril.
ROBIN:  Oh ... wacho!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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: Changing the defaults with Vim 8

[Bram Moolenaar]

Manuel Ortega wrote:

> On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega 
> wrote:
> 
> > On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar 
> > wrote:
> >
> >>
> >>
> >> " Switch syntax highlighting on when the terminal has colors or when
> >> using the
> >> " GUI (which always has colors).
> >> if _Co > 2 || has("gui_running")
> >>   syntax on
> >>
> >
> > Wait a sec.  If "syntax on" is done here, then won't it be impossible to
> > use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
> > say that in order for that to work, it must be done "before switching on
> > syntax or filetype recognition".  But if syntax is turned on here, by the
> > time the  "set go+=M" in his .vimrc is encountered it will be too late,
> > right?
> 
> Indeed, that is the case (I tried it).  If you put "syntax on" in the
> system vimrc, then the user cannot use "set go+=M".   I think this is a
> good reason to remove "syntax on" from the proposal.  If it's left in, you
> might as well just eliminate "M" as one of the guioptions, because it's
> totally unusable unless it goes in the local machine's system vimrc, which
> many users will not be able to change, or will not want to tweak it every
> time they build a new Vim.

Thanks for mentioning this.

I don't think the solution is to not enable syntax highlighting, but
do this in another way.  But how?

The trick to do something in an ftdetect script smells like a hack.

Perhaps part of the defaults can be set before loading the .vimrc, so
that they can be overruled, and others can be done after loading the
.vimrc, so that they can be disabled.

Could also move loading menu.vim out of filetype.vim, but it's hard to
predict what side effects this has.  E.g. if someone enables filetype
detection and then deletes a menu.  That would break.


Another solution: When there is a .vimrc, then don't load startup.vim.
Rely on the user already have his preferences in the .vimrc.
Thus only apply these better defaults when the user doesn't have his own
settings.  Ah, I see Ben also had this idea.

The more I think about it, the more this seems like a good solution:
- If the user has a .vimrc, use that.
- If there is no .vimrc, use the default .vimrc.
- When a new user creates a .vimrc, he can source the default one or
  copy it.  It's possible to do settings before this, such as adding 'M'
  to 'guioptions'.

That way anybody which already has a .vimrc isn't bothered by different
defaults.  100% backwards compatible.

New users will get better defaults.  When using Vim on a new system it
also has better defaults.

Only those who really want the Vi defaults or the Vim 7 defaults would
need to create a .vimrc and set 'compatible' or 'nocompatible'.

There is some confusion for users who create their .vimrc for the
first time and don't know about the default vimrc.  That can be
documented and once discovered it's easy to fix.


-- 
Sorry, no fortune today.

 /// 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: Changing the defaults with Vim 8

[Manuel Ortega]

Perhaps another way to fix this would be if the user could have a
~/.vim/menu.vim that is treated like ~/.vim/filetype.vim is treated.  I.e.,
that Vim will load the ~/.vim/menu.vim before it loads
$VIMRUNTIME/menu.vim.  That way, a user could in his own ~/.vim/menu.vim
set some variables that will cause most or all of the $VIMRUNTIME/menu.vim
to be skipped.  No need for +=M.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:47 PM, Gary Johnson  wrote:

> On 2016-07-27, Manuel Ortega wrote:
> > On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote:
> >
> > On 2016-07-27, Manuel Ortega wrote:
> >
> > > What if "syntax on" and "filetype plugin indent on" were moved
> into the
> > autocmd
> > > group "vimStartup" that the proposed system vimrc defines, under
> VimEnter
> > > autocmds:
> > >
> > > au VimEnter * syntax on
> > > au VimEnter * filetype plugin on
> > >
> > > This way, everyone who wants them still gets them, and +=M
> still works
> > > without modification.  As an added bonus, both of the "ons" can be
> > prevented
> > > from ever happening using the same "au!" line that kills the
> others in
> > that
> > > group.
> >
> > From ":help VimEnter", the VimEnter event occurs 'After doing all
> > the startup stuff, including loading .vimrc files, executing the
> > "-c cmd" arguments, creating all windows and loading the buffers in
> > them.'
> >
> > Enabling filetype detection after buffers are loaded is too late.
> >
> >
> > Filetype *detection* is on by default in Vim.  It's not being "turned
> on" by
> > "filetype plugin indent on".  So what you say will be too late is not too
> > late.
>
> What makes you think filetype detection is on by default?  That's
> not what I observe.


Because all the files I tested it with had modelines and like an idiot I
forgot about that.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 7:47 PM, Gary Johnson  wrote:
> On 2016-07-27, Manuel Ortega wrote:
>> On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote:
>>
>> On 2016-07-27, Manuel Ortega wrote:
>>
>> > What if "syntax on" and "filetype plugin indent on" were moved into the
>> autocmd
>> > group "vimStartup" that the proposed system vimrc defines, under 
>> VimEnter
>> > autocmds:
>> >
>> > au VimEnter * syntax on
>> > au VimEnter * filetype plugin on
>> >
>> > This way, everyone who wants them still gets them, and +=M still 
>> works
>> > without modification.  As an added bonus, both of the "ons" can be
>> prevented
>> > from ever happening using the same "au!" line that kills the others in
>> that
>> > group.
>>
>> From ":help VimEnter", the VimEnter event occurs 'After doing all
>> the startup stuff, including loading .vimrc files, executing the
>> "-c cmd" arguments, creating all windows and loading the buffers in
>> them.'
>>
>> Enabling filetype detection after buffers are loaded is too late.
>>
>>
>> Filetype *detection* is on by default in Vim.  It's not being "turned on" by
>> "filetype plugin indent on".  So what you say will be too late is not too
>> late.
>
> What makes you think filetype detection is on by default?  That's
> not what I observe.
>
> $ vim -N -u /dev/null hello.c
> :set ft?
>   filetype=
>
> It is turned on by "filetype [args] on" and by "syntax on".
>
> Regards,
> Gary

Indeed: filetype detection is turned on by the vimrc_example.vim, but
it is neither the 'compatible' nor the 'nocompatible' default in the
absence of startup scripts (i.e. neither "vim -u NONE" nor "vim -u
NONE -N" have it. Even "vim -u NORC -N" i.e., no vimrc but with global
plugins and 'nocompatible' doesn't set it.)

To get a reproducible setup with filetype detection, you might want to
do something like

vim -u /usr/local/share/vim/vim74/vimrc_example.vim

(no need to use -N in this case because the vimrc_example.vim sets it.)


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: Changing the defaults with Vim 8

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 8:00 PM, Gary Johnson  wrote:
> On 2016-07-27, Tony Mechelynck wrote:
>> On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson wrote:
>> > On 2016-07-27, Manuel Ortega wrote:
>> >
>> >> If "syntax on" is in the system vimrc as proposed, then I can't seem to 
>> >> find
>> >> any way *at all* to disable the loading of the system menu.vim (short of
>> >> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>> >
>> > How about "sudo rm /usr/share/vim/vimrc"?
>> >
>> > Another, less drastic way would be to create a file,
>> > ~/.vim/ftdetect/guioptions.vim, containing this:
>> >
>> > set guioptions+=M
>> >
>> > Regards,
>> > Gary
>>
>> That ftdetect/guioptions.vim would, with current Vim, be sourced from
>> $VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
>> only _after_ filetype detection has been set, which is too late for
>> clearing menus, unless you first set ":filetype off". But then you
>> would have to run ":filetype on" afterwards _only_ if it was
>> originally on.
>
> Apparently that's not true:  it's not too late.
>
> Here are the initial lines from :scriptnames:
>
>   1: ~/.vimrc
>   2: ~/.vim/filetype.vim
>   3: /usr/local/share/vim/vim74/filetype.vim
>   4: ~/.vim/ftdetect/csv.vim
>   5: ~/.vim/ftdetect/mediawiki.vim
>   6: /usr/local/share/vim/vim74/menu.vim
>   7: /usr/local/share/vim/vim74/autoload/paste.vim
>   8: /usr/local/share/vim/vim74/ftplugin.vim
>   9: /usr/local/share/vim/vim74/indent.vim
>  10: /usr/local/share/vim/vim74/syntax/manual.vim
>  11: /usr/local/share/vim/vim74/syntax/synload.vim
>  12: /usr/local/share/vim/vim74/syntax/syncolor.vim
>
> You can see that the files in ~/.vim/ftdetect are sourced before
> menu.vim, and in fact are sourced before the decision to source
> menu.vim is made.  I verified that putting "set guioptions+=M" into
> ~/.vim/ftdetect/guioptions.vim would work before posting that
> solution.
>
> Regards,
> Gary

Oops, you're right, it is just in time, but barely.

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: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-27, Tony Mechelynck wrote:
> On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson wrote:
> > On 2016-07-27, Manuel Ortega wrote:
> >
> >> If "syntax on" is in the system vimrc as proposed, then I can't seem to 
> >> find
> >> any way *at all* to disable the loading of the system menu.vim (short of
> >> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
> >
> > How about "sudo rm /usr/share/vim/vimrc"?
> >
> > Another, less drastic way would be to create a file,
> > ~/.vim/ftdetect/guioptions.vim, containing this:
> >
> > set guioptions+=M
> >
> > Regards,
> > Gary
> 
> That ftdetect/guioptions.vim would, with current Vim, be sourced from
> $VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
> only _after_ filetype detection has been set, which is too late for
> clearing menus, unless you first set ":filetype off". But then you
> would have to run ":filetype on" afterwards _only_ if it was
> originally on.

Apparently that's not true:  it's not too late.

Here are the initial lines from :scriptnames:

  1: ~/.vimrc
  2: ~/.vim/filetype.vim
  3: /usr/local/share/vim/vim74/filetype.vim
  4: ~/.vim/ftdetect/csv.vim
  5: ~/.vim/ftdetect/mediawiki.vim
  6: /usr/local/share/vim/vim74/menu.vim
  7: /usr/local/share/vim/vim74/autoload/paste.vim
  8: /usr/local/share/vim/vim74/ftplugin.vim
  9: /usr/local/share/vim/vim74/indent.vim
 10: /usr/local/share/vim/vim74/syntax/manual.vim
 11: /usr/local/share/vim/vim74/syntax/synload.vim
 12: /usr/local/share/vim/vim74/syntax/syncolor.vim

You can see that the files in ~/.vim/ftdetect are sourced before
menu.vim, and in fact are sourced before the decision to source
menu.vim is made.  I verified that putting "set guioptions+=M" into
~/.vim/ftdetect/guioptions.vim would work before posting that
solution.

Regards,
Gary

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

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

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson  wrote:
> On 2016-07-27, Manuel Ortega wrote:
>
>> If "syntax on" is in the system vimrc as proposed, then I can't seem to find
>> any way *at all* to disable the loading of the system menu.vim (short of
>> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>
> How about "sudo rm /usr/share/vim/vimrc"?
>
> Another, less drastic way would be to create a file,
> ~/.vim/ftdetect/guioptions.vim, containing this:
>
> set guioptions+=M
>
> Regards,
> Gary

That ftdetect/guioptions.vim would, with current Vim, be sourced from
$VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
only _after_ filetype detection has been set, which is too late for
clearing menus, unless you first set ":filetype off". But then you
would have to run ":filetype on" afterwards _only_ if it was
originally on.

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: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-27, Manuel Ortega wrote:

> What if "syntax on" and "filetype plugin indent on" were moved into the 
> autocmd
> group "vimStartup" that the proposed system vimrc defines, under VimEnter
> autocmds:
> 
> au VimEnter * syntax on
> au VimEnter * filetype plugin on
> 
> This way, everyone who wants them still gets them, and +=M still works
> without modification.  As an added bonus, both of the "ons" can be prevented
> from ever happening using the same "au!" line that kills the others in that
> group.

>From ":help VimEnter", the VimEnter event occurs 'After doing all
the startup stuff, including loading .vimrc files, executing the
"-c cmd" arguments, creating all windows and loading the buffers in
them.'

Enabling filetype detection after buffers are loaded is too late.

I suppose you do that and add something like this:

au VimEnter * bufdo filetype detect

I haven't thought that all the way through.

Regards,
Gary

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

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

Re: Wish list for a more powerful search in Vim

[Bram Moolenaar]

Christian Brabandt wrote:

> >> On Do, 14 Jul 2016, Yegappan Lakshmanan wrote:
> >> 
> >> > Hi all,
> >> >
> >> > My wish list for extending the Vim search feature:
> >> >
> >> > 1. When searching for a pattern, pressing a key at the search prompt
> >> > should jump to the next or previous match.
> >> > 2. After jumping multiple times from the search prompt, pressing the
> >> > escape key should restore the cursor to the original cursor position
> >> > before the search.
> >> > 3. Pressing backspace at the search prompt to erase a few characters and
> >> > then typing additional characters should start the search from the
> >> > previously matched position and not from the original position.
> >> > 4. As characters are typed at the search prompt, all the matching text
> >> > should be highlighted (multiple matches). This can be turned on/off 
> >> > by
> >> > an option.
> >> >
> >> > I know there are some Vim plugins that support some of these features.
> >> > But it will be useful to extend the built-in Vim feature to support these
> >> > features.
> >> 
> >> Here is an experimental patch, that does this using Ctrl-N Ctrl-P in
> >> search mode, when 'incsearch' is set. I am not super happy, about
> >> depending on 'incsearch', but on the other hand, Ctrl-L already only
> >> works when 'incsearch' is set. Also I am open to suggestions for
> >> alternative keys, although I must admit, Ctrl-N/Ctrl-P seem like 
> >> logical
> >> choices.
> >> 
> >> It doesn't do everything you want, but it seems to work well for me. I
> >> made it so, that pressing enter will remain at the current selected
> >> match, which seems obvious and so I did not need to introduce a new 
> >> key
> >> function. Pressing ESC however will return the cursor to the position
> >> where you started with the search.
> >> 
> >> This was just written very fast, I am pretty sure, there are some bugs
> >> lying around and also tests are missing. But if this turns out to be
> >> useful, I'll work more on it (and add a test of course).
> >> 
> >> Comments welcome,
> > 
> > This smells like an interactive search dialog.  Does this combine with
> > the search count?  So when pressing CTRL-N it goes from "match 2 of 23"
> > to "match 3 of 23"?  And when typing a character it goes to "match 1 of
> > 8"?  (I would think the match index is counting from the original start
> > position).
> 
> You mean the search_stat patch from last week? No, I haven't looked,
> how well those two features would work together.
> 
> Would it make sense to submit it as one single patch, adding several
> features at once?

Doesn't matter, just seems that they should well work together.  But if
one needs more time we could include the other first.

-- 
BEDEVERE: Look!  It's the old man from scene 24 - what's he Doing here?
ARTHUR:   He is the keeper of the Bridge.  He asks each traveler five
  questions ...
GALAHAD:  Three questions.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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: [vim/vim] getcompletion() fails to append slashes to dirnames (#947)

[Bram Moolenaar]

Yegappan wrote:

> On Mon, Jul 25, 2016 at 11:28 AM, Yegappan Lakshmanan
>  wrote:
> > Hi,
> >
> > On Mon, Jul 25, 2016 at 10:42 AM, chdiza  wrote:
> >>
> >> The new getcompletion() function is of limited usefulness if one wants to
> >> use it for any "type" that might return directory names. That's because it
> >> doesn't append the trailing slash to dir names. That means that
> >> getcompletion()'s results don't actually match what you would get at the
> >> command line by pressing .
> >>
> >> For example: from the command line, :cd myd yields :cd mydir/. Yet
> >> echo getcompletion('myd', 'dir') yields mydir.
> >>
> >> This could be worked around by calling map() on the result of
> >> getcompletion() to append the slashes. But that only works for the type
> >> "dir". For "file", one can't just append slashes because some of
> >> getcompletion()'s matches will be file names, not dir names.
> >>
> >> Example: Suppose in the cwd I have a dir names "mydir" and a file named
> >> "myfile".
> >>
> >> At the command line, :e my will show mydir/ and then myfile if you
> >> hit again. But :echo getcompletion("my", "file") will show a list 
> >> containing
> >> mydir and myfile. A blanket use of map() to append trailing slashes would
> >> result in myfile/ which is wrong.
> >>
> >> In short, getcompletion() should return a list that shows what would
> >> actually be presented at the command line. If that list contains dirnames,
> >> they should end in a slash. Otherwise, it isn't very useful in helping to
> >> define custom completion for files and dirs.
> >>
> > This is easy to fix (need to add WILD_ADD_SLASH to options in
> > f_getcompletion()).
> > I will send out a patch later.
> 
> A patch to fix this problem is attached. I have updated the test case
> to test for backslash or forward slash depending on the system
> (Unix/Windows). I have tested this on a Mac system. I haven't tested
> this on MS-Windows to make sure the test passes.

The tests are run with 'shellslash' set, thus I suspect the text fails.

-- 
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

 /// 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: [vim/vim] getcompletion() fails to append slashes to dirnames (#947)

[Yegappan Lakshmanan]

Hi,

On Tue, Jul 26, 2016 at 2:17 PM, chdiza  wrote:

> Actually, I seem to have found a problem with it.
>
> Suppose I have a dir named "Desktop" in my $HOME. From a Vim whose cwd is
> $HOME:
>
> echo getcompletion("de", "dir")
>
> Gives ['Desktop/*']. Note the asterisk, which messes things up if you
> want to use getcompletion() to soup-up ordinary dirname completion. For
> example, compare :cd De to
>

The getcompletion() function adds a star to the supplied pattern to get
all the matches. If the expansion fails, then the star is not removed.
The expansion may fail if the directory doesn't exist or if there are no
sub-directories under the specified directory. That is why you are seeing
a star at the end of the returned match. I will see how this can be fixed.

- Yegappan


> ec getcompletion(getcompletion("Desktop/", "dir")[0], "dir")
>
> The former has no asterisk, the latter has one. That means that using call
> input("CD to: ", "", "customlist,Foo"), where the function Foo is defined
> thus
>
> func Foo(A,L,P)
>   return getcompletion(a:A, "dir")
> endfunc
>
> will be such that hitting twice after "D" at the prompt will give
> Desktop/*, when it should just give Desktop/.
>
>
>

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 11:40 AM, Manuel Ortega 
wrote:

>
>> I agree that "syntax on" and "filetype on" (maybe even "filetype plugin
>> indent on") are pretty core features that should probably be enabled by
>> default, as nearly everyone will use them.
>>
>
>
>> However, I disagree that this should come at the expense of being able
>> to set up specific options. Anything done in the default settings should
>> be modifiable by the user, and it looks like in this situation that is
>> not possible, if the default settings are always sourced.
>>
>
> I would have no problem with "syntax on" going in a system vimrc if it
> didn't have unfixable side-effects.
>
> Perhaps it's possible for Bram to change the behavior of "syntax on" so
> that it doesn't cause menu.vim to be loaded.  Same for "filetype on".
>
> Or perhaps it's possible for Bram to change them so that menu.vim isn't
> loaded until after the user's vimrc is loaded.  Then the user could at
> least set the "did_install_*" variables.
>
> -Manny
>

What if "syntax on" and "filetype plugin indent on" were moved into the
autocmd group "vimStartup" that the proposed system vimrc defines, under
VimEnter autocmds:

au VimEnter * syntax on
au VimEnter * filetype plugin on

This way, everyone who wants them still gets them, and +=M still works
without modification.  As an added bonus, both of the "ons" can be
prevented from ever happening using the same "au!" line that kills the
others in that group.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[James McCoy]

On Jul 27, 2016 6:20 AM, "Kazunobu Kuriyama" 
wrote:
>
> 2016-07-27 17:01 GMT+09:00 Manuel Ortega :
>> If "syntax on" is in the system vimrc as proposed, then I can't seem to
find any way *at all* to disable the loading of the system menu.vim (short
of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>>
>> Not only that, but the variables in menu.vim intended to be settable by
the user to stop certain segments from loading, i.e.,
>>
>> let did_install_default_menus = 1
>> let no_buffers_menu =1
>> let did_install_syntax_menu = 1
>>
>> ... have no effect in the user's vimrc because menu.vim is already
loaded by the system vimrc's "syntax on".
>>
>> Please, please, remove "syntax on" from the proposal.  There is no way
for the user to undo its side-effects.
>>
>> -Manny
>
>
> Hi,
>
> After having read your argument through, I’m still for ‘syntax on’.
>
> After all, the problem boils down to this: How many GUI users do they
actually set go=+M?
>
> My bet is that the number is nearly zero.
>
> If our system menu were of such less importance that one could kill it at
will, it would not be worth being called “the system menu.”

I'd wager it's more than you think. I know many people that change gvim to
basically look like console vim. Personally, I set 'guioptions' to just
"cM".

Cheers,
James

-- 
-- 
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: quickfix information

[Yegappan Lakshmanan]

Hi,

On Tue, Jul 26, 2016 at 10:15 PM, LCD 47  wrote:
> On 26 July 2016, Bram Moolenaar  wrote:
>>
>> Lcd wrote:
>>
>> > On 25 July 2016, Yegappan Lakshmanan  wrote:
>> > > Hi,
>> > >
>> > > On Mon, Jul 25, 2016 at 12:27 AM, LCD 47  wrote:
>> > > > On 24 July 2016, Yegappan Lakshmanan 
>> > > > wrote:
>> > > >> I am attaching a patch to enhance the getqflist/getloclist()
>> > > >> functions to return the title string and the
>> > > >> setqflist()/setloclist() functions to set the title string.
>> > > >>
>> > > >> After this patch is incorporated, it will be easy to add the
>> > > >> additional items (e.g. context, items, number, stack, etc.).
>> > > >>
>> > > >> The getqflist/setqflist functions now accept an optional
>> > > >> dictionary parameter. The dictionary parameter specifies which
>> > > >> items to get or set.  If the {dict} argument is specified, then
>> > > >> the getqflist function returns a dictionary.
>> > > >
>> > > > Why a dictionary (where values are ignored), rather than a
>> > > > list, or a string of, say, comma-separated names?  Or both?
>> > > >
>> > >
>> > > This is to be consistent between the getqflist()/getloclist()
>> > > and the setqflist()/setloclist() functions. In the setqflist()
>> > > function, the value of a dictionary key specifies the value to
>> > > set. In the getqflist() function, it specifies the value to
>> > > return. For example, the following call sets the quickfix title:
>> > >
>> > > call setqflist([], 'a', {'title' : 'example'})
>> > >
>> > > The following call returns the quickfix title:
>> > >
>> > > call getqflist({'title' : 1})
>> >
>> > The arguments of setqflist() are already different from those of
>> > getqflist(), so why does an extra argument has to be the same?  Why
>> > not something like this:
>> >
>> > call getqflist('title,context,nr')
>> > or
>> > call getqflist(['title', 'context', 'nr'])
>> >
>> > vs.
>> >
>> > call setqflist(errors, 'r',
>> > \ { 'title': 'My preciousss', 'context': ctx, 'nr': -1 })
>> >
>> > (BTW, { 'nr': -1 } could mean last).
>>
>> Although we can probably do a lot with a list of strings, there is a
>> tendency for builtin-functions to use a dictionary to pass optional
>> extra argumens through a dict.  A list can only use "present" flags, a
>> dictionary can also use values for the arguments.
>
> So basically you want all plugins daring enough to use the new
> features to carry along dicts with useless values, just because some
> of these values might become useful at some unspecified point in the
> future?  Vim can nicely deal with changing the type of an argument, so
> why not use lists for now, and add dict arguments when and if there is
> an actual use for those?
>

I did make the changes to use a list argument for the getqflist() function.
Then realized that with a list, you cannot specify the quickfix list number
(to pick a specific list in the stack). With a dict, you can modify a specific
quickfix list in the stack.

- Yegappan

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 3:51 AM, Manuel Ortega 
wrote:

> On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega 
> wrote:
>
>> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar 
>> wrote:
>>
>>>
>>>
>>> " Switch syntax highlighting on when the terminal has colors or when
>>> using the
>>> " GUI (which always has colors).
>>> if _Co > 2 || has("gui_running")
>>>   syntax on
>>>
>>
>> Wait a sec.  If "syntax on" is done here, then won't it be impossible to
>> use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
>> say that in order for that to work, it must be done "before switching on
>> syntax or filetype recognition".  But if syntax is turned on here, by the
>> time the  "set go+=M" in his .vimrc is encountered it will be too late,
>> right?
>>
>
> Indeed, that is the case (I tried it).  If you put "syntax on" in the
> system vimrc, then the user cannot use "set go+=M".   I think this is a
> good reason to remove "syntax on" from the proposal.  If it's left in, you
> might as well just eliminate "M" as one of the guioptions, because it's
> totally unusable unless it goes in the local machine's system vimrc, which
> many users will not be able to change, or will not want to tweak it every
> time they build a new Vim.
>

If "syntax on" is in the system vimrc as proposed, then I can't seem to
find any way *at all* to disable the loading of the system menu.vim (short
of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

Not only that, but the variables in menu.vim intended to be settable by the
user to stop certain segments from loading, i.e.,

let did_install_default_menus = 1
let no_buffers_menu =1
let did_install_syntax_menu = 1

... have no effect in the user's vimrc because menu.vim is already loaded
by the system vimrc's "syntax on".

Please, please, remove "syntax on" from the proposal.  There is no way for
the user to undo its side-effects.

-Manny

-- 
-- 
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: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega 
wrote:

> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar 
> wrote:
>
>>
>>
>> " Switch syntax highlighting on when the terminal has colors or when
>> using the
>> " GUI (which always has colors).
>> if _Co > 2 || has("gui_running")
>>   syntax on
>>
>
> Wait a sec.  If "syntax on" is done here, then won't it be impossible to
> use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
> say that in order for that to work, it must be done "before switching on
> syntax or filetype recognition".  But if syntax is turned on here, by the
> time the  "set go+=M" in his .vimrc is encountered it will be too late,
> right?
>

Indeed, that is the case (I tried it).  If you put "syntax on" in the
system vimrc, then the user cannot use "set go+=M".   I think this is a
good reason to remove "syntax on" from the proposal.  If it's left in, you
might as well just eliminate "M" as one of the guioptions, because it's
totally unusable unless it goes in the local machine's system vimrc, which
many users will not be able to change, or will not want to tweak it every
time they build a new Vim.

-Manny

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

[Christian Brabandt]

Am 2016-07-26 23:07, schrieb Bram Moolenaar:

Christian Brabandt wrote:


On Do, 14 Jul 2016, Yegappan Lakshmanan wrote:

> Hi all,
>
> My wish list for extending the Vim search feature:
>
> 1. When searching for a pattern, pressing a key at the search prompt
> should jump to the next or previous match.
> 2. After jumping multiple times from the search prompt, pressing the
> escape key should restore the cursor to the original cursor position
> before the search.
> 3. Pressing backspace at the search prompt to erase a few characters and
> then typing additional characters should start the search from the
> previously matched position and not from the original position.
> 4. As characters are typed at the search prompt, all the matching text
> should be highlighted (multiple matches). This can be turned on/off by
> an option.
>
> I know there are some Vim plugins that support some of these features.
> But it will be useful to extend the built-in Vim feature to support these
> features.

Here is an experimental patch, that does this using Ctrl-N Ctrl-P in
search mode, when 'incsearch' is set. I am not super happy, about
depending on 'incsearch', but on the other hand, Ctrl-L already only
works when 'incsearch' is set. Also I am open to suggestions for
alternative keys, although I must admit, Ctrl-N/Ctrl-P seem like 
logical

choices.

It doesn't do everything you want, but it seems to work well for me. I
made it so, that pressing enter will remain at the current selected
match, which seems obvious and so I did not need to introduce a new 
key

function. Pressing ESC however will return the cursor to the position
where you started with the search.

This was just written very fast, I am pretty sure, there are some bugs
lying around and also tests are missing. But if this turns out to be
useful, I'll work more on it (and add a test of course).

Comments welcome,


This smells like an interactive search dialog.  Does this combine with
the search count?  So when pressing CTRL-N it goes from "match 2 of 23"
to "match 3 of 23"?  And when typing a character it goes to "match 1 of
8"?  (I would think the match index is counting from the original start
position).


You mean the search_stat patch from last week? No, I haven't looked,
how well those two features would work together.

Would it make sense to submit it as one single patch, adding several 
features

at once?

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.