Marcin Szamotulski wrote:
> 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
> > reprod
Marcin Szamotulski wrote:
> 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
> > reprod
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
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
hi!
thanks Marcin, it now works perfectly :)
--
--
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 t
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
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
--
--
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,
Marcin Szamotulski wrote:
> 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 a
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 inc
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 ra
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
> 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.
Hi! sorry, didn't have the time to check the flags myself. anyway, thanks for
the support, let's hope someone with a mac will fix it :)
--
--
You received this messa
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
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
> 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.
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
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 --noplug
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
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 s
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
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)
> > >
> >
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
> >
> >
Daniel Hahler wrote:
> Thanks for the patch, I have found some typos and grammar issues with it,
> and commented them inline.
Thanks, I'll include the suggested changes.
--
"Lisp has all the visual appeal of oatmeal with nail clippings thrown in."
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
Thanks for the patch, I have found some typos and grammar issues with it,
and commented them inline.
Bram Moolenaar wrote:
> ***
> *** 608,614
> {not in Vi}
>
> :[count]arga[dd] {name} .. *:arga* *:argadd* *E479*
> !
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 ca
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
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
- s
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://oi6
> 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 report
Marcin Szamotulski wrote:
> 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=*
> > > \ -c
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
> > \
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
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 w
As promised I did some other tests. First I can say the new patch fixed the
error I could reproduce with my example. It also fixed EasyAlign, BUT
CoffeeCompile is still giving the same error (Invalid Address)
Anyway, here' a screenshot I took before updating vim:
http://oi61.tinypic.com/2cr7plw.
On Sunday, November 30, 2014 1:38:09 AM UTC+9, Marcin Szamotulski wrote:
> 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.
> >
>
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
> My guess is that the
> implementation of `tcomment#Comment` must have change or before it was
> defined with `-range=1`.
The implementation of `tcomment#Comment` has changed but it still works
perfectly well with 7.3-460.
`-range=1` wasn't used.
--
--
You received this message from the "vim
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
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 13:15 Fri 28 Nov , Bram Moolenaar wrote:
>
> Marcin Szamotulski wrote:
>
> > > Ken Takata wrote:
> > >
> > > > 2014/11/28 Fri 0:23:27 UTC+9 Bram Moolenaar wrote:
> > > > > Patch 7.4.530
> > > > > P
On 08:55 Fri 28 Nov , Marius Gedminas wrote:
> On Thu, Nov 27, 2014 at 09:55:36PM +, Marcin Szamotulski wrote:
> > I found that `:.,$-bdelete` will trigger a segfault. The attached patch
> > fixes that, and in addition it makes `:%bdelete` and `:%bwipeout`
> > work as well.
>
> > diff --g
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
No idea... Monday I'll try it again and I'll post full version output. I'll
try Marcin patch too.
Il giorno ven 28 nov 2014 alle 22:14 Bram Moolenaar
b...@moolenaar.net> ha scritto:
> Matteo Cavalleri wrote:
>
> > > This patch made a big change in how ranges are handled, thus it's
> > > possibl
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
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?
--
How come wrong numbers are never busy?
/// Bram Moolenaar -- b...@mo
I run vim with "--noplugin -u NONE -N" which, if I remember correctly,
should put it in nocompatible mode. I don't know if it makes any difference.
Anyway I'll check the patch, but unfortunately I won't be able to do that
before Monday.
Thanks for the help!
Il giorno ven 28 nov 2014 alle 19:32 Ma
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 "
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:
:comman
> 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
endfun
Bram, the is always 1 (probably after this patch).
:command! Test echo
try :Test and it always echoes 1.
--
--
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
Matteo Cavalleri wrote:
> did this patch change vim behavior with ranges somehow? I'm using vim
> compiled from source with all the patches, and recently the EasyAlign
> plugin has stopped working. Whatever I do it just moves the cursor on
> the first line / first column of the buffer. Moreover i
Marcin Szamotulski 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
> > > > number
did this patch change vim behavior with ranges somehow? I'm using vim compiled
from source with all the patches, and recently the EasyAlign plugin has stopped
working. Whatever I do it just moves the cursor on the first line / first
column of the buffer. Moreover if I select a range of text and
On Thu, Nov 27, 2014 at 09:55:36PM +, Marcin Szamotulski wrote:
> I found that `:.,$-bdelete` will trigger a segfault. The attached patch
> fixes that, and in addition it makes `:%bdelete` and `:%bwipeout`
> work as well.
> diff --git a/runtime/doc/windows.txt b/runtime/doc/windows.txt
> inde
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.
>
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
> >
Hi,
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 argumen
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.
59 matches
Mail list logo
