Haskell and cabal syntax files

['Marcin Szamotulski' via vim_dev]

Hi Bram,

I attach updated syntax files for haskell and cabal.

Best regards,
Marcin Szamotulski

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ZLoRFo8Lc1JTG0sM0MW1E2YaBdIG_khab8uDkSLwN9UW7NocAApcALoyylQqVUxyXkkiiYOr1zflAa80oJNL24tbVQdXH0bTkU778St6I0Y%3D%40pm.me.


cabal.vim
Description: Binary data


haskell.vim
Description: Binary data


signature.asc
Description: OpenPGP digital signature

`:find` results order

['Marcin Szamotulski' via vim_dev]

Hello vim_dev, 


I was always struck by the inconsistency of file ordere as returned by `:find 
lost.file` and command completion, e.g. `:e **/lost.file^d`. If there are 
multiple files of with name `lost.file` `:find` will explore them in different 
order than what completion will suggest. Maybe somebody would like to try fix 
this, or maybe this is a feature? 


Best regards, Marcin




-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/lqcdTzly2kBLLLSt1cd-N1FLw5x9Iub5LkgloDB9QbvE0o1zYToT8D7ksC1PHd0pcRnw-YkUp5x8gjPVT-5U_1Nl-Em7ZVC3vDEI1_owBFY%3D%40pm.me.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Patch 8.1.1464

['Marcin Szamotulski' via vim_dev]

‐‐‐ Original Message ‐‐‐
On Tuesday, 4 June 2019 22:18, Marcin Szamotulski  wrote:

> Hello vim_dev,
> 

> I was always struck by the inconsistency of file ordere as returned by `:find 
> lost.file` and command completion, e.g. `:e **/lost.file^d`. If there are 
> multiple files of with name `lost.file` `:find` will explore them in 
> different order than what completion will suggest. Maybe somebody would like 
> to try fix this, or maybe this is a feature?


Ups, I sent it as a reply; It was meant to sent as a new thread.

Regards,
Marcin

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/GZGcvMUH9LygN0n1duiawghxru0AuCjbb_9tpj9zJ_gGOMjR7bnfbSnpx1pI7o21NyhApg5EOlA7IIMCQObcQ4T7PZqyyfOQ1FQq5Gd1i3c%3D%40pm.me.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Patch 8.1.1464

['Marcin Szamotulski' via vim_dev]

Hello vim_dev,

I was always struck by the inconsistency of file ordere as returned by `:find 
lost.file` and command completion, e.g. `:e **/lost.file^d`. If there are 
multiple files of with name `lost.file` `:find` will explore them in different 
order than what completion will suggest.  Maybe somebody would like to try fix 
this, or maybe this is a feature?

Best regards,
Marcin




‐‐‐ Original Message ‐‐‐
On Tuesday, 4 June 2019 21:41, Bram Moolenaar  wrote:

> 

> 

