Haskell and cabal syntax files
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
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
‐‐‐ 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
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
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)
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
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, '&buftype'))
> + exe 'sbuf ' . bnr
> + call assert_equal('terminal', &buftype)
> + 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.
Re: Haskell syntax file
On 12:31 Fri 30 Mar , Bram Moolenaar wrote: > > Marcin Szamotulski wrote: > > > 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. > > Thanks, I'll include it. Thank you. 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: PGP signature
Haskell syntax file
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
" Last Change: 2017 Dec 16
" Original Author: John Williams
"
" 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-
no matching autocommands for acwrite buffer
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()
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
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
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
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
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
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
support module names in location lists
Hello vim_dev :) I wrote a patch to support module names in quickfix list. In various languages (Python, JavaScript, Haskell, PureScript) and many others module names are easier to recognize than file names - which often become tediously long (especially with 'autochdir` setting. The PR is at github: https://github.com/vim/vim/pull/1757 I wonder what's the feedback. I will write some tests if there is a chance to include it. 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: make g< more robust
On Mon, 13 Mar, 2017 at 9:29 PM, Bram Moolenaar 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
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
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!
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 vim_dev+unsubscr...@googlegroups.com. > For more opt
Re: Patch 7.4.2231
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
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
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
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
Re: Channel & job design
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 w
Re: Lua 5.3 detection on Windows using Vim 7.4.691
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
Re: ls with flags
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
ls with flags
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: BUG: /foo/,/bar/argdo proceeds after E14: Invalid address
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
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)
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
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
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: Vim 7.4.579: wincmd range problem with manpageview plugin
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: 0wincmd gives E16: Invalid range: 0wincmd w
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
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\+" > > 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
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
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
characters. If the String ends in a , 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)
+ {
+
Re: Patch 7.4.530
On 14:19 Tue 23 Dec , Marcin Szamotulski wrote: > 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 Dear Bram, I attach patch + a test for this case. 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 */ diff --git a/src/testdir/test_command_count.in b/src/testdir/test_command_count.in index cca178e..c71ae5a 100644 --- a/src/testdir/test_command_count.in +++ b/src/testdir/test_command_count.in @@ -3,7 +3,7 @@ Test for user command counts vim: set ft=vim : STARTTEST :let g:lines = [] :so tiny.vim -:com -range RangeLines :call add(g:lines, 'Rangeg:Lines '..' '.) +:com -range=% RangeLines :call add(g:lines, 'RangeLines '..' '.) :com -range -addr=arguments RangeArguments :call add(g:lines, 'RangeArguments '..' '.) :com -range=% -addr=arguments RangeArgumentsAll :call add(g:lines, 'RangeArgumentsAll '..' '.) :com -range -addr=loaded_buffers RangeLoadedBuffers :call add(g:lines, 'RangeLoadedBuffers '..' '.) @@ -42,6 +42,12 @@ STARTTEST :%RangeTabs :RangeTabsAll :1tabonly +:s/\n/\r\r\r\r\r/ +:2ma< +:$-ma> +:'<,'>RangeLines +:com -range=% -buffer LocalRangeLines :call add(g:lines, 'LocalRangeLines '..' '.) +:'<,'>LocalRangeLines :e! test.out :call append(0, g:lines) :w|qa! diff --git a/src/testdir/test_command_count.ok b/src/testdir/test_command_count.ok index 11e88b3..693a22d 100644 --- a/src/testdir/test_command_count.ok +++ b/src/testdir/test_command_count.ok @@ -14,4 +14,6 @@ RangeBuffersAll 1 5 RangeTabs 2 5 RangeTabs 1 5 RangeTabsAll 1 5 +RangeLines 2 5 +LocalRangeLines 2 5 signature.asc Description: Digital signature
Re: Patch 7.4.530
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
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: check if range is invalid
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_WINDO
Re: Patch 7.4.530
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, &qu
Re: check if range is invalid
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
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
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
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
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.530
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_
Re: Patch 7.4.530
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.5
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.5
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
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.530
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(, ) > > > > > > > > > > > > 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 .' '. > > which is the same as: > > com -addr=lines RangeLines :echo .' '. > > com -addr=arguments RangeArguments :echo .' '. > > com -addr=loaded_buffers RangeLoadedBuffers :echo .' '. > > com -addr=buffers RangeBuffers :echo .' '. > > com -addr=windows RangeWindows :echo .' '. > > com -addr=tabs RangeTabs :echo .' '. > > > > 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(CM
Re: Patch 7.4.530
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(, ) > > > > > > 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 .' '. which is the same as: com -addr=lines RangeLines :echo .' '. com -addr=arguments RangeArguments :echo .' '. com -addr=loaded_buffers RangeLoadedBuffers :echo .' '. com -addr=buffers RangeBuffers :echo .' '. com -addr=windows RangeWindows :echo .' '. com -addr=tabs RangeTabs :echo .' '. 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 whe
Re: Patch 7.4.530
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(, ) > > > 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
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 ." ". 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
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
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(, , )
> >
> > 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 **co
Re: Patch 7.4.530
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(, , ) > > 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
On 22:14 Fri 28 Nov , Bram Moolenaar wrote:
>
> Itchyny wrote:
>
> > Bram, the is always 1 (probably after this patch).
> >
> > :command! Test echo
> >
> > 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: >
+ :.+,$bwipeout " wipe 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,
Re: Patch 7.4.530
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 wrote: > > > Bram, the is always 1 (probably after this patch). > > > > > > :command! Test echo > > > > > > 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 > > > > /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(, , 'G', "", ) and by default and 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
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(, ) > > > 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
On 08:55 Fri 28 Nov , Marius Gedminas wrote:
> On Thu, Nov 27, 2014 at 09:55:36PM +0000, 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: >
+ :.+,$bwipeout " wipe 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
On 15:33 Fri 28 Nov , LCD 47 wrote: > On 28 November 2014, itchyny wrote: > > Bram, the is always 1 (probably after this patch). > > > > :command! Test echo > > > > 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 > > /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
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: >
+ :.+,$bwipeout " wipe out all buffers after the current
+" one
+ :%bwipeout " wipe out all buffers
+<
:[N]bun[load][!]*:bun* *:
Re: [Bulk] [Bulk] Add count to :close and :hide commands
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
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
> 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
Re: gettabvar(1, '') doesn't return dict of variables
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
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
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
Re: add +cmd argument to :buffer command
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] *:sb
add +cmd argument to :buffer command
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 count to :close and :hide commands
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
Re: Add count to :close and :hide commands
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 @@
test
Add count to :close and :hide commands
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
Re: usearglist patch
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, &qu
Re: usearglist patch
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
usearglist patch
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: Patch 7.4.312
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
Re: Patch 7.4.312
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.txt 2014-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.txt2014-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.c2014-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;
> + longn;
> +
> + 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
Re: argisglobal patch
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: argisglobal patch
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 *argv
Re: [BUG] “:execute 'if 1'” works like “:if 1”
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.
Re: argisglobal patch
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
argisglobal patch
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: search from command line
On 22:34 Sun 02 Feb , glts wrote: > On Sun, Feb 2, 2014 at 9:06 PM, Marcin Szamotulski wrote: > > On 15:24 Sun 02 Feb , glts wrote: > >> On Sun, Feb 2, 2014 at 2:46 PM, Marcin Szamotulski > >> 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 \. If I run :/\ 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: search from command line
On 15:24 Sun 02 Feb , glts wrote: > Hi, > > On Sun, Feb 2, 2014 at 2:46 PM, Marcin Szamotulski 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 \. If I run :/\ 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.
search from command line
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 \. If I run :/\ 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: Patch to utilize undefined text-objects
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
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
On 23:25 Fri 29 Nov , Nikolay Pavlov wrote: > On Nov 29, 2013 11:14 PM, "Marcin Szamotulski" wrote: > > > > 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. > > Can you try forgetting about ColorScheme and using > > autocmd SourcePre */colors/blue_sky.vim :set background=dark > ? > Thanks! That works like charm. 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
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
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. can be used for the
> + name of the actual file where this option was
> + set, and 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 b
Re: Vim 7.4: Vim script execution stops when Python raises vim.error
On 18:50 Mon 11 Nov , Nikolay Pavlov wrote:
> On Nov 11, 2013 6:38 PM, "Marcin Szamotulski" wrote:
> >
> > On 09:10 Mon 11 Nov , Vlad Irnov wrote:
> > > On 11/4/13, ZyX 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 cpo&vim
> > > 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: Vim 7.4: Vim script execution stops when Python raises vim.error
On 09:10 Mon 11 Nov , Vlad Irnov wrote:
> On 11/4/13, ZyX 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 cpo&vim
> 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: [PATCH] Asynchronous functions (settimeout, setinterval, and cancelinterval)
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 ( 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
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.
