Ben Schmidt, 17.11.2008:
>
> >> Anyway, all this makes me wonder if we really should be basing the Git
> >> repo on the SVN repo since not even Edward is satisfied with it. I've
> >> been thinking if it wouldn't be simpler to just apply the patches Bram
> >> posts myself. Did you consider this
Ben Schmidt wrote:
> I gave up on SVN ages ago--I would have loved to use it, but
> it's just too messy. Now I apply patches. Below is the script
Eventually I'd like to have a tip (http://vim.wikia.com/) on building Vim, with
probably one overview article, and separate articles for downloading,
Ben Schmidt wrote:
>>> Anyway, all this makes me wonder if we really should be basing the Git
>>> repo on the SVN repo since not even Edward is satisfied with it. I've
>>> been thinking if it wouldn't be simpler to just apply the patches Bram
>>> posts myself. Did you consider this option Markus
>> Anyway, all this makes me wonder if we really should be basing the Git
>> repo on the SVN repo since not even Edward is satisfied with it. I've
>> been thinking if it wouldn't be simpler to just apply the patches Bram
>> posts myself. Did you consider this option Markus?
>
> Not really until
Hello!
When folding is on (foldmethod=syntax, syntax-perl) current
indent script advises this style:
-- test.pl -
sub aa() {
my $a;
if (aaa) {
if (bbb) {
ccc
}
return 1;
}
}
On Sunday 16 November 2008 2:34 pm, Markus Heidelberg wrote:
>
> sc, 15.11.2008:
> >
> > I finally bit the bullet and applied Markus Heidelberg's relative number
> > patch to my source -- I love it so much I added
>
> Nice to hear.
>
> With subversion you don't have to reapply the patch. When
sc, 15.11.2008:
>
> I finally bit the bullet and applied Markus Heidelberg's relative number
> patch to my source -- I love it so much I added
Nice to hear.
> In the meantime I would like to know if there's a slick way to check svn
> updates and runtime rsyncs against the list of 22 files the
björn, 16.11.2008:
>
> 2008/11/16 Edward L. Fox <[EMAIL PROTECTED]>:
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> You fetch from the trunk branch, right? What kind of conflicts did arise? I
> >> suspect mostly from the runtime files!?
> >
> > Any conflicts are possible. I'm not feeling surprised to
Edward L. Fox, 16.11.2008:
> On Sun, Nov 16, 2008 at 17:56, Markus Heidelberg
> <[EMAIL PROTECTED]> wrote:
> > björn, 15.11.2008:
> > [...]
> >
> > Avoiding these conflicts is more important than having nice commit logs. But
> > there should be a way to get both. Edward, do you know why the trunk
Dominique Pelle wrote:
> > This makes sense. It actually mentions that -D_FORTIFY_SOURCE=2 may
> > break confirming programs. This also means it should never be the
> > default. So perhaps you can file a bug that the default should be to
> > use 1.
> >
> > The argument is only needed for GCC
2008/11/16 Bram Moolenaar <[EMAIL PROTECTED]>:
> Dominique Pelle wrote:
>
>> 2008/11/16 Dominique Pelle <[EMAIL PROTECTED]>:
>>
>> > 2008/11/16 Bram Moolenaar <[EMAIL PROTECTED]>:
>> >
>> >> Apparently -fstack-protector is on by default. The "inline-functions"
>> >> apparently does something to
2008/11/16 Edward L. Fox <[EMAIL PROTECTED]>:
> <[EMAIL PROTECTED]> wrote:
>>
>> You fetch from the trunk branch, right? What kind of conflicts did arise? I
>> suspect mostly from the runtime files!?
>
> Any conflicts are possible. I'm not feeling surprised to that.
> Because there's no much rela
Dominique Pelle wrote:
> 2008/11/16 Dominique Pelle <[EMAIL PROTECTED]>:
>
> > 2008/11/16 Bram Moolenaar <[EMAIL PROTECTED]>:
> >
> >> Apparently -fstack-protector is on by default. The "inline-functions"
> >> apparently does something to reveal the size of the destination to
> >> strcpy(). T
On Sun, Nov 16, 2008 at 17:56, Markus Heidelberg
<[EMAIL PROTECTED]> wrote:
> björn, 15.11.2008:
> [...]
>
> Avoiding these conflicts is more important than having nice commit logs. But
> there should be a way to get both. Edward, do you know why the trunk branch
> doesn't have nice commit logs and
2008/11/16 Dominique Pelle <[EMAIL PROTECTED]>:
> 2008/11/16 Bram Moolenaar <[EMAIL PROTECTED]>:
>
>> Apparently -fstack-protector is on by default. The "inline-functions"
>> apparently does something to reveal the size of the destination to
>> strcpy(). That's a bit unexpected though.
>>
>> Wh
2008/11/16 Bram Moolenaar <[EMAIL PROTECTED]>:
> Apparently -fstack-protector is on by default. The "inline-functions"
> apparently does something to reveal the size of the destination to
> strcpy(). That's a bit unexpected though.
>
> Why not compile Vim with -fno-stack-protector ? Can you tr
Tony Mechelynck wrote:
> On 15/11/08 16:18, Bram Moolenaar wrote:
> >
> > Dominique Pelle wrote:
> >
> >> Using latest vim-7.2.40 from CVS, I notice that 'make test' fails on
> >> test42.
> >>
> >> Looking at previous versions, I see that:
> >>
> >> - vim-7.2.33 fails test42
> >> - vm-7.2.32 su
Dominique Pelle wrote:
> 2008/11/15 Tony Mechelynck <[EMAIL PROTECTED]>:
>
> > On 15/11/08 11:12, Dominique Pelle wrote:
> >> Hi
> >>
> >> I notice that Vim-7.2.40 (huge) crashes on start up when I
> >> compile it with gcc 4.3.2 with -O3 (that's the default gcc
> >> version from Ubuntu-8.10), b
björn, 15.11.2008:
>
> 2008/11/15 Markus Heidelberg <[EMAIL PROTECTED]>:
> >
> > björn, 15.11.2008:
> >>
> >> Anyway, I still haven't seen any reasons to switch to vim_extended yet
> >> (so far, nothing makes _my_ life simpler).
> >
> > If you don't want to use any of the features included in vim
19 matches
Mail list logo