> Patch 8.1.1464
> Problem: Only 4-digit rgb termresponse is recognized.
> Solution: Also recognize 2-digit rgb response. (closes #4486)
> Files: src/term.c, src/test_termcodes.vim
> 

> *** ../vim-8.1.1463/src/term.c 2019-05-28 23:08:12.080648632 +0200
> --- src/term.c 2019-06-04 21:23:11.508570961 +0200
> 

> *** 4962,4967 
> --- 4962,4968 
> /* Check for fore/background color response from the terminal:
> *
> * {lead}{code};rgb:{}/{}/{}{tail}
> 

> -  * or{lead}{code};rgb:{rr}/{gg}/{bb}{tail}
>*
>* {code} is 10 for foreground, 11 for background
>* {lead} can be ] or OSC
> 

> 

> 

> *** 4985,4998 
> : (tp[i] == ESC && i + 1 < len && tp[i + 1] == '\\')))
> {
> int is_bg = argp[1] == '1';
> 

> ! if (i - j >= 21 && STRNCMP(tp + j + 3, "rgb:", 4) == 0
> ! && tp[j + 11] == '/' && tp[j + 16] == '/')
> {
> 

> ifdef FEAT_TERMINAL
> 

> 
> 

> ! int rval = hexhex2nr(tp + j + 7);
> ! int gval = hexhex2nr(tp + j + 12);
> ! int bval = hexhex2nr(tp + j + 17);
> 

> endif
> 

> ==
> 

>   if (is_bg)
>   {
> 

> 

> --- 4986,5004 
> : (tp[i] == ESC && i + 1 < len && tp[i + 1] == '\\')))
> {
> int is_bg = argp[1] == '1';
> 

> - int is_4digit = i - j >= 21 && tp[j + 11] == '/'
> 

> 

> -   && tp[j + 16] == '/';
> 

> 

> 

> ! if (i - j >= 14 && STRNCMP(tp + j + 3, "rgb:", 4) == 0
> ! && (is_4digit
> ! || (tp[j + 9] == '/' && tp[i + 12 == '/'])))
> {
> 

> ifdef FEAT_TERMINAL
> 

> 
> 

> ! int rval, gval, bval;
> !
> ! rval = hexhex2nr(tp + j + 7);
> ! gval = hexhex2nr(tp + j + (is_4digit ? 12 : 10));
> ! bval = hexhex2nr(tp + j + (is_4digit ? 17 : 13));
> 

> endif
> 

> ==
> 

>   if (is_bg)
>   {
> 

> 

> *** ../vim-8.1.1463/src/version.c 2019-06-04 19:16:25.518124894 +0200
> --- src/version.c 2019-06-04 21:39:56.729716125 +0200
> 

> *** 769,770 
> --- 769,772 
> { /* Add new patch number below this line */
> 

> -   /**/
> -   1464,
> 

> 

> /**/
> 

> --
> From "know your smileys":
> +<(:-) The Pope
> 

> /// 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/vim_dev/201906041941.x54JfmlM006862%40masaka.moolenaar.net.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/xCNuiXm-uyVcLhECbqN9FoeILmB6AJx8-osyvHLH-047bKo8CZT3_4FETwthUW4LjLzsY6eeb3Y93yuwwmpBbnmYJ4P5eCVqmU_nQpsi3vA%3D%40pm.me.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

vim's command line rendering

['Marcin Szamotulski' via vim_dev]

Hello Vim Devs,

Let me propose a change to the vim rendering stack.

Currently vim is rendering command line in such a way that when there is more 
input (e.g. after ^d pressed in the command line), all the other windows are 
moved up, preserving the next line above the command line.  I think, it should 
be the other way, i.e. keep the same top line (rather than bottom line). This 
would make an impression that the command line is drawn on top of the buffers.  
It should be also more performant,  since one wouldn't need to redraw whole 
screen.

Best regards,
Marcin

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

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


signature.asc
Description: OpenPGP digital signature

Re: [vim/vim] Support for plugin authors needs to be improved (poll) (#3573)

['Marcin Szamotulski' via vim_dev]

It would be nice to add multiline support for quickfix list. Some languages 
output multi line error messages (Haskell, PureScript, ...) with a lot of 
information that's not fitting into a single line.
Currently, one has to show each error line as a separate quick fix entry, but 
this breaks the correspondence between number of entries in quickfix  list and 
number of errors/warnings, or the jump to error from quickfix list.
It would also be nice to have syntax highlighting for quick fix buffers.

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

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


signature.asc
Description: OpenPGP digital signature

Re: Patch 8.1.0238

['Marcin Szamotulski' via vim_dev]

Thanks for a prompt patch!

Marcin

 Original Message 
On 4 Aug 2018, 15:54, Bram Moolenaar wrote:

> Patch 8.1.0238
> Problem: 'buftype' is cleared when using ":term ++hidden cat". (Marcin
> Szamotulski)
> Solution: Set the "options initialized" flag earlier. (closes #3278)
> Files: src/terminal.c, src/testdir/test_terminal.vim
>
> *** ../vim-8.1.0237/src/terminal.c 2018-07-08 20:49:03.427359658 +0200
> --- src/terminal.c 2018-08-04 16:52:59.228476711 +0200
> ***
> *** 529,534 
> --- 529,536 
>
> set_string_option_direct((char_u *)"buftype", -1,
> (char_u *)"terminal", OPT_FREE|OPT_LOCAL, 0);
> + // Avoid that 'buftype' is reset when this buffer is entered.
> + curbuf->b_p_initialized = TRUE;
>
> /* Mark the buffer as not modifiable. It can only be made modifiable after
> * the job finished. */
> *** ../vim-8.1.0237/src/testdir/test_terminal.vim 2018-07-08 
> 20:49:03.427359658 +0200
> --- src/testdir/test_terminal.vim 2018-08-04 16:51:08.821245793 +0200
> ***
> *** 1605,1607 
> --- 1605,1623 
> set guioptions&
> call delete(filename)
> endfunc
> +
> + func Test_terminal_hidden()
> + if !has('unix')
> + return
> + endif
> + term ++hidden cat
> + let bnr = bufnr('$')
> + call assert_equal('terminal', getbufvar(bnr, ''))
> + exe 'sbuf ' . bnr
> + call assert_equal('terminal', )
> + call term_sendkeys(bnr, "asdf\")
> + call WaitForAssert({-> assert_match('asdf', term_getline(bnr, 2))})
> + call term_sendkeys(bnr, "\")
> + call WaitForAssert({-> assert_equal('finished', term_getstatus(bnr))})
> + bwipe!
> + endfunc
> *** ../vim-8.1.0237/src/version.c 2018-08-04 15:13:31.034718130 +0200
> --- src/version.c 2018-08-04 16:53:18.336344327 +0200
> ***
> *** 796,797 
> --- 796,799 
> { /* Add new patch number below this line */
> + /**/
> + 238,
> /**/
>
> --
> -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
> -rwxr-xr-t 4 root 131720 Jan 1 1970 /usr/ucb/vi
> -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
>
> /// 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.

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

Haskell syntax file

[Marcin Szamotulski]

Hi Bram,

I send updated Haskell syntax file.  I contacted the hasakell-cafe 
mailing list for changes (which governs the file), and there was no 
objection.


This just adds @Spell and @NoSpell syntax clusters.

Best regards,
Marcin Szamotulski

--
--
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.
" Vim syntax file
" Language: Haskell
" Maintainer:   Haskell Cafe mailinglist <haskell-c...@haskell.org>
" Last Change:  2017 Dec 16
" Original Author:  John Williams <j...@pobox.com>
"
" Thanks to Ryan Crumley for suggestions and John Meacham for
" pointing out bugs. Also thanks to Ian Lynagh and Donald Bruce Stewart
" for providing the inspiration for the inclusion of the handling
" of C preprocessor directives, and for pointing out a bug in the
" end-of-line comment handling.
"
" Options-assign a value to these variables to turn the option on:
"
" hs_highlight_delimiters - Highlight delimiter characters--users
"   with a light-colored background will
"   probably want to turn this on.
" hs_highlight_boolean - Treat True and False as keywords.
" hs_highlight_types - Treat names of primitive types as keywords.
" hs_highlight_more_types - Treat names of other common types as keywords.
" hs_highlight_debug - Highlight names of debugging functions.
" hs_allow_hash_operator - Don't highlight seemingly incorrect C
"  preprocessor directives but assume them to be
"  operators
"
" 2004 Feb 19: Added C preprocessor directive handling, corrected eol comments
"  cleaned away literate haskell support (should be entirely in
"  lhaskell.vim)
" 2004 Feb 20: Cleaned up C preprocessor directive handling, fixed single \
"  in eol comment character class
" 2004 Feb 23: Made the leading comments somewhat clearer where it comes
"  to attribution of work.
" 2008 Dec 15: Added comments as contained element in import statements

" quit when a syntax file was already loaded
if exists("b:current_syntax")
  finish
endif

" (Qualified) identifiers (no default highlighting)
syn match ConId "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=\<[A-Z][a-zA-Z0-9_']*\>" 
contains=@NoSpell
syn match VarId "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=\<[a-z][a-zA-Z0-9_']*\>" 
contains=@NoSpell

" Infix operators--most punctuation characters and any (qualified) identifier
" enclosed in `backquotes`. An operator starting with : is a constructor,
" others are variables (e.g. functions).
syn match hsVarSym 
"\(\<[A-Z][a-zA-Z0-9_']*\.\)\=[-!#$%&\*\+/<=>\?@\\^|~.][-!#$%&\*\+/<=>\?@\\^|~:.]*"
syn match hsConSym "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=:[-!#$%&\*\+./<=>\?@\\^|~:]*"
syn match hsVarSym "`\(\<[A-Z][a-zA-Z0-9_']*\.\)\=[a-z][a-zA-Z0-9_']*`"
syn match hsConSym "`\(\<[A-Z][a-zA-Z0-9_']*\.\)\=[A-Z][a-zA-Z0-9_']*`"

" Reserved symbols--cannot be overloaded.
syn match hsDelimiter  "(\|)\|\[\|\]\|,\|;\|_\|{\|}"

" Strings and constants
syn match   hsSpecialChar   contained 
"\\\([0-9]\+\|o[0-7]\+\|x[0-9a-fA-F]\+\|[\"\\'&\\abfnrtv]\|^[A-Z^_\[\\\]]\)"
syn match   hsSpecialChar   contained 
"\\\(NUL\|SOH\|STX\|ETX\|EOT\|ENQ\|ACK\|BEL\|BS\|HT\|LF\|VT\|FF\|CR\|SO\|SI\|DLE\|DC1\|DC2\|DC3\|DC4\|NAK\|SYN\|ETB\|CAN\|EM\|SUB\|ESC\|FS\|GS\|RS\|US\|SP\|DEL\)"
syn match   hsSpecialCharError  contained "\\&\|'''\+"
syn region  hsStringstart=+"+  skip=+\|\\"+  end=+"+  
contains=hsSpecialChar,@NoSpell
syn match   hsCharacter "[^a-zA-Z0-9_']'\([^\\]\|\\[^']\+\|\\'\)'"lc=1 
contains=hsSpecialChar,hsSpecialCharError
syn match   hsCharacter "^'\([^\\]\|\\[^']\+\|\\'\)'" 
contains=hsSpecialChar,hsSpecialCharError
syn match   hsNumber
"\v<[0-9]%(_*[0-9])*>|<0[xX]_*[0-9a-fA-F]%(_*[0-9a-fA-F])*>|<0[oO]_*%(_*[0-7])*>|<0[bB]_*[01]%(_*[01])*>"
syn match   hsFloat 
"\v<[0-9]%(_*[0-9])*\.[0-9]%(_*[0-9])*%(_*[eE][-+]?[0-9]%(_*[0-9])*)?>|<[0-9]%(_*[0-9])*_*[eE][-+]?[0-9]%(_*[0-9])*>|<0[xX]_*[0-9a-fA-F]%(_*[0-9a-fA-F])*\.[0-9a-fA-F]%(_*[0-9a-fA-F])*%(_*[pP][-+]?[0-9]%(_*[0-9])*)?&g

no matching autocommands for acwrite buffer

[Marcin Szamotulski]

Hello vim_dev,

With some vim plugins (ack, but also fugitive) and a terminal opened
I am getting this error:

Error detected while processing function ack#Ack[41]..181_SearchWithGrep:
line8:
E676: No matching autocommands for acwrite buffer
Error detected while processing function ack#Ack:
line   41:
E171: Missing :endif
E89: No write since last change for buffer 8 (add ! to override) 

setting `set eventignore=BufWriteCmd` does not help (but it probably
shouldn't).  Is this a known issue?

Best regards,
Marcin

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

[Marcin Szamotulski]

On 15:42 Tue 17 Oct , ?? ? wrote:
> when using quickfix list, if the filename is too long, it is hard to read the 
> `text` of each item of the list. I think we should add a new key, such as 
> `abbr`, this will be deplayed if it is not a empty string instead of 
> `filename` or `bufnr`.
> 
> 
> Shidong Wang
> 
> wsd...@outlook.com

I did a PR for this: https://github.com/vim/vim/pull/1757
It's using `module` instead of `abbr`, but otherwise it does what you
want.

Best regards,
Marcin

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

vim screen coruptions

[Marcin Szamotulski]

Hello,

With one of the recent changes when scrolling with  or  the
screen gets corrupted.  The end of lines have ^E or ^Y respectively and
I need to redraw the screen to get rid of them.  I cannot reproduce it
in `vim -u NONE --noplugins` though.

Best,
Marcin

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

[Marcin Szamotulski]

On 21:55 Mon 02 Oct , Bram Moolenaar wrote:
> 
> Patch 8.0.1173
> Problem:Terminal window is not redrawn after CTRL-L. (Marcin Szamotulski)
> Solution:   Redraw the whole terminal when w_redr_type is NOT_VALID.
> Files:  src/terminal.c
> 
> 
> *** ../vim-8.0.1172/src/terminal.c2017-09-30 20:40:23.715291191 +0200
> --- src/terminal.c2017-10-02 21:54:46.477186426 +0200
> ***
> *** 56,61 
> --- 56,62 
>* - GUI: when 'confirm' is set and trying to exit Vim, dialog offers to 
> save
>*   changes to "!shell".
>*   (justrajdeep, 2017 Aug 22)
> +  * - Redrawing is slow with Athena and Motif.
>* - For the GUI fill termios with default values, perhaps like pangoterm:
>*   
> http://bazaar.launchpad.net/~leonerd/pangoterm/trunk/view/head:/main.c#L134
>* - if the job in the terminal does not support the mouse, we can use the
> ***
> *** 2238,2243 
> --- 2239,2250 
>   screen = vterm_obtain_screen(vterm);
>   state = vterm_obtain_state(vterm);
>   
> + if (wp->w_redr_type >= NOT_VALID)
> + {
> + term->tl_dirty_row_start = 0;
> + term->tl_dirty_row_end = MAX_ROW;
> + }
> + 
>   /*
>* If the window was resized a redraw will be triggered and we get here.
>* Adjust the size of the vterm unless 'termsize' specifies a fixed 
> size.
> *** ../vim-8.0.1172/src/version.c 2017-10-02 19:29:44.810988948 +0200
> --- src/version.c 2017-10-02 21:53:37.209617695 +0200
> ***
> *** 763,764 
> --- 763,766 
>   {   /* Add new patch number below this line */
> + /**/
> + 1173,
>   /**/
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 254. You wake up daily with your keyboard printed on your forehead.

Thank you Bram, that fixed the issue.

Best regards,
Marcin

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

terminal && redraw

[Marcin Szamotulski]

Hello,

I have some issues with vim not redrawing the terminal.  For example
after saving a buffer in the same tab the terminal window gets
blank.  These are steps to reproduce it:

```
vim -u NONE --noplugin ~/.vimrc
```
And these vim commands:
```
:terminal
^W^W
:redraw
```

In my setup there's likely a `:redraw` command running when saving
a buffer.

Best,
Marcin

-- 
-- 
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: Terminal normal mode

[Marcin Szamotulski]

On 21:29 Fri 29 Sep , Bram Moolenaar wrote:
> 
> Marcin Szamotulski wrote:
> 
> > There is some interaction between syntax and terminal normal mode.  For
> > me the terminal normal mode draws everything without colors, but if I do
> > `syn off|syn enable`.  The terminal colors are back in terminal normal
> > mode.
> > 
> > If I start `vim -u NONE` and run `:terminal` and go to terminal normal
> > mode:
> > * terminal colors are preserved
> > when I run now `:syn enable`
> > * terminal colors are lost
> > when I run `:syn off|syn enable`
> > * they are back again.
> 
> I cannot reproduce this.

Thank you Bram.  I should have tested it with --noplugin.  That's an
issue caused by https://github.com/vim-scripts/utl.vim

Best regards,
Marcin
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 221. Your wife melts your keyboard in the oven.
> 
>  /// 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.

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

Terminal normal mode

[Marcin Szamotulski]

Hi vim_dev,

There is some interaction between syntax and terminal normal mode.  For
me the terminal normal mode draws everything without colors, but if I do
`syn off|syn enable`.  The terminal colors are back in terminal normal
mode.

If I start `vim -u NONE` and run `:terminal` and go to terminal normal
mode:
* terminal colors are preserved
when I run now `:syn enable`
* terminal colors are lost
when I run `:syn off|syn enable`
* they are back again.

Best regards,
Marcin

-- 
-- 
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: make g< more robust

[Marcin Szamotulski]

On Mon, 13 Mar, 2017 at 9:29 PM, Bram Moolenaar <b...@moolenaar.net> 
wrote:


Marcin Szamotulski wrote:


 On 16:32 Sun 12 Mar , Bram Moolenaar wrote:
 >
 > Marcin Szamotulski wrote:
 >
 > > Currently when leaving cmd line with CTRL-c or ESC the 
lastmsg_chunk is
 > > cleared and hence the g< command will not be useful anymore.  I 
think it
 > > would be nice if it the lastmsg_chunk was not cleared on that 
occasion.
 > > Unfortunately the function that clears it `clear_db_text` is 
called when
 > > the screen is redrawing, e.g. also when entering the command 
line.

 > >
 > > Any hints how to get it done? And if that feature would be 
appreciated?

 >
 > I cannot find lastmsg_chunk or clear_db_text in the Vim code.

 Sorry, it's clear_sb_text
 https://github.com/vim/vim/blob/master/src/message.c#L2458


Aha.

I still don't see how it can be cleared without a reason.  I guess you
actually start typing another command.  So yes, then the output of the
previous command is cleared, that is normal.  "g<" only works when 
typed
right after you (accidentally) ended listing messages.  We don't keep 
it

for more than one command, it would just keep growing forever.


Yes, that's indeed how it gets cleared. I just would like to preserve 
it if I pressed ESC or CTRL-C or the following command did not produced 
any messages.  I think that would make `g<` more robust and useful in 
various scenarios.



Marcin




--
Corduroy pillows: They're making headlines!

 /// 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: make g< more robust

[Marcin Szamotulski]

On 16:32 Sun 12 Mar , Bram Moolenaar wrote:
> 
> Marcin Szamotulski wrote:
> 
> > Currently when leaving cmd line with CTRL-c or ESC the lastmsg_chunk is
> > cleared and hence the g< command will not be useful anymore.  I think it
> > would be nice if it the lastmsg_chunk was not cleared on that occasion.
> > Unfortunately the function that clears it `clear_db_text` is called when
> > the screen is redrawing, e.g. also when entering the command line.
> > 
> > Any hints how to get it done? And if that feature would be appreciated?
> 
> I cannot find lastmsg_chunk or clear_db_text in the Vim code.

Sorry, it's clear_sb_text
https://github.com/vim/vim/blob/master/src/message.c#L2458

> 
> > I also found one bug how messages are shown:
> > 
> > :for x in [1,2,3]|echom x|endfor
> > 1
> > 2
> > 3
> > " so far so good but hit enter and press g< and the screen shows
> > 1for x in [1,2,3]|echom x|endfor
> > 2
> > 3
> 
> I can reproduce this.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 92. It takes you two hours to check all 14 of your mailboxes.
> 
>  /// 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.


signature.asc
Description: Digital signature

make g< more robust

[Marcin Szamotulski]

Hello,

Currently when leaving cmd line with CTRL-c or ESC the lastmsg_chunk is
cleared and hence the g< command will not be useful anymore.  I think it
would be nice if it the lastmsg_chunk was not cleared on that occasion.
Unfortunately the function that clears it `clear_db_text` is called when
the screen is redrawing, e.g. also when entering the command line.

Any hints how to get it done? And if that feature would be appreciated?

I also found one bug how messages are shown:

:for x in [1,2,3]|echom x|endfor
1
2
3
" so far so good but hit enter and press g< and the screen shows
1for x in [1,2,3]|echom x|endfor
2
3

Best regards,
Marcin Szamotulski

-- 
-- 
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: Vim 8.0 released!

[Marcin Szamotulski]

Congrats and thanks for the work!

Marcin

On 14:53 Mon 12 Sep , Bram Moolenaar wrote:
> 
> 
> Hello Vim users!
> 
> 
> Announcing:  Vim (Vi IMproved) version 8.0
> 
> 
> This the first major Vim release in ten years.  There are interesting
> new features, many small improvements and lots of bug fixes.
> 
> Among the new features are:
> - Asynchronous I/O support, channels, JSON
> - Jobs
> - Timers
> - Partials, Lambdas and Closures
> - Packages
> - New style testing
> - Viminfo merged by timestamp
> - GTK+ 3 support
> - MS-Windows DirectX support
> 
> 
> Once you have installed Vim 8.0 you can find details about the changes
> since Vim 7.4 with:
> :help version8
> Or view it online:
> https://raw.githubusercontent.com/vim/vim/master/runtime/doc/version8.txt
> 
> 
> Gratitude
> -
> 
> If you like Vim, please consider helping poor children in the south of
> Uganda: http://iccf-holland.org
> 
> 
> Where to get it
> ---
> 
> The best way to obtain the latest Vim is using Git.  Summary:
>   git clone https://github.com/vim/vim.git
> More information here: http://www.vim.org/git.php
> 
> For MS-Windows most of you will want the self-installing executable:
> ftp://ftp.vim.org/pub/vim/pc/gvim80.exe
> 
> Information about which files to download for what system:
> http://www.vim.org/download.php
> 
> A list of mirror sites can be found here:
> http://www.vim.org/mirrors.php
> 
> 
> The files available for download:
> 
> UNIX:
> sources + runtime files, bzip2 compressed:
>   ftp://ftp.vim.org/pub/vim/unix/vim-8.0.tar.bz2
> 
> VARIOUS:
> help files converted to HTML:
>   ftp://ftp.vim.org/pub/vim/doc/vim80html.zip
> 
> MS-WINDOWS one-size-fits-all:
> Self-installing, includes all runtime files, loads libraries dynamically:
>   ftp://ftp.vim.org/pub/vim/pc/gvim80.exe
> 
> MS-WINDOWS separate files:
> Runtime files:
>   ftp://ftp.vim.org/pub/vim/pc/vim80rt.zip
> GUI binary for Windows 95/98/NT/2000/XP/7:
>   ftp://ftp.vim.org/pub/vim/pc/gvim80.zip
> GUI binary with OLE support:
>   ftp://ftp.vim.org/pub/vim/pc/gvim80ole.zip
> Console version for Windows NT/2000/XP/7:
>   ftp://ftp.vim.org/pub/vim/pc/vim80w32.zip
> Sources for PC (with CR-LF):
>   ftp://ftp.vim.org/pub/vim/pc/vim80src.zip
> 
> For debugging:
> ftp://ftp.vim.org/pub/vim/pc/gvim80.pdb
> ftp://ftp.vim.org/pub/vim/pc/gvim80ole.pdb
> ftp://ftp.vim.org/pub/vim/pc/vim80w32.pdb
> 
> AMIGA:
> Only runtime and sources are provided, no binary:
>   ftp://ftp.vim.org/pub/vim/amiga/vim80rt.tgz
>   ftp://ftp.vim.org/pub/vim/amiga/vim80src.tgz
> 
> 
> Omitted in this version are:
> - The 16-bit DOS, OS/2 and Amiga versions, these are obsolete.
> - The 32-bit console version for MS-DOS/Windows 95/98
> - The 16 bit MS-Windows version
> 
> 
> Mailing lists
> -
> 
> For user questions you can turn to the Vim mailing list.  There are a
> lot of tips, scripts and solutions.  You can ask your Vim questions, but
> only if you subscribe.  See http://www.vim.org/maillist.php#vim
> 
> If you want to help Vim development, discuss new features or get the
> latest patches, subscribe to the vim-dev mailing list.  See
> http://www.vim.org/maillist.php#vim-dev
> 
> Subject specific lists:
> Macintosh issues:  http://www.vim.org/maillist.php#vim-mac
> 
> Before you ask a question you should search the archives, someone may
> already have given the answer.
> 
> 
> Reporting bugs
> --
> 
> Send them to .  Please describe the problem precisely.
> All the time spent on answering mail is subtracted from the time that is
> spent on improving Vim!  Always give a reproducible example and try to
> find out which settings or other things influence the appearance of the
> bug.  Try starting without your own vimrc file: "vim -u NONE".  Try
> different machines if possible.  See ":help bugs" in Vim.
> 
> Alternatively, create an issue at github and/or a pull request.
> Please try to write a test that reproduces the problem and will pass
> once it is fixed. See https://github.com/vim/vim
> 
> 
> Happy Vimming!
> 
> 
> -- 
> "Marriage is a wonderful institution...
> but who wants to live in an institution?"
>  - Groucho Marx
> 
>  /// 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 

Re: Patch 7.4.2231

[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

[Marcin Szamotulski]

On 07:52 Mon 22 Aug , David Fishburn wrote:
> On Sat, Aug 20, 2016 at 12:37 PM, Bram Moolenaar  wrote:
> 
> >
> > Patch 7.4.2231
> > Problem:":oldfiles" output is a very long list.
> > Solution:   Add a pattern argument. (Coot, closes #575)
> >
> >
> I was wondering if something similar to this could be added to the :let
> command (though it has a lot of permutations).
> 
> I can do the following:
> :let g:
> 
> I would love to do the following:
> :let g:loaded_db\w\+
> 
> And return only those matching variables.
> 
> David

Indeed this might be useful.  You can do

:let g:loaded_db

But this will not show the values.

Cheers,
Marcin

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

[Marcin Szamotulski]

On 05:38 Sun 21 Aug , John Marriott wrote:
> On 21-Aug-2016 02:37, Bram Moolenaar wrote:
> > Patch 7.4.2231
> > Problem:":oldfiles" output is a very long list.
> > Solution:   Add a pattern argument. (Coot, closes #575)
> > Files:  runtime/doc/starting.txt, src/ex_cmds.h, src/eval.c,
> >  src/ex_cmds.c, src/proto/eval.pro, src/proto/ex_cmds.pro,
> >  src/testdir/test_viminfo.vim
> >
> >
> After this patch I get the following warning (on mingw64) if 
> FEAT_QUICKFIX is not defined:
> gcc -c -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 
> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32
>   -DFEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer 
> -freg-struct-return -s ex_cmds.c -o gobjnative/ex_cmds.o
> ex_cmds.c: In function 'ex_oldfiles':
> ex_cmds.c:8415:10: warning: implicit declaration of function 
> 'skip_vimgrep_pat' [-Wimplicit-function-declaration]
>if (skip_vimgrep_pat(eap->arg, _pat, NULL) == NULL)
>^~~~
> ex_cmds.c:8415:53: warning: comparison between pointer and integer
>if (skip_vimgrep_pat(eap->arg, _pat, NULL) == NULL)
>   ^~
> 
> Followed by this linker error:
> gcc -Iproto -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 -DHAVE_PATHDEF 
> -DFEAT_NORMAL -DHAVE_STDINT_H -DFEAT_GUI_W32 -D
> FEAT_CLIPBOARD -pipe -march=native -Wall -O3 -fomit-frame-pointer 
> -freg-struct-return -s -Wl,-nxcompat,-dynamicbase -mwindows -o gvim.exe 
> gobjnative/arabic.o gobjnative/blowfish.o gobjnative/buffer.o 
> gobjnative/charset.o gobjnative/crypt.o gobjnative/crypt_zip.o 
> gobjnative/dict.o gobjnative/diff.o gobjnative/digraph.o 
> gobjnative/edit.o gobjnative/eval.o gobjnative/evalfunc.o 
> gobjnative/ex_cmds.o gobjnative/ex_cmds2.o gobjnative/ex_docmd.o 
> gobjnative/ex_eval.o gobjnative/ex_getln.o gobjnative/farsi.o 
> gobjnative/fileio.o gobjnative/fold.o gobjnative/getchar.o 
> gobjnative/hardcopy.o gobjnative/hashtab.o gobjnative/json.o 
> gobjnative/list.o gobjnative/main.o gobjnative/mark.o 
> gobjnative/memfile.o gobjnative/memline.o gobjnative/menu.o 
> gobjnative/message.o gobjnative/misc1.o gobjnative/misc2.o 
> gobjnative/move.o gobjnative/mbyte.o gobjnative/normal.o 
> gobjnative/ops.o gobjnative/option.o gobjnative/os_win32.o 
> gobjnative/os_mswin.o gobjnative/winclip.o gobjnative/pathdef.o 
> gobjnative/popupmnu.o gobjnative/quickfix.o gobjnative/regexp.o 
> gobjnative/screen.o gobjnative/search.o gobjnative/sha256.o 
> gobjnative/spell.o gobjnative/spellfile.o gobjnative/syntax.o 
> gobjnative/tag.o gobjnative/term.o gobjnative/ui.o gobjnative/undo.o 
> gobjnative/userfunc.o gobjnative/version.o gobjnative/vimrc.o 
> gobjnative/window.o gobjnative/gui.o gobjnative/gui_w32.o 
> gobjnative/gui_beval.o gobjnative/os_w32exe.o -lkernel32 -luser32 
> -lgdi32 -ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lole32 -luuid
> gobjnative/ex_cmds.o:ex_cmds.c:(.text+0xb229): undefined reference to 
> `skip_vimgrep_pat'
> collect2.exe: error: ld returned 1 exit status
> Make_cyg_ming.mak:829: recipe for target 'gvim.exe' failed
> make: *** [gvim.exe] Error 1
> 
> skip_vimgrep_pat() is defined in quickfix.c, but the contents are only 
> included if FEAT_QUICKFIX or PROTO is defined.
> 
> Cheers
> John

The attached patch fixes that.

Cheers,
Marcin

-- 
-- 
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/quickfix.c b/src/quickfix.c
index 2fa6ed9..d3def61 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -4317,6 +4317,7 @@ theend:
 vim_free(target_dir);
 vim_regfree(regmatch.regprog);
 }
+#endif
 
 /*
  * Skip over the pattern argument of ":vimgrep /pat/[g][j]".
@@ -4370,6 +4371,7 @@ skip_vimgrep_pat(char_u *p, char_u **s, int *flags)
 return p;
 }
 
+#if defined(FEAT_QUICKFIX) || defined(PROTO)
 /*
  * Restore current working directory to "dirname_start" if they differ, taking
  * into account whether it is set locally or globally.


signature.asc
Description: Digital signature

Re: Channel & job design

[Marcin Szamotulski]

On 23:58 Sat 13 Feb , Bram Moolenaar wrote:
> 
> Marcin Szamotulski wrote:
> 
> > > > That's a really great feature.  I am trying to implemented a gulp plugin
> > > > (gulp is a node package used to build web apps) based on channels and
> > > > there are two things that I has a problem with:
> > > 
> > > Thanks for the feedback.  Keep in mind that the feature is still being
> > > developed.  Some things may just be missing.  But there can also be bugs
> > > and things that don't work for you, so feedback is useful anyway.
> > 
> > Yes I understand that, the idea is to contribute to the development in
> > some fruitful way.
> 
> Note that the type of the channel handle has changed.  That mainly
> matters for when checking whether ch_open() worked.
> 
> > > > 1) when I use `job_start()` to start a server in the background and
> > > > immediately after I call `ch_open()` to open channel to that server I am
> > > > always refused: `E896: read from channel: Connection refused`.
> > > > 
> > > > However, if I check `job_status` in between (which is what
> > > > I should do anyway), then the following `ch_open` runs fine.  There is
> > > > no way now to communicate from the job that started that what it runs is
> > > > ready to connect to.
> > > 
> > > It's normal for a process to have some initialization time before the
> > > socket is ready for use.  This is implemented, it already existed for
> > > netbeans.  Did you add a "waittime" argument?  The default is zero.
> > 
> > I just tried it:
> > * adding waittime does not help
> > * adding `sleep 1m` before calling `ch_open` solved the problem
> > 
> > Which is not what I'd expect.
> 
> I assume we need to treat that error as a temporary failure and retry.
> There was a similar problem on Mac, where a 1 msec waittime did work.

`sleep 100m` is more reliable, with just 1m wait I am getting errors
today,

> 
> > > > 2) when my server sends data back to vim only the first message is
> > > > received.  This can be reproduced by the demoserver.py example.  Just
> > > > double the lines in `ThreadedTCPRequestHandler.handle`:
> > > > print("sending {}".format(encoded))
> > > > self.request.sendall(encoded.encode('utf-8'))
> > > > print("sending {}".format(encoded))
> > > > self.request.sendall(encoded.encode('utf-8'))
> > > > 
> > > > And vim will only get the first message.  It would be nice if the socket
> > > > was reading until explicitly closed by the server.  It would be useful
> > > > for my case to send updates from the background process spawn by the 
> > > > server
> > > > that I wrote.
> > > 
> > > If you are using raw messages Vim has no clue where a message ends and
> > > whether there is more coming.  Vim should get the second message, but
> > > possibly only in the next read.  If it never arrives there can be a bug.
> > > I just fixed one where raw messages were dropped when there is no
> > > handler.
> > 
> > I am using the default `json` messages.  I found that this works fine,
> > from the server:
> > 
> > socket.write(JSON.stringify([0, ["ex", "call MyHandler('" + msg + 
> > "')"]);
> > 
> > the problem with this approach is to encode msg properly so that it
> > does not contain any `'` which would be misinterpreted by vim when
> > evaluating the expression.
> > 
> > 
> > > I just added the ch_logfile() function, that will be useful to find out
> > > what is happening.
> > 
> > Great, I will try and check what is going on.

`ch_logfile` is very helpful.  I could see that when I attach a handler
with `ch_sendexpr` it is invoked only once on a message that has the
correct ID. I was sending from the server `[requestID, data]` and if
`requestID` is greater than 0 the callback is invoked only once and this
seems the intended behaviour of `may_invoke_callback` function in
channel.c.  Reading the source I found that I should rather register the
callback as a channel callback using `ch_open`.

I think that the user expects that the callback will be called on every
message with that given `requestID`.  The problem might be when to
un-register the callback.  One could for example to check for the
returned value, if is is false or true and remove it when is it is true.
I guess this is all about freeing the memory and leaving this up to
a plugin author might not be a safe option, 

Re: Channel & job design

[Marcin Szamotulski]

Hello Bram!

That's a really great feature.  I am trying to implemented a gulp plugin
(gulp is a node package used to build web apps) based on channels and
there are two things that I has a problem with:

1) when I use `job_start()` to start a server in the background and
immediately after I call `ch_open()` to open channel to that server I am
always refused: `E896: read from channel: Connection refused`.

However, if I check `job_status` in between (which is what
I should do anyway), then the following `ch_open` runs fine.  There is
no way now to communicate from the job that started that what it runs is
ready to connect to.

2) when my server sends data back to vim only the first message is
received.  This can be reproduced by the demoserver.py example.  Just
double the lines in `ThreadedTCPRequestHandler.handle`:
print("sending {}".format(encoded))
self.request.sendall(encoded.encode('utf-8'))
print("sending {}".format(encoded))
self.request.sendall(encoded.encode('utf-8'))

And vim will only get the first message.  It would be nice if the socket
was reading until explicitly closed by the server.  It would be useful
for my case to send updates from the background process spawn by the server
that I wrote.

Best regards,
Marcin Szamotulski

On 22:08 Mon 08 Feb , Bram Moolenaar wrote:
> 
> Thanks for the feedback.  I think it's time to sketch the upcoming work.
> It appears some thought that sockets was the end of it, that's not so.
> 
> 
> For jobs the most useful are probably:
> - A deamon, serving several Vim instances, connect by socket.
> - One server working with one Vim instance, asynchronously.
> - A server performing some work for a short time, asynchronously.
> - Running a filter, synchronously (existing functionality)
> 
> A channel can communicate over:
> - A socket (what ch_open() currently does)
> - A pipe (only possible with an associated job) connected to
>   stdin/stdout/stderr.
> 
> A channel can communicate:
> - With JSON messages
> - With JS messages
> - Raw messages
> - NL-separated messages (this is what netbeans uses)
> 
> A channel can be associated with a job, but that job does not
> necessarily need be under control of the current Vim (or any Vim)
> instance.
> 
> It looks like all the functionality is already present in the Vim code
> somewhere, we just have to make it available in the right way.  The
> missing part, a timeout on connect(), was recently added, this may still
> need some work.
> 
> Raw messages have the problem that Vim doesn't know where the end of a
> message is, thus it might invoke a callback with an incomplete message.
> The callback will then have the task of parsing and queuing readahead.
> Using line breaks is the most common alternative, we can support that.
> 
> Some combinations are likely to be most useful.  I heard some people
> mention using a server over pipes to write a message to and call a
> callback when the response is received.  I assume this would work best
> with NL separated messages.
> 
> Using pipes only works when starting a job.  Thus these are closely
> coupled.
> 
> The deamon that serves multiple Vim instances would be most useful to
> lookup code locations, for example.  Probably best use JSON or JS for
> that, as it makes it easier to add more features over time.
> 
> One step further would be to use protocol buffers.  I think that it's a
> step too far right now, maybe later.  The current protocol buffer
> support unfortunately doesn't support the JS format that I like (the
> JSON format uses field names instead of numbers, an unfortunate choice,
> as it makes version mismatches difficult).
> 
> 
> Some parts that we still need that require some thougths:
> 
> - Communicating over a socket requires knowing the port number.  For a
>   deamon this would be a known number.  For a server started by Vim it's
>   best to let the server pick an available port.  Then how does it tell
>   Vim what port it picked?  In test_channel we write the port number in
>   a file.  That's not ideal, but perhaps there is no better solution.
>   Having Vim pick a free port and pass it to the server has race conditions
>   (but it might still be an acceptable solution).
> 
> - When starting a job, where does it's stdin/stdout/stderr go?
>   Possibly the same terminal as Vim, a newly started terminal, a file or
>   /dev/null.  No, running a terminal inside Vim is not an option.  But
>   we could write stdout/stderr into a buffer.
> 
> 
> For starting a deamon job we could have:
>let job = job_start("cmd", {options})
> 
> We could make it a bit clever, only start the deamon when it's not
> running yet.  This would check whether connecting to the socket works,
> with a zero ti

Re: Lua 5.3 detection on Windows using Vim 7.4.691

[Marcin Szamotulski]

On 20:41 Tue 07 Apr , Pedro Ferrari wrote:
 I use the following Vim 7.4.691 build on a Windows x64 machine:
 
 https://tuxproject.de/projects/vim/
 
 I have Lua 5.3 correctly installed and added to my `%PATH%` env variable. In 
 fact when I run `:!where lua53.dll` I get `C:\Users\Pedro\lua\lua53.dll`.
 However`:echo has('lua')` returns `0` and `:lua print('foo')` gives the 
 following error:

It seems that your vim is not compiled with lua support.  You need to
compile it your self or find a windows precompiled version with lua on
the net.

You can also check `:version` and I guess you will find `-lua` (while
you'd like to have there `+lua`.

Cheers,
Marcin

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

ls with flags

[Marcin Szamotulski]

Dear Bram,

Some times I have lots of files opened in vim, I found it very useful to
limit the output of `:ls` command to only modified ones, etc.  The
attached patch adds flags to the ls command which let to list files
which are hidden or active or modified, or readonly or with nomodifiable
set, etc.  The same as what ls puts in the output.  I think this might
be useful for others as well.  Let me know what do you think of it.

Best regards,
Marcin

-- 
-- 
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/windows.txt b/runtime/doc/windows.txt
index 532cca3..d5eeca8 100644
--- a/runtime/doc/windows.txt
+++ b/runtime/doc/windows.txt
@@ -986,9 +986,10 @@ A buffer can also be unlisted.  This means it exists, but it is not in the
 list of buffers. |unlisted-buffer|
 
 
-:files[!]	*:files*
-:buffers[!]	*:buffers* *:ls*
-:ls[!]		Show all buffers.  Example:
+:files[!] [flag]*:files*
+:buffers[!] [flag]*:buffers* *:ls*
+:ls[!] [flag]
+		Show all buffers.  Example:
 
 			1 #h   /test/text		line 1 ~
 			2u asdf			line 0 ~
@@ -1014,6 +1015,16 @@ list of buffers. |unlisted-buffer|
 		+	a modified buffer
 		x   a buffer with read errors
 
+		[flag] can be one of 'u', '%', '#', 'a', 'h', '-', '=', '+' or
+		'x'.  Only files with the given flag will be listed, you can
+		set more than one flag, e.g.  
+		ls +  list modified buffers
+		ls -  list buffers with 'modifiable' off
+		ls =  list readonly buffers
+		ls u  list unloaded buffers (overwrites the bang)
+		ls h+  list hidden buffers which are modified
+		ls a+  list active buffers which are modified, etc
+
 		*:bad* *:badd*
 :bad[d]	[+lnum] {fname}
 		Add file name {fname} to the buffer list, without loading it.
diff --git a/src/buffer.c b/src/buffer.c
index e4230fc..0659e9f 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -2754,7 +2754,17 @@ buflist_list(eap)
 for (buf = firstbuf; buf != NULL  !got_int; buf = buf-b_next)
 {
 	/* skip unlisted buffers, unless ! was used */
-	if (!buf-b_p_bl  !eap-forceit)
+	if (!buf-b_p_bl  !eap-forceit  !vim_strchr((char_u *) eap-arg, 'u') ||
+		vim_strchr((char_u *) eap-arg, 'u')  buf-b_p_bl ||
+		vim_strchr((char_u *) eap-arg, '+')  (buf-b_flags  BF_READERR || !bufIsChanged(buf)) ||
+		vim_strchr((char_u *) eap-arg, 'a')  (buf-b_ml.ml_mfp == NULL || buf-b_nwindows == 0) ||
+		vim_strchr((char_u *) eap-arg, 'h')  (buf-b_ml.ml_mfp == NULL || buf-b_nwindows != 0) ||
+		vim_strchr((char_u *) eap-arg, '-')  buf-b_p_ma ||
+		vim_strchr((char_u *) eap-arg, '=')  !buf-b_p_ro ||
+		vim_strchr((char_u *) eap-arg, 'x')  !(buf-b_flags  BF_READERR) ||
+		vim_strchr((char_u *) eap-arg, '%')  buf != curbuf ||
+		vim_strchr((char_u *) eap-arg, '#')  (buf == curbuf || curwin-w_alt_fnum != buf-b_fnum)
+	)
 	continue;
 	msg_putchar('\n');
 	if (buf_spname(buf) != NULL)
diff --git a/src/ex_cmds.h b/src/ex_cmds.h
index 21d42d5..7945956 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -217,7 +217,7 @@ EX(CMD_browse,		browse,	ex_wrongmodifier,
 			NEEDARG|EXTRA|NOTRLCOM|CMDWIN,
 			ADDR_LINES),
 EX(CMD_buffers,		buffers,	buflist_list,
-			BANG|TRLBAR|CMDWIN,
+			BANG|EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_bufdo,		bufdo,	ex_listdo,
 			BANG|NEEDARG|EXTRA|NOTRLCOM|RANGE|NOTADR|DFLALL,
@@ -526,7 +526,7 @@ EX(CMD_file,		file,		ex_file,
 			RANGE|NOTADR|ZEROR|BANG|FILE1|TRLBAR,
 			ADDR_LINES),
 EX(CMD_files,		files,	buflist_list,
-			BANG|TRLBAR|CMDWIN,
+			BANG|EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_filetype,	filetype,	ex_filetype,
 			EXTRA|TRLBAR|CMDWIN,
@@ -847,7 +847,7 @@ EX(CMD_lwindow,		lwindow,	ex_cwindow,
 			RANGE|NOTADR|COUNT|TRLBAR,
 			ADDR_LINES),
 EX(CMD_ls,		ls,		buflist_list,
-			BANG|TRLBAR|CMDWIN,
+			BANG|EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_move,		move,		ex_copymove,
 			RANGE|WHOLEFOLD|EXTRA|TRLBAR|CMDWIN|MODIFY,


signature.asc
Description: Digital signature

Re: ls with flags

[Marcin Szamotulski]

On 22:23 Sat 31 Jan , Bram Moolenaar wrote:
 
 Marcin -
 
  Dear Bram,
  
  Some times I have lots of files opened in vim, I found it very useful to
  limit the output of `:ls` command to only modified ones, etc.  The
  attached patch adds flags to the ls command which let to list files
  which are hidden or active or modified, or readonly or with nomodifiable
  set, etc.  The same as what ls puts in the output.  I think this might
  be useful for others as well.  Let me know what do you think of it.
 
 Yes, that sounds useful.  Thanks for the patch.
 
 With overwrites the bang I think you mean overrules the bang.
 
 - Bram

Yes indeed. I updated the patch.

Marcin

-- 
-- 
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/windows.txt b/runtime/doc/windows.txt
index 532cca3..1284a86 100644
--- a/runtime/doc/windows.txt
+++ b/runtime/doc/windows.txt
@@ -986,9 +986,10 @@ A buffer can also be unlisted.  This means it exists, but it is not in the
 list of buffers. |unlisted-buffer|
 
 
-:files[!]	*:files*
-:buffers[!]	*:buffers* *:ls*
-:ls[!]		Show all buffers.  Example:
+:files[!] [flag]*:files*
+:buffers[!] [flag]*:buffers* *:ls*
+:ls[!] [flag]
+		Show all buffers.  Example:
 
 			1 #h   /test/text		line 1 ~
 			2u asdf			line 0 ~
@@ -1014,6 +1015,16 @@ list of buffers. |unlisted-buffer|
 		+	a modified buffer
 		x   a buffer with read errors
 
+		[flag] can be one of 'u', '%', '#', 'a', 'h', '-', '=', '+' or
+		'x'.  Only files with the given flag will be listed, you can
+		set more than one flag, e.g.  
+		ls +  list modified buffers
+		ls -  list buffers with 'modifiable' off
+		ls =  list readonly buffers
+		ls u  list unloaded buffers (overrules the bang)
+		ls h+  list hidden buffers which are modified
+		ls a+  list active buffers which are modified, etc
+
 		*:bad* *:badd*
 :bad[d]	[+lnum] {fname}
 		Add file name {fname} to the buffer list, without loading it.
diff --git a/src/buffer.c b/src/buffer.c
index e4230fc..0659e9f 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -2754,7 +2754,17 @@ buflist_list(eap)
 for (buf = firstbuf; buf != NULL  !got_int; buf = buf-b_next)
 {
 	/* skip unlisted buffers, unless ! was used */
-	if (!buf-b_p_bl  !eap-forceit)
+	if (!buf-b_p_bl  !eap-forceit  !vim_strchr((char_u *) eap-arg, 'u') ||
+		vim_strchr((char_u *) eap-arg, 'u')  buf-b_p_bl ||
+		vim_strchr((char_u *) eap-arg, '+')  (buf-b_flags  BF_READERR || !bufIsChanged(buf)) ||
+		vim_strchr((char_u *) eap-arg, 'a')  (buf-b_ml.ml_mfp == NULL || buf-b_nwindows == 0) ||
+		vim_strchr((char_u *) eap-arg, 'h')  (buf-b_ml.ml_mfp == NULL || buf-b_nwindows != 0) ||
+		vim_strchr((char_u *) eap-arg, '-')  buf-b_p_ma ||
+		vim_strchr((char_u *) eap-arg, '=')  !buf-b_p_ro ||
+		vim_strchr((char_u *) eap-arg, 'x')  !(buf-b_flags  BF_READERR) ||
+		vim_strchr((char_u *) eap-arg, '%')  buf != curbuf ||
+		vim_strchr((char_u *) eap-arg, '#')  (buf == curbuf || curwin-w_alt_fnum != buf-b_fnum)
+	)
 	continue;
 	msg_putchar('\n');
 	if (buf_spname(buf) != NULL)
diff --git a/src/ex_cmds.h b/src/ex_cmds.h
index 21d42d5..7945956 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -217,7 +217,7 @@ EX(CMD_browse,		browse,	ex_wrongmodifier,
 			NEEDARG|EXTRA|NOTRLCOM|CMDWIN,
 			ADDR_LINES),
 EX(CMD_buffers,		buffers,	buflist_list,
-			BANG|TRLBAR|CMDWIN,
+			BANG|EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_bufdo,		bufdo,	ex_listdo,
 			BANG|NEEDARG|EXTRA|NOTRLCOM|RANGE|NOTADR|DFLALL,
@@ -526,7 +526,7 @@ EX(CMD_file,		file,		ex_file,
 			RANGE|NOTADR|ZEROR|BANG|FILE1|TRLBAR,
 			ADDR_LINES),
 EX(CMD_files,		files,	buflist_list,
-			BANG|TRLBAR|CMDWIN,
+			BANG|EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_filetype,	filetype,	ex_filetype,
 			EXTRA|TRLBAR|CMDWIN,
@@ -847,7 +847,7 @@ EX(CMD_lwindow,		lwindow,	ex_cwindow,
 			RANGE|NOTADR|COUNT|TRLBAR,
 			ADDR_LINES),
 EX(CMD_ls,		ls,		buflist_list,
-			BANG|TRLBAR|CMDWIN,
+			BANG|EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_move,		move,		ex_copymove,
 			RANGE|WHOLEFOLD|EXTRA|TRLBAR|CMDWIN|MODIFY,


signature.asc
Description: Digital signature

Re: BUG: /foo/,/bar/argdo proceeds after E14: Invalid address

[Marcin Szamotulski]

On 15:33 Fri 30 Jan , Ingo Karkat wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 29-Jan-2015 22:05, Marcin Szamotulski wrote:
  On 17:13 Thu 29 Jan , Ingo Karkat wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
  
  Hello Vim developers,
  
  the new range handling on :argdo (and :bufdo, :windo) proceeds
  even if a silly (and invalid) range is passed to it:
  
  $ vim -N -u NONE :args *.txt :/foo/,/bar/argdo echo bufnr('') 
  E14: Invalid address 2 INSTALLmac.txt 67 lines, 1942
  characters 3 INSTALLpc.txt 513 lines, 19434 characters 4 
  INSTALLvms.txt 393 lines, 12432 characters 5 INSTALLx.txt 165
  lines, 5354 characters 6 README.txt 143 lines, 5178 characters 
  7
  
  In contrast, :1,999argdo echo bufnr('') correctly aborts with 
  E16: Invalid range
  
  - -- regards, ingo
  
  The attached patch fixes this and also fixes a typo in a comment.
  
  Regards, Marcin
 
 Thanks Marcin for that very quick response. However, your patch didn't
 fix the given problem; two very similar other places need to set cmd
 to NULL, too. Please see the attached, revised patch (still including
 the fixed typo).
 
 - -- regards, ingo

Thanks Ingo, indeed I missed the other places.  Now cmd is set to NULL
before every `goto error` as it should be.

Regards,
Marci

-- 
-- 
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: BUG: /foo/,/bar/argdo proceeds after E14: Invalid address

[Marcin Szamotulski]

On 17:13 Thu 29 Jan , Ingo Karkat wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello Vim developers,
 
 the new range handling on :argdo (and :bufdo, :windo) proceeds even if
 a silly (and invalid) range is passed to it:
 
 $ vim -N -u NONE
 :args *.txt
 :/foo/,/bar/argdo echo bufnr('')
 E14: Invalid address
 2
 INSTALLmac.txt 67 lines, 1942 characters
 3
 INSTALLpc.txt 513 lines, 19434 characters
 4
 INSTALLvms.txt 393 lines, 12432 characters
 5
 INSTALLx.txt 165 lines, 5354 characters
 6
 README.txt 143 lines, 5178 characters
 7
 
 In contrast,
 :1,999argdo echo bufnr('')
 correctly aborts with
 E16: Invalid range
 
 - -- regards, ingo

The attached patch fixes this and also fixes a typo in a comment.

Regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index a59bbd1..97259ff 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -4484,6 +4484,7 @@ get_address(ptr, addr_type, skip, to_other_file)
 		if (addr_type != ADDR_LINES)
 		{
 		EMSG(_(e_invaddr));
+		cmd = NULL;
 		goto error;
 		}
 		if (*cmd == '')
@@ -4662,7 +4663,7 @@ invalid_range(eap)
 		return (char_u *)_(e_invrange);
 		break;
 	case ADDR_ARGUMENTS:
-		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARCOUNT is 0
+		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARGCOUNT is 0
 		return (char_u *)_(e_invrange);
 		break;
 	case ADDR_BUFFERS:


signature.asc
Description: Digital signature

count for zr and zm (patch)

[Marcin Szamotulski]

Hi Bram,

I attach a small patch which adds count for zr and zm normal commands.  It
also adds a check to not go beyond the maximal fold level with zr.

Best regards,
Marcin

-- 
-- 
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/fold.txt b/runtime/doc/fold.txt
index 6ae2ff8..20017d3 100644
--- a/runtime/doc/fold.txt
+++ b/runtime/doc/fold.txt
@@ -365,7 +365,7 @@ zX		Undo manually opened and closed folds: re-apply 'foldlevel'.
 		Also forces recomputing folds, like |zx|.
 
 			*zm*
-zm		Fold more: Subtract one from 'foldlevel'.  If 'foldlevel' was
+zm		Fold more: Subtract |v:count1| from 'foldlevel'.  If 'foldlevel' was
 		already zero nothing happens.
 		'foldenable' will be set.
 
@@ -374,7 +374,7 @@ zM		Close all folds: set 'foldlevel' to 0.
 		'foldenable' will be set.
 
 			*zr*
-zr		Reduce folding: Add one to 'foldlevel'.
+zr		Reduce folding: Add |v:count1| to 'foldlevel'.
 
 			*zR*
 zR		Open all folds.  This sets 'foldlevel' to highest fold level.
diff --git a/src/normal.c b/src/normal.c
index 74a001e..311f1cf 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -4750,6 +4750,7 @@ nv_zet(cap)
 long	n;
 colnr_T	col;
 int		nchar = cap-nchar;
+int		d;
 #ifdef FEAT_FOLDING
 long	old_fdl = curwin-w_p_fdl;
 int		old_fen = curwin-w_p_fen;
@@ -5098,7 +5099,11 @@ dozet:
 
 		/* zm: fold more */
 case 'm':	if (curwin-w_p_fdl  0)
-		--curwin-w_p_fdl;
+		{
+		curwin-w_p_fdl -= cap-count1;
+		if (curwin-w_p_fdl  0)
+			curwin-w_p_fdl = 0;
+		}
 		old_fdl = -1;		/* force an update */
 		curwin-w_p_fen = TRUE;
 		break;
@@ -5110,7 +5115,10 @@ dozet:
 		break;
 
 		/* zr: reduce folding */
-case 'r':	++curwin-w_p_fdl;
+case 'r':	curwin-w_p_fdl += cap-count1;
+		d = getDeepestNesting();
+		if (curwin-w_p_fdl = d)
+		curwin-w_p_fdl = d;
 		break;
 
 		/* zR: open all folds */


signature.asc
Description: Digital signature

Re: :bdelete broken

[Marcin Szamotulski]

On 17:19 Mon 19 Jan , Ronald Schild wrote:
 Hello group,
 
 one of the recent patches broke something for bdelete with range. I tried
 with vim -Nu NONE -U NONE to eliminate influence of my vimrc files.
 
 vim -Nu NONE -U NONE xxx yyy zzz
 
 :ls
   1 %a   xxx  line 1
   2  yyy  line 0
   3  zzz  line 0
 Press ENTER or type command to continue
 :2,3bdelete
 E16: Invalid range
 :2bdelete
 E16: Invalid range
 :3bdelete
 E16: Invalid range
 
 It's Vim 7.4, Included patches: 1-580
 
 TIA
 
 Ronald

Thanks for reporting, I can reproduce the error.  I'll write a fix for
that soon.

Best regards,
Marcin

-- 
-- 
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: Vim 7.4.579: wincmd range problem with manpageview plugin

[Marcin Szamotulski]

On 14:40 Wed 14 Jan , Charles Campbell wrote:
 Gary Johnson wrote:
  I just updated to 7.4.579 on one of my Linux systems.  With the
  cursor over printf in a C file, typing K results in the following
  error message.
 
  Error detected while processing function 
  manpageview#KMap..manpageview#ManPageView:  
  
   
  line  258:
  E16: Invalid range: 3wincmd -
  Press ENTER or type command to continue
 
  I'm using plugin/manpageviewPlugin.vim version 25b (Aug 06, 2012)
  and autoload/manpageview.vim version 25k ASTRO-ONLY (Apr 05, 2013).
 
 
 Hello, Gary:
 
 Patch #565 introduced a problem in its attempt to error-check ranges;
 its being worked now.  To demonstrate:  try
 
   vim -u NONE
   :52wincmd v
 
 and you'll likely get an invalid range error message.
 
 Regards,
 Chip Campbell

Hello,

Bram the attached patch fixes this issue.

Best regards,
Marcin

-- 
-- 
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/window.c b/src/window.c
index 6ca288e..39b4777 100644
--- a/src/window.c
+++ b/src/window.c
@@ -632,7 +632,7 @@ get_wincmd_addr_type(arg, eap)
 char_u	*arg;
 exarg_T	*eap;
 {
-switch (*arg)
+switch (*skipwhite(arg))
 {
 case 'S':
 case Ctrl_S:


signature.asc
Description: Digital signature

Re: Vim 7.4.579: wincmd range problem with manpageview plugin

[Marcin Szamotulski]

On 13:06 Wed 14 Jan , Gary Johnson wrote:
 On 2015-01-14, Bram Moolenaar wrote:
  Gary Johnson wrote:
  
   I just updated to 7.4.579 on one of my Linux systems.  With the
   cursor over printf in a C file, typing K results in the following
   error message.
   
   Error detected while processing function 
   manpageview#KMap..manpageview#ManPageView:
 

   line  258:
   E16: Invalid range: 3wincmd -
   Press ENTER or type command to continue
   
   I'm using plugin/manpageviewPlugin.vim version 25b (Aug 06, 2012)
   and autoload/manpageview.vim version 25k ASTRO-ONLY (Apr 05, 2013).
  
  Should be fixed by patch 7.4.580.
 
 Fixed.  Thank you!
 
 Regards,
 Gary

Indeed,

Best regards,
Marcin

-- 
-- 
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: 0wincmd gives E16: Invalid range: 0wincmd w

[Marcin Szamotulski]

On 22:26 Mon 12 Jan , Bram Moolenaar wrote:
 
 Enno Nagel wrote:
 
  Le lundi 12 janvier 2015 14:41:00 UTC+1, Bram Moolenaar a écrit :
   Enno Nagel wrote:
   
The command

0wincmd w

throws an error in the latest Vim version:

E16: Invalid range: 0wincmd w

Before, it simply stayed in the same window. 
Is this a new feature or a bug?
   
   There is no window with the number zero, so the error is correct.
   
   Is this breaking some plugin?
   
   -- 
   hundred-and-one symptoms of being an internet addict:
   74. Your most erotic dreams are about cybersex
   
/// 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
   ///
  
  Well I have a plugin FastFold https://github.com/Konfekt/FastFold that
  uses a WinDo command that restores the current and alternate window by
  
  let curaltwin = winnr('#')
  let currwin=winnr()
  execute 'windo ' . a:command
  execute curaltwin . 'wincmd w'
  execute currwin . 'wincmd w'
  
  This used to work fine even if there was no alternate window before,
  but now there appear issue
  (https://github.com/Konfekt/FastFold/issues/11 and
  https://github.com/Konfekt/FastFold/issues/12) about 
  
  :0wincmd w
  
  throwing an error.
  
  Perhaps it used to be that
  
  winnr('#') 
  
  returned the current window number if there is no alternate window.
  
  It's easy to work around it though.
 
 Well, I don't think there is a problem with recognizing zero as the
 current window number.  It's not something that you accidentally type or
 would something bad that we need to prevent from happening.
 
 Marcin, can you make it work that way?

Sure that's quite simple.

Best regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 3276abf..c36f407 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -4686,8 +4686,7 @@ invalid_range(eap)
 		return (char_u *)_(e_invrange);
 		break;
 	case ADDR_WINDOWS:
-		if (eap-line1  1
-			|| eap-line2  LAST_WIN_NR)
+		if (eap-line2  LAST_WIN_NR)
 		return (char_u *)_(e_invrange);
 		break;
 	case ADDR_TABS:


signature.asc
Description: Digital signature

Re: :wincmd bug

[Marcin Szamotulski]

On 14:23 Fri 09 Jan , Charles Campbell wrote:
 Bram Moolenaar wrote:
  Sung Pae wrote:
 
  On Thu  8 Jan 2015 at 05:15:55PM -0600, guns wrote:
  On Thu  8 Jan 2015 at 03:06:45PM -0800, Amadeus Demarzi wrote:
  Using vim with patches 1-567 I get a range error when calling wincmd in 
  certain contexts:
 
  vim -u NONE
  :split
  :wincmd+ # works as expected
  :2wincmd+ # also works as expected
  :3wincmd+ # throws the error: Invalid Range
 
  In fact, any value above 2 seems to throw this error.
  Just a guess; I was planning on looking into it tonight.
  The problem is indeed introduced in 7.4.565. In particular:
 
  --- a/src/ex_cmds.h
  +++ b/src/ex_cmds.h
  @@ -1574,7 +1574,7 @@ EX(CMD_winsize,  winsize,  
  ex_winsize,
 ADDR_LINES),
   EX(CMD_wincmd,wincmd,   ex_wincmd,
 NEEDARG|WORD1|RANGE|NOTADR,
  -  ADDR_LINES),
  +  ADDR_WINDOWS),
   EX(CMD_windo, windo,ex_listdo,
 BANG|NEEDARG|EXTRA|NOTRLCOM,
 ADDR_LINES),
 
  I think the author of the patch forgot about:
 
  :wincmd +
  :wincmd -
  :wincmd 
  :wincmd 
  :wincmd n
  :wincmd s
  :wincmd v
  :wincmd |
 
  which all interpret the [count] as a number of lines, and not a number
  of windows.
 
  I suppose the preceding commands could be spared the bounds check, but
  as long as Ctrl-W commands are spared from the checks as well¹, I would
  advocate just reverting the hunk above.
 
  guns
 
  ¹ :execute normal! 100\C-w+
  Yeah, this is getting complicated.  :wincmd can have different types of
  ranges.  Using the line count is actually also wrong.
  There probably is no other solution than postponing the range check
  until the argument has been parsed.  That makes it difficult to give a
  meaning to :$wincmd.  Depending on the argument it can mean the last
  window or the maximum size.
 
 Actually :wincmd , , and | are column oriented, not line oriented. 
 So, sometimes its window oriented, line oriented, or column oriented.  I
 guess that means we need new window commands that are buffer oriented
 and tab oriented just to make things maximally difficult! :)
 
 Regards,
 Chip

Yes that's a problem.  Bram maybe we should:
- add a special range type `ADDR_POSTPONED`
- for commands which have it we could store the range on `exarg_T`
  struct
- parse it when we know how to do it, in this case inside the
  `do_window` function; for that we could factor out the range
  parsing code from `do_one_cmd` into a seprate function and use
  inside `do_window`.

Best regards,
Marcin

-- 
-- 
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: writeable # register

[Marcin Szamotulski]

On 18:38 Sun 28 Dec , Justin M. Keyes wrote:
On Dec 28, 2014 9:28 AM, Marcin Szamotulski [1]c...@riseup.net
wrote:

 Dear Bram,

 This patch makes # register writeable - which is present in the todo
 file.
 
It would also be very useful to be able to get the alternate buffer
number for a given buffer number without having to switch buffers (or
using :bufdo which has side effects).

For that we should rather have a function which would return it.  Note
that it is window related rather buffer dependent.

Cheers,
Marcin

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

writeable # register

[Marcin Szamotulski]

Dear Bram,

This patch makes # register writeable - which is present in the todo
file.

Best regards,
Marcin

-- 
-- 
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/change.txt b/runtime/doc/change.txt
index de340ec..0a45f22 100644
--- a/runtime/doc/change.txt
+++ b/runtime/doc/change.txt
@@ -1103,11 +1103,12 @@ There are nine types of registers:			*registers* *E354*
 2. 10 numbered registers 0 to 9
 3. The small delete register -
 4. 26 named registers a to z or A to Z
-5. four read-only registers :, ., % and #
-6. the expression register =
-7. The selection and drop registers *, + and ~ 
-8. The black hole register _
-9. Last search pattern register /
+5. three read-only registers :, ., %
+7. alternate buffer register #
+7. the expression register =
+8. The selection and drop registers *, + and ~ 
+9. The black hole register _
+10. Last search pattern register /
 
 1. Unnamed register *quote_quote* *quotequote*
 Vim fills this register with text deleted with the d, c, s, x commands
@@ -1164,8 +1165,6 @@ and :put commands and with CTRL-R.  {not in Vi}
 		('textwidth' and other options affect what is inserted).
 			*quote_%* *quote%*
 	%	Contains the name of the current file.
-			*quote_#* *quote#*
-	#	Contains the name of the alternate file.
 		*quote_:* *quote:* *E30*
 	:	Contains the most recent executed command-line.  Example: Use
 		@: to repeat the previous command-line command.
@@ -1174,8 +1173,18 @@ and :put commands and with CTRL-R.  {not in Vi}
 		the command was completely from a mapping.
 		{not available when compiled without the |+cmdline_hist|
 		feature}
-
-6. Expression register =			*quote_=* *quote=* *@=*
+			*quote_#* *quote#*
+6. Alternate file register #
+Contains the name of the alternate file for the current window. This register
+is writeble. It accepts buffer name or buffer number. 
+let @# = bufnr('buffer_name')
+let @# = 'buffer_name'
+It will change how the |CTRL-^| command works.  It will emit |E86| if you pass
+buffer number and such buffer does not exist or |E93| if there is more than
+one buffer matching the given name or |E94| if none of buffers matches the
+given name.
+
+7. Expression register =			*quote_=* *quote=* *@=*
 This is not really a register that stores text, but is a way to use an
 expression in commands which use a register.  The expression register is
 read-only; you cannot put text into it.  After the '=', the cursor moves to
@@ -1196,7 +1205,7 @@ If the = register is used for the p command, the String is split up at NL
 characters.  If the String ends in a NL, it is regarded as a linewise
 register.  {not in Vi}
 
-7. Selection and drop registers *, + and ~ 
+8. Selection and drop registers *, + and ~ 
 Use these registers for storing and retrieving the selected text for the GUI.
 See |quotestar| and |quoteplus|.  When the clipboard is not available or not
 working, the unnamed register is used instead.  For Unix systems the clipboard
@@ -1218,12 +1227,12 @@ GTK GUI}
 Note: The ~ register is only used when dropping plain text onto Vim.
 Drag'n'drop of URI lists is handled internally.
 
-8. Black hole register _*quote_*
+9. Black hole register _*quote_*
 When writing to this register, nothing happens.  This can be used to delete
 text without affecting the normal registers.  When reading from this register,
 nothing is returned.  {not in Vi}
 
-9. Last search pattern register	/			*quote_/* *quote/*
+10. Last search pattern register	/			*quote_/* *quote/*
 Contains the most recent search-pattern.  This is used for n and 'hlsearch'.
 It is writable with `:let`, you can change it to have 'hlsearch' highlight
 other matches without actually searching.  You can't yank or delete into this
diff --git a/src/ops.c b/src/ops.c
index 0c3d11b..d2c8b94 100644
--- a/src/ops.c
+++ b/src/ops.c
@@ -856,11 +856,12 @@ valid_yank_reg(regname, writing)
 if (   (regname  0  ASCII_ISALNUM(regname))
 	|| (!writing  vim_strchr((char_u *)
 #ifdef FEAT_EVAL
-/.%#:=
+/.%:=
 #else
-/.%#:
+/.%:
 #endif
 	, regname) != NULL)
+	|| regname == '#'
 	|| regname == ''
 	|| regname == '-'
 	|| regname == '_'
@@ -6516,6 +6517,31 @@ write_reg_contents_ex(name, str, maxlen, must_append, yank_type, block_len)
 	return;
 }
 
+if (name == '#')
+{
+	buf_T	*buf;
+	if ((VIM_ISDIGIT(*str)))
+	{
+	int	num = atoi(str);
+	buf = buflist_findnr(num);
+	if (buf == NULL)
+	{
+		EMSGN(_(E86: Buffer %ld does not exist), num);
+		return;
+	}
+	}
+	else
+	

Re: Patch 7.4.530

[Marcin Szamotulski]

On 14:07 Mon 22 Dec , Matteo Cavalleri wrote:
 looks like i'm no longer the only one experiencing problems with the new 
 range code :)
 
 https://github.com/kchmck/vim-coffee-script/issues/180

I think I found the problem.  Please try the attached patch.

Best regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 0c8123c..b37c6ed 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -2133,12 +2133,13 @@ do_one_cmd(cmdlinep, sourcing,
 if (ea.cmdidx != CMD_SIZE
 #ifdef FEAT_USR_CMDS
 	 ea.cmdidx != CMD_USER
+	 ea.cmdidx != CMD_USER_BUF
 #endif
)
 	ea.addr_type = cmdnames[(int)ea.cmdidx].cmd_addr_type;
 else
 #ifdef FEAT_USR_CMDS
-	if (ea.cmdidx != CMD_USER)
+	if (ea.cmdidx != CMD_USER  ea.cmdidx != CMD_USER_BUF)
 #endif
 	ea.addr_type = ADDR_LINES;
 /* ea.addr_type for user commands is set by find_ucmd */


signature.asc
Description: Digital signature

Re: Patch 7.4.530

[Marcin Szamotulski]

On 04:24 Tue 23 Dec , Matteo Cavalleri wrote:
 hi!
 
 thanks Marcin, it now works perfectly :)
 

Interestingly when I was compiling vim with `-ggdb -g3` flags I couldn't
reproduce it.  Only when I compiled with the default cglags.

Best regards,
Marcin

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

[Marcin Szamotulski]

On 22:24 Sun 14 Dec , Marcin Szamotulski wrote:
 On 03:19 Sun 14 Dec , Bram Moolenaar wrote:
  
  Marcin Szamotulski wrote:
  
   I also include another patch (on top of that) which adds support for
   counts in :argdo, :bufdo, :tabdo and :windo commands.
  
  I haven't included this part yet.  Can you please add some tests for
  using a range (and for no range, if that doesn't exist yet) for these
  four commands?
 
 Sure I will add some tests soon.
 
 Regards,
 Marcin

Here is an updated patch which includes tests.

Best regards,
Marcin

-- 
-- 
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/editing.txt b/runtime/doc/editing.txt
index 71f2f8c..82a7d02 100644
--- a/runtime/doc/editing.txt
+++ b/runtime/doc/editing.txt
@@ -832,8 +832,9 @@ current window.  The two windows then share this list, until one of them uses
 USING THE ARGUMENT LIST
 
 		*:argdo*
-:argdo[!] {cmd}		Execute {cmd} for each file in the argument list.
-			It works like doing this: 
+:[range]argdo[!] {cmd}	Execute {cmd} for each file in the argument list or
+			if [range] is specified only for arguments in that
+			range.  It works like doing this: 
 :rewind
 :{cmd}
 :next
diff --git a/runtime/doc/tabpage.txt b/runtime/doc/tabpage.txt
index 47e1a4b..aded300 100644
--- a/runtime/doc/tabpage.txt
+++ b/runtime/doc/tabpage.txt
@@ -224,8 +224,10 @@ clarification what +N means in this context see |[range]|.
 LOOPING OVER TAB PAGES:
 
 			*:tabd* *:tabdo*
-:tabd[o] {cmd}	Execute {cmd} in each tab page.
-		It works like doing this: 
+:[range]tabd[o] {cmd}
+		Execute {cmd} in each tab page or if [range] is given only in
+		tab pages which tab page number is in the [range].  It works
+		like doing this: 
 			:tabfirst
 			:{cmd}
 			:tabnext
diff --git a/runtime/doc/windows.txt b/runtime/doc/windows.txt
index 67925b8..532cca3 100644
--- a/runtime/doc/windows.txt
+++ b/runtime/doc/windows.txt
@@ -698,8 +698,9 @@ can also get to them with the buffer list commands, like :bnext.
 8. Do a command in all buffers or windows			*list-repeat*
 
 			*:windo*
-:windo {cmd}		Execute {cmd} in each window.
-			It works like doing this: 
+:[range]windo {cmd}	Execute {cmd} in each window or if [range] is given
+			only in windows for which the window number lies in
+			the [range].  It works like doing this: 
 CTRL-W t
 :{cmd}
 CTRL-W w
@@ -717,8 +718,10 @@ can also get to them with the buffer list commands, like :bnext.
 			Also see |:tabdo|, |:argdo| and |:bufdo|.
 
 			*:bufdo*
-:bufdo[!] {cmd}		Execute {cmd} in each buffer in the buffer list.
-			It works like doing this: 
+:[range]bufdo[!] {cmd}	Execute {cmd} in each buffer in the buffer list or if
+			[range] is given only for buffers for which their
+			buffer numer is in the [range].  It works like doing
+			this: 
 :bfirst
 :{cmd}
 :bnext
diff --git a/src/ex_cmds.h b/src/ex_cmds.h
index 95a2289..31b0da9 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -133,8 +133,8 @@ EX(CMD_argdelete,	argdelete,	ex_argdelete,
 			BANG|RANGE|NOTADR|FILES|TRLBAR,
 			ADDR_ARGUMENTS),
 EX(CMD_argdo,		argdo,	ex_listdo,
-			BANG|NEEDARG|EXTRA|NOTRLCOM,
-			ADDR_LINES),
+			BANG|NEEDARG|EXTRA|NOTRLCOM|RANGE|NOTADR|DFLALL,
+			ADDR_ARGUMENTS),
 EX(CMD_argedit,		argedit,	ex_argedit,
 			BANG|NEEDARG|RANGE|NOTADR|FILE1|EDITCMD|ARGOPT|TRLBAR,
 			ADDR_ARGUMENTS),
@@ -220,8 +220,8 @@ EX(CMD_buffers,		buffers,	buflist_list,
 			BANG|TRLBAR|CMDWIN,
 			ADDR_LINES),
 EX(CMD_bufdo,		bufdo,	ex_listdo,
-			BANG|NEEDARG|EXTRA|NOTRLCOM,
-			ADDR_LINES),
+			BANG|NEEDARG|EXTRA|NOTRLCOM|RANGE|NOTADR|DFLALL,
+			ADDR_UNLOADED_BUFFERS),
 EX(CMD_bunload,		bunload,	ex_bunload,
 			BANG|RANGE|NOTADR|BUFNAME|COUNT|EXTRA|TRLBAR,
 			ADDR_LOADED_BUFFERS),
@@ -1384,8 +1384,8 @@ EX(CMD_tabclose,	tabclose,	ex_tabclose,
 			RANGE|NOTADR|COUNT|BANG|TRLBAR|CMDWIN,
 			ADDR_TABS),
 EX(CMD_tabdo,		tabdo,	ex_listdo,
-			NEEDARG|EXTRA|NOTRLCOM,
-			ADDR_LINES),
+			NEEDARG|EXTRA|NOTRLCOM|RANGE|NOTADR|DFLALL,
+			ADDR_TABS),
 EX(CMD_tabedit,		tabedit,	ex_splitview,
 			BANG|FILE1|RANGE|NOTADR|ZEROR|EDITCMD|ARGOPT|TRLBAR,
 			ADDR_TABS),
@@ -1576,8 +1576,8 @@ EX(CMD_wincmd,		wincmd,	ex_wincmd,
 			NEEDARG|WORD1|RANGE|NOTADR,
 			ADDR_LINES),
 EX(CMD_windo,		windo,	ex_listdo,
-			BANG|NEEDARG|EXTRA|NOTRLCOM,
-			ADDR_LINES),
+			BANG|NEEDARG|EXTRA|NOTRLCOM|RANGE|NOTADR|DFLALL,
+			ADDR_WINDOWS),
 EX(CMD_winpos,		winpos,	ex_winpos,
 			EXTRA|TRLBAR|CMDWIN,
 			ADDR_LINES),
diff --git a/src/ex_cmds2.c b/src/ex_cmds2.c
index 4614dea..3fac506 100644
--- a/src/ex_cmds2.c
+++ b

Re: check if range is invalid

[Marcin Szamotulski]

On 22:32 Wed 17 Dec , Marcin Szamotulski wrote:
 On 13:07 Wed 17 Dec , Bram Moolenaar wrote:
  
  Marcin Szamotulski wrote:
  
   On 20:11 Sat 13 Dec , Bram Moolenaar wrote:

Marcin Szamotulski wrote:

 I attach the promised patch for checking if the range is invalid.

Thanks!
   
   Updated version,  I figured out that 0 range is needed for :tabe.
  
  Thanks.  I tried including it, but it breaks tests.
  Also, it would be useful if you can write tests for the boundary checks.
 
 I see, actually tests fail because one cannot do :888tabnew, which
 test62 used, and the tests I wrote were testing that going over the
 range will still work for various other commands.  I will update the
 tests.
 
 One more question: there is ZEROR flag for the range which some commands
 are using.  Do you want that the `invalid_range` function tests if the
 range is = 0 or = 1 depending on the ZEROR flag?
 
 For example, that would make a difference for the range of :argadd (which can 
 be 0)
 and :argu which does not accept 0.
 
 Best regards,
 Marcin

Here is a patch.  I did checked for ZEROR, as this wasn't done before
probably by a reason.

Best regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 0c8123c..16e62d0 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -2160,6 +2160,8 @@ do_one_cmd(cmdlinep, sourcing,
 		break;
 	case ADDR_ARGUMENTS:
 		ea.line2 = curwin-w_arg_idx + 1;
+		if (ea.line2  ARGCOUNT)
+		ea.line2 = ARGCOUNT;
 		break;
 	case ADDR_LOADED_BUFFERS:
 	case ADDR_BUFFERS:
@@ -4572,46 +4574,6 @@ get_address(ptr, addr_type, skip, to_other_file)
 		lnum -= n;
 	else
 		lnum += n;
-
-	switch (addr_type)
-	{
-		case ADDR_LINES:
-		break;
-		case ADDR_ARGUMENTS:
-		if (lnum  0)
-			lnum = 0;
-		else if (lnum = ARGCOUNT)
-			lnum = ARGCOUNT;
-		break;
-		case ADDR_TABS:
-		if (lnum  0)
-		{
-			lnum = 0;
-			break;
-		}
-		if (lnum = LAST_TAB_NR)
-			lnum = LAST_TAB_NR;
-		break;
-		case ADDR_WINDOWS:
-		if (lnum  0)
-		{
-			lnum = 0;
-			break;
-		}
-		if (lnum = LAST_WIN_NR)
-			lnum = LAST_WIN_NR;
-		break;
-		case ADDR_LOADED_BUFFERS:
-		case ADDR_BUFFERS:
-		if (lnum  firstbuf-b_fnum)
-		{
-			lnum = firstbuf-b_fnum;
-			break;
-		}
-		if (lnum  lastbuf-b_fnum)
-			lnum = lastbuf-b_fnum;
-		break;
-	}
 	}
 } while (*cmd == '/' || *cmd == '?');
 
@@ -4674,17 +4636,65 @@ ex_script_ni(eap)
 invalid_range(eap)
 exarg_T	*eap;
 {
+buf_T	*buf;
 if (   eap-line1  0
 	|| eap-line2  0
-	|| eap-line1  eap-line2
-	|| ((eap-argt  RANGE)
-		 !(eap-argt  NOTADR)
-		 eap-line2  curbuf-b_ml.ml_line_count
+	|| eap-line1  eap-line2)
+	return (char_u *)_(e_invrange);
+
+if (eap-argt  RANGE)
+{
+	switch(eap-addr_type)
+	{
+	case ADDR_LINES:
+		if (!(eap-argt  NOTADR)
+			 eap-line2  curbuf-b_ml.ml_line_count
 #ifdef FEAT_DIFF
-			+ (eap-cmdidx == CMD_diffget)
+			+ (eap-cmdidx == CMD_diffget)
 #endif
-		))
-	return (char_u *)_(e_invrange);
+		   )
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_ARGUMENTS:
+		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARCOUNT is 0
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_BUFFERS:
+		if (eap-line1  firstbuf-b_fnum
+			|| eap-line2  lastbuf-b_fnum)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_LOADED_BUFFERS:
+		buf = firstbuf;
+		while (buf-b_ml.ml_mfp == NULL)
+		{
+		if (buf-b_next == NULL)
+			return (char_u *)_(e_invrange);
+		buf = buf-b_next;
+		}
+		if (eap-line1  buf-b_fnum)
+		return (char_u *)_(e_invrange);
+		buf = lastbuf;
+		while (buf-b_ml.ml_mfp == NULL)
+		{
+		if (buf-b_prev == NULL)
+			return (char_u *)_(e_invrange);
+		buf = buf-b_prev;
+		}
+		if (eap-line2  buf-b_fnum)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_WINDOWS:
+		if (eap-line1  1
+			|| eap-line2  LAST_WIN_NR)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_TABS:
+		if (eap-line2  LAST_TAB_NR)
+		return (char_u *)_(e_invrange);
+		break;
+	}
+}
 return NULL;
 }
 
diff --git a/src/testdir/test62.in b/src/testdir/test62.in
index 93d968b..c201fe7 100644
--- a/src/testdir/test62.in
+++ b/src/testdir/test62.in
@@ -13,7 +13,7 @@ STARTTEST
 : Open three tab pages and use :tabdo
 :0tabnew
 :1tabnew
-:888tabnew
+:$tabnew
 :tabdo call append(line('$'), 'this is tab page ' . tabpagenr())
 :tabclose! 2
 :tabrewind
diff

Re: check if range is invalid

[Marcin Szamotulski]

On 13:07 Wed 17 Dec , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  On 20:11 Sat 13 Dec , Bram Moolenaar wrote:
   
   Marcin Szamotulski wrote:
   
I attach the promised patch for checking if the range is invalid.
   
   Thanks!
  
  Updated version,  I figured out that 0 range is needed for :tabe.
 
 Thanks.  I tried including it, but it breaks tests.
 Also, it would be useful if you can write tests for the boundary checks.

I see, actually tests fail because one cannot do :888tabnew, which
test62 used, and the tests I wrote were testing that going over the
range will still work for various other commands.  I will update the
tests.

One more question: there is ZEROR flag for the range which some commands
are using.  Do you want that the `invalid_range` function tests if the
range is = 0 or = 1 depending on the ZEROR flag?

For example, that would make a difference for the range of :argadd (which can 
be 0)
and :argu which does not accept 0.

Best regards,
Marcin

-- 
-- 
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: check if range is invalid

[Marcin Szamotulski]

On 20:11 Sat 13 Dec , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  I attach the promised patch for checking if the range is invalid.
 
 Thanks!

Updated version,  I figured out that 0 range is needed for :tabe.

Best regards,
Marcin

-- 
-- 
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/ex_cmds.h b/src/ex_cmds.h
index fc6a8ac..95a2289 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -63,7 +63,7 @@
 #define ADDR_WINDOWS		1
 #define ADDR_ARGUMENTS		2
 #define ADDR_LOADED_BUFFERS	3
-#define ADDR_BUFFERS	4
+#define ADDR_BUFFERS		4
 #define ADDR_TABS		5
 
 #ifndef DO_DECLARE_EXCMD
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 0c8123c..16e62d0 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -2160,6 +2160,8 @@ do_one_cmd(cmdlinep, sourcing,
 		break;
 	case ADDR_ARGUMENTS:
 		ea.line2 = curwin-w_arg_idx + 1;
+		if (ea.line2  ARGCOUNT)
+		ea.line2 = ARGCOUNT;
 		break;
 	case ADDR_LOADED_BUFFERS:
 	case ADDR_BUFFERS:
@@ -4572,46 +4574,6 @@ get_address(ptr, addr_type, skip, to_other_file)
 		lnum -= n;
 	else
 		lnum += n;
-
-	switch (addr_type)
-	{
-		case ADDR_LINES:
-		break;
-		case ADDR_ARGUMENTS:
-		if (lnum  0)
-			lnum = 0;
-		else if (lnum = ARGCOUNT)
-			lnum = ARGCOUNT;
-		break;
-		case ADDR_TABS:
-		if (lnum  0)
-		{
-			lnum = 0;
-			break;
-		}
-		if (lnum = LAST_TAB_NR)
-			lnum = LAST_TAB_NR;
-		break;
-		case ADDR_WINDOWS:
-		if (lnum  0)
-		{
-			lnum = 0;
-			break;
-		}
-		if (lnum = LAST_WIN_NR)
-			lnum = LAST_WIN_NR;
-		break;
-		case ADDR_LOADED_BUFFERS:
-		case ADDR_BUFFERS:
-		if (lnum  firstbuf-b_fnum)
-		{
-			lnum = firstbuf-b_fnum;
-			break;
-		}
-		if (lnum  lastbuf-b_fnum)
-			lnum = lastbuf-b_fnum;
-		break;
-	}
 	}
 } while (*cmd == '/' || *cmd == '?');
 
@@ -4674,17 +4636,65 @@ ex_script_ni(eap)
 invalid_range(eap)
 exarg_T	*eap;
 {
+buf_T	*buf;
 if (   eap-line1  0
 	|| eap-line2  0
-	|| eap-line1  eap-line2
-	|| ((eap-argt  RANGE)
-		 !(eap-argt  NOTADR)
-		 eap-line2  curbuf-b_ml.ml_line_count
+	|| eap-line1  eap-line2)
+	return (char_u *)_(e_invrange);
+
+if (eap-argt  RANGE)
+{
+	switch(eap-addr_type)
+	{
+	case ADDR_LINES:
+		if (!(eap-argt  NOTADR)
+			 eap-line2  curbuf-b_ml.ml_line_count
 #ifdef FEAT_DIFF
-			+ (eap-cmdidx == CMD_diffget)
+			+ (eap-cmdidx == CMD_diffget)
 #endif
-		))
-	return (char_u *)_(e_invrange);
+		   )
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_ARGUMENTS:
+		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARCOUNT is 0
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_BUFFERS:
+		if (eap-line1  firstbuf-b_fnum
+			|| eap-line2  lastbuf-b_fnum)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_LOADED_BUFFERS:
+		buf = firstbuf;
+		while (buf-b_ml.ml_mfp == NULL)
+		{
+		if (buf-b_next == NULL)
+			return (char_u *)_(e_invrange);
+		buf = buf-b_next;
+		}
+		if (eap-line1  buf-b_fnum)
+		return (char_u *)_(e_invrange);
+		buf = lastbuf;
+		while (buf-b_ml.ml_mfp == NULL)
+		{
+		if (buf-b_prev == NULL)
+			return (char_u *)_(e_invrange);
+		buf = buf-b_prev;
+		}
+		if (eap-line2  buf-b_fnum)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_WINDOWS:
+		if (eap-line1  1
+			|| eap-line2  LAST_WIN_NR)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_TABS:
+		if (eap-line2  LAST_TAB_NR)
+		return (char_u *)_(e_invrange);
+		break;
+	}
+}
 return NULL;
 }
 


signature.asc
Description: Digital signature

Re: Patch 7.4.530

[Marcin Szamotulski]

On 03:19 Sun 14 Dec , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  I also include another patch (on top of that) which adds support for
  counts in :argdo, :bufdo, :tabdo and :windo commands.
 
 I haven't included this part yet.  Can you please add some tests for
 using a range (and for no range, if that doesn't exist yet) for these
 four commands?

Sure I will add some tests soon.

Regards,
Marcin

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

check if range is invalid

[Marcin Szamotulski]

Dear Bram,

I attach the promised patch for checking if the range is invalid.

Best regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 0c8123c..7894ae2 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -2160,6 +2160,8 @@ do_one_cmd(cmdlinep, sourcing,
 		break;
 	case ADDR_ARGUMENTS:
 		ea.line2 = curwin-w_arg_idx + 1;
+		if (ea.line2  ARGCOUNT)
+		ea.line2 = ARGCOUNT;
 		break;
 	case ADDR_LOADED_BUFFERS:
 	case ADDR_BUFFERS:
@@ -4572,46 +4574,6 @@ get_address(ptr, addr_type, skip, to_other_file)
 		lnum -= n;
 	else
 		lnum += n;
-
-	switch (addr_type)
-	{
-		case ADDR_LINES:
-		break;
-		case ADDR_ARGUMENTS:
-		if (lnum  0)
-			lnum = 0;
-		else if (lnum = ARGCOUNT)
-			lnum = ARGCOUNT;
-		break;
-		case ADDR_TABS:
-		if (lnum  0)
-		{
-			lnum = 0;
-			break;
-		}
-		if (lnum = LAST_TAB_NR)
-			lnum = LAST_TAB_NR;
-		break;
-		case ADDR_WINDOWS:
-		if (lnum  0)
-		{
-			lnum = 0;
-			break;
-		}
-		if (lnum = LAST_WIN_NR)
-			lnum = LAST_WIN_NR;
-		break;
-		case ADDR_LOADED_BUFFERS:
-		case ADDR_BUFFERS:
-		if (lnum  firstbuf-b_fnum)
-		{
-			lnum = firstbuf-b_fnum;
-			break;
-		}
-		if (lnum  lastbuf-b_fnum)
-			lnum = lastbuf-b_fnum;
-		break;
-	}
 	}
 } while (*cmd == '/' || *cmd == '?');
 
@@ -4674,17 +4636,66 @@ ex_script_ni(eap)
 invalid_range(eap)
 exarg_T	*eap;
 {
+buf_T	*buf;
 if (   eap-line1  0
 	|| eap-line2  0
-	|| eap-line1  eap-line2
-	|| ((eap-argt  RANGE)
-		 !(eap-argt  NOTADR)
-		 eap-line2  curbuf-b_ml.ml_line_count
+	|| eap-line1  eap-line2)
+	return (char_u *)_(e_invrange);
+
+if (eap-argt  RANGE)
+{
+	switch(eap-addr_type)
+	{
+	case ADDR_LINES:
+		if (!(eap-argt  NOTADR)
+			 eap-line2  curbuf-b_ml.ml_line_count
 #ifdef FEAT_DIFF
-			+ (eap-cmdidx == CMD_diffget)
+			+ (eap-cmdidx == CMD_diffget)
 #endif
-		))
-	return (char_u *)_(e_invrange);
+		   )
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_ARGUMENTS:
+		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARCOUNT is 0
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_BUFFERS:
+		if (eap-line1  firstbuf-b_fnum
+			|| eap-line2  lastbuf-b_fnum)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_LOADED_BUFFERS:
+		buf = firstbuf;
+		while (buf-b_ml.ml_mfp == NULL)
+		{
+		if (buf-b_next == NULL)
+			return (char_u *)_(e_invrange);
+		buf = buf-b_next;
+		}
+		if (eap-line1  buf-b_fnum)
+		return (char_u *)_(e_invrange);
+		buf = lastbuf;
+		while (buf-b_ml.ml_mfp == NULL)
+		{
+		if (buf-b_prev == NULL)
+			return (char_u *)_(e_invrange);
+		buf = buf-b_prev;
+		}
+		if (eap-line2  buf-b_fnum)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_WINDOWS:
+		if (eap-line1  1
+			|| eap-line2  LAST_WIN_NR)
+		return (char_u *)_(e_invrange);
+		break;
+	case ADDR_TABS:
+		if (eap-line1  1
+			|| eap-line2  LAST_TAB_NR)
+		return (char_u *)_(e_invrange);
+		break;
+	}
+}
 return NULL;
 }
 


signature.asc
Description: Digital signature

Re: Patch 7.4.530

[Marcin Szamotulski]

On 00:13 Wed 10 Dec , Matteo Cavalleri wrote:
 Hi, i know my problem is not reproducible, but now that I've upgraded to vim 
 7.4.542 it seems it's gotten a little bit worse. now whenever I try to 
 :CoffeeCompile the whole buffer or just the selection, the range is always 
 from line 1 to line 1.
 
 This still happens when running vim with --noplugin -u NONE -N and doing my 
 usual tests with my code snippet
 
 Marcin can you please paste your --version? I want to check your compiled in 
 features and see if something differs with mines. as I see patches frequently 
 break tiny builds, maybe this one has some similar problem with some ifdef... 
 (otherwise I have no other ideas :p )
 

Hi,

I use the `huge` set of features plus a few interpreters:
--with-features=huge --enable-pythoninterp --enable-perlinterp 
--with-local-dir=/usr/share --with-global-runtime=/etc/vim
I attachment you will find the output of my `vim --version`.

The tiny build does not have user commands, so you would not have problems with 
it ;).

Can you post your --version.

Best regards,
Marcin

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

[Marcin Szamotulski]

On 03:14 Wed 10 Dec , Matteo Cavalleri wrote:
 
  The tiny build does not have user commands, so you would not have problems 
  with it ;).
 
 
 Sorry, I probably didn't explain myself clearly. I meant to say that maybe my 
 problems were due to some piece of code inside some wrong or missing #ifdef 
 due to a particular set of features compiled in. the tiny build is just an 
 example as I see it breaks quite often for this reason ;)
 
 I think you forgot your attachment :p however here's mine. It should have 
 been compiled with these flags:
 
 --enable-multibyte
 --with-tlib=ncurses
 --enable-cscope
 --with-features=huge
 --enable-gui=no
 --without-x
 --enable-pythoninterp
 --enable-rubyinterp
 --enable-perlinterp
 
 
 
 VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 10 2014 09:04:43)
 MacOS X (unix) version
 Included patches: 1-542
 Compiled by Homebrew
 Huge version without GUI.  Features included (+) or not (-):
 +acl +farsi   +mouse_netterm   +syntax
 +arabic  +file_in_path+mouse_sgr   +tag_binary
 +autocmd +find_in_path-mouse_sysmouse  +tag_old_static
 -balloon_eval+float   +mouse_urxvt -tag_any_white
 -browse  +folding +mouse_xterm -tcl
 ++builtin_terms  -footer  +multi_byte  +terminfo
 +byte_offset +fork()  +multi_lang  +termresponse
 +cindent -gettext -mzscheme+textobjects
 -clientserver-hangul_input+netbeans_intg   +title
 +clipboard   +iconv   +path_extra  -toolbar
 +cmdline_compl   +insert_expand   +perl+user_commands
 +cmdline_hist+jumplist+persistent_undo +vertsplit
 +cmdline_info+keymap  +postscript  +virtualedit
 +comments+langmap +printer +visual
 +conceal +libcall +profile +visualextra
 +cryptv  +linebreak   +python  +viminfo
 +cscope  +lispindent  -python3 +vreplace
 +cursorbind  +listcmds+quickfix+wildignore
 +cursorshape +localmap+reltime +wildmenu
 +dialog_con  -lua +rightleft   +windows
 +diff+menu+ruby+writebackup
 +digraphs+mksession   +scrollbind  -X11
 -dnd +modify_fname+signs   -xfontset
 -ebcdic  +mouse   +smartindent -xim
 +emacs_tags  -mouseshape  -sniff   -xsmp
 +eval+mouse_dec   +startuptime -xterm_clipboard
 +ex_extra-mouse_gpm   +statusline  -xterm_save
 +extra_search-mouse_jsbterm   -sun_workshop-xpm
system vimrc file: $VIM/vimrc
  user vimrc file: $HOME/.vimrc
  2nd user vimrc file: ~/.vim/vimrc
   user exrc file: $HOME/.exrc
   fall-back for $VIM: /usr/local/share/vim
 Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  
 -Os -w -pipe -march=native -mmacosx-version-min=10.10 -U_FORTIFY_SOURCE 
 -D_FORTIFY_SOURCE=1
 Linking: /usr/bin/clang   -L. -L/Users/matteo/.rbenv/versions/2.1.5/lib  
 -fstack-protector -L/usr/local/lib -Wl,-headerpad_max_install_names -o vim
 -lm  -lncurses -liconv -framework Cocoa   -fstack-protector  
 -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -framework 
 Python   -lruby-static -framework CoreFoundation -lobjc 
 -L/Users/matteo/.rbenv/versions/2.1.5/lib

Thanks I will check this soon. Now with the attachment.

Best regards,
Marcin

-- 
-- 
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.
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec  8 2014 22:13:51)
Included patches: 1-540
Compiled by coot@flying-circus
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl +farsi   +mouse_netterm   +syntax
+arabic  +file_in_path+mouse_sgr   +tag_binary
+autocmd +find_in_path-mouse_sysmouse  +tag_old_static
+balloon_eval+float   +mouse_urxvt -tag_any_white
+browse  +folding +mouse_xterm -tcl
++builtin_terms  -footer  +multi_byte  +terminfo
+byte_offset +fork()  +multi_lang  +termresponse
+cindent +gettext -mzscheme+textobjects
+clientserver-hangul_input+netbeans_intg   +title
+clipboard   +iconv   +path_extra  +toolbar
+cmdline_compl   +insert_expand   +perl+user_commands
+cmdline_hist+jumplist+persistent_undo +vertsplit
+cmdline_info+keymap  +postscript  +virtualedit

Re: Patch 7.4.530

[Marcin Szamotulski]

On 13:15 Wed 10 Dec , Marcin Szamotulski wrote:
 On 03:14 Wed 10 Dec , Matteo Cavalleri wrote:
  
   The tiny build does not have user commands, so you would not have 
   problems with it ;).
  
  
  Sorry, I probably didn't explain myself clearly. I meant to say that maybe 
  my problems were due to some piece of code inside some wrong or missing 
  #ifdef due to a particular set of features compiled in. the tiny build is 
  just an example as I see it breaks quite often for this reason ;)
  
  I think you forgot your attachment :p however here's mine. It should have 
  been compiled with these flags:
  
  --enable-multibyte
  --with-tlib=ncurses
  --enable-cscope
  --with-features=huge
  --enable-gui=no
  --without-x
  --enable-pythoninterp
  --enable-rubyinterp
  --enable-perlinterp
  
  
  
  VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 10 2014 09:04:43)
  MacOS X (unix) version
  Included patches: 1-542
  Compiled by Homebrew
  Huge version without GUI.  Features included (+) or not (-):
  +acl +farsi   +mouse_netterm   +syntax
  +arabic  +file_in_path+mouse_sgr   +tag_binary
  +autocmd +find_in_path-mouse_sysmouse  +tag_old_static
  -balloon_eval+float   +mouse_urxvt -tag_any_white
  -browse  +folding +mouse_xterm -tcl
  ++builtin_terms  -footer  +multi_byte  +terminfo
  +byte_offset +fork()  +multi_lang  +termresponse
  +cindent -gettext -mzscheme+textobjects
  -clientserver-hangul_input+netbeans_intg   +title
  +clipboard   +iconv   +path_extra  -toolbar
  +cmdline_compl   +insert_expand   +perl+user_commands
  +cmdline_hist+jumplist+persistent_undo +vertsplit
  +cmdline_info+keymap  +postscript  +virtualedit
  +comments+langmap +printer +visual
  +conceal +libcall +profile +visualextra
  +cryptv  +linebreak   +python  +viminfo
  +cscope  +lispindent  -python3 +vreplace
  +cursorbind  +listcmds+quickfix+wildignore
  +cursorshape +localmap+reltime +wildmenu
  +dialog_con  -lua +rightleft   +windows
  +diff+menu+ruby+writebackup
  +digraphs+mksession   +scrollbind  -X11
  -dnd +modify_fname+signs   -xfontset
  -ebcdic  +mouse   +smartindent -xim
  +emacs_tags  -mouseshape  -sniff   -xsmp
  +eval+mouse_dec   +startuptime -xterm_clipboard
  +ex_extra-mouse_gpm   +statusline  -xterm_save
  +extra_search-mouse_jsbterm   -sun_workshop-xpm
 system vimrc file: $VIM/vimrc
   user vimrc file: $HOME/.vimrc
   2nd user vimrc file: ~/.vim/vimrc
