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. (Ma
or (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 func
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
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 o
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&#x
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
> > &g
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
> &g
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"
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
>
> > >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
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/ev
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
> 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 t
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
> > > specifi
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
> > 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
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
>
> ---
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
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 definin
ent#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
implem
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 fo
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
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=*
> >
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 a
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
> -> ev
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
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)
> &
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 t
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 wante
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 pr
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 ;-
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
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
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
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
---
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 ple
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
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 r
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
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:
>
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
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 fr
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
> rep
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.
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
>
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
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:
> > > >
> > > >
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
> > manpagevie
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.
> > >
> > > Err
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"
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 reply
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
> :/fo
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
> >>
>
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, e
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
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\Pedr
s
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 thi
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 la
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 th
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
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
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
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 l
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.117
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 fr
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`.
>
>
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
> > > &
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:
lin
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 "vi
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.
> >
> > Th
forward five positions.
Any comments are welcome,
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 th
On 20:44 Thu 29 Aug , glts wrote:
> Hi Marcin,
>
> On Thu, Aug 29, 2013 at 8:10 PM, Marcin Szamotulski wrote:
> > Recently I tried to make a user function for jumping through the jump
> > list (by files), but it happens that there is no good interface for
> > that
On 16:44 Thu 29 Aug , glts wrote:
> On Friday, August 30, 2013 1:31:16 AM UTC+2, Marcin Szamotulski wrote:
> > That's interesting, but apparently:
> >
> > nm \ :exe "norm! \"
> > ends with error E471: Argument reuired, exactly the same as:
> >
Dear vim dev,
I found that there is no way of checking weather :args returns local or
global arglist. I am actually missing such a functionality. If I am
wrong let me know.
Best regards,
Marcin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply bel
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.
>
> re
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 r
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
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
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
>
>
> *** ../v
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.
> &g
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 N
piled 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 re
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
re 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 mor
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
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
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 mor
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
us 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
e
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 curre
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.
> > > >
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.
Dear Vim Devs,
If one sets:
set pastetoggle=\p
inoremap #p \pi
Then typing #p in insert mode results in i, the \p is consumed by
pastetoggle. Since pastetoggle help sais that it essentially works like
a map it would be nice if it could respect noremap.
Best regards,
Marcin
--
--
You receiv
Dear Vim_Dev,
If one is in the directory of the current file '%:h:h' expands to '.',
while it should expand tas '%:p:h:h' does. This is probably is not very
useful case since using '../' is much simpler, though it might be used
in a plugin (I've never been hit by this though). Expansion of '%:h:
t; Christian Brabandt wrote:
> >>>
> >>>> On Sa, 23 Mär 2013, Marcin Szamotulski wrote:
> >>>>
> >>>>> Dear Vim_Dev,
> >>>>>
> >>>>> If one is in the directory of the current file '%:h:h' expands t
Dear Devs,
I've found a problem with the search() function. Put a line like the
one below
(X
as a last line which contains a (. Then place the cursor over X and run:
:call search('(', 'cW')
Here the cursor lands on (. It seems that with the 'c' switch the
search begins where the line
t
have an idea how to do that in VimL since there is no autocommand and
there is no way of user over writting vim commands.
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 re
On 21:00 Sun 26 May , Christian Brabandt wrote:
> Hi Marcin!
>
> On Sa, 25 Mai 2013, Marcin Szamotulski wrote:
>
> > I have a proposition for a small but nice feature. Whenever I do
> > diff & then diffo (or diffo!) some settings are lost, for example the
>
The
patch was written by Dominique Pellé.
Both are attached.
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
On 09:40 Wed 05 Jun , Ingo Karkat wrote:
> On 05-Jun-2013 09:10 +0200, Christian Brabandt wrote:
>
> > On Wed, June 5, 2013 08:56, Ingo Karkat wrote:
> >> On 05-Jun-2013 08:03 +0200, Christian Brabandt wrote:
> >>
> >>> [...] the old engine has an long standing bug with \%V ;(
> >>>
> >>> e.g:
1 - 100 of 198 matches
Mail list logo