user exrc file: $HOME/.exrc
fall-back for $VIM: /usr/local/share/vim
  Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX 
   -Os -w -pipe -march=native -mmacosx-version-min=10.10 -U_FORTIFY_SOURCE 
  -D_FORTIFY_SOURCE=1
  Linking: /usr/bin/clang   -L. -L/Users/matteo/.rbenv/versions/2.1.5/lib  
  -fstack-protector -L/usr/local/lib -Wl,-headerpad_max_install_names -o vim  
-lm  -lncurses -liconv -framework Cocoa   -fstack-protector  
  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl 
  -framework Python   -lruby-static -framework CoreFoundation -lobjc 
  -L/Users/matteo/.rbenv/versions/2.1.5/lib

I compiled with the same flags as you and everything works fine.  The
difference is that I am on gnu/linux and you on macos.

Regards,
Marcin

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

[Marcin Szamotulski]

On 07:02 Tue 09 Dec , Holger Trapp wrote:
 Hi Bram,
 
  This patch is not available through ftp:
  ftp://ftp.vim.org/pub/vim/patches/7.4/
 
  Should be there now.
 
 yes, it is.
 
  And thanks for confirming that some people still use ftp :-).
 
 I can confirm this as well ;-) Normally I mirror the patches via ftp.
 
 Cheers,
 Holger

No no, I don't use ftp ;) - I was just writing a twit and I thought
I'll add a link, and I found out that twitter does not understands ftp
urls.  I actually use a git clone of the hg repo.

Best regards,
Marcin

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

[Marcin Szamotulski]

On 04:17 Mon 08 Dec , Bram Moolenaar wrote:
 
 Marcin -
 
 I think that we need to be more strict about window numbers. E.g., when
 using 3close while there are only two windows, should not close the
 second window.  This avoids mistakenly closing the wrong window.
 
 If someone wanted to close the last window he should have used
 :$close.
 
 The same for buffer numbers: Using a non-existing buffer number should
 fail, not use one close by or the last one.
 
 - Bram

I agree, I will make a patch for that soon.

- Marcin

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

[Marcin Szamotulski]

On 04:17 Mon 08 Dec , Bram Moolenaar wrote:
 
 Patch 7.4.542
 Problem:Using a range for window and buffer commands has a few problems.
   Cannot specify the type of range for a user command.
 Solution:   Add the -addr argument for user commands.  Fix problems. (Marcin
   Szamotulski)
 Files:src/testdir/test_command_count.in,
   src/testdir/test_command_count.ok src/testdir/Make_amiga.mak
   src/testdir/Make_dos.mak, src/testdir/Make_ming.mak,
   src/testdir/Make_os2.mak, src/testdir/Make_vms.mms,
   src/testdir/Makefile, runtime/doc/map.txt, src/Makefile,
   src/ex_cmds.h, src/ex_docmd.c, src/ex_getln.c,
   src/proto/ex_docmd.pro, src/vim.h,

This patch is not available through ftp:
ftp://ftp.vim.org/pub/vim/patches/7.4/

Best regards,
Marcin

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

[Marcin Szamotulski]

On 22:41 Sat 06 Dec , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  On 09:32 Thu 04 Dec , Marcin Szamotulski wrote:
   On 14:31 Wed 03 Dec , Matteo Cavalleri wrote:
I'm using the code I posted a while ago in this thread, I'm copying it 
here again :) (it was without the -buffer option, I'm adding it now)

create and source this file 

 
function! Test(f,l) 
echom a:f. - .a:l 
endfunction 
command! -buffer -range=% RangeTest call Test(line1, line2) 
 

then select a couple of lines and do: 

:','RangeTest 
   
   I cannot reproduce it with the patch I sent.
   
   Best regards,
   Marcin
  
  Dear Bram,
  
  The attached patch adds support for user commands.  For example this
  patch makes it possible to define the following commands:
  com RangeLines :echo line1.' '.line2
  which is the same as:
  com -addr=lines RangeLines :echo line1.' '.line2
  com -addr=arguments RangeArguments :echo line1.' '.line2
  com -addr=loaded_buffers RangeLoadedBuffers :echo line1.' '.line2
  com -addr=buffers RangeBuffers :echo line1.' '.line2
  com -addr=windows RangeWindows :echo line1.' '.line2
  com -addr=tabs RangeTabs :echo line1.' '.line2
  
  The patch also includes a test, and it includes all the fixes
  I published before in one place.
 
 Thanks, I'll look into it soon.

Once again, now it does not break the tiny build.

I also include another patch (on top of that) which adds support for
counts in :argdo, :bufdo, :tabdo and :windo commands.

Best regards,
Marcin

-- 
-- 
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/map.txt b/runtime/doc/map.txt
index 1be2827..ad21d64 100644
--- a/runtime/doc/map.txt
+++ b/runtime/doc/map.txt
@@ -1358,6 +1358,19 @@ Possible attributes are:
 Note that -range=N and -count=N are mutually exclusive - only one should be
 specified.
 
+	*E889* *:command-addr*
+It is possible that the special characters in the range like ., $ or % which
+by default correspond to the current line, last line and the whole buffer,
+relate to arguments, (loaded) buffers, windows or tab pages.
+
+Possible values are:
+	-addr=lines		Range of lines (this is the default)
+	-addr=arguments		Range for arguments
+	-addr=buffers		Range for (all) buffers
+	-addr=loaded_buffers	Range for only loaded buffers
+	-addr=windows		Range for windows
+	-addr=tabs		Range for tab pages
+
 Special cases*:command-bang* *:command-bar*
 	*:command-register* *:command-buffer*
 There are some special cases as well:
diff --git a/src/Makefile b/src/Makefile
index 13fe70b..5a5518d 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -1896,6 +1896,7 @@ test1 \
 	test_breakindent \
 	test_changelist \
 	test_close_count \
+	test_command_count \
 	test_eval \
 	test_insertcount \
 	test_listlbr \
diff --git a/src/ex_cmds.h b/src/ex_cmds.h
index 5574ea7..fc6a8ac 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -63,7 +63,7 @@
 #define ADDR_WINDOWS		1
 #define ADDR_ARGUMENTS		2
 #define ADDR_LOADED_BUFFERS	3
-#define ADDR_UNLOADED_BUFFERS	4
+#define ADDR_BUFFERS	4
 #define ADDR_TABS		5
 
 #ifndef DO_DECLARE_EXCMD
@@ -161,7 +161,7 @@ EX(CMD_aunmenu,		aunmenu,	ex_menu,
 			ADDR_LINES),
 EX(CMD_buffer,		buffer,	ex_buffer,
 			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|EDITCMD|TRLBAR,
-			ADDR_UNLOADED_BUFFERS),
+			ADDR_BUFFERS),
 EX(CMD_bNext,		bNext,	ex_bprevious,
 			BANG|RANGE|NOTADR|COUNT|EDITCMD|TRLBAR,
 			ADDR_LINES),
@@ -227,7 +227,7 @@ EX(CMD_bunload,		bunload,	ex_bunload,
 			ADDR_LOADED_BUFFERS),
 EX(CMD_bwipeout,	bwipeout,	ex_bunload,
 			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|TRLBAR,
-			ADDR_UNLOADED_BUFFERS),
+			ADDR_BUFFERS),
 EX(CMD_change,		change,	ex_change,
 			BANG|WHOLEFOLD|RANGE|COUNT|TRLBAR|CMDWIN|MODIFY,
 			ADDR_LINES),
@@ -1184,7 +1184,7 @@ EX(CMD_saveas,		saveas,	ex_write,
 			ADDR_LINES),
 EX(CMD_sbuffer,		sbuffer,	ex_buffer,
 			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|EDITCMD|TRLBAR,
-			ADDR_UNLOADED_BUFFERS),
+			ADDR_BUFFERS),
 EX(CMD_sbNext,		sbNext,	ex_bprevious,
 			RANGE|NOTADR|COUNT|EDITCMD|TRLBAR,
 			ADDR_LINES),
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 607dbd9..a1401e4 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -27,6 +27,7 @@ typedef struct ucmd
 char_u	*uc_rep;	/* The command's replacement string */
 long	uc_def;		/* The default value for a range/count */
 int		uc_compl;	/* completion type */
+int		uc_addr_type;	/* The command's address type */
 # ifdef

Re: Patch 7.4.530

[Marcin Szamotulski]

On 09:32 Thu 04 Dec , Marcin Szamotulski wrote:
 On 14:31 Wed 03 Dec , Matteo Cavalleri wrote:
  I'm using the code I posted a while ago in this thread, I'm copying it here 
  again :) (it was without the -buffer option, I'm adding it now)
  
  create and source this file 
  
   
  function! Test(f,l) 
  echom a:f. - .a:l 
  endfunction 
  command! -buffer -range=% RangeTest call Test(line1, line2) 
   
  
  then select a couple of lines and do: 
  
  :','RangeTest 
 
 I cannot reproduce it with the patch I sent.
 
 Best regards,
 Marcin

Dear Bram,

The attached patch adds support for user commands.  For example this
patch makes it possible to define the following commands:
com RangeLines :echo line1.' '.line2
which is the same as:
com -addr=lines RangeLines :echo line1.' '.line2
com -addr=arguments RangeArguments :echo line1.' '.line2
com -addr=loaded_buffers RangeLoadedBuffers :echo line1.' '.line2
com -addr=buffers RangeBuffers :echo line1.' '.line2
com -addr=windows RangeWindows :echo line1.' '.line2
com -addr=tabs RangeTabs :echo line1.' '.line2

The patch also includes a test, and it includes all the fixes
I published before in one place.

Best regards,
Marcin

-- 
-- 
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/map.txt b/runtime/doc/map.txt
index 1be2827..ad21d64 100644
--- a/runtime/doc/map.txt
+++ b/runtime/doc/map.txt
@@ -1358,6 +1358,19 @@ Possible attributes are:
 Note that -range=N and -count=N are mutually exclusive - only one should be
 specified.
 
+	*E889* *:command-addr*
+It is possible that the special characters in the range like ., $ or % which
+by default correspond to the current line, last line and the whole buffer,
+relate to arguments, (loaded) buffers, windows or tab pages.
+
+Possible values are:
+	-addr=lines		Range of lines (this is the default)
+	-addr=arguments		Range for arguments
+	-addr=buffers		Range for (all) buffers
+	-addr=loaded_buffers	Range for only loaded buffers
+	-addr=windows		Range for windows
+	-addr=tabs		Range for tab pages
+
 Special cases*:command-bang* *:command-bar*
 	*:command-register* *:command-buffer*
 There are some special cases as well:
diff --git a/src/Makefile b/src/Makefile
index 13fe70b..5a5518d 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -1896,6 +1896,7 @@ test1 \
 	test_breakindent \
 	test_changelist \
 	test_close_count \
+	test_command_count \
 	test_eval \
 	test_insertcount \
 	test_listlbr \
diff --git a/src/ex_cmds.h b/src/ex_cmds.h
index 5574ea7..fc6a8ac 100644
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -63,7 +63,7 @@
 #define ADDR_WINDOWS		1
 #define ADDR_ARGUMENTS		2
 #define ADDR_LOADED_BUFFERS	3
-#define ADDR_UNLOADED_BUFFERS	4
+#define ADDR_BUFFERS	4
 #define ADDR_TABS		5
 
 #ifndef DO_DECLARE_EXCMD
@@ -161,7 +161,7 @@ EX(CMD_aunmenu,		aunmenu,	ex_menu,
 			ADDR_LINES),
 EX(CMD_buffer,		buffer,	ex_buffer,
 			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|EDITCMD|TRLBAR,
-			ADDR_UNLOADED_BUFFERS),
+			ADDR_BUFFERS),
 EX(CMD_bNext,		bNext,	ex_bprevious,
 			BANG|RANGE|NOTADR|COUNT|EDITCMD|TRLBAR,
 			ADDR_LINES),
@@ -227,7 +227,7 @@ EX(CMD_bunload,		bunload,	ex_bunload,
 			ADDR_LOADED_BUFFERS),
 EX(CMD_bwipeout,	bwipeout,	ex_bunload,
 			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|TRLBAR,
-			ADDR_UNLOADED_BUFFERS),
+			ADDR_BUFFERS),
 EX(CMD_change,		change,	ex_change,
 			BANG|WHOLEFOLD|RANGE|COUNT|TRLBAR|CMDWIN|MODIFY,
 			ADDR_LINES),
@@ -1184,7 +1184,7 @@ EX(CMD_saveas,		saveas,	ex_write,
 			ADDR_LINES),
 EX(CMD_sbuffer,		sbuffer,	ex_buffer,
 			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|EDITCMD|TRLBAR,
-			ADDR_UNLOADED_BUFFERS),
+			ADDR_BUFFERS),
 EX(CMD_sbNext,		sbNext,	ex_bprevious,
 			RANGE|NOTADR|COUNT|EDITCMD|TRLBAR,
 			ADDR_LINES),
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 607dbd9..af41aba 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -27,6 +27,7 @@ typedef struct ucmd
 char_u	*uc_rep;	/* The command's replacement string */
 long	uc_def;		/* The default value for a range/count */
 int		uc_compl;	/* completion type */
+int		uc_addr_type;	/* The command's address type */
 # ifdef FEAT_EVAL
 scid_T	uc_scriptID;	/* SID where the command was defined */
 #  ifdef FEAT_CMDL_COMPL
@@ -2135,8 +2136,9 @@ do_one_cmd(cmdlinep, sourcing,
 #endif
)
 	ea.addr_type = cmdnames[(int)ea.cmdidx].cmd_addr_type;
-else
+else if (ea.cmdidx != CMD_USER)
 	ea.addr_type = ADDR_LINES;
+/* ea.addr_type for user commands is set by find_ucmd

Re: Patch 7.4.530

[Marcin Szamotulski]

On 14:31 Wed 03 Dec , Matteo Cavalleri wrote:
 I'm using the code I posted a while ago in this thread, I'm copying it here 
 again :) (it was without the -buffer option, I'm adding it now)
 
 create and source this file 
 
  
 function! Test(f,l) 
 echom a:f. - .a:l 
 endfunction 
 command! -buffer -range=% RangeTest call Test(line1, line2) 
  
 
 then select a couple of lines and do: 
 
 :','RangeTest 

I cannot reproduce it with the patch I sent.

Best regards,
Marcin

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

[Marcin Szamotulski]

On 00:22 Wed 03 Dec , Matteo Cavalleri wrote:
 
  On 18:21 Tue 02 Dec , Marcin Szamotulski wrote:
  
  This patch should fix this.
 
 Hi! sorry, I forgot to specify I tried again with vim patched up to 540. 
 anyway, I've tried your patch and I still get the error:
 
 http://oi60.tinypic.com/21b991x.jpg
 
 this time it seems range is always reported as 1 - 1
 btw I've forgot to copy it, but during compilation I saw an error about the 
 implicit definition of parse_addr_type_arg or something like that.
 
 anyway thanks for your time and work :)

I sent wrong patch.  With the attached one I don't get any error.

Regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 607dbd9..b4ca2bc 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -2629,8 +2629,40 @@ do_one_cmd(cmdlinep, sourcing,
 
 if ((ea.argt  DFLALL)  ea.addr_count == 0)
 {
-	ea.line1 = 1;
-	ea.line2 = curbuf-b_ml.ml_line_count;
+	buf_T	*buf;
+	switch (ea.addr_type)
+	{
+	case ADDR_LINES:
+		ea.line1 = 1;
+		ea.line2 = curbuf-b_ml.ml_line_count;
+		break;
+	case ADDR_LOADED_BUFFERS:
+		buf = firstbuf;
+		while (buf-b_next != NULL  buf-b_ml.ml_mfp == NULL)
+		buf = buf-b_next;
+		ea.line1 = buf-b_fnum;
+		buf = lastbuf;
+		while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL)
+		buf = buf-b_prev;
+		ea.line2 = buf-b_fnum;
+		break;
+	case ADDR_UNLOADED_BUFFERS:
+		ea.line1 = firstbuf-b_fnum;
+		ea.line2 = lastbuf-b_fnum;
+		break;
+	case ADDR_WINDOWS:
+		ea.line1 = 1;
+		ea.line2 = LAST_WIN_NR;
+		break;
+	case ADDR_TABS:
+		ea.line1 = 1;
+		ea.line2 = LAST_TAB_NR;
+		break;
+	case ADDR_ARGUMENTS:
+		ea.line1 = 1;
+		ea.line2 = ARGCOUNT;
+		break;
+	}
 }
 
 /* accept numbered register only when no count allowed (:put) */


signature.asc
Description: Digital signature

Re: Patch 7.4.530

[Marcin Szamotulski]

On 12:41 Wed 03 Dec , Matteo Cavalleri wrote:
 sorry, I still get the error. I also noticed something strange:
 
 - I apply the patch
 - run it from ./src/vim (i also changed version.c to double check I was 
 really using the patched binary ;)
 - load my example file
 - source it
 - everything is fine
 - modify the file adding the -buffer option
 - save the file
 - source it again
 - I get the error
 - remove the -buffer option
 - save the file
 - source it again
 - I still get the error
 
 somehow, after getting the error I cannot get rid of it until I quit vim and 
 reload it again. No idea if it has something to do with how user commands are 
 (re)defined or if it's a bug (maybe related with this one)

can you post your test example.  I'm testing with

com! -buffer -range=% -bar Range :echo line1. .line2

and don't see any problem with
:','Range

Regards,
Marcin

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

[Marcin Szamotulski]

On 07:13 Tue 02 Dec , Matteo Cavalleri wrote:
 I think I've tracked down the remaining problem.
 
 CoffeeCompile is defined as:
 
 command! -buffer -range=% -bar -nargs=*
   \  -complete=customlist,s:CoffeeComplete
   \  CoffeeCompile call s:CoffeeCompile(line1, line2, q-args)
 
 and it still gives me the invalid range error. If i remove the -buffer 
 argument it works again. If I take the example I posted and add the -buffer 
 argument, I can reproduce the problem again when running vim with --noplugin 
 -u NONE -N

Do you still get this with vim-7.4.539?

Marcin

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

[Marcin Szamotulski]

On 18:21 Tue 02 Dec , Marcin Szamotulski wrote:
 On 07:13 Tue 02 Dec , Matteo Cavalleri wrote:
  I think I've tracked down the remaining problem.
  
  CoffeeCompile is defined as:
  
  command! -buffer -range=% -bar -nargs=*
\  -complete=customlist,s:CoffeeComplete
\  CoffeeCompile call s:CoffeeCompile(line1, line2, q-args)
  
  and it still gives me the invalid range error. If i remove the -buffer 
  argument it works again. If I take the example I posted and add the 
  -buffer argument, I can reproduce the problem again when running vim with 
  --noplugin -u NONE -N
 
 Do you still get this with vim-7.4.539?
 
 Marcin

This patch should fix this.

Best regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 607dbd9..26630f6 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -27,6 +27,7 @@ typedef struct ucmd
 char_u	*uc_rep;	/* The command's replacement string */
 long	uc_def;		/* The default value for a range/count */
 int		uc_compl;	/* completion type */
+int		uc_addr_type;	/* The command's address type */
 # ifdef FEAT_EVAL
 scid_T	uc_scriptID;	/* SID where the command was defined */
 #  ifdef FEAT_CMDL_COMPL
@@ -2135,8 +2136,9 @@ do_one_cmd(cmdlinep, sourcing,
 #endif
)
 	ea.addr_type = cmdnames[(int)ea.cmdidx].cmd_addr_type;
-else
+else if (ea.cmdidx != CMD_USER)
 	ea.addr_type = ADDR_LINES;
+/* ea.addr_type for user commands is set by find_ucmd */
 ea.cmd = cmd;
 
 /* repeat for all ',' or ';' separated addresses */
@@ -2196,9 +2198,32 @@ do_one_cmd(cmdlinep, sourcing,
 			ea.line2 = lastbuf-b_fnum;
 			break;
 		case ADDR_WINDOWS:
+			if (IS_USER_CMDIDX(ea.cmdidx))
+			{
+			ea.line1 = 1;
+			ea.line2 = LAST_WIN_NR;
+			}
+			else
+			{
+			/* there is no vim command which uses '%' and
+			 * ADDR_WINDOWS */
+			errormsg = (char_u *)_(e_invrange);
+			goto doend;
+			}
+			break;
 		case ADDR_TABS:
-			errormsg = (char_u *)_(e_invrange);
-			goto doend;
+			if (IS_USER_CMDIDX(ea.cmdidx))
+			{
+			ea.line1 = 1;
+			ea.line2 = LAST_TAB_NR;
+			}
+			else
+			{
+			/* there is no vim command which uses '%' and
+			 * ADDR_TABS */
+			errormsg = (char_u *)_(e_invrange);
+			goto doend;
+			}
 			break;
 		case ADDR_ARGUMENTS:
 			ea.line1 = 1;
@@ -2629,8 +2654,40 @@ do_one_cmd(cmdlinep, sourcing,
 
 if ((ea.argt  DFLALL)  ea.addr_count == 0)
 {
-	ea.line1 = 1;
-	ea.line2 = curbuf-b_ml.ml_line_count;
+	buf_T	*buf;
+	switch (ea.addr_type)
+	{
+	case ADDR_LINES:
+		ea.line1 = 1;
+		ea.line2 = curbuf-b_ml.ml_line_count;
+		break;
+	case ADDR_LOADED_BUFFERS:
+		buf = firstbuf;
+		while (buf-b_next != NULL  buf-b_ml.ml_mfp == NULL)
+		buf = buf-b_next;
+		ea.line1 = buf-b_fnum;
+		buf = lastbuf;
+		while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL)
+		buf = buf-b_prev;
+		ea.line2 = buf-b_fnum;
+		break;
+	case ADDR_UNLOADED_BUFFERS:
+		ea.line1 = firstbuf-b_fnum;
+		ea.line2 = lastbuf-b_fnum;
+		break;
+	case ADDR_WINDOWS:
+		ea.line1 = 1;
+		ea.line2 = LAST_WIN_NR;
+		break;
+	case ADDR_TABS:
+		ea.line1 = 1;
+		ea.line2 = LAST_TAB_NR;
+		break;
+	case ADDR_ARGUMENTS:
+		ea.line1 = 1;
+		ea.line2 = ARGCOUNT;
+		break;
+	}
 }
 
 /* accept numbered register only when no count allowed (:put) */
@@ -3211,6 +3268,7 @@ find_ucmd(eap, p, full, xp, compl)
 			eap-cmdidx = CMD_USER_BUF;
 		eap-argt = (long)uc-uc_argt;
 		eap-useridx = j;
+		eap-addr_type = uc-uc_addr_type;
 
 # ifdef FEAT_CMDL_COMPL
 		if (compl != NULL)
@@ -5585,14 +5643,14 @@ get_command_name(xp, idx)
 #endif
 
 #if defined(FEAT_USR_CMDS) || defined(PROTO)
-static int	uc_add_command __ARGS((char_u *name, size_t name_len, char_u *rep, long argt, long def, int flags, int compl, char_u *compl_arg, int force));
+static int	uc_add_command __ARGS((char_u *name, size_t name_len, char_u *rep, long argt, long def, int flags, int compl, char_u *compl_arg, int addr_type, int force));
 static void	uc_list __ARGS((char_u *name, size_t name_len));
-static int	uc_scan_attr __ARGS((char_u *attr, size_t len, long *argt, long *def, int *flags, int *compl, char_u **compl_arg));
+static int	uc_scan_attr __ARGS((char_u *attr, size_t len, long *argt, long *def, int *flags, int *compl, char_u **compl_arg, int* attr_type_arg));
 static char_u	*uc_split_args __ARGS((char_u *arg, size_t *lenp));
 static size_t	uc_check_code __ARGS((char_u *code, size_t len, char_u *buf, ucmd_T *cmd, exarg_T *eap, char_u

Re: Patch 7.4.530

[Marcin Szamotulski]

On 22:14 Fri 28 Nov , Bram Moolenaar wrote:
 
 Itchyny wrote:
 
  Bram, the line1 is always 1 (probably after this patch).
  
:command! Test echo line1
  
  try :Test and it always echoes 1.
 
 I cannot reproduce this problem, I get the current line.
 Anything else that matters?

I found some small issues, the attached patch solves them all.  It
includes other small patches I send yesterday.

- fix SEGFAULT in compute_buffer_local_count
- fix buf number returned by compute_buffer_local_count
- `penultimate` in docs
- check for CMD_USER in do_one_cmd

Best regards,
Marcin

-- 
-- 
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/windows.txt b/runtime/doc/windows.txt
index d116c9f..17123ce 100644
--- a/runtime/doc/windows.txt
+++ b/runtime/doc/windows.txt
@@ -1029,7 +1029,11 @@ list of buffers. |unlisted-buffer|
 		Actually, the buffer isn't completely deleted, it is removed
 		from the buffer list |unlisted-buffer| and option values,
 		variables and mappings/abbreviations for the buffer are
-		cleared.
+		cleared. Examples: 
+		:.,$-bdelete delete buffers from the current one to
+ penultimate one
+		:%bdelete	 delete all buffers
+
 
 :bdelete[!] {bufname}		*E93* *E94*
 		Like :bdelete[!] [N], but buffer given by name.  Note that a
@@ -1053,7 +1057,11 @@ list of buffers. |unlisted-buffer|
 		Like |:bdelete|, but really delete the buffer.  Everything
 		related to the buffer is lost.  All marks in this buffer
 		become invalid, option settings are lost, etc.  Don't use this
-		unless you know what you are doing.
+		unless you know what you are doing. Examples: 
+		:.+,$bwipeoutwipe out all buffers after the current
+ one
+		:%bwipeout	 wipe out all buffers
+
 
 :[N]bun[load][!]*:bun* *:bunload* *E515*
 :bun[load][!] [N]
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 4ce9e92..711f513 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -1701,15 +1701,24 @@ compute_buffer_local_count(addr_type, lnum, offset)
 	buf = buf-b_next;
 while (count != 0)
 {
-	count += (count  0) ? 1 : -1;
-	if (buf-b_prev == NULL)
+	count += (offset  0) ? 1 : -1;
+	if (((offset  0) ? buf-b_prev : buf-b_next) == NULL)
 	break;
-	buf = (count  0) ? buf-b_prev : buf-b_next;
+	buf = (offset  0) ? buf-b_prev : buf-b_next;
 	if (addr_type == ADDR_LOADED_BUFFERS)
 	/* skip over unloaded buffers */
-	while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL)
-		buf = (count  0) ? buf-b_prev : buf-b_next;
+	while (((offset  0) ? buf-b_prev : buf-b_next) != NULL
+	 buf-b_ml.ml_mfp == NULL)
+		buf = (offset  0) ? buf-b_prev : buf-b_next;
 }
+/* we might have gone too far */
+if (addr_type == ADDR_LOADED_BUFFERS  buf-b_ml.ml_mfp == NULL)
+	while (((offset = 0) ? buf-b_prev : buf-b_next) != NULL)
+	{
+	buf = ((offset = 0) ? buf-b_prev : buf-b_next);
+	if (buf-b_ml.ml_mfp != NULL)
+		break;
+	}
 return buf-b_fnum;
 }
 
@@ -2113,7 +2122,7 @@ do_one_cmd(cmdlinep, sourcing,
  * is equal to the lower.
  */
 
-if (ea.cmdidx != CMD_SIZE)
+if (ea.cmdidx != CMD_USER  ea.cmdidx != CMD_SIZE)
 	ea.addr_type = cmdnames[(int)ea.cmdidx].cmd_addr_type;
 else
 	ea.addr_type = ADDR_LINES;
@@ -2153,6 +2162,7 @@ do_one_cmd(cmdlinep, sourcing,
 	{
 	if (*ea.cmd == '%')		/* '%' - all lines */
 	{
+		buf_T	*buf;
 		++ea.cmd;
 		switch (ea.addr_type)
 		{
@@ -2160,9 +2170,21 @@ do_one_cmd(cmdlinep, sourcing,
 			ea.line1 = 1;
 			ea.line2 = curbuf-b_ml.ml_line_count;
 			break;
-		case ADDR_WINDOWS:
 		case ADDR_LOADED_BUFFERS:
+			buf = firstbuf;
+			while (buf-b_next != NULL  buf-b_ml.ml_mfp == NULL)
+			buf = buf-b_next;
+			ea.line1 = buf-b_fnum;
+			buf = lastbuf;
+			while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL)
+			buf = buf-b_prev;
+			ea.line2 = buf-b_fnum;
+			break;
 		case ADDR_UNLOADED_BUFFERS:
+			ea.line1 = firstbuf-b_fnum;
+			ea.line2 = lastbuf-b_fnum;
+			break;
+		case ADDR_WINDOWS:
 		case ADDR_TABS:
 			errormsg = (char_u *)_(e_invrange);
 			goto doend;
@@ -4463,7 +4485,7 @@ get_address(ptr, addr_type, skip, to_other_file)
 		n = getdigits(cmd);
 	if (addr_type == ADDR_LOADED_BUFFERS
 		|| addr_type == ADDR_UNLOADED_BUFFERS)
-		lnum = compute_buffer_local_count(addr_type, lnum, n);
+		lnum = compute_buffer_local_count(addr_type, lnum, (i == '-') ? -1 * n : n);
 	else if (i == '-')
 		lnum -= n;
 	else
@@ -4485,9 +4507,8 @@ get_address(ptr, addr_type, skip, to_other_file)
 			lnum = 0;
 			break;
 		}
-		c = 

Re: Patch 7.4.530

[Marcin Szamotulski]

On 05:00 Fri 28 Nov , Matteo Cavalleri wrote:
  This patch made a big change in how ranges are handled, thus it's
  possible that it introduced a bug.
  
  Can you reproduce it without any plugins?
  With a simple user command perhaps?
 
 create and source this file
 
 
 function! Test(f,l)
 echom a:f. - .a:l
 endfunction
 command! -range=% RangeTest call Test(line1, line2)
 
 
 then select a couple of lines and do:
 
 :','RangeTest
 
 and you can see the error I reported, plus the result is always 1 - 5

I cannot reproduce it with `vim -u NONE`.  If I select a few lines and
yank them then
:','RangeTest
always shows the correct range.  I also tested that the :'[,']RangeTest
works fine.

But I think we should apply the attached patch.  Matteo can you please
check if this solves the issue for you.

Best regards,
Marcin

-- 
-- 
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/ex_docmd.c b/src/ex_docmd.c
index 4ce9e92..69396ec 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -2113,7 +2113,7 @@ do_one_cmd(cmdlinep, sourcing,
  * is equal to the lower.
  */
 
-if (ea.cmdidx != CMD_SIZE)
+if (ea.cmdidx != CMD_USER  ea.cmdidx != CMD_SIZE)
 	ea.addr_type = cmdnames[(int)ea.cmdidx].cmd_addr_type;
 else
 	ea.addr_type = ADDR_LINES;


signature.asc
Description: Digital signature

Re: Patch 7.4.530

[Marcin Szamotulski]

On 08:55 Fri 28 Nov , Marius Gedminas wrote:
 On Thu, Nov 27, 2014 at 09:55:36PM +, Marcin Szamotulski wrote:
  I found that `:.,$-bdelete` will trigger a segfault.  The attached patch
  fixes that, and in addition it makes `:%bdelete` and `:%bwipeout`
  work as well.
 
  diff --git a/runtime/doc/windows.txt b/runtime/doc/windows.txt
  index d116c9f..30e62d9 100644
  --- a/runtime/doc/windows.txt
  +++ b/runtime/doc/windows.txt
  @@ -1029,7 +1029,11 @@ list of buffers. |unlisted-buffer|
  Actually, the buffer isn't completely deleted, it is removed
  from the buffer list |unlisted-buffer| and option values,
  variables and mappings/abbreviations for the buffer are
  -   cleared.
  +   cleared. Examples: 
  +   :.,$-bdelete delete buffers from the current one to
  +penulimum one
 
 Is that a word?  Did you mean penultimate?

You're right, using latin (http://en.wiktionary.org/wiki/penultimum) in
vim's manual is not the best idea :)

Marcin

-- 
-- 
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/windows.txt b/runtime/doc/windows.txt
index d116c9f..17123ce 100644
--- a/runtime/doc/windows.txt
+++ b/runtime/doc/windows.txt
@@ -1029,7 +1029,11 @@ list of buffers. |unlisted-buffer|
 		Actually, the buffer isn't completely deleted, it is removed
 		from the buffer list |unlisted-buffer| and option values,
 		variables and mappings/abbreviations for the buffer are
-		cleared.
+		cleared. Examples: 
+		:.,$-bdelete delete buffers from the current one to
+ penultimate one
+		:%bdelete	 delete all buffers
+
 
 :bdelete[!] {bufname}		*E93* *E94*
 		Like :bdelete[!] [N], but buffer given by name.  Note that a
@@ -1053,7 +1057,11 @@ list of buffers. |unlisted-buffer|
 		Like |:bdelete|, but really delete the buffer.  Everything
 		related to the buffer is lost.  All marks in this buffer
 		become invalid, option settings are lost, etc.  Don't use this
-		unless you know what you are doing.
+		unless you know what you are doing. Examples: 
+		:.+,$bwipeoutwipe out all buffers after the current
+ one
+		:%bwipeout	 wipe out all buffers
+
 
 :[N]bun[load][!]*:bun* *:bunload* *E515*
 :bun[load][!] [N]
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 4ce9e92..852ca16 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -1701,14 +1701,14 @@ compute_buffer_local_count(addr_type, lnum, offset)
 	buf = buf-b_next;
 while (count != 0)
 {
-	count += (count  0) ? 1 : -1;
+	count += (offset  0) ? 1 : -1;
 	if (buf-b_prev == NULL)
 	break;
-	buf = (count  0) ? buf-b_prev : buf-b_next;
+	buf = (offset  0) ? buf-b_prev : buf-b_next;
 	if (addr_type == ADDR_LOADED_BUFFERS)
 	/* skip over unloaded buffers */
 	while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL)
-		buf = (count  0) ? buf-b_prev : buf-b_next;
+		buf = (offset  0) ? buf-b_prev : buf-b_next;
 }
 return buf-b_fnum;
 }
@@ -2153,6 +2153,7 @@ do_one_cmd(cmdlinep, sourcing,
 	{
 	if (*ea.cmd == '%')		/* '%' - all lines */
 	{
+		buf_T	*buf;
 		++ea.cmd;
 		switch (ea.addr_type)
 		{
@@ -2160,9 +2161,21 @@ do_one_cmd(cmdlinep, sourcing,
 			ea.line1 = 1;
 			ea.line2 = curbuf-b_ml.ml_line_count;
 			break;
-		case ADDR_WINDOWS:
 		case ADDR_LOADED_BUFFERS:
+			buf = firstbuf;
+			while (buf-b_next != NULL  buf-b_ml.ml_mfp == NULL)
+			buf = buf-b_next;
+			ea.line1 = buf-b_fnum;
+			buf = lastbuf;
+			while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL)
+			buf = buf-b_prev;
+			ea.line2 = buf-b_fnum;
+			break;
 		case ADDR_UNLOADED_BUFFERS:
+			ea.line1 = firstbuf-b_fnum;
+			ea.line2 = lastbuf-b_fnum;
+			break;
+		case ADDR_WINDOWS:
 		case ADDR_TABS:
 			errormsg = (char_u *)_(e_invrange);
 			goto doend;
@@ -4463,7 +4476,7 @@ get_address(ptr, addr_type, skip, to_other_file)
 		n = getdigits(cmd);
 	if (addr_type == ADDR_LOADED_BUFFERS
 		|| addr_type == ADDR_UNLOADED_BUFFERS)
-		lnum = compute_buffer_local_count(addr_type, lnum, n);
+		lnum = compute_buffer_local_count(addr_type, lnum, (i == '-') ? -1 * n : n);
 	else if (i == '-')
 		lnum -= n;
 	else


signature.asc
Description: Digital signature

Re: Patch 7.4.530

[Marcin Szamotulski]

On 15:33 Fri 28 Nov , LCD 47 wrote:
 On 28 November 2014, itchyny neknekneknek.ky...@gmail.com wrote:
  Bram, the line1 is always 1 (probably after this patch).
  
:command! Test echo line1
  
  try :Test and it always echoes 1.
 
 I don't think this is a relevant test.  You need to pass -range
 when defining Test if you want it to handle ranges:
 
 :command! -range Test echo line1
 
 /lcd

Indeed, one needs `-range` and it works fine, note that still your file
has to be long enough for the range.

Regards,
Marcin

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

[Marcin Szamotulski]

On 08:52 Fri 28 Nov , Enno wrote:
 Le vendredi 28 novembre 2014 14:33:25 UTC+1, LCD 47 a écrit :
  On 28 November 2014, itchyny neknekneknek.ky...@gmail.com wrote:
   Bram, the line1 is always 1 (probably after this patch).
   
 :command! Test echo line1
   
   try :Test and it always echoes 1.
  
  I don't think this is a relevant test.  You need to pass -range
  when defining Test if you want it to handle ranges:
  
  :command! -range Test echo line1
  
  /lcd
 
 Most likely this patch also relates to the sudden problems occurring in Vim 
 versions higher than 7.4.514 discussed at 
 https://github.com/tomtom/tcomment_vim/issues/121

It is not.  `:TCommand` is defined as

command! -bar -bang -range -nargs=* -complete=customlist,tcomment#CompleteArgs 
TComment
\ keepjumps call tcomment#Comment(line1, line2, 'G', bang, 
f-args)

and by default line1 and line2 are set to the current line (which
I just checked that they are set correctly).  I also test that it
comments the current line with vim-529.  My guess is that the
implementation of `tcomment#Comment` must have change or before it was
defined with `-range=1`.

Regards,
Marcin Szamotulski

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

[Marcin Szamotulski]

On 18:06 Thu 27 Nov , Bram Moolenaar wrote:
 
 Ken Takata wrote:
 
  2014/11/28 Fri 0:23:27 UTC+9 Bram Moolenaar wrote:
   Patch 7.4.530
   Problem:Many commands take a count or range that is not using line
 numbers.
   Solution:   For each command specify what kind of count it uses.  For 
   windows,
 buffers and arguments have $ and . have a relevant meaning.
 (Marcin Szamotulski)
   Files:runtime/doc/editing.txt, runtime/doc/tabpage.txt,
 runtime/doc/windows.txt, src/Makefile, src/ex_cmds.h,
 src/ex_docmd.c, src/testdir/Make_amiga.mak
 src/testdir/Make_dos.mak, src/testdir/Make_ming.mak,
 src/testdir/Make_os2.mak, src/testdir/Make_vms.mms,
 src/testdir/Makefile, src/testdir/test_argument_count.in,
 src/testdir/test_argument_count.ok,
 src/testdir/test_close_count.in, src/testdir/test_close_count.ok,
 src/window.c
  
  After this patch, tiny build fails:
  https://travis-ci.org/vim-jp/vim-ci/jobs/42317489#L568
 
 I'll make a fix.
 
 I also notice that when the window number is out of range it just uses
 the last window.  Now that we have $ it could be better to give an
 error (if backwards compatible).
 
  And test on Windows fails:
  https://ci.appveyor.com/project/k-takata/vim-ci/build/108#L1156
   NMAKE : fatal error U1073: don't know how to make 
   'test_argument_count.out'
  Are the test files missing in the repository?
 
 Yeah, forgot to add them.  Done now.
 
 -- 
 I am always surprised in the Linux world how quickly solutions can be
 obtained.  (Imagine sending an email to Bill Gates, asking why Windows
 crashed, and how to fix it...  and then getting an answer that fixed the
 problem... 0_0 !)   -- Mark Langdon
 
  /// 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.

I found that `:.,$-bdelete` will trigger a segfault.  The attached patch
fixes that, and in addition it makes `:%bdelete` and `:%bwipeout`
work as well.

Best regards,
Marcin Szamotulski

-- 
-- 
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/windows.txt b/runtime/doc/windows.txt
index d116c9f..30e62d9 100644
--- a/runtime/doc/windows.txt
+++ b/runtime/doc/windows.txt
@@ -1029,7 +1029,11 @@ list of buffers. |unlisted-buffer|
 		Actually, the buffer isn't completely deleted, it is removed
 		from the buffer list |unlisted-buffer| and option values,
 		variables and mappings/abbreviations for the buffer are
-		cleared.
+		cleared. Examples: 
+		:.,$-bdelete delete buffers from the current one to
+ penulimum one
+		:%bdelete	 delete all buffers
+
 
 :bdelete[!] {bufname}		*E93* *E94*
 		Like :bdelete[!] [N], but buffer given by name.  Note that a
@@ -1053,7 +1057,11 @@ list of buffers. |unlisted-buffer|
 		Like |:bdelete|, but really delete the buffer.  Everything
 		related to the buffer is lost.  All marks in this buffer
 		become invalid, option settings are lost, etc.  Don't use this
-		unless you know what you are doing.
+		unless you know what you are doing. Examples: 
+		:.+,$bwipeoutwipe out all buffers after the current
+ one
+		:%bwipeout	 wipe out all buffers
+
 
 :[N]bun[load][!]*:bun* *:bunload* *E515*
 :bun[load][!] [N]
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 4ce9e92..852ca16 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -1701,14 +1701,14 @@ compute_buffer_local_count(addr_type, lnum, offset)
 	buf = buf-b_next;
 while (count != 0)
 {
-	count += (count  0) ? 1 : -1;
+	count += (offset  0) ? 1 : -1;
 	if (buf-b_prev == NULL)
 	break;
-	buf = (count  0) ? buf-b_prev : buf-b_next;
+	buf = (offset  0) ? buf-b_prev : buf-b_next;
 	if (addr_type == ADDR_LOADED_BUFFERS)
 	/* skip over unloaded buffers */
 	while (buf-b_prev != NULL  buf-b_ml.ml_mfp == NULL

Re: [Bulk] [Bulk] Add count to :close and :hide commands

[Marcin Szamotulski]

On 17:04 Wed 12 Nov , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
   I had a look at the count patch.  I don't like the solution much.
   
   I think it would work better to add a flag similar to NOTADD that
   specifies the kind of count: window number, buffer number, etc.  That
   way there is no need to pass information from where the counts are
   parsed to where there is a switch on the command.  Can use
   compute_count() directly.  First computing counts based on line numbers
   and then redoing that for something else doesn't seem right.
   
   The code that computes the counts looks much too complicated.
   
   Please give the tests a name, we stopped using numbers recently.
  
  I slightly improved the patch, I added NOTLNR to command's flags and now
  the count is not computed twice.  I also refactored the code so it's
  simpler and I think easier to follow.  
 
 Thanks for the update.  The code is still quite bulky.  What I don't
 like is first adding NOTLNR and then, when it is set, using a switch on
 the specific command.  There already is NOTADR, which has a similar
 meaning but would now be a bit different.
 
 It's probably better to add a new field in the cmdname struct that
 specifies the type of range.  Like cmd_argt, but with a separate list of
 values, e.g. ADDR_LNUM, ADDR_WINDOW, etc.
 
 Then where the special characters such as $ are parsed, that flag can
 be used to decide what the value is: Last line number, highest window
 number, etc.  That avoids having to pass the type around and then later
 using it.
 
 There we can also check for errors.  E.g. when the address is
 /pattern/ while the command takes a window number.

I think there is no way of getting rid of `addr_T` struct.  The reason
is that when the range is parsed we don't yet know what is the command,
so we cannot use ADDR_LNUM, ADDR_WINDOW yet.  You're right though that
`NOTLNT` wasn't a good idea.   What I suggest that we first parse the
range into `addr_T` structs, without setting the `ea.line1` and
`ea.line2`; after parsing the range we know which command runs (what is
checked by `find_command` at this point and now we can set `ea.line1` and 
`ea.line2`
since we will now which of `ADDR_LNUM`, ... should be used.  It can be
done using the function I wrote `compute_count`.  At this place we will
be able to handle errors as well.

I will write a patch for that if you don't have any objections.

Best regards,
Marcin

-- 
-- 
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: [Bulk] [Bulk] Add count to :close and :hide commands

[Marcin Szamotulski]

On 18:48 Sat 22 Nov , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  On 17:04 Wed 12 Nov , Bram Moolenaar wrote:
   
   Marcin Szamotulski wrote:
   
 I had a look at the count patch.  I don't like the solution much.
 
 I think it would work better to add a flag similar to NOTADD that
 specifies the kind of count: window number, buffer number, etc.  That
 way there is no need to pass information from where the counts are
 parsed to where there is a switch on the command.  Can use
 compute_count() directly.  First computing counts based on line 
 numbers
 and then redoing that for something else doesn't seem right.
 
 The code that computes the counts looks much too complicated.
 
 Please give the tests a name, we stopped using numbers recently.

I slightly improved the patch, I added NOTLNR to command's flags and now
the count is not computed twice.  I also refactored the code so it's
simpler and I think easier to follow.  
   
   Thanks for the update.  The code is still quite bulky.  What I don't
   like is first adding NOTLNR and then, when it is set, using a switch on
   the specific command.  There already is NOTADR, which has a similar
   meaning but would now be a bit different.
   
   It's probably better to add a new field in the cmdname struct that
   specifies the type of range.  Like cmd_argt, but with a separate list of
   values, e.g. ADDR_LNUM, ADDR_WINDOW, etc.
   
   Then where the special characters such as $ are parsed, that flag can
   be used to decide what the value is: Last line number, highest window
   number, etc.  That avoids having to pass the type around and then later
   using it.
   
   There we can also check for errors.  E.g. when the address is
   /pattern/ while the command takes a window number.
  
  I think there is no way of getting rid of `addr_T` struct.  The reason
  is that when the range is parsed we don't yet know what is the command,
  so we cannot use ADDR_LNUM, ADDR_WINDOW yet.  You're right though that
  `NOTLNT` wasn't a good idea.   What I suggest that we first parse the
  range into `addr_T` structs, without setting the `ea.line1` and
  `ea.line2`; after parsing the range we know which command runs (what is
  checked by `find_command` at this point and now we can set `ea.line1`
  and `ea.line2` since we will now which of `ADDR_LNUM`, ... should be
  used.  It can be done using the function I wrote `compute_count`.  At
  this place we will be able to handle errors as well.
  
  I will write a patch for that if you don't have any objections.
 
 Right, the range comes before the command, thus we don't know what to
 do with the range when first encountering it.
 
 So we basically have two alternatives:
 1. What you say: parse the range and store it in some intermediate form,
then parse the command and once we know the type of rnage we can
compute the actual range.
 2. Go over the range twice: Once to skip over it and find the command,
then a second time when we know the command, and thus how to compute
the actual range.
 
 I would argue the second solution is better.  We do not need to come up
 with an intermediate format, with new symbols and stuff.  Also, we do
 not need to store anything in the first round.  The disadvantage is
 having to parse twice, but that should be fast and we can use the same
 code: A function that skips over the actual computation in the first
 round.
 
 How about that?

Sounds good.  I will go with the second solution.

Best regards,
Marcin

-- 
-- 
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: [Bulk] [Bulk] Add count to :close and :hide commands

[Marcin Szamotulski]

 I had a look at the count patch.  I don't like the solution much.
 
 I think it would work better to add a flag similar to NOTADD that
 specifies the kind of count: window number, buffer number, etc.  That
 way there is no need to pass information from where the counts are
 parsed to where there is a switch on the command.  Can use
 compute_count() directly.  First computing counts based on line numbers
 and then redoing that for something else doesn't seem right.
 
 The code that computes the counts looks much too complicated.
 
 Please give the tests a name, we stopped using numbers recently.

I slightly improved the patch, I added NOTLNR to command's flags and now
the count is not computed twice.  I also refactored the code so it's
simpler and I think easier to follow.  

Best regards,
Marcin
diff --git a/runtime/doc/editing.txt b/runtime/doc/editing.txt
index add3bb0..1c9c6d1 100644
--- a/runtime/doc/editing.txt
+++ b/runtime/doc/editing.txt
@@ -622,7 +622,8 @@ list of the current window.
 :argadd x	a b x c
 :0argadd x	x a b c
 :1argadd x	a x b c
-:99argadd x	a b c x
+:$argadd x	a b c x
+:+2aradd y	a b c x y
 			There is no check for duplicates, it is possible to
 			add a file to the argument list twice.
 			The currently edited file is not changed.
@@ -644,11 +645,19 @@ list of the current window.
 			{not in Vi} {not available when compiled without the
 			|+listcmds| feature}
 
-:{range}argd[elete]	Delete the {range} files from the argument list.
+:[count]argd[elete]
+:[range]argd[elete]	Delete the {range} files from the argument list.
 			When the last number in the range is too high, up to
 			the last argument is deleted.  Example: 
-:10,1000argdel
-			Deletes arguments 10 and further, keeping 1-9.
+:10,$argdel
+			Deletes arguments 10 and further, keeping 1-9. 
+:$argd
+			Deletes just the last one. 
+:argd
+:.argd
+			Deletes the current argument. 
+:%argd
+			Removes all the files from the arglist.
 			{not in Vi} {not available when compiled without the
 			|+listcmds| feature}
 
diff --git a/runtime/doc/tabpage.txt b/runtime/doc/tabpage.txt
index 3c7ad9f..b8726ae 100644
--- a/runtime/doc/tabpage.txt
+++ b/runtime/doc/tabpage.txt
@@ -61,16 +61,25 @@ In the GUI tab pages line you can use the right mouse button to open menu.
 :[count]tabe[dit]*:tabe* *:tabedit* *:tabnew*
 :[count]tabnew
 		Open a new tab page with an empty window, after the current
-		tab page.  For [count] see |:tab| below.
+		tab page.  If [count] is given the new tab page appears after
+		the tab page [count] otherwise the new tab page will appear
+		after the current one. 
+		:tabnew	 opens tabpage after the current one
+		:.tabnew	 as above
+		:+tabnew	 opens tabpage after the next tab page
+ note: it is one further than :tabnew
+		:-tabnew	 opens tabpage before the current one
+		:0tabnew	 opens tabpage before the first one
+		:$tabnew	 opens tabpage after the last one
 
 :[count]tabe[dit] [++opt] [+cmd] {file}
 :[count]tabnew [++opt] [+cmd] {file}
 		Open a new tab page and edit {file}, like with |:edit|.
-		For [count] see |:tab| below.
+		For [count] see |:tabnew| above.
 
 :[count]tabf[ind] [++opt] [+cmd] {file}			*:tabf* *:tabfind*
 		Open a new tab page and edit {file} in 'path', like with
-		|:find|.  For [count] see |:tab| below.
+		|:find|.  For [count] see |:tabnew| above.
 		{not available when the |+file_in_path| feature was disabled
 		at compile time}
 
@@ -104,27 +113,42 @@ the top right to close the current tab page.  A custom |'tabline'| may show
 something else.
 
 			*:tabc* *:tabclose*
-:tabc[lose][!]	Close current tab page.
+:[N]tabc[lose][!]
+		Close current tab page or if [N] is given close [N]th tab page.
 		This command fails when:
 		- There is only one tab page on the screen.		*E784*
 		- When 'hidden' is not set, [!] is not used, a buffer has
 		  changes, and there is no other window on this buffer.
 		Changes to the buffer are not written and won't get lost, so
-		this is a safe command.
+		this is a safe command. 
+		:tabclose	 close the current tab page
+		:-tabclose	 close the previous tab page
+		:+tabclose	 close the next tab page
+		:1tabclose	 close the first tab page
+		:$tabclose	 close the last tab page
 
 :tabc[lose][!] {count}
-		Close tab page {count}.  Fails in the same way as `:tabclose`
+		Close tab page {count}.  Fails in the same way as |:tabclose|
 		above.
 
 			*:tabo* *:tabonly*
-:tabo[nly][!]	Close all other tab pages.
+:[N]tabo[nly][!]
+		Close all tab pages except the current one or the [N]th one if
+		[N] is given.
 		When the 'hidden' option is set, all buffers in closed windows
 		become hidden.
 		When 'hidden' is not set, and the 'autowrite' option is set,
 		modified buffers are written.  Otherwise, windows that have
 		buffers that are modified are not removed, unless the [!] is
 		given, then they become hidden.  But modified 

Re: gettabvar(1, '') doesn't return dict of variables

[Marcin Szamotulski]

On 19:27 Tue 02 Sep , mattn wrote:
 Bram, This is not a new feature. This is a bug. Please remember this. :)

hi mattn,

you forgot to attach the patch.

best regards,
marcin


signature.asc
Description: Digital signature

getcmdtype documentation

[Marcin Szamotulski]

Hi Bram,

I found that when an expression is evaluated using the expression
register i_CTRL-R_= the getcmdtype() function returns '='.  I attach
patch which documents that.

Best regards,
Marcin Szamotulski
diff -r 35ec194cce5b -r 98ba880f7ddf runtime/doc/eval.txt
--- a/runtime/doc/eval.txt	Fri Aug 29 17:45:32 2014 +0200
+++ b/runtime/doc/eval.txt	Sun Aug 31 13:55:04 2014 +0100
@@ -3346,6 +3346,7 @@
 		?	backward search command
 		@	|input()| command
 		-	|:insert| or |:append| command
+		=	|i_CTRL-R_=|
 		Only works when editing the command line, thus requires use of
 		|c_CTRL-\_e| or |c_CTRL-R_=| or an expression mapping.
 		Returns an empty string otherwise.


signature.asc
Description: Digital signature

Re: [Bulk] [Bulk] Add count to :close and :hide commands

[Marcin Szamotulski]

On 20:02 Thu 21 Aug , Christian Brabandt wrote:
 
 On Do, 21 Aug 2014, 'Andy Wokula' via vim_dev wrote:
 
  Am 21.08.2014 um 07:49 schrieb Christian Brabandt:
  Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:
  Some people expect  :1,$bd  or :%bd  to delete all buffers.
  
  That only works by accident, because your current buffer has more
  lines than you have open buffers.
  
  Or saying it differently, this does not work in an empty buffer.
  
  So this expectation is not really valid.
  
  Er, what you cited implies that it doesn't work at the moment
  (as expected (by some people (for a long time))).
 
  The idea is to make it become valid ...
  
  Marcin Szamotulski wrote:
  There are probably a few other commands that could benefit with a
  similar approach.
  
  Got it?
  
 
 Ah, I thought you wanted to keep the current behaviour, that currently 
 %bd already does delete all buffers (but only, if your buffer has enough 
 lines).
 
 Best,
 Christian
 -- 
 Richtiges Auffassen einer Sache und Mißverstehen der gleichen Sache
 schließen einander nicht aus.
   -- Franz Kafka
 

Hi,

So here are updated patches:
count.patch - the counts
argadd.patch - :argadd to be a valid command without and argument (:argadd%)

Best regards,
Marcin
diff -r b9ec5ed29480 -r b95122e84f81 src/ex_cmds.h
--- a/src/ex_cmds.h	Thu Aug 21 00:16:25 2014 +0100
+++ b/src/ex_cmds.h	Tue Aug 12 10:31:37 2014 +0100
@@ -110,7 +110,7 @@
 EX(CMD_args,		args,		ex_args,
 			BANG|FILES|EDITCMD|ARGOPT|TRLBAR),
 EX(CMD_argadd,		argadd,	ex_argadd,
-			BANG|NEEDARG|RANGE|NOTADR|ZEROR|FILES|TRLBAR),
+			BANG|RANGE|NOTADR|ZEROR|FILES|TRLBAR),
 EX(CMD_argdelete,	argdelete,	ex_argdelete,
 			BANG|RANGE|NOTADR|FILES|TRLBAR),
 EX(CMD_argdo,		argdo,	ex_listdo,
diff -r b9ec5ed29480 -r b95122e84f81 src/ex_cmds2.c
--- a/src/ex_cmds2.c	Thu Aug 21 00:16:25 2014 +0100
+++ b/src/ex_cmds2.c	Tue Aug 12 10:31:37 2014 +0100
@@ -1946,6 +1946,11 @@
 #endif
 
 /*
+ * Set default argument for :argadd command.
+ */
+if (what == AL_ADD  STRLEN(str) == 0)
+	str = curbuf-b_fname;
+/*
  * Collect all file name arguments in new_ga.
  */
 if (get_arglist(new_ga, str) == FAIL)
diff -r 35ec194cce5b -r 1333a7ca01af runtime/doc/editing.txt
--- a/runtime/doc/editing.txt	Fri Aug 29 17:45:32 2014 +0200
+++ b/runtime/doc/editing.txt	Sun Aug 24 18:55:01 2014 +0100
@@ -619,7 +619,8 @@
 :argadd x	a b x c
 :0argadd x	x a b c
 :1argadd x	a x b c
-:99argadd x	a b c x
+:$argadd x	a b c x
+:+2aradd y	a b c x y
 			There is no check for duplicates, it is possible to
 			add a file to the argument list twice.
 			The currently edited file is not changed.
@@ -641,11 +642,19 @@
 			{not in Vi} {not available when compiled without the
 			|+listcmds| feature}
 
-:{range}argd[elete]	Delete the {range} files from the argument list.
+:[count]argd[elete]
+:[range]argd[elete]	Delete the {range} files from the argument list.
 			When the last number in the range is too high, up to
 			the last argument is deleted.  Example: 
-:10,1000argdel
-			Deletes arguments 10 and further, keeping 1-9.
+:10,$argdel
+			Deletes arguments 10 and further, keeping 1-9. 
+:$argd
+			Deletes just the last one. 
+:argd
+:.argd
+			Deletes the current argument. 
+:%argd
+			Removes all the files from the arglist.
 			{not in Vi} {not available when compiled without the
 			|+listcmds| feature}
 
diff -r 35ec194cce5b -r 1333a7ca01af runtime/doc/windows.txt
--- a/runtime/doc/windows.txt	Fri Aug 29 17:45:32 2014 +0200
+++ b/runtime/doc/windows.txt	Sun Aug 24 18:55:01 2014 +0100
@@ -265,26 +265,40 @@
 
 CTRL-W q		*CTRL-W_q*
 CTRL-W CTRL-Q		*CTRL-W_CTRL-Q*
-:q[uit]		Quit current window.  When quitting the last window (not
-		counting a help window), exit Vim.
-		When 'hidden' is set, and there is only one window for the
-		current buffer, it becomes hidden.
-		When 'hidden' is not set, and there is only one window for the
-		current buffer, and the buffer was changed, the command fails.
-		(Note: CTRL-Q does not work on all terminals)
-
-:q[uit]!	Quit current window.  If this was the last window for a buffer,
+:[count]q[uit]	Quit current window if [count] is not given, otherwise close
+		window with window number equal to [count].  When quitting the
+		last window (not counting a help window), exit Vim.  When
+		'hidden' is set, and there is only one window for the current
+		buffer, it becomes hidden.  When 'hidden' is not set, and
+		there is only one window for the current buffer, and the
+		buffer was changed, the command fails.  (Note: CTRL-Q does not
+		work on all terminals).  If [count] is greater than
+		the last window number the last window will be closed: 
+		:1quit   quit the first window
+		:$quit   quit the last window
+		:9quit   quit the last window
+			  if there are less than 9 windows opened
+		:-quit   quit the previews window
+		:+quit   quit the next window

add +cmd argument to :buffer command

[Marcin Szamotulski]

Hello,

I was wondering for some time why the :buffer command does not allow for
+cmd argument (:help +cmd), like :edit does.  Though this is not
strictly necessary since one can always do
:buffer1|cmd
but the same is true for :edit command; one can do both:
:edit +cmd file
:edit file|cmd

I attach a patch as a proof of concept and to let it try.

Best regards,
Marcin Szamotulski
diff -r 18fd959b07ef -r 1c58235619f2 src/ex_cmds.h
--- a/src/ex_cmds.h	Wed Aug 13 22:05:54 2014 +0200
+++ b/src/ex_cmds.h	Mon Aug 18 12:07:52 2014 +0100
@@ -132,7 +132,7 @@
 EX(CMD_aunmenu,		aunmenu,	ex_menu,
 			EXTRA|TRLBAR|NOTRLCOM|USECTRLV|CMDWIN),
 EX(CMD_buffer,		buffer,	ex_buffer,
-			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|TRLBAR),
+			BANG|RANGE|NOTADR|BUFNAME|BUFUNL|COUNT|EXTRA|EDITCMD|TRLBAR),
 EX(CMD_bNext,		bNext,	ex_bprevious,
 			BANG|RANGE|NOTADR|COUNT|TRLBAR),
 EX(CMD_ball,		ball,		ex_buffer_all,
diff -r 18fd959b07ef -r 1c58235619f2 src/ex_docmd.c
--- a/src/ex_docmd.c	Wed Aug 13 22:05:54 2014 +0200
+++ b/src/ex_docmd.c	Mon Aug 18 12:07:52 2014 +0100
@@ -5115,6 +5115,8 @@
 	goto_buffer(eap, DOBUF_CURRENT, FORWARD, 0);
 	else
 	goto_buffer(eap, DOBUF_FIRST, FORWARD, (int)eap-line2);
+	if (eap-do_ecmd_cmd != NULL)
+	do_cmdline_cmd(eap-do_ecmd_cmd);
 }
 }
 


signature.asc
Description: Digital signature

Re: add +cmd argument to :buffer command

[Marcin Szamotulski]

On 15:36 Mon 18 Aug , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  I was wondering for some time why the :buffer command does not allow for
  +cmd argument (:help +cmd), like :edit does.  Though this is not
  strictly necessary since one can always do
  :buffer1|cmd
  but the same is true for :edit command; one can do both:
  :edit +cmd file
  :edit file|cmd
  
  I attach a patch as a proof of concept and to let it try.
 
 I suppose we would make this consistent, also do this for :sbuf,
 :bnext, etc.

Here is a patch which includes:
:buffer
:sbuffer
:bnext
:sbnext
:bNext
:sbNext
:bprevious
:sbprevious
:bfirst
:brewind
:sbfirst
:sbrewind
:blast
:sblast
:bmodified
:sbmodified

Best regards,
Marcin Szamotulski
diff -r 18fd959b07ef -r bf9ff84941f6 runtime/doc/windows.txt
--- a/runtime/doc/windows.txt	Wed Aug 13 22:05:54 2014 +0200
+++ b/runtime/doc/windows.txt	Mon Aug 18 12:07:52 2014 +0100
@@ -1042,36 +1042,41 @@
 		a number).  Insert a backslash before a space in a buffer
 		name.
 
-:[N]b[uffer][!] [N]			*:b* *:bu* *:buf* *:buffer* *E86*
+:[N]b[uffer][!] [+cmd] [N]		*:b* *:bu* *:buf* *:buffer* *E86*
 		Edit buffer [N] from the buffer list.  If [N] is not given,
 		the current buffer remains being edited.  See |:buffer-!| for
 		[!].  This will also edit a buffer that is not in the buffer
 		list, without setting the 'buflisted' flag.
+		Also see ||+cmd|.
 
-:[N]b[uffer][!] {bufname}
+:[N]b[uffer][!] [+cmd] {bufname}
 		Edit buffer for {bufname} from the buffer list.  See
 		|:buffer-!| for [!].  This will also edit a buffer that is not
 		in the buffer list, without setting the 'buflisted' flag.
+		Also see ||+cmd|.
 
-:[N]sb[uffer] [N]	*:sb* *:sbuffer*
+:[N]sb[uffer] [+cmd] [N]*:sb* *:sbuffer*
 		Split window and edit buffer [N] from the buffer list.  If [N]
 		is not given, the current buffer is edited.  Respects the
 		useopen setting of 'switchbuf' when splitting.  This will
 		also edit a buffer that is not in the buffer list, without
 		setting the 'buflisted' flag.
+		Also see ||+cmd|.
 
-:[N]sb[uffer] {bufname}
+:[N]sb[uffer] [+cmd] {bufname}
 		Split window and edit buffer for {bufname} from the buffer
 		list.  This will also edit a buffer that is not in the buffer
 		list, without setting the 'buflisted' flag.
 		Note: If what you want to do is split the buffer, make a copy
 		under another name, you can do it this way: 
 			:w foobar | sp #
+		Also see ||+cmd|.
 
-:[N]bn[ext][!] [N]	*:bn* *:bnext* *E87*
+:[N]bn[ext][!] [+cmd] [N]*:bn* *:bnext* *E87*
 		Go to [N]th next buffer in buffer list.  [N] defaults to one.
 		Wraps around the end of the buffer list.
 		See |:buffer-!| for [!].
+		Also see ||+cmd|.
 		If you are in a help buffer, this takes you to the next help
 		buffer (if there is one).  Similarly, if you are in a normal
 		(non-help) buffer, this takes you to the next normal buffer.
@@ -1079,55 +1084,61 @@
 		the way when you're browsing code/text buffers.  The next three
 		commands also work like this.
 
+
 			*:sbn* *:sbnext*
-:[N]sbn[ext] [N]
+:[N]sbn[ext] [+cmd] [N]
 		Split window and go to [N]th next buffer in buffer list.
 		Wraps around the end of the buffer list.  Uses 'switchbuf'
+		Also see ||+cmd|.
 
-:[N]bN[ext][!] [N]			*:bN* *:bNext* *:bp* *:bprevious* *E88*
-:[N]bp[revious][!] [N]
+:[N]bN[ext][!] [+cmd] [N]		*:bN* *:bNext* *:bp* *:bprevious* *E88*
+:[N]bp[revious][!] [+cmd] [N]
 		Go to [N]th previous buffer in buffer list.  [N] defaults to
 		one.  Wraps around the start of the buffer list.
 		See |:buffer-!| for [!] and 'switchbuf'.
+		Also see ||+cmd|.
 
-:[N]sbN[ext] [N]			*:sbN* *:sbNext* *:sbp* *:sbprevious*
-:[N]sbp[revious] [N]
+:[N]sbN[ext] [+cmd] [N]			*:sbN* *:sbNext* *:sbp* *:sbprevious*
+:[N]sbp[revious] [+cmd] [N]
 		Split window and go to [N]th previous buffer in buffer list.
 		Wraps around the start of the buffer list.
 		Uses 'switchbuf'.
+		Also see ||+cmd|.
 
-			*:br* *:brewind*
-:br[ewind][!]	Go to first buffer in buffer list.  If the buffer list is
+:br[ewind][!] [+cmd]	*:br* *:brewind*
+		Go to first buffer in buffer list.  If the buffer list is
 		empty, go to the first unlisted buffer.
 		See |:buffer-!| for [!].
 
-			*:bf* *:bfirst*
-:bf[irst]	Same as :brewind.
+:bf[irst] [+cmd]	*:bf* *:bfirst*
+		Same as |:brewind|.
+		Also see |+cmd|.
 
-			*:sbr* *:sbrewind*
-:sbr[ewind]	Split window and go to first buffer in buffer list.  If the
+:sbr[ewind] [+cmd]	*:sbr* *:sbrewind*
+		Split window and go to first buffer in buffer list.  If the
 		buffer list is empty, go to the first unlisted buffer.
 		Respects the 'switchbuf' option.
+		Also see |+cmd|.
 
-			*:sbf* *:sbfirst*
-:sbf[irst]	Same as :sbrewind.
+:sbf[irst] [+cmd]	*:sbf* *:sbfirst*
+		Same as :sbrewind.
 
-			*:bl* *:blast*
-:bl[ast][!]	Go to last buffer in buffer list.  If the buffer list is
+:bl[ast][!] [+cmd]	*:bl* *:blast*
+		Go to last buffer in buffer list.  If the buffer list is
 		empty, go to the last

Re: Add count to :close and :hide commands

[Marcin Szamotulski]

On 19:33 Sun 10 Aug , Marcin Szamotulski wrote:
 On 15:51 Sun 10 Aug , Bram Moolenaar wrote:
  
  I wrote:
  
   Marcin Szamotulski wrote:
   
I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
command.  When given the window with window number [count] will be
closed/hidden.  Sometimes I want to close not the current window but
another one, this command let to do that without switching windows
without ^Ww normal command.
   
   Nice idea.  I would find :1close and :9close the most useful,
   closing the first and last window.  Looks like the code does take the
   last window when the count is more than the number of windows.  This
   isn't obvious in the documentation, adding these two as an example will
   make them found quicker.  And perhaps :hide docs should refer to the
   explanation of [count] in :close.
   
   How about a test?
  
  Thinking about this, it would also be very nice to be able to close the
  next or previous window:
  
  :+1close
  :-1close
  
  And there is this entry in the todo list:
  
  Can't easily close the help window, like :pc closes the
  preview window and :ccl closes the quickfix window.  Add
  :hclose. (Chris Gaal)
  Patch for :helpclose, Christian Brabandt, 2010 Sep 6.
  
  Looks like I'm a bit behind including patches...
 
 Here is the patch.  As a bonus:
 :$close  will close the last window
 :$-close  will close the penultimate window
 :.close   the same as :close
 :%close, :/pattern/close, :*close, ...  will emit E16 error
 
 There are probably a few other commands that could benefit with
 a similar approach.
 
 Best regards,
 Marcin Szamotulski

I updated the patch.  It also includes changes for :argument,
:sargument, :argedit, :argadd (they share the same logic for the [count]),
and :argdelete.  The supported counts are:

:$argadd%add at the end of arglist
:-argadd%add before the current argument
:.argadd%the same as :argadd%

:%argdelete  delete all arguments
:$argdelete  delete the last one
:.argdelete  delete the current argument
:+argdelete  delete the one after current
:argdelete   with no count and no command argument: delete the current 
argument
:2,$-2argdelete  will also work

The patch includes a test.

I attach also one more patch which makes :argadd work as :argadd%.

Best regards,
Marcin Szamotulski
diff -r 18fd959b07ef -r 804c40325957 runtime/doc/editing.txt
--- a/runtime/doc/editing.txt	Wed Aug 13 22:05:54 2014 +0200
+++ b/runtime/doc/editing.txt	Thu Aug 14 01:37:00 2014 +0100
@@ -619,7 +619,8 @@
 :argadd x	a b x c
 :0argadd x	x a b c
 :1argadd x	a x b c
-:99argadd x	a b c x
+:$argadd x	a b c x
+:+2aradd y	a b c x y
 			There is no check for duplicates, it is possible to
 			add a file to the argument list twice.
 			The currently edited file is not changed.
@@ -641,11 +642,19 @@
 			{not in Vi} {not available when compiled without the
 			|+listcmds| feature}
 
-:{range}argd[elete]	Delete the {range} files from the argument list.
+:[count]argd[elete]
+:[range]argd[elete]	Delete the {range} files from the argument list.
 			When the last number in the range is too high, up to
 			the last argument is deleted.  Example: 
-:10,1000argdel
-			Deletes arguments 10 and further, keeping 1-9.
+:10,$argdel
+			Deletes arguments 10 and further, keeping 1-9. 
+:$argd
+			Deletes just the last one. 
+:argd
+:.argd
+			Deletes the current argument. 
+:%argd
+			Removes all the files from the arglist.
 			{not in Vi} {not available when compiled without the
 			|+listcmds| feature}
 
diff -r 18fd959b07ef -r 804c40325957 runtime/doc/windows.txt
--- a/runtime/doc/windows.txt	Wed Aug 13 22:05:54 2014 +0200
+++ b/runtime/doc/windows.txt	Thu Aug 14 01:37:00 2014 +0100
@@ -279,12 +279,23 @@
 		the buffer are lost, even when 'hidden' is set.
 
 CTRL-W c	*CTRL-W_c* *:clo* *:close*
-:clo[se][!]	Close current window.  When the 'hidden' option is set, or
-		when the buffer was changed and the [!] is used, the buffer
-		becomes hidden (unless there is another window editing it).
-		When there is only one window in the current tab page and
-		there is another tab page, this closes the current tab page.
-		|tab-page|.
+:[count]clo[se][!]
+		Close current window if [count] is not given, otherwise close
+		window with window number equal to [count].  When the 'hidden'
+		option is set, or when the buffer was changed and the [!] is
+		used, the buffer becomes hidden (unless there is another
+		window editing it).  When there is only one window in the
+		current tab page and there is another tab page, this closes
+		the current tab page.  |tab-page|.  If [count] is greater than
+		the last window number the last window will be closed: 
+		:1close   close the first window
+		:$close   close the last window
+		:9close   close the last window
+			  if there are less than 9 windows opened

Re: Add count to :close and :hide commands

[Marcin Szamotulski]

On 15:51 Sun 10 Aug , Bram Moolenaar wrote:
 
 I wrote:
 
  Marcin Szamotulski wrote:
  
   I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
   command.  When given the window with window number [count] will be
   closed/hidden.  Sometimes I want to close not the current window but
   another one, this command let to do that without switching windows
   without ^Ww normal command.
  
  Nice idea.  I would find :1close and :9close the most useful,
  closing the first and last window.  Looks like the code does take the
  last window when the count is more than the number of windows.  This
  isn't obvious in the documentation, adding these two as an example will
  make them found quicker.  And perhaps :hide docs should refer to the
  explanation of [count] in :close.
  
  How about a test?
 
 Thinking about this, it would also be very nice to be able to close the
 next or previous window:
 
   :+1close
   :-1close
 
 And there is this entry in the todo list:
 
   Can't easily close the help window, like :pc closes the
   preview window and :ccl closes the quickfix window.  Add
   :hclose. (Chris Gaal)
   Patch for :helpclose, Christian Brabandt, 2010 Sep 6.
 
 Looks like I'm a bit behind including patches...

Here is the patch.  As a bonus:
:$close  will close the last window
:$-close  will close the penultimate window
:.close   the same as :close
:%close, :/pattern/close, :*close, ...  will emit E16 error

There are probably a few other commands that could benefit with
a similar approach.

Best regards,
Marcin Szamotulski
diff -r 7090d7f160f7 runtime/doc/windows.txt
--- a/runtime/doc/windows.txt	Sat Jul 26 13:40:44 2014 +0200
+++ b/runtime/doc/windows.txt	Sun Aug 10 19:32:26 2014 +0100
@@ -279,12 +279,23 @@
 		the buffer are lost, even when 'hidden' is set.
 
 CTRL-W c	*CTRL-W_c* *:clo* *:close*
-:clo[se][!]	Close current window.  When the 'hidden' option is set, or
-		when the buffer was changed and the [!] is used, the buffer
-		becomes hidden (unless there is another window editing it).
-		When there is only one window in the current tab page and
-		there is another tab page, this closes the current tab page.
-		|tab-page|.
+:[count]clo[se][!]
+		Close current window if [count] is not given, otherwise close
+		window with window number equal to [count].  When the 'hidden'
+		option is set, or when the buffer was changed and the [!] is
+		used, the buffer becomes hidden (unless there is another
+		window editing it).  When there is only one window in the
+		current tab page and there is another tab page, this closes
+		the current tab page.  |tab-page|.  If [count] is greater than
+		the last window number the last window will be closed: 
+		:1close   close the first window
+		:$close   close the last window
+		:9close   close the last window
+			  if there are less than 9 windows opened
+		:-close   close the previews window
+		:+close   close the next window
+		:+2close  will also work as expected
+
 		This command fails when:			*E444*
 		- There is only one window on the screen.
 		- When 'hidden' is not set, [!] is not used, the buffer has
@@ -298,14 +309,14 @@
 		command.
 
 			*:hide*
-:hid[e]		Quit current window, unless it is the last window on the
-		screen.  The buffer becomes hidden (unless there is another
-		window editing it or 'bufhidden' is unload or delete).
-		If the window is the last one in the current tab page the tab
-		page is closed. |tab-page|
-		The value of 'hidden' is irrelevant for this command.
-		Changes to the buffer are not written and won't get lost, so
-		this is a safe command.
+:[count]hid[e]	Quit current window, unless it is the last window on the
+		screen.  For [count] see |:close| command. The buffer becomes
+		hidden (unless there is another window editing it or
+		'bufhidden' is unload or delete).  If the window is the
+		last one in the current tab page the tab page is closed.
+		|tab-page| The value of 'hidden' is irrelevant for this
+		command.  Changes to the buffer are not written and won't get
+		lost, so this is a safe command.
 
 :hid[e] {cmd}	Execute {cmd} with 'hidden' is set.  The previous value of
 		'hidden' is restored after {cmd} has been executed.
diff -r 7090d7f160f7 src/Makefile
--- a/src/Makefile	Sat Jul 26 13:40:44 2014 +0200
+++ b/src/Makefile	Sun Aug 10 19:32:26 2014 +0100
@@ -1894,7 +1894,7 @@
 	test70 test71 test72 test73 test74 test75 test76 test77 test78 test79 \
 	test80 test81 test82 test83 test84 test85 test86 test87 test88 test89 \
 	test90 test91 test92 test93 test94 test95 test96 test97 test98 test99 \
-	test100 test101 test102 test103 test104 test105 test106 test107:
+	test100 test101 test102 test103 test104 test105 test106 test107 test108:
 	cd testdir; rm $@.out; $(MAKE) -f Makefile $@.out VIMPROG=../$(VIMTARGET) $(GUI_TESTARG) SCRIPTSOURCE=../$(SCRIPTSOURCE)
 
 testclean:
diff -r 7090d7f160f7 src/ex_cmds.h
--- a/src/ex_cmds.h	Sat

Add count to :close and :hide commands

[Marcin Szamotulski]

Hello,

I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
command.  When given the window with window number [count] will be
closed/hidden.  Sometimes I want to close not the current window but
another one, this command let to do that without switching windows
without ^Ww normal command.

Best regards,
Marcin Szamotulski
diff -r 7090d7f160f7 -r 5f398504f605 runtime/doc/windows.txt
--- a/runtime/doc/windows.txt	Sat Jul 26 13:40:44 2014 +0200
+++ b/runtime/doc/windows.txt	Sat Aug 09 10:52:43 2014 +0100
@@ -279,12 +279,15 @@
 		the buffer are lost, even when 'hidden' is set.
 
 CTRL-W c	*CTRL-W_c* *:clo* *:close*
-:clo[se][!]	Close current window.  When the 'hidden' option is set, or
-		when the buffer was changed and the [!] is used, the buffer
-		becomes hidden (unless there is another window editing it).
-		When there is only one window in the current tab page and
-		there is another tab page, this closes the current tab page.
-		|tab-page|.
+:[count]clo[se][!]
+		Close current window if [count] is not given, otherwise close
+		window with window number equal to [count].  When the 'hidden'
+		option is set, or when the buffer was changed and the [!] is
+		used, the buffer becomes hidden (unless there is another
+		window editing it).  When there is only one window in the
+		current tab page and there is another tab page, this closes
+		the current tab page.  |tab-page|.  If [count] is greater than
+		the last window number the last window will be closed.
 		This command fails when:			*E444*
 		- There is only one window on the screen.
 		- When 'hidden' is not set, [!] is not used, the buffer has
@@ -298,11 +301,12 @@
 		command.
 
 			*:hide*
-:hid[e]		Quit current window, unless it is the last window on the
-		screen.  The buffer becomes hidden (unless there is another
-		window editing it or 'bufhidden' is unload or delete).
-		If the window is the last one in the current tab page the tab
-		page is closed. |tab-page|
+:[count]hid[e]	Quit current window, unless it is the last window on the
+		screen.  If [count] is given quit the window with window
+		number equal to [count].  The buffer becomes hidden (unless
+		there is another window editing it or 'bufhidden' is unload
+		or delete).  If the window is the last one in the current
+		tab page the tab page is closed. |tab-page|
 		The value of 'hidden' is irrelevant for this command.
 		Changes to the buffer are not written and won't get lost, so
 		this is a safe command.
diff -r 7090d7f160f7 -r 5f398504f605 src/ex_cmds.h
--- a/src/ex_cmds.h	Sat Jul 26 13:40:44 2014 +0200
+++ b/src/ex_cmds.h	Sat Aug 09 10:52:43 2014 +0100
@@ -232,7 +232,7 @@
 EX(CMD_clast,		clast,	ex_cc,
 			RANGE|NOTADR|COUNT|TRLBAR|BANG),
 EX(CMD_close,		close,	ex_close,
-			BANG|TRLBAR|CMDWIN),
+			BANG|RANGE|NOTADR|COUNT|TRLBAR|CMDWIN),
 EX(CMD_cmap,		cmap,		ex_map,
 			EXTRA|TRLBAR|NOTRLCOM|USECTRLV|CMDWIN),
 EX(CMD_cmapclear,	cmapclear,	ex_mapclear,
@@ -428,7 +428,7 @@
 EX(CMD_highlight,	highlight,	ex_highlight,
 			BANG|EXTRA|TRLBAR|SBOXOK|CMDWIN),
 EX(CMD_hide,		hide,		ex_hide,
-			BANG|EXTRA|NOTRLCOM),
+			BANG|RANGE|NOTADR|COUNT|EXTRA|NOTRLCOM),
 EX(CMD_history,		history,	ex_history,
 			EXTRA|TRLBAR|CMDWIN),
 EX(CMD_insert,		insert,	ex_append,
diff -r 7090d7f160f7 -r 5f398504f605 src/ex_docmd.c
--- a/src/ex_docmd.c	Sat Jul 26 13:40:44 2014 +0200
+++ b/src/ex_docmd.c	Sat Aug 09 10:52:43 2014 +0100
@@ -6657,6 +6657,8 @@
 ex_close(eap)
 exarg_T	*eap;
 {
+win_T	*win;
+int		winnr = 0;
 # ifdef FEAT_CMDWIN
 if (cmdwin_type != 0)
 	cmdwin_result = Ctrl_C;
@@ -6667,7 +6669,21 @@
 		 !curbuf_locked()
 #endif
 		)
-	ex_win_close(eap-forceit, curwin, NULL);
+	{
+	if (eap-addr_count == 0)
+		ex_win_close(eap-forceit, curwin, NULL);
+	else {
+		for (win = firstwin; win != NULL; win = win-w_next)
+		{
+		winnr++;
+		if (winnr == eap-line2)
+			break;
+		}
+		if (win == NULL)
+		win = lastwin;
+		ex_win_close(eap-forceit, win, NULL);
+	}
+	}
 }
 
 # ifdef FEAT_QUICKFIX
@@ -6895,6 +6911,9 @@
 ex_hide(eap)
 exarg_T	*eap;
 {
+win_T	*win;
+int		winnr = 0;
+
 if (*eap-arg != NUL  check_nextcmd(eap-arg) == NULL)
 	eap-errmsg = e_invarg;
 else
@@ -6907,7 +6926,18 @@
 # ifdef FEAT_GUI
 	need_mouse_correct = TRUE;
 # endif
-	win_close(curwin, FALSE);	/* don't free buffer */
+	if (eap-addr_count == 0)
+		win_close(curwin, FALSE);	/* don't free buffer */
+	else {
+		for(win = firstwin; win != NULL; win-w_next) {
+		winnr++;
+		if (winnr == eap-line2)
+			break;
+		}
+		if (win == NULL)
+		win = lastwin;
+		win_close(win, FALSE);
+	}
 	}
 #endif
 }
diff -r 7090d7f160f7 -r 5f398504f605 src/window.c
--- a/src/window.c	Sat Jul 26 13:40:44 2014 +0200
+++ b/src/window.c	Sat Aug 09 10:52:43 2014 +0100
@@ -206,7 +206,11 @@
 case Ctrl_C:
 case 'c':
 		reset_VIsual_and_resel();	/* stop Visual mode */
-		do_cmdline_cmd((char_u *)close);
+		STRCPY(cbuf, close);
+		if (Prenum

Re: usearglist patch

[Marcin Szamotulski]

On 15:15 Wed 30 Jul , Marcin Szamotulski wrote:
 On 12:53 Wed 30 Jul , Bram Moolenaar wrote:
  
  Marcin Szamotulski wrote:
  
   I wrote a patch to reuse an argument list from different window.
   I think it is useful to have a way of setting an argument list from
   a different window [tab page].  One scenario where it is useful is when
   a window has global argument list and one makes a ':split|argl' and
   after a while one would like to reuse the new local argument list 
   somewhere
   else.  With the attached patch one can:
   
   :call usearglist({winnr} [, {tabnr}])
   
   to use the argument list from window number {winnr} (in tab page
   {tabnr}) in the current window.
   
   The function returns 0 on success and -1 on error (window or tab page not
   found).
  
  Hmm, it's a bit strange to have this as a function.  Otherwise setting
  the argument list is done with commands.  E.g. :argglobal is similar,
  but always switches to the global argument list.
  
  We could use :{nr}arglocal instead.  The question is where the user gets
  the {nr} from.  When using arglistid() this requires using :exe.  I
  think we need a command to list all the arglists.
 
 I agree.
  
  For a user who actually uses multiple arglists it would indeed be useful
  to list the ones that are in use.  With a summary of the file names, and
  which window/tab they are used in.
  
 
 Maybe it should show columns:
 file name, window id, tab id and arglist id
 
 or even omit tab id by default and only include other tab pages when
 a bang is used.  I think it is better to organize the list by tab page id
 and window id rather by arglist id, since it will be easier to find the
 correct arglist id.
 
 Something like:
 tabdo windo echo printf('%2d %4d %4d  %s', tabpagenr(), winnr(), arglistid(), 
 bufname('%'))
 
 (but without the drawback of landing in a different window/tab page)
 
 Best regards,
 Marcin Szamotulski

Dear Bram,

I attach patch for :{N}arglocal (for using arglist with ID {N} in the
current window) command which also adds :arglists[!] (for listing all
the arglists).

During compilation I get a warning:
ex_docmd.c:205:13: warning: ‘ex_arglists’ used but never defined [enabled by 
default]
which I don't know how to fix.

Best regards,
Marcin Szamotulski
diff -r 7090d7f160f7 -r d4ccab55a143 runtime/doc/editing.txt
--- a/runtime/doc/editing.txt	Sat Jul 26 13:40:44 2014 +0200
+++ b/runtime/doc/editing.txt	Mon Aug 04 00:15:39 2014 +0100
@@ -798,6 +798,14 @@
 			Define a new argument list, which is local to the
 			current window.  Works like |:args_f| otherwise.
 
+:{count}argl[ocal]
+			Use argument list with ID {count} in the current
+			window.  To find the argument list ID use |:arglists|
+			command.  If the {count} is 0 the command acts like
+			|:argglobal|.
+			{not in Vi} {not available when compiled without the
+			|+listcmds| feature}
+
 			*:argglobal*
 :argg[lobal]		Use the global argument list for the current window.
 			Doesn't start editing another file.
@@ -808,6 +816,17 @@
 			All windows using the global argument list will see
 			this new list.
 
+			*:arglists*
+:argli[sts][!]
+			List all windows in the current tab page together with
+			their arugment list ID.  If bang is used show all
+			windows in all tab pages.  The '' indicates the
+			current window and '' indicates the previous window
+			as for |CTRL-W_p| normal command.  See also
+			|arglistid()|.
+			{not in Vi} {not available when compiled without the
+			|+listcmds| feature}
+
 There can be several argument lists.  They can be shared between windows.
 When they are shared, changing the argument list in one window will also
 change it in the other window.
diff -r 7090d7f160f7 -r d4ccab55a143 runtime/doc/eval.txt
--- a/runtime/doc/eval.txt	Sat Jul 26 13:40:44 2014 +0200
+++ b/runtime/doc/eval.txt	Mon Aug 04 00:15:39 2014 +0100
@@ -2113,7 +2113,7 @@
 		Return the argument list ID.  This is a number which
 		identifies the argument list being used.  Zero is used for the
 		global argument list.
-		Return zero if the arguments are invalid.
+		Return -1 if the arguments are invalid.
 
 		Without arguments use the current window.
 		With {winnr} only use this window in the current tab page.
diff -r 7090d7f160f7 -r d4ccab55a143 src/ex_cmds.h
--- a/src/ex_cmds.h	Sat Jul 26 13:40:44 2014 +0200
+++ b/src/ex_cmds.h	Mon Aug 04 00:15:39 2014 +0100
@@ -120,7 +120,9 @@
 EX(CMD_argglobal,	argglobal,	ex_args,
 			BANG|FILES|EDITCMD|ARGOPT|TRLBAR),
 EX(CMD_arglocal,	arglocal,	ex_args,
-			BANG|FILES|EDITCMD|ARGOPT|TRLBAR),
+			BANG|RANGE|NOTADR|ZEROR|COUNT|FILES|EDITCMD|ARGOPT|TRLBAR),
+EX(CMD_arglists,	arglists,	ex_arglists,
+			BANG|TRLBAR|ARGOPT|CMDWIN),
 EX(CMD_argument,	argument,	ex_argument,
 			BANG|RANGE|NOTADR|COUNT|EXTRA|EDITCMD|ARGOPT|TRLBAR),
 EX(CMD_ascii,		ascii,	do_ascii,
diff -r 7090d7f160f7 -r d4ccab55a143 src/ex_cmds2.c
--- a/src/ex_cmds2.c	Sat Jul 26 13:40:44 2014 +0200
+++ b/src/ex_cmds2.c	Mon Aug 04 00:15:39 2014

Re: usearglist patch

[Marcin Szamotulski]

On 12:53 Wed 30 Jul , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  I wrote a patch to reuse an argument list from different window.
  I think it is useful to have a way of setting an argument list from
  a different window [tab page].  One scenario where it is useful is when
  a window has global argument list and one makes a ':split|argl' and
  after a while one would like to reuse the new local argument list somewhere
  else.  With the attached patch one can:
  
  :call usearglist({winnr} [, {tabnr}])
  
  to use the argument list from window number {winnr} (in tab page
  {tabnr}) in the current window.
  
  The function returns 0 on success and -1 on error (window or tab page not
  found).
 
 Hmm, it's a bit strange to have this as a function.  Otherwise setting
 the argument list is done with commands.  E.g. :argglobal is similar,
 but always switches to the global argument list.
 
 We could use :{nr}arglocal instead.  The question is where the user gets
 the {nr} from.  When using arglistid() this requires using :exe.  I
 think we need a command to list all the arglists.

I agree.
 
 For a user who actually uses multiple arglists it would indeed be useful
 to list the ones that are in use.  With a summary of the file names, and
 which window/tab they are used in.
 

Maybe it should show columns:
file name, window id, tab id and arglist id

or even omit tab id by default and only include other tab pages when
a bang is used.  I think it is better to organize the list by tab page id
and window id rather by arglist id, since it will be easier to find the
correct arglist id.

Something like:
tabdo windo echo printf('%2d %4d %4d  %s', tabpagenr(), winnr(), arglistid(), 
bufname('%'))

(but without the drawback of landing in a different window/tab page)

Best regards,
Marcin Szamotulski

 
 -- 
 Your company is doomed if your primary product is overhead transparencies.
   (Scott Adams - The Dilbert principle)
 
  /// 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.


signature.asc
Description: Digital signature

Re: Patch 7.4.312

[Marcin Szamotulski]

On 00:48 Sun 20 Jul , Marcin Szamotulski wrote:
 On 18:23 Wed 28 May , Bram Moolenaar wrote:
  
  Patch 7.4.312
  Problem:Cannot figure out what argument list is being used for a window.
  Solution:   Add the arglistid() function. (Marcin Szamotulski)
  Files:  runtime/doc/eval.txt, runtime/doc/usr_41.txt, src/eval.c,
  src/ex_docmd.c, src/globals.h, src/structs.h, src/main.c
  
  
  *** ../vim-7.4.311/runtime/doc/eval.txt 2014-05-28 16:47:11.396174926 
  +0200
  --- runtime/doc/eval.txt2014-05-28 18:00:06.248213223 +0200
  ***
  *** 1716,1721 
  --- 1716,1723 
append( {lnum}, {list})   Number  append lines {list} below line 
  {lnum}
argc()Number  number of files in the argument 
  list
argidx()  Number  current index in the argument list
  + arglistid( [{winnr}, [ {tabnr}]])
  +   Number  argument list id
argv( {nr})   String  {nr} entry of the argument list
argv( )   Listthe argument list
asin( {expr}) Float   arc sine of {expr}
  ***
  *** 2103,2108 
  --- 2105,2122 
argidx()  The result is the current index in the argument list.  0 is
  the first file.  argc() - 1 is the last one.  See |arglist|.

  +   *arglistid()*
  + arglistid([{winnr}, [ {tabnr} ]])
  +   Return the argument list ID.  This is a number which
  +   identifies the argument list being used.  Zero is used for the
  +   global argument list.
  +   Return zero if the arguments are invalid.
  + 
  +   Without arguments use the current window.
  +   With {winnr} only use this window in the current tab page.
  +   With {winnr} and {tabnr} use the window in the specified tab
  +   page.
  + 
  *argv()*
argv([{nr}])  The result is the {nr}th file in the argument list of 
  the
  current window.  See |arglist|.  argv(0) is the first one.
  *** ../vim-7.4.311/runtime/doc/usr_41.txt   2014-03-25 18:23:27.054087691 
  +0100
  --- runtime/doc/usr_41.txt  2014-05-28 18:07:43.096217222 +0200
  ***
  *** 770,775 
  --- 772,778 
Buffers, windows and the argument list:
  argc()  number of entries in the argument list
  argidx()current position in the argument list
  +   arglistid() get id of the argument list
  argv()  get one entry from the argument list
  bufexists() check if a buffer exists
  buflisted() check if a buffer exists and is listed
  *** ../vim-7.4.311/src/eval.c   2014-05-28 16:47:11.392174926 +0200
  --- src/eval.c  2014-05-28 18:11:10.264219035 +0200
  ***
  *** 463,468 
  --- 463,469 
static void f_append __ARGS((typval_T *argvars, typval_T *rettv));
static void f_argc __ARGS((typval_T *argvars, typval_T *rettv));
static void f_argidx __ARGS((typval_T *argvars, typval_T *rettv));
  + static void f_arglistid __ARGS((typval_T *argvars, typval_T *rettv));
static void f_argv __ARGS((typval_T *argvars, typval_T *rettv));
#ifdef FEAT_FLOAT
static void f_asin __ARGS((typval_T *argvars, typval_T *rettv));
  ***
  *** 7875,7880 
  --- 7876,7882 
{append,2, 2, f_append},
{argc,  0, 0, f_argc},
{argidx,0, 0, f_argidx},
  + {arglistid, 0, 2, f_arglistid},
{argv,  0, 1, f_argv},
#ifdef FEAT_FLOAT
{asin,  1, 1, f_asin},  /* WJMc */
  ***
  *** 8859,8864 
  --- 8861,8901 
}

/*
  +  * arglistid() function
  +  */
  + static void
  + f_arglistid(argvars, rettv)
  + typval_T  *argvars UNUSED;
  + typval_T  *rettv;
  + {
  + win_T *wp;
  + tabpage_T *tp = NULL;
  + long  n;
  + 
  + rettv-vval.v_number = -1;
  + if (argvars[0].v_type != VAR_UNKNOWN)
  + {
  +   if (argvars[1].v_type != VAR_UNKNOWN)
  +   {
  +   n = get_tv_number(argvars[1]);
  +   if (n = 0)
  +   tp = find_tabpage(n);
  +   }
  +   else
  +   tp = curtab;
  + 
  +   if (tp != NULL)
  +   {
  +   wp = find_win_by_nr(argvars[0], tp);
  +   if (wp != NULL)
  +   rettv-vval.v_number = wp-w_alist-id;
  +   }
  + }
  + else
  +   rettv-vval.v_number = curwin-w_alist-id;
  + }
  + 
  + /*
 * argv(nr) function
 */
static void
  *** ../vim-7.4.311/src/ex_docmd.c   2014-05-07 21:14:42.913299714 +0200
  --- src/ex_docmd.c  2014-05-28 18:10:01.696218435 +0200
  ***
  *** 7211,7216 
  --- 7211,7217 
else
{
  curwin-w_alist-al_refcount = 1;
  +   curwin-w_alist-id

usearglist patch

[Marcin Szamotulski]

Dear Bram,

I wrote a patch to reuse an argument list from different window.
I think it is useful to have a way of setting an argument list from
a different window [tab page].  One scenario where it is useful is when
a window has global argument list and one makes a ':split|argl' and
after a while one would like to reuse the new local argument list somewhere
else.  With the attached patch one can:

:call usearglist({winnr} [, {tabnr}])

to use the argument list from window number {winnr} (in tab page
{tabnr}) in the current window.

The function returns 0 on success and -1 on error (window or tab page not
found).

Thanks for reviewing the patch,
Marcin Szamotulski
diff -r cf43c4c44e7a runtime/doc/eval.txt
--- a/runtime/doc/eval.txt	Tue Jul 29 10:15:21 2014 +0100
+++ b/runtime/doc/eval.txt	Tue Jul 29 12:27:19 2014 +0100
@@ -6362,6 +6362,11 @@
 		The default compare function uses the string representation of
 		each item.  For the use of {func} and {dict} see |sort()|.
 
+usearglist({winnr} [, {tabnr}])*usearglist()*
+		Use the argument list of window number {winnr} in the current
+		window.  If {tabnr} is given use the {winnr} from the given
+		tabpage.
+
 values({dict})		*values()*
 		Return a |List| with all the values of {dict}.	The |List| is
 		in arbitrary order.
diff -r cf43c4c44e7a src/eval.c
--- a/src/eval.c	Tue Jul 29 10:15:21 2014 +0100
+++ b/src/eval.c	Tue Jul 29 12:27:19 2014 +0100
@@ -754,6 +754,7 @@
 static void f_undofile __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_undotree __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_uniq __ARGS((typval_T *argvars, typval_T *rettv));
+static void f_usearglist __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_values __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_virtcol __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_visualmode __ARGS((typval_T *argvars, typval_T *rettv));
@@ -8187,6 +8188,7 @@
 {undofile,	1, 1, f_undofile},
 {undotree,	0, 0, f_undotree},
 {uniq,		1, 3, f_uniq},
+{usearglist,	1, 2, f_usearglist},
 {values,		1, 1, f_values},
 {virtcol,		1, 1, f_virtcol},
 {visualmode,	0, 1, f_visualmode},
@@ -17629,6 +17631,42 @@
 }
 
 /*
+ * usearglist(winnr [, tabnr]) function
+ */
+static void
+f_usearglist(argvars, rettv)
+typval_T	*argvars;
+typval_T	*rettv;
+{
+win_T	*wp;
+tabpage_T	*tp = NULL;
+long	n;
+
+if (argvars[1].v_type != VAR_UNKNOWN) {
+	n = get_tv_number(argvars[1]);
+	if (n = 0)
+	tp = find_tabpage(n);
+}
+else
+	tp = curtab;
+
+if (tp == NULL) {
+	rettv-vval.v_number = -1;
+	return;
+}
+
+wp = find_win_by_nr(argvars[0], tp);
+if (wp == NULL) {
+	rettv-vval.v_number = -1;
+	return;
+}
+alist_unlink(ALIST(curwin));
+curwin-w_alist = wp-w_alist;
+++curwin-w_alist-al_refcount;
+rettv-vval.v_number = 0;
+}
+
+/*
  * soundfold({word}) function
  */
 static void


signature.asc
Description: Digital signature

Re: argisglobal patch

[Marcin Szamotulski]

On 08:22 Sat 08 Feb , Marcin Szamotulski wrote:
 On 22:27 Fri 07 Feb , Bram Moolenaar wrote:
  
  Marcin Szamotulski wrote:
  
 I wrote a small patch which adds argisglobal() function which returns
 1 if the current buffer has global arglist otherwise, if there is
 a local arg list it return 0.  I haven't found any other way to test 
 if
 the arglist is gobal/local.
 
 I've been using this patch for some time already (I have a plugin
 http://www.vim.org/scripts/script.php?script_id=4681 which is using 
 it)
 and it works fine.

I'm sure someone will ask for another thing: What local argument list is
being used.  They can be shared between windows.

A more generic solution would be to request the ID of the local argument
list.  When zero, then the window is using the global argument list.

And then we of course also want to optionally pass in the window number.
So it would be:

arglistid([winnr])
   
   Yes that's much better solution.  I have a question though.  The alist_T
   structure does not contain an ID of arglist (only list of files, and
   number of windows using it).  How should I generate the ID?
  
  You could use the pointer and turn it into an int, but that's ugly (and
  doesn't work if sizeof(int) is smaller than sizeof(char *).
  
  So the best is to add an ID to alist_T and use a static global to store
  the last used ID.  That's in alist_new().
 
 Thanks.  I'll follow your advice.
 
 Best regards,
 Marcin


Dear Bram,

I attach the patch for arglistid().


Best regards,
Marcin Szamotulski
diff -r 01f2b7e6b33c -r 0e4dacbbe8b4 .hgtags
--- a/.hgtags	Thu Apr 24 17:12:33 2014 +0200
+++ b/.hgtags	Sun Apr 27 08:05:29 2014 +0100
@@ -2987,4 +2987,3 @@
 0ea551fa607dc443b97c2fba97dc0c9cb0bcf303 v7-4-262
 af1bb39774f41c28eabd24d80cffc775695bc124 v7-4-263
 00acac0af680c2d8c82db5258474b121a5908926 v7-4-264
-8ec9d2196bee0c5108f2d2c196a660a7f4e5f29f v7-4-265
diff -r 01f2b7e6b33c -r 0e4dacbbe8b4 runtime/doc/eval.txt
--- a/runtime/doc/eval.txt	Thu Apr 24 17:12:33 2014 +0200
+++ b/runtime/doc/eval.txt	Sun Apr 27 08:05:29 2014 +0100
@@ -1716,6 +1716,8 @@
 append( {lnum}, {list})		Number	append lines {list} below line {lnum}
 argc()Number	number of files in the argument list
 argidx()			Number	current index in the argument list
+arglistid( [{winnr}, [ {tabnr}]])
+Number	argument list id
 argv( {nr})			String	{nr} entry of the argument list
 argv( )List	the argument list
 asin( {expr})			Float	arc sine of {expr}
@@ -2103,6 +2105,12 @@
 argidx()	The result is the current index in the argument list.  0 is
 		the first file.  argc() - 1 is the last one.  See |arglist|.
 
+			*arglistid()*
+arglistid([{winnr}, [ {tabnr} ]])
+		Return argument list id for the current window or for the
+		winndow number {winnr} in tabpage {tabnr}. 0 if the window is
+		using global argument list, -1 is returned on error. 
+
 			*argv()*
 argv([{nr}])	The result is the {nr}th file in the argument list of the
 		current window.  See |arglist|.  argv(0) is the first one.
diff -r 01f2b7e6b33c -r 0e4dacbbe8b4 runtime/doc/usr_41.txt
--- a/runtime/doc/usr_41.txt	Thu Apr 24 17:12:33 2014 +0200
+++ b/runtime/doc/usr_41.txt	Sun Apr 27 08:05:29 2014 +0100
@@ -772,6 +772,7 @@
 Buffers, windows and the argument list:
 	argc()			number of entries in the argument list
 	argidx()		current position in the argument list
+	arglistid()		return id of the argument list
 	argv()			get one entry from the argument list
 	bufexists()		check if a buffer exists
 	buflisted()		check if a buffer exists and is listed
diff -r 01f2b7e6b33c -r 0e4dacbbe8b4 src/eval.c
--- a/src/eval.c	Thu Apr 24 17:12:33 2014 +0200
+++ b/src/eval.c	Sun Apr 27 08:05:29 2014 +0100
@@ -100,6 +100,7 @@
 static char *e_missbrac = N_(E111: Missing ']');
 static char *e_listarg = N_(E686: Argument of %s must be a List);
 static char *e_listdictarg = N_(E712: Argument of %s must be a List or Dictionary);
+max_alist_id = 0;
 static char *e_emptykey = N_(E713: Cannot use empty key for Dictionary);
 static char *e_listreq = N_(E714: List required);
 static char *e_dictreq = N_(E715: Dictionary required);
@@ -463,6 +464,7 @@
 static void f_append __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_argc __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_argidx __ARGS((typval_T *argvars, typval_T *rettv));
+static void f_arglistid __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_argv __ARGS((typval_T *argvars, typval_T *rettv));
 #ifdef FEAT_FLOAT
 static void f_asin __ARGS((typval_T *argvars, typval_T *rettv));
@@ -7872,6 +7874,7 @@
 {append,		2, 2, f_append},
 {argc,		0, 0, f_argc},
 {argidx,		0, 0, f_argidx},
+{arglistid,	0, 2, f_arglistid},
 {argv,		0, 1, f_argv},
 #ifdef FEAT_FLOAT
 {asin,		1, 1, f_asin},	/* WJMc */
@@ -8856,6 +8859,50 @@
 }
 
 /*
+ * arglistid() function
+ */
+static void
+f_arglistid(argvars, rettv

Re: argisglobal patch

[Marcin Szamotulski]

On 12:20 Sun 27 Apr , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  I'm sure someone will ask for another thing: What local argument
  list is being used.  They can be shared between windows.
  
  A more generic solution would be to request the ID of the local
  argument list.  When zero, then the window is using the global
  argument list.
  
  And then we of course also want to optionally pass in the window
  number.  So it would be:
  
  arglistid([winnr])
 
 Yes that's much better solution.  I have a question though.  The
 alist_T structure does not contain an ID of arglist (only list of
 files, and number of windows using it).  How should I generate the
 ID?

You could use the pointer and turn it into an int, but that's ugly (and
doesn't work if sizeof(int) is smaller than sizeof(char *).

So the best is to add an ID to alist_T and use a static global to store
the last used ID.  That's in alist_new().
   
   Thanks.  I'll follow your advice.
  
  I attach the patch for arglistid().
 
 Thanks, I'll add it in the todo list.

Thanks,

Marcin Szamotulski


signature.asc
Description: Digital signature

Re: [BUG] “:execute 'if 1'” works like “:if 1”

[Marcin Szamotulski]

On 15:33 Sat 22 Mar , Bram Moolenaar wrote:
 
 ZyX wrote:
 
  Consider the following script:
  
  execute 'if 0'
  echo 'Not shown'
  else
  echo 'Shown'
  endif
  
  . If you source it you find that instead of 3 errors (“missing
  :endif”, “:else without :if”, “:endif without :if”) and two messages
  (“Not shown” and “Shown”) you will see one message (“Shown”) and no
  errors.
  
  Note that `execute 'if 0'` is explicitly forbidden in help:
  
 Note: The executed string may be any command-line, but
 you cannot start or end a while, for or if
 command.  Thus this is illegal:
 :execute 'while i  5'
 :execute 'echo test | break'
 
 The docs are wrong, using if is allowed.  The other two are not.

Well, this script works just fine for me:

let i = 0
execute 'while i  10'
let i += 1
echo 1
endwhile

also this one works:

execute 'for i in range(10)'
echo i
endfor

Best regards,
Marcin Szamotulski

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

argisglobal patch

[Marcin Szamotulski]

Hello,

I wrote a small patch which adds argisglobal() function which returns
1 if the current buffer has global arglist otherwise, if there is
a local arg list it return 0.  I haven't found any other way to test if
the arglist is gobal/local.

I've been using this patch for some time already (I have a plugin
http://www.vim.org/scripts/script.php?script_id=4681 which is using it)
and it works fine.

Best regards,
Marcin Szamotulski

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

Re: argisglobal patch

[Marcin Szamotulski]

On 18:48 Mon 03 Feb , Marcin Szamotulski wrote:
 Hello,
 
 I wrote a small patch which adds argisglobal() function which returns
 1 if the current buffer has global arglist otherwise, if there is
 a local arg list it return 0.  I haven't found any other way to test if
 the arglist is gobal/local.
 
 I've been using this patch for some time already (I have a plugin
 http://www.vim.org/scripts/script.php?script_id=4681 which is using it)
 and it works fine.
 
 Best regards,
 Marcin Szamotulski

and here is the patch which I've forgotten to attach.

Best regards,
Marcin Szamotulski

-- 
-- 
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/groups/opt_out.
diff -r a83960ec9e6d -r c535a1c9985e src/eval.c
--- a/src/eval.c	Sun Sep 08 20:00:48 2013 +0200
+++ b/src/eval.c	Sat Sep 14 22:25:44 2013 +0100
@@ -459,6 +459,7 @@
 static void f_append __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_argc __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_argidx __ARGS((typval_T *argvars, typval_T *rettv));
+static void f_argisglobal __ARGS((typval_T *argvars, typval_T *rettv));
 static void f_argv __ARGS((typval_T *argvars, typval_T *rettv));
 #ifdef FEAT_FLOAT
 static void f_asin __ARGS((typval_T *argvars, typval_T *rettv));
@@ -7841,6 +7842,7 @@
 {append,		2, 2, f_append},
 {argc,		0, 0, f_argc},
 {argidx,		0, 0, f_argidx},
+{argisglobal,	0, 0, f_argisglobal},
 {argv,		0, 1, f_argv},
 #ifdef FEAT_FLOAT
 {asin,		1, 1, f_asin},	/* WJMc */
@@ -8814,6 +8816,20 @@
 }
 
 /*
+ * argisglobal() function
+ */
+static void
+f_argisglobal(argvars, rettv)
+typval_T	*argvars UNUSED;
+typval_T	*rettv;
+{
+if (curwin-w_alist == global_alist)
+	rettv-vval.v_number = 1;
+else
+	rettv-vval.v_number = 0;
+}
+
+/*
  * argv(nr) function
  */
 static void

search from command line

[Marcin Szamotulski]

Hello,

Is this supposed to work (note the : at the beginning):
:/pattern

This does not land on the pattern when matching on a longer line.
For example the previous line in this email has only one place that
matches \a\.  If I run :/\a\ when the cursor is on that line it will
not land where I would expect.  I don't know what is the pattern in this
bug but some times it lands where it should.

Best regards,
Marcin Szamotulski

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

Re: search from command line

[Marcin Szamotulski]

On 15:24 Sun 02 Feb , glts wrote:
 Hi,
 
 On Sun, Feb 2, 2014 at 2:46 PM, Marcin Szamotulski msza...@gmail.com wrote:
  Is this supposed to work (note the : at the beginning):
  :/pattern
 
  This does not land on the pattern when matching on a longer line.
  For example the previous line in this email has only one place that
  matches \a\.  If I run :/\a\ when the cursor is on that line it will
  not land where I would expect.  I don't know what is the pattern in this
  bug but some times it lands where it should.
 
 in
 
 :/pattern
 
 you are using /pattern as an Ex command range. It brings you to the next
 line that contains pattern, just like
 
 :45
 :'t
 
 bring you to line 45 and the line with mark t, respectively: :h 10.3.
 
 A suggestion: ask on vim_use about things that surprise you in Vim. It
 happens quite often that people post here with an alleged bug only to be
 told it's a feature.
 
 Best,
 
 
 
 -- 
 David

Yes, I use searches in range and this still is unexpected.  Actually if
vim would correctly set the column position this wouldn't be so
surprising and still it would work fine for command range.  What
I want to report is that :/pattern doesn't land on the right column - it
actually preserves the column.

Best regards,
Marcin

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

Re: search from command line

[Marcin Szamotulski]

On 22:34 Sun 02 Feb , glts wrote:
 On Sun, Feb 2, 2014 at 9:06 PM, Marcin Szamotulski msza...@gmail.com wrote:
  On 15:24 Sun 02 Feb , glts wrote:
  On Sun, Feb 2, 2014 at 2:46 PM, Marcin Szamotulski msza...@gmail.com 
  wrote:
   Is this supposed to work (note the : at the beginning):
   :/pattern
  
   This does not land on the pattern when matching on a longer line.
   For example the previous line in this email has only one place that
   matches \a\.  If I run :/\a\ when the cursor is on that line it will
   not land where I would expect.  I don't know what is the pattern in this
   bug but some times it lands where it should.
 
  in
 
  :/pattern
 
  you are using /pattern as an Ex command range. It brings you to the next
  line that contains pattern, just like
 
  :45
  :'t
 
  bring you to line 45 and the line with mark t, respectively: :h 10.3.
 
  A suggestion: ask on vim_use about things that surprise you in Vim. It
  happens quite often that people post here with an alleged bug only to be
  told it's a feature.
 
  Yes, I use searches in range and this still is unexpected.  Actually if
  vim would correctly set the column position this wouldn't be so
  surprising and still it would work fine for command range.  What
  I want to report is that :/pattern doesn't land on the right column - it
  actually preserves the column.
 
 Presumably this is because you have nostartofline set in your vimrc.
 When reporting a bug, it's best to first try to reproduce it with
 
 vim -Nu NONE
 
 But again, this is a discussion that is better suited for vim_use.
 
 Best,

I am aware of nostartofline and I did try vim -Nu NONE.  I just think
that regardless of this setting it would be nice if :/pattern without
a command would land on pattern, rather than just the line.

Best regards,
Marcin

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

Re: Patch to utilize undefined text-objects

[Marcin Szamotulski]

On 11:54 Fri 31 Jan , Daniel paradigm Thau wrote:
 On Thursday, January 30, 2014 9:07:19 PM UTC-5, Daniel paradigm Thau wrote:
  On Thursday, January 30, 2014 8:07:04 PM UTC-5, Marcin Szamotulski wrote:
   On 16:45 Wed 29 Jan , Daniel paradigm Thau wrote:
   
Apologies for the delay.
   

   
Review for those who have forgotten and/or don't care to backread:
   

   
This patch adds a new text object, m, which will take one more 
character as input.  That character will be used as bounds to the left 
and right for the object.  For example, cim$ will change between 
dollar signs.  This supports multi-line objects, so one could do cim' 
which, unlike ci', will search across lines; this way users have both.
   

   
I've been using it quite happily for the last two months or so, but 
more eyes and testing would not be a bad idea.
   

   
Attached is the patch, in both unified and context format, including a 
test.
   
   
   
   Hi,
   
   
   
   Thanks I'm really happy to see this patch.  I compiled it now and there
   
   is one thing that does not work: the . command.  For example di or ci
   
   can be repeated with . but dim, or cim, cannot.  
   
   
   
   Best regards,
   
   Marcin Szamotulski
  
  Good catch.  I can replicate that on my end.  Will fix.
 
 Should be fixed in the attachment.  As a bonus, it now supports things such 
 as digraphs.
 

Thanks that indeed works.

Regards,
Marcin

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

Re: Patch to utilize undefined text-objects

[Marcin Szamotulski]

On 16:45 Wed 29 Jan , Daniel paradigm Thau wrote:
 Apologies for the delay.
 
 Review for those who have forgotten and/or don't care to backread:
 
 This patch adds a new text object, m, which will take one more character as 
 input.  That character will be used as bounds to the left and right for the 
 object.  For example, cim$ will change between dollar signs.  This supports 
 multi-line objects, so one could do cim' which, unlike ci', will search 
 across lines; this way users have both.
 
 I've been using it quite happily for the last two months or so, but more eyes 
 and testing would not be a bad idea.
 
 Attached is the patch, in both unified and context format, including a test.

Hi,

Thanks I'm really happy to see this patch.  I compiled it now and there
is one thing that does not work: the . command.  For example di or ci
can be repeated with . but dim, or cim, cannot.  

Best regards,
Marcin Szamotulski

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

Re: Patch 7.4.109

[Marcin Szamotulski]

On 11:59 Fri 29 Nov , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  On 18:54 Thu 28 Nov , Bram Moolenaar wrote:
   
   Patch 7.4.109
   Problem:ColorScheme autocommand matches with the current buffer name.
   Solution:   Match with the colorscheme name. (Christian Brabandt)
   Files:runtime/doc/autocmd.txt, src/fileio.c, src/syntax.c
 
 [...]
 
  Hello,
  
  I am happy to see this patch.  I was hoping the following autocommand
  will work:
  
  au ColorScheme colorscheme_name :set bg=dark
  
  but unfortunately one has to set the background once again in order to
  visually see a change (when switching from light background colorscheme).
 
 The autocommand triggers *after* loading the colorscheme.  And usually
 you need to set the background before loading the colorscheme for it to
 take effect.  You can load the same colorscheme again, if you don't mind
 the flickering.

I don't mind flickering.  I have tried this autocommand:
au ColorScheme blue_sky :set bg=dark|colo blue_sky

and it was not working.  I had to run the :colorscheme command manually.

Best regards,
Marcin

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

Re: Patch 7.4.109

[Marcin Szamotulski]

On 18:54 Thu 28 Nov , Bram Moolenaar wrote:
 
 Patch 7.4.109
 Problem:ColorScheme autocommand matches with the current buffer name.
 Solution:   Match with the colorscheme name. (Christian Brabandt)
 Files:runtime/doc/autocmd.txt, src/fileio.c, src/syntax.c
 
 
 *** ../vim-7.4.108/runtime/doc/autocmd.txt2013-08-10 13:24:52.0 
 +0200
 --- runtime/doc/autocmd.txt   2013-11-28 18:44:20.0 +0100
 ***
 *** 480,485 
 --- 480,491 
   |cmdwin-char|
   *ColorScheme*
   ColorScheme After loading a color scheme. |:colorscheme|
 + The pattern is matched against the
 + colorscheme name. afile can be used for the
 + name of the actual file where this option was
 + set, and amatch for the new colorscheme
 + name.
 + 
   
   *CompleteDone*
   CompleteDoneAfter Insert mode completion is done.  
 Either
 *** ../vim-7.4.108/src/fileio.c   2013-11-12 18:09:20.0 +0100
 --- src/fileio.c  2013-11-28 18:44:20.0 +0100
 ***
 *** 9330,9336 
*/
   if (fname_io == NULL)
   {
 ! if (fname != NULL  *fname != NUL)
   autocmd_fname = fname;
   else if (buf != NULL)
   autocmd_fname = buf-b_ffname;
 --- 9330,9338 
*/
   if (fname_io == NULL)
   {
 ! if (event == EVENT_COLORSCHEME)
 ! autocmd_fname = NULL;
 ! else if (fname != NULL  *fname != NUL)
   autocmd_fname = fname;
   else if (buf != NULL)
   autocmd_fname = buf-b_ffname;
 ***
 *** 9383,9396 
   else
   {
   sfname = vim_strsave(fname);
 ! /* Don't try expanding FileType, Syntax, FuncUndefined, WindowID or
 !  * QuickFixCmd* */
   if (event == EVENT_FILETYPE
   || event == EVENT_SYNTAX
   || event == EVENT_FUNCUNDEFINED
   || event == EVENT_REMOTEREPLY
   || event == EVENT_SPELLFILEMISSING
   || event == EVENT_QUICKFIXCMDPRE
   || event == EVENT_QUICKFIXCMDPOST)
   fname = vim_strsave(fname);
   else
 --- 9385,9399 
   else
   {
   sfname = vim_strsave(fname);
 ! /* Don't try expanding FileType, Syntax, FuncUndefined, WindowID,
 !  * ColorScheme or QuickFixCmd* */
   if (event == EVENT_FILETYPE
   || event == EVENT_SYNTAX
   || event == EVENT_FUNCUNDEFINED
   || event == EVENT_REMOTEREPLY
   || event == EVENT_SPELLFILEMISSING
   || event == EVENT_QUICKFIXCMDPRE
 + || event == EVENT_COLORSCHEME
   || event == EVENT_QUICKFIXCMDPOST)
   fname = vim_strsave(fname);
   else
 *** ../vim-7.4.108/src/syntax.c   2013-06-08 16:10:08.0 +0200
 --- src/syntax.c  2013-11-28 18:44:20.0 +0100
 ***
 *** 7071,7077 
   retval = source_runtime(buf, FALSE);
   vim_free(buf);
   #ifdef FEAT_AUTOCMD
 ! apply_autocmds(EVENT_COLORSCHEME, NULL, NULL, FALSE, curbuf);
   #endif
   }
   recursive = FALSE;
 --- 7071,7077 
   retval = source_runtime(buf, FALSE);
   vim_free(buf);
   #ifdef FEAT_AUTOCMD
 ! apply_autocmds(EVENT_COLORSCHEME, name, curbuf-b_fname, FALSE, curbuf);
   #endif
   }
   recursive = FALSE;
 *** ../vim-7.4.108/src/version.c  2013-11-28 17:41:41.0 +0100
 --- src/version.c 2013-11-28 18:48:42.0 +0100
 ***
 *** 740,741 
 --- 740,743 
   {   /* Add new patch number below this line */
 + /**/
 + 109,
   /**/
 
 -- 
 How is your new girlfriend?
 90-60-90 man!
 What, pale purple?
 
  /// 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/groups/opt_out.

Hello,

I am happy to see this patch.  I was hoping the following autocommand
will work:

au ColorScheme colorscheme_name :set bg=dark

but unfortunately one has to set the background once again in order to
visually see a change (when switching from light 

Re: Vim 7.4: Vim script execution stops when Python raises vim.error

[Marcin Szamotulski]

On 09:10 Mon 11 Nov , Vlad Irnov wrote:
 On 11/4/13, ZyX zyx@gmail.com wrote:
  This means in Vim 7.4 Vim script stops after a Vim error occurs in
  Python code. This seems very wrong to me. Vim script writers are used
  to the fact that VimL code execution does not stop after an error
  unless there is a try/catch or when function has abort argument.
 
  Code that relies on this is broken. No matter how is some functionality used
  it *can* be put inside try/catch by the user*. I already got a few “nice” to
  debug bugs when was assuming `echoerr` is not breaking execution flaw (note:
  without any traces of python). Now they will be easier to fix: now when I
  see `echoerr` I say I must remove it.
 
  For echoing errors from python there is `sys.stderr`.
 
  Besides, any error shown to user indicates a bug.
 
  *:
 
  - Any command and function can be naturally put inside :try/catch in a
  script.
  - Any mapping can be called with :normal that can be put inside :try/catch.
  - Any autocommand can be called either directly with :doau inside :try/catch
  or by putting commands that invoke autocommand inside :try/catch (i.e. :e
  for BufRead*).
 
  There is no way write code that will never stop execution on error without
  using :silent! or :try/catch catching the error on your own. Hence any error
  must be considered to break execution. Any code that considers error not
  breaking execution is broken.
 
 All this is true in theory. In practice, nobody ever puts the entire
 Vim script plugin inside try/finally/endtry. The simplest case:
 
 let s:keepcpo= cpo
 set cpovim
 echo 1
 let a = bogus
 echo 2
 python a = bogus
 echo 3
 python vim.command(let a=bogus)
  execution stops here
 echo 4
 let cpo= s:keepcpo
 unlet s:keepcpo
 
 When such script is sourced, execution does not stop after a Vim
 script error or a regular Python error. Why should it stop after a
 Python vim.error error? This is an inconsistent behavior of Vim error
 handling that is bound to cause confusion.
 
 Regards,
 Vlad

Just throwing an idea.  Maybe:
vim.command(echoerr 'py-vim-Error')
should raise a Python exception?

Best regards,
Marcin

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

Re: Vim 7.4: Vim script execution stops when Python raises vim.error

[Marcin Szamotulski]

On 18:50 Mon 11 Nov , Nikolay Pavlov wrote:
 On Nov 11, 2013 6:38 PM, Marcin Szamotulski msza...@gmail.com wrote:
 
  On 09:10 Mon 11 Nov , Vlad Irnov wrote:
   On 11/4/13, ZyX zyx@gmail.com wrote:
This means in Vim 7.4 Vim script stops after a Vim error occurs in
Python code. This seems very wrong to me. Vim script writers are used
to the fact that VimL code execution does not stop after an error
unless there is a try/catch or when function has abort argument.
   
Code that relies on this is broken. No matter how is some
 functionality used
it *can* be put inside try/catch by the user*. I already got a few
 “nice” to
debug bugs when was assuming `echoerr` is not breaking execution flaw
 (note:
without any traces of python). Now they will be easier to fix: now
 when I
see `echoerr` I say I must remove it.
   
For echoing errors from python there is `sys.stderr`.
   
Besides, any error shown to user indicates a bug.
   
*:
   
- Any command and function can be naturally put inside :try/catch in a
script.
- Any mapping can be called with :normal that can be put inside
 :try/catch.
- Any autocommand can be called either directly with :doau inside
 :try/catch
or by putting commands that invoke autocommand inside :try/catch
 (i.e. :e
for BufRead*).
   
There is no way write code that will never stop execution on error
 without
using :silent! or :try/catch catching the error on your own. Hence
 any error
must be considered to break execution. Any code that considers error
 not
breaking execution is broken.
  
   All this is true in theory. In practice, nobody ever puts the entire
   Vim script plugin inside try/finally/endtry. The simplest case:
  
   let s:keepcpo= cpo
   set cpovim
   echo 1
   let a = bogus
   echo 2
   python a = bogus
   echo 3
   python vim.command(let a=bogus)
execution stops here
   echo 4
   let cpo= s:keepcpo
   unlet s:keepcpo
  
   When such script is sourced, execution does not stop after a Vim
   script error or a regular Python error. Why should it stop after a
   Python vim.error error? This is an inconsistent behavior of Vim error
   handling that is bound to cause confusion.
  
   Regards,
   Vlad
 
  Just throwing an idea.  Maybe:
  vim.command(echoerr 'py-vim-Error')
  should raise a Python exception?
 
 It does raise exception.
 

Great, for me this is the expected behaviour.  Then indeed the op can
use try/except to catch it.  I presume op wants to:

try:
vim.command(source some_script.vim)
except vim.error as err:
print(err)

Best regards,
Marcin

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

Re: [PATCH] Asynchronous functions (settimeout, setinterval, and cancelinterval)

[Marcin Szamotulski]

On 05:06 Mon 14 Oct , Ben Fritz wrote:
 On Monday, October 14, 2013 5:59:48 AM UTC-5, Michael Henry wrote:
  All,
  
  
  
  I've been wondering about the use of CTRL-C regarding timers.
  
  There has been a lot of discussion on ways to regain control in
  
  the face of a runaway timer, which is of course an important
  
  consideration.  I've been wondering, however, about any negative
  
  effects of accidental cancellation.  If I understand correctly, when
  
  a user presses CTRL-C while a timer happens to be running, that
  
  timer will be canceled and not rescheduled.  Can this happen
  
  accidentally when the user is pressing CTRL-C for other reasons
  
  (e.g., to abandon an ex-mode command he was typing)?  Since
  
  timers might be running at arbitrary times, how can a user be
  
  sure it's safe to press CTRL-C without running the risk of canceling
  
  a timer by mistake?  Should it require multiple CTRL-C presses in
  
  a row before aborting current and future timers, or is there some
  
  other way to make sure the user won't accidentally cancel timers
  
  that are operating properly?
  
  
 
 I think this is a valid concern.
 
 I'm not exactly sure how this works now, I remember discussion about a list 
 of canceled timers. Perhaps a single invocation could be canceled allowing 
 this list to be displayed, then a second CTRL-C would be required (with the 
 list displayed) to actually cancel all future invocations as well.

And what about i^c (c-c in the insert mode).  Will it cancel timers or go
to normal mode?

Best regards,
Marcin

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

Re: [patch] colorscheme autocommand should match against the colorscheme name

[Marcin Szamotulski]

On 23:00 Wed 25 Sep , Christian Brabandt wrote:
 Bram,
 
 currently, the colorscheme autocommand matches the pattern against the 
 buffer name. I think, it would be more useful, to have the pattern match 
 against the actual colorscheme name. So here is a patch, that changes 
 it.
 
 regards,
 Christian

I like this patch since I was once hit by not having it.

Thanks!
Marcin

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

check local arglist

[Marcin Szamotulski]

Dear vim dev,

I found that there is no way of checking weather :args returns local or
global arglist.  I am actually missing such a functionality.  If I am
wrong let me know. 

Best regards,
Marcin

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

Re: jump function

[Marcin Szamotulski]

On 20:44 Thu 29 Aug , glts wrote:
 Hi Marcin,
 
 On Thu, Aug 29, 2013 at 8:10 PM, Marcin Szamotulski msza...@gmail.com wrote:
  Recently I tried to make a user function for jumping through the jump
  list (by files), but it happens that there is no good interface for
  that.  For example CTRL-I could possibly be only with :normal! c-i but
  this does not work (even in vim -U NONE in the terminal, I have not
  tested this in the GUI though) and also using CTRL-V will not work since
  CTRL-V_CTRL-I produces a tab (this works with CTRL-O thought).
  I present here a very simple patch which introduce a vim function
  jump({count}).  :call jump(-5) will jump back in the jump list by
  5 positions and :call jump(5) will jump forward five positions.
 
 cheers. But for what it's worth, I don't see a big advantage in
 
 :call jump(-3)
 :call jump(1)
 
 over
 
 :norm! 3^O
 :norm! 1^I
 
 or
 
 :exe norm! 3\C-O
 :exe norm! 1\C-I
 
 Just one more function to add to the list.

That's interesting, but apparently:

nm \c-i :exe norm! \C-Icr
ends with error E471: Argument reuired, exactly the same as:
:normal! ^I

Though as I have mentioned earlier there is no problem with ^O.  I use
vim, but this also does not work in gvim (on GNU/Linux).  I also tested
this with vim -U NONE, and it does not work.  Having a simple reliable
solution would be good, that's why I wrote the small patch.  Is it
possible to fix :normal when \C-I get expanded to a tab character?
I don't think so, but I am not a vim-guru ...

Cheers,
Marcin

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

Re: jump function

[Marcin Szamotulski]

On 16:44 Thu 29 Aug , glts wrote:
 On Friday, August 30, 2013 1:31:16 AM UTC+2, Marcin Szamotulski wrote:
  That's interesting, but apparently:
  
  nm \c-i :exe norm! \C-Icr
  ends with error E471: Argument reuired, exactly the same as:
  :normal! ^I
  
  Though as I have mentioned earlier there is no problem with ^O.  I use
  vim, but this also does not work in gvim (on GNU/Linux).  I also tested
  this with vim -U NONE, and it does not work.  Having a simple reliable
  solution would be good, that's why I wrote the small patch.  Is it
  possible to fix :normal when \C-I get expanded to a tab character?
  I don't think so, but I am not a vim-guru ...
 
 :normal! apparently gobbles whitespace, that is, spaces and tabs. The
 obvious work-around is to use a count of 1, as in my example.
 
 Best,
 

I see, that's tricky.

Best,
Marcin

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

Re: Crash with regexp

[Marcin Szamotulski]

On 06:28 Mon 29 Jul , Marcin Szamotulski wrote:
 On 22:07 Sun 28 Jul , Bram Moolenaar wrote:
  
  Marcin Szamotulski wrote:
  
   Vim crashes with the following pattern:
   
   \%(\%(\|\d\|-\|\.\)*\|\*\)
   
   And it does not crash with
   
   \%(\%(\d\|-\|\.\)*\|\*\)
   
   It is part of a pattern that matches package (the part matches the
   version number) inside: 
   
   sys-kernel/gentoo-sources-3.6.11
   
   I am not sure why I put \(\| inside the pattern, but vim (with -u
   NONE) crashes when searching for that pattern in a file which contains
   the above example.
  
  I can easily reproduce it, unfortunately.
  
  -- 
  How To Keep A Healthy Level Of Insanity:
  17. When the money comes out the ATM, scream I won!, I won! 3rd
  time this week!
  
   /// 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///
 
 This is a simpler pattern that crashes vim:
 
 \%(\%(\|a\)*\)
 
 but 
 
 \(\(\|a\)*\)
 
 works fine.  Also 
 
 \%(\(\|a\)*\) 
 
 works fine but
 
 \(\%(\|a\)*\)
 
 crashes.  So there is some problem with the inner \%(\) group.
 
 Best regards,
 Marcin

Today a user of my plugin reported that vim crashes and this is due to
a similar problem.  Now vim crashes with this pattern:

{\%([^{}]*\|{\%([^{}]\)*}\)*}

but changing only the outer \%(...\) to \(...\) fixes the problem.  This
pattern matches what is inside {...} but also will match {  {} },
i.e when another {...} is embedded.

Bets regards,
Marcin

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

Re: Crash with regexp

[Marcin Szamotulski]

On 16:27 Thu 01 Aug , Bram Moolenaar wrote:
 
 Marcin Szamotulski wrote:
 
  On 06:28 Mon 29 Jul , Marcin Szamotulski wrote:
   On 22:07 Sun 28 Jul , Bram Moolenaar wrote:

Marcin Szamotulski wrote:

 Vim crashes with the following pattern:
 
 \%(\%(\|\d\|-\|\.\)*\|\*\)
 
 And it does not crash with
 
 \%(\%(\d\|-\|\.\)*\|\*\)
 
 It is part of a pattern that matches package (the part matches the
 version number) inside: 
 
 sys-kernel/gentoo-sources-3.6.11
 
 I am not sure why I put \(\| inside the pattern, but vim (with -u
 NONE) crashes when searching for that pattern in a file which contains
 the above example.

I can easily reproduce it, unfortunately.

-- 
How To Keep A Healthy Level Of Insanity:
17. When the money comes out the ATM, scream I won!, I won! 3rd
time this week!

 /// 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
///
   
   This is a simpler pattern that crashes vim:
   
   \%(\%(\|a\)*\)
   
   but 
   
   \(\(\|a\)*\)
   
   works fine.  Also 
   
   \%(\(\|a\)*\) 
   
   works fine but
   
   \(\%(\|a\)*\)
   
   crashes.  So there is some problem with the inner \%(\) group.
   
   Best regards,
   Marcin
  
  Today a user of my plugin reported that vim crashes and this is due to
  a similar problem.  Now vim crashes with this pattern:
  
  {\%([^{}]*\|{\%([^{}]\)*}\)*}
  
  but changing only the outer \%(...\) to \(...\) fixes the problem.  This
  pattern matches what is inside {...} but also will match {  {} },
  i.e when another {...} is embedded.
 
 Patch 7.4b.002 changes these kind of things.  I could also make it crash
 with \%(\)*.
 
 There was another problem that went unnoticed that only happened for
 \(\) after the fix and there was only a test for \%(\).  So hopefully
 all similar cases are solved now.
 
 -- 
 hundred-and-one symptoms of being an internet addict:
 36. You miss more than five meals a week downloading the latest games from
 Apogee.
 
  /// 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///


Thanks, indeed it fixed the issues.

Best regards,
Marcin

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