Remove empty Mercurial tag commits?

[Marius Gedminas]

The current Git conversion has a lot of empty commits like

  https://github.com/vim/vim/commit/e675d947a7ec993176262a888bfde5702427056d

Are they of any use to anyone?  Can they be stripped away when doing the
final conversion ('git filter-branch --prune-empty' might be helpful
here)?

Marius Gedminas
-- 
I code in vi because I don't want to learn another OS. :)
-- Robert Love

-- 
-- 
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: Preparations for moving to github

[Marius Gedminas]

On Fri, Mar 27, 2015 at 04:42:31PM +1300, Jan Larres wrote:
> James McCoy :
> > $ git clone https://github.com/vim/vim
> > ...
> > $ cd vim
> > $ du -hs .git .
> > 685M.git
> > 47M .
> > $ git gc --aggressive
> > ...
> > $ du -hs .git .
> > 34M .git
> > 47M .
> 
> The Google Code to GitHub exporter seems to do a pretty bad job at finding
> good deltas; I've seen other projects that were exported with it and had a
> similarly bloated repository. I would probably be a good idea to contact
> GitHub support and ask them to perform an aggressive gc on the server so that
> first-time cloners don't have to download so much junk.

I pinged @GitHub on Twitter and they say they've fixed this on the server
side: https://twitter.com/vmg/status/581144886826672130

'git clone' now needs to download only 32 megs, yay!

mg@platonas: /tmp $ git clone https://github.com/vim/vim vim2
Cloning into 'vim2'...
remote: Counting objects: 51714, done.
remote: Total 51714 (delta 0), reused 0 (delta 0), pack-reused 51714
Receiving objects: 100% (51714/51714), 32.43 MiB | 527.00 KiB/s, done.
Resolving deltas: 100% (41960/41960), done.
Checking connectivity... done.

[1m11s]
mg@platonas: /tmp $ du -chs vim2/.git
35M vim2/.git
35M viso

mg@platonas: /tmp $ du -chs vim2
81M vim2
81M viso

Marius Gedminas
-- 
Si fractum non sit, noli id reficere.

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

log messages slightly corrupted in new github repo

[Manuel Ortega]

I cloned the new "testing" repo from github.

When I do "git log" and scroll through the results, I find that multi-line
log messages that look fine in the hg repo are a bit mangled in the github
repo.

For example, a line starting with "Problem:" that has a description long
enough to continue on to the next line has bad indentation on the second
line. The commit messaget for atch 7.4.682 is a good example.

I can't tell right now on my terminal, but I suspect github (or the google
code exporter) is inserting a tab where there should only be spaces (or
vice versa).

I don't know whether anything can be done about that, but I thought I'd
raise the issue here.

-Manny

-- 
-- 
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: [Patch] Build Vim on Mac OS X with Privately Installed Python (src/configure.in)

[Francisco Lopes]

Em sexta-feira, 27 de março de 2015 01:51:05 UTC-3, Francisco Lopes  escreveu:
> Em sexta-feira, 27 de março de 2015 01:44:37 UTC-3, Francisco Lopes  escreveu:
> > Em quinta-feira, 26 de março de 2015 00:10:51 UTC-3, Kazunobu Kuriyama  
> > escreveu:
> > > On Mar 26, 2015, at 1:36, Francisco Lopes 
> > >  wrote:
> > > 
> > > > Em segunda-feira, 23 de março de 2015 04:19:30 UTC-3, Kazunobu Kuriyama 
> > > >  escreveu:
> > > >> Hi list,
> > > >> 
> > > >> 
> > > >> The attached patch was written to address two issues on Vim build on 
> > > >> Mac OS X with privately installed Python.
> > > >> 
> > > >> 
> > > >> (1) The current configure script uses the responses of the Python 
> > > >> executable AC_PATH_PROGS() finds.  This doesn’t cause any problem when 
> > > >> you try to link Vim against the Python that came to your system 
> > > >> together with the OS.  But when you installed another Python and try 
> > > >> to link Vim against it, you’ll find that the resulting Vim is always 
> > > >> linked against the Python framework of /usr/bin/python, not that of, 
> > > >> e.g., /opt/local/bin/python, even if the configure script correctly 
> > > >> detects that the Python executable /opt/local/bin/python differs from 
> > > >> the native /usr/bin/python.
> > > >> 
> > > >> 
> > > >> This issue is caused by forgetting to tell the linker to use an extra 
> > > >> linker search path which corresponds to the Python framework you want 
> > > >> to use.
> > > >> 
> > > >> 
> > > >> The proposed patch addresses the issue by prepending an appropriate 
> > > >> linker search path if the Python executable in use doesn’t look like 
> > > >> the native one so that the linker will try to link vim against your 
> > > >> favorite Python first.  The path is determined by examining the 
> > > >> contents of config/Makefile in the Python framework corresponding to 
> > > >> the executable in use.
> > > >> 
> > > >> 
> > > >> (2) Another issue is closely related to the issue above and they 
> > > >> surely resemble one another.  But the cause of it slightly differs 
> > > >> from that and thus should be handled as such.
> > > >> 
> > > >> 
> > > >> The current configure script relies on the variables defined in Python 
> > > >> framework’s config/Makefile.  LINKFORSHARED is one of such variables 
> > > >> and has a form of:
> > > >> 
> > > >> 
> > > >> -u {symbol} {path}
> > > >> 
> > > >> 
> > > >> When Vim is built on Mac OS X with —disable-darwin, the configure 
> > > >> script is to pass the value of LINKFORSHAED to the linker without 
> > > >> referring to a Python framework.
> > > >> 
> > > >> 
> > > >> If {path} is relative, then it is almost certain that you’ll suffer 
> > > >> from a “No such file or directory” error from the linker behind the 
> > > >> scenes.  Consequently, if LINKFORSHARED contains a relative path while 
> > > >> the privately installed Python is known usable, then the “sanity” test 
> > > >> on compile and linker flags is doomed to fail.  In other words, the 
> > > >> test gives an unreliable result when {path} is relative.
> > > >> 
> > > >> 
> > > >> This is what had happened to me with Python (2.7.9) that was privately 
> > > >> installed through MacPorts.
> > > >> 
> > > >> 
> > > >> The proposed patch corrects the behavior of the configure script by 
> > > >> checking whether or not the given {path} makes sense for the linker, 
> > > >> and, if necessary, make and try other candidates so that the sanity 
> > > >> test will give a result more faithful to the state of the system.
> > > >> 
> > > >> 
> > > >> The issue (1) may be related to Issue #315, but I don’t want to claim 
> > > >> that this patch solves #315, because the Mac system mentioned there 
> > > >> looks different from mine in subtle points. So I’m not sure if #315 is 
> > > >> solved with the patch.
> > > >> 
> > > >> 
> > > >> Regards,
> > > >> Kazunobu Kuriyama
> > > > 
> > > > Did you review information from issue 315: 
> > > > https://code.google.com/p/vim/issues/detail?id=315.
> > > > 
> > > > I think it's quite important for solving OS X build problems, I use 
> > > > that information for flipping a flag and vanish with the linker issues.
> > > 
> > > Hi,
> > > 
> > > If I understand correctly, you mean you fixed the linker issues using the 
> > > information that was given in the URL you mentioned, right?
> > > 
> > > If so, I’d be happy if you could help me understand what I’m probably 
> > > missing there.
> > > 
> > > In the URL in question:
> > > 
> > > Comment #1 says “It looks like the fix is not working anymore.”
> > > 
> > > Comment #2 saya “…(with the build patches I mention included).”
> > > 
> > > I’m no sure what “the fix” and “the build patches” are referred to, 
> > > because I can’t see any of them nor links on the same page.  If you know 
> > > something about them, please let me know.
> > > 
> > > Or, more preferably, why don’t you share with the list the way you 
> > > actually used to fix the issues?
> >

Re: [Patch] Build Vim on Mac OS X with Privately Installed Python (src/configure.in)

[Francisco Lopes]

Em sexta-feira, 27 de março de 2015 01:44:37 UTC-3, Francisco Lopes  escreveu:
> Em quinta-feira, 26 de março de 2015 00:10:51 UTC-3, Kazunobu Kuriyama  
> escreveu:
> > On Mar 26, 2015, at 1:36, Francisco Lopes 
> >  wrote:
> > 
> > > Em segunda-feira, 23 de março de 2015 04:19:30 UTC-3, Kazunobu Kuriyama  
> > > escreveu:
> > >> Hi list,
> > >> 
> > >> 
> > >> The attached patch was written to address two issues on Vim build on Mac 
> > >> OS X with privately installed Python.
> > >> 
> > >> 
> > >> (1) The current configure script uses the responses of the Python 
> > >> executable AC_PATH_PROGS() finds.  This doesn’t cause any problem when 
> > >> you try to link Vim against the Python that came to your system together 
> > >> with the OS.  But when you installed another Python and try to link Vim 
> > >> against it, you’ll find that the resulting Vim is always linked against 
> > >> the Python framework of /usr/bin/python, not that of, e.g., 
> > >> /opt/local/bin/python, even if the configure script correctly detects 
> > >> that the Python executable /opt/local/bin/python differs from the native 
> > >> /usr/bin/python.
> > >> 
> > >> 
> > >> This issue is caused by forgetting to tell the linker to use an extra 
> > >> linker search path which corresponds to the Python framework you want to 
> > >> use.
> > >> 
> > >> 
> > >> The proposed patch addresses the issue by prepending an appropriate 
> > >> linker search path if the Python executable in use doesn’t look like the 
> > >> native one so that the linker will try to link vim against your favorite 
> > >> Python first.  The path is determined by examining the contents of 
> > >> config/Makefile in the Python framework corresponding to the executable 
> > >> in use.
> > >> 
> > >> 
> > >> (2) Another issue is closely related to the issue above and they surely 
> > >> resemble one another.  But the cause of it slightly differs from that 
> > >> and thus should be handled as such.
> > >> 
> > >> 
> > >> The current configure script relies on the variables defined in Python 
> > >> framework’s config/Makefile.  LINKFORSHARED is one of such variables and 
> > >> has a form of:
> > >> 
> > >> 
> > >> -u {symbol} {path}
> > >> 
> > >> 
> > >> When Vim is built on Mac OS X with —disable-darwin, the configure script 
> > >> is to pass the value of LINKFORSHAED to the linker without referring to 
> > >> a Python framework.
> > >> 
> > >> 
> > >> If {path} is relative, then it is almost certain that you’ll suffer from 
> > >> a “No such file or directory” error from the linker behind the scenes.  
> > >> Consequently, if LINKFORSHARED contains a relative path while the 
> > >> privately installed Python is known usable, then the “sanity” test on 
> > >> compile and linker flags is doomed to fail.  In other words, the test 
> > >> gives an unreliable result when {path} is relative.
> > >> 
> > >> 
> > >> This is what had happened to me with Python (2.7.9) that was privately 
> > >> installed through MacPorts.
> > >> 
> > >> 
> > >> The proposed patch corrects the behavior of the configure script by 
> > >> checking whether or not the given {path} makes sense for the linker, 
> > >> and, if necessary, make and try other candidates so that the sanity test 
> > >> will give a result more faithful to the state of the system.
> > >> 
> > >> 
> > >> The issue (1) may be related to Issue #315, but I don’t want to claim 
> > >> that this patch solves #315, because the Mac system mentioned there 
> > >> looks different from mine in subtle points. So I’m not sure if #315 is 
> > >> solved with the patch.
> > >> 
> > >> 
> > >> Regards,
> > >> Kazunobu Kuriyama
> > > 
> > > Did you review information from issue 315: 
> > > https://code.google.com/p/vim/issues/detail?id=315.
> > > 
> > > I think it's quite important for solving OS X build problems, I use that 
> > > information for flipping a flag and vanish with the linker issues.
> > 
> > Hi,
> > 
> > If I understand correctly, you mean you fixed the linker issues using the 
> > information that was given in the URL you mentioned, right?
> > 
> > If so, I’d be happy if you could help me understand what I’m probably 
> > missing there.
> > 
> > In the URL in question:
> > 
> > Comment #1 says “It looks like the fix is not working anymore.”
> > 
> > Comment #2 saya “…(with the build patches I mention included).”
> > 
> > I’m no sure what “the fix” and “the build patches” are referred to, because 
> > I can’t see any of them nor links on the same page.  If you know something 
> > about them, please let me know.
> > 
> > Or, more preferably, why don’t you share with the list the way you actually 
> > used to fix the issues?
> > 
> > If I come to know something about them, there may be something I can do for 
> > Issue 315.
> > 
> > Regards,
> > Kazunobu Kuriyama
> 
> The way I solve it when I have to build on OS X is just flip the test
> from < 2.3 to >= 2.3.
> 
> The reason is explained at the issue, section entitled as

Re: [Patch] Build Vim on Mac OS X with Privately Installed Python (src/configure.in)

[Francisco Lopes]

Em quinta-feira, 26 de março de 2015 00:10:51 UTC-3, Kazunobu Kuriyama  
escreveu:
> On Mar 26, 2015, at 1:36, Francisco Lopes 
>  wrote:
> 
> > Em segunda-feira, 23 de março de 2015 04:19:30 UTC-3, Kazunobu Kuriyama  
> > escreveu:
> >> Hi list,
> >> 
> >> 
> >> The attached patch was written to address two issues on Vim build on Mac 
> >> OS X with privately installed Python.
> >> 
> >> 
> >> (1) The current configure script uses the responses of the Python 
> >> executable AC_PATH_PROGS() finds.  This doesn’t cause any problem when you 
> >> try to link Vim against the Python that came to your system together with 
> >> the OS.  But when you installed another Python and try to link Vim against 
> >> it, you’ll find that the resulting Vim is always linked against the Python 
> >> framework of /usr/bin/python, not that of, e.g., /opt/local/bin/python, 
> >> even if the configure script correctly detects that the Python executable 
> >> /opt/local/bin/python differs from the native /usr/bin/python.
> >> 
> >> 
> >> This issue is caused by forgetting to tell the linker to use an extra 
> >> linker search path which corresponds to the Python framework you want to 
> >> use.
> >> 
> >> 
> >> The proposed patch addresses the issue by prepending an appropriate linker 
> >> search path if the Python executable in use doesn’t look like the native 
> >> one so that the linker will try to link vim against your favorite Python 
> >> first.  The path is determined by examining the contents of 
> >> config/Makefile in the Python framework corresponding to the executable in 
> >> use.
> >> 
> >> 
> >> (2) Another issue is closely related to the issue above and they surely 
> >> resemble one another.  But the cause of it slightly differs from that and 
> >> thus should be handled as such.
> >> 
> >> 
> >> The current configure script relies on the variables defined in Python 
> >> framework’s config/Makefile.  LINKFORSHARED is one of such variables and 
> >> has a form of:
> >> 
> >> 
> >> -u {symbol} {path}
> >> 
> >> 
> >> When Vim is built on Mac OS X with —disable-darwin, the configure script 
> >> is to pass the value of LINKFORSHAED to the linker without referring to a 
> >> Python framework.
> >> 
> >> 
> >> If {path} is relative, then it is almost certain that you’ll suffer from a 
> >> “No such file or directory” error from the linker behind the scenes.  
> >> Consequently, if LINKFORSHARED contains a relative path while the 
> >> privately installed Python is known usable, then the “sanity” test on 
> >> compile and linker flags is doomed to fail.  In other words, the test 
> >> gives an unreliable result when {path} is relative.
> >> 
> >> 
> >> This is what had happened to me with Python (2.7.9) that was privately 
> >> installed through MacPorts.
> >> 
> >> 
> >> The proposed patch corrects the behavior of the configure script by 
> >> checking whether or not the given {path} makes sense for the linker, and, 
> >> if necessary, make and try other candidates so that the sanity test will 
> >> give a result more faithful to the state of the system.
> >> 
> >> 
> >> The issue (1) may be related to Issue #315, but I don’t want to claim that 
> >> this patch solves #315, because the Mac system mentioned there looks 
> >> different from mine in subtle points. So I’m not sure if #315 is solved 
> >> with the patch.
> >> 
> >> 
> >> Regards,
> >> Kazunobu Kuriyama
> > 
> > Did you review information from issue 315: 
> > https://code.google.com/p/vim/issues/detail?id=315.
> > 
> > I think it's quite important for solving OS X build problems, I use that 
> > information for flipping a flag and vanish with the linker issues.
> 
> Hi,
> 
> If I understand correctly, you mean you fixed the linker issues using the 
> information that was given in the URL you mentioned, right?
> 
> If so, I’d be happy if you could help me understand what I’m probably missing 
> there.
> 
> In the URL in question:
> 
> Comment #1 says “It looks like the fix is not working anymore.”
> 
> Comment #2 saya “…(with the build patches I mention included).”
> 
> I’m no sure what “the fix” and “the build patches” are referred to, because I 
> can’t see any of them nor links on the same page.  If you know something 
> about them, please let me know.
> 
> Or, more preferably, why don’t you share with the list the way you actually 
> used to fix the issues?
> 
> If I come to know something about them, there may be something I can do for 
> Issue 315.
> 
> Regards,
> Kazunobu Kuriyama

The way I solve it when I have to build on OS X is just flip the test
from < 2.3 to >= 2.3.

The reason is explained at the issue, section entitled as "Please provide any
additional information below."

Regards

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

Re: Preparations for moving to github

[Jan Larres]

James McCoy :
> $ git clone https://github.com/vim/vim
> ...
> $ cd vim
> $ du -hs .git .
> 685M.git
> 47M .
> $ git gc --aggressive
> ...
> $ du -hs .git .
> 34M .git
> 47M .

The Google Code to GitHub exporter seems to do a pretty bad job at finding
good deltas; I've seen other projects that were exported with it and had a
similarly bloated repository. I would probably be a good idea to contact
GitHub support and ask them to perform an aggressive gc on the server so that
first-time cloners don't have to download so much junk.

-Jan

-- 
-[ OpenPGP key ID: 00A0FD5F ]-
The most dangerous phrase in the language is, "We've always done it this
way."
-- Grace Hopper

-- 
-- 
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: Preparations for moving to github

[James McCoy]

On Thu, Mar 26, 2015 at 08:25:12PM -0700, Ben Fritz wrote:
> On Tuesday, March 24, 2015 at 4:36:32 PM UTC-5, Bram Moolenaar wrote:
> > 
> > Look here: https://github.com/vim
> > 
> > Please respond to the list if something doesn't work well.
> > 
> 
> When I click the "branches" tab I get a Unicorn! error page saying "This page 
> is taking way too long to load."
> 
> Somehow I don't think that's a good thing. Is this because of something weird 
> in the Vim repository? Some temporary fluke? Some problem with the conversion?

It's not just the Vim repo.  Github is being DDoSed: 
https://status.github.com/messages

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

-- 
-- 
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: Preparations for moving to github

[Ben Fritz]

On Tuesday, March 24, 2015 at 4:36:32 PM UTC-5, Bram Moolenaar wrote:
> 
> Look here: https://github.com/vim
> 
> Please respond to the list if something doesn't work well.
> 

When I click the "branches" tab I get a Unicorn! error page saying "This page 
is taking way too long to load."

Somehow I don't think that's a good thing. Is this because of something weird 
in the Vim repository? Some temporary fluke? Some problem with the conversion?

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

To keep good projects on github

[MURAOKA Taro]

Hi Bram.


I suggest to give "write access" permission of vim organization to
some reliable users.

It is important to act for PR on github.
PR becomes a cause of flaming sometimes.
So we need to close, lock, or delete PR which have seed of troubles.

But this kind of operations require "write access" permission.
So, currently only one Bram, you can do it.
Yasuhiro Matsumoto (mattn) wrote replys for those PR,
however it have limited effects.

This kind of works are not worth for using Bram's time, I think.
So, I suggest to mandate it with write permission.

# of course, if we keep using github. ;)


Best regards.
-- 
MURAOKA Taro 

-- 
-- 
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: Preparations for moving to github

[Manuel Ortega]

On Thu, Mar 26, 2015 at 7:44 PM, James McCoy  wrote:

>
> On Mar 26, 2015 5:03 PM, "John Szakmeister"  wrote:
> >
> > On Thu, Mar 26, 2015 at 11:26 AM, James McCoy 
> wrote:
> > [snip]
> > > $ git gc --aggressive
> > > ...
> > > $ du -hs .git .
> > > 34M .git
> > > 47M .
> >
> > Just wanted to point out that there's really no need for
> > "--aggressive" here.  "git gc" without it will often produce similar
> > results in less time. :-)
>
> I initially ran just "git gc" and there was no change in disk space.  I'm
> using a new enough git that it periodically kicks off a background "git gc"
> after a normal git command. Maybe clone is one those cases.
>

While "git gc" will *sometimes* produce similar results to "git gc
--aggressive", it very, very often in my experience does not.  This is
perhaps one of those cases.

-Manny

-- 
-- 
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: Preparations for moving to github

[James McCoy]

On Mar 26, 2015 5:03 PM, "John Szakmeister"  wrote:
>
> On Thu, Mar 26, 2015 at 11:26 AM, James McCoy 
wrote:
> [snip]
> > $ git gc --aggressive
> > ...
> > $ du -hs .git .
> > 34M .git
> > 47M .
>
> Just wanted to point out that there's really no need for
> "--aggressive" here.  "git gc" without it will often produce similar
> results in less time. :-)

I initially ran just "git gc" and there was no change in disk space.  I'm
using a new enough git that it periodically kicks off a background "git gc"
after a normal git command. Maybe clone is one those cases.

-- 
-- 
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: Preparations for moving to github

[Kana Natsuno]

On Friday, March 27, 2015 at 5:00:19 AM UTC+9, Bram Moolenaar wrote:
> Isn't there a way to clone only up to some time ago, e.g., the 7.4
> release?  I rather leave this a decision on the user side than on the
> server side (meaning that history would be lost forever).

git clone --depth 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.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: Bug with renderoptions

[Christian Brabandt]

On Do, 26 Mär 2015, Christian Brabandt wrote:
> I am suspecting, this is because I use some fonts, that I can't
> install on my work station
> (due to restricted access rights) and therefore I have to use
> registerfonts (a small utility
> that makes them available for the current session to load those
> fonts, available here:
> http://www.dailygyan.com/2008/05/how-to-install-fonts-in-windows-without.html
> ).
> Because it works with the standard default fonts in Windows.

Yes, that seems to be the case. Using a debugger, I can see, that after 
the CreateFontIndirect() call, I get a handle like this:
0xc011751 {unused=???}

Anyone knows what that means?

Best,
Christian
-- 
Die Kunst soll das Penible nicht vorstellen.
-- Goethe, Maximen und Reflektionen, Nr. 1212

-- 
-- 
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: Preparations for moving to github

[John Szakmeister]

On Thu, Mar 26, 2015 at 11:26 AM, James McCoy  wrote:
[snip]
> $ git gc --aggressive
> ...
> $ du -hs .git .
> 34M .git
> 47M .

Just wanted to point out that there's really no need for
"--aggressive" here.  "git gc" without it will often produce similar
results in less time. :-)

-John

-- 
-- 
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: Preparations for moving to github

[Elimar Riesebieter]

* James McCoy  [2015-03-26 11:26 -0400]:

[...]

> $ git clone https://github.com/vim/vim
> ...
> $ cd vim
> $ du -hs .git .
> 685M.git
> 47M .
> $ git gc --aggressive
> ...
> $ du -hs .git .
> 34M .git
> 47M .
> 
> For reference, are similar numbers for a fresh Mercurial clone:
> 
> $ du -hs .hg .
> 55M .hg
> 47M .
> 
[...]

* Bram Moolenaar  [2015-03-26 21:00 +0100]:

> 
> Manuel Ortega wrote:
[...]
> > It would be nice if, when this gets finalized, the new repo trims out
> > ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to
> > have to clone all that and carry it around on disk.  Yes, I know about
> > shallow clones, but they're pretty wonky, especially wrt making PRs from a
> > shallow clone to the main repo (not that Bram is going to look at them).
> 
> Isn't there a way to clone only up to some time ago, e.g., the 7.4
> release?  I rather leave this a decision on the user side than on the
> server side (meaning that history would be lost forever).

As James pointed out: There is not that much space needed! So please
keep the history as it is quite easy to filter tags the user wants
to work on.

Elimar

-- 
 Experience is something you don't get until
  just after you need it!

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

Issue 349 in vim: feature request: set gVim GTK border color to eliminate borders when maximized

[vim]

Status: New
Owner: 
Labels: Type-Defect Priority-Medium

New issue 349 by jacksene...@gmail.com: feature request: set gVim GTK  
border color to eliminate borders when maximized

https://code.google.com/p/vim/issues/detail?id=349

What steps will reproduce the problem?
1. choose a dark colorscheme
2. maximize the window

What is the expected output? What do you see instead?

On the right side and bottom there will be a border that is the GTK default  
border color. You may need to change the font size to see it properly,  
since the border is the left-over space after gvim has filled the screen  
with the maximum number of lines/cols that will fit in the window.


The ideal behavior would be that this border would be set to the same color  
as the background of your color scheme, and changed when you change color  
schemes. The border will still be there, but will be less of an eyesore.


In the discussions linked below people have also mentioned it would be nice  
if vim was centered inside the available space rather than positioned at  
the top-left, so the borders would be equal left-right and top-bottom. This  
sounds good as well, but I would consider it secondary to the primary issue  
of the border color.


What version of the product are you using? On what operating system?

gVim on Ubuntu 14.04

:version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan  2 2014 19:39:47)
Included patches: 1-52
Modified by pkg-vim-maintain...@lists.alioth.debian.org
Compiled by buildd@
Huge version with GTK2-GNOME GUI ...

Please provide any additional information below.

Here's a good discussion of the issue:  
http://vim.1045645.n5.nabble.com/Empty-lines-at-bottom-and-right-side-when-on-Fullscreen-td5709762.html
Also https://groups.google.com/forum/#!topic/vim_dev/hfN-kMZDAEY,  
https://wiki.archlinux.org/index.php/Vim#Empty_space_at_the_bottom_of_gVim_windows,  
and  
http://stackoverflow.com/questions/12763692/paddings-around-the-actual-vim-window-in-gvim



Attachments:
0lAYU.png  32.1 KB

--
You received this message because this project is configured to send all  
issue notifications to this address.

You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
--
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: expand("%") and utf-8 characters in directory names

[Bram Moolenaar]

Charles Campbell wrote:

> I tried a directory named "josé" and found that netrw wasn't handling it
> well.  One of the reasons is expand("%"), which is used to get the full
> path.  However, when in that directory, expand("%") shows
> /home/cec/joe instead of the desired /home/cec/josé .  Do I need to
> program around this or is this problem a bug with expand()?

I don't see this problem.  What is 'encoding' set to?

-- 
An indication you must be a manager:
You believe you never have any problems in your life, just
"issues" and "improvement opportunities".

 /// 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: Preparations for moving to github

[Bram Moolenaar]

Manuel Ortega wrote:

> On Tue, Mar 24, 2015 at 5:36 PM, Bram Moolenaar  wrote:
> 
> >
> > Since Google Code is going to be shut down we need a new place for the
> > Vim repository.  Many users have given their opinion and github appears
> > to be the preferred site.
> >
> 
> Darn.
> 
> It would be nice if, when this gets finalized, the new repo trims out
> ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to
> have to clone all that and carry it around on disk.  Yes, I know about
> shallow clones, but they're pretty wonky, especially wrt making PRs from a
> shallow clone to the main repo (not that Bram is going to look at them).

Isn't there a way to clone only up to some time ago, e.g., the 7.4
release?  I rather leave this a decision on the user side than on the
server side (meaning that history would be lost forever).

-- 
An indication you must be a manager:
You give constructive feedback to your dog.

 /// 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: Any automatic bracket-insertion plugins not breaking undo?

[Thiago Alves]

Awesome patch. I tested here it works perfectly. Any chance this to be applied 
to mainline?

On Wednesday, March 25, 2015 at 12:02:32 PM UTC-7, Ben Fritz wrote:
> On Wednesday, January 21, 2015 at 11:06:53 AM UTC-6, Ben Fritz wrote:
> > On Saturday, January 17, 2015 at 1:20:04 PM UTC-6, Bram Moolenaar wrote:
> > > 
> > > Since undo works by saving the line before changing it, restricting the
> > > "keep undo" modifier to only work when the cursor remains in the same
> > > line should work.  It's also fairly easy to understand, instead of
> > > making a list of specific commands for which undo can be kept.
> > > 
> > > Note that "." to repeat the insert may not always work properly.  Need
> > > to check that.
> > > 
> > 
> > Wow. WOW! Thanks for the patch, Christian!
> > 
> > I tested with some fairly simple mappings, and it works perfectly!
> > 
> 
> Updated patch to apply cleanly (with line offsets but no fuzz) to the latest 
> source.

-- 
-- 
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: Preparations for moving to github

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26-Mar-2015 17:25, Manuel Ortega wrote:
> On Thu, Mar 26, 2015 at 9:43 AM, Ingo Karkat  > wrote:
> 
>> Bram already is a bottleneck in development; please don't make
>> him
> 
> work harder by adding yet more complexity in repo maintenance!
> 
> It's quite obvious that almost nobody on this list cares about
> adding complexity for Bram; it they did, they would not be
> insisting that he switch over to git rather than just moving the
> repo to BB and beind done with it.

I've followed this entire thread; Bram explicitly asked for feedback,
and showed his openness about switching to GitHub (and thereby Git);
he's even considering using pull requests (which I'm quite fond of; it
could streamline the current process of posting patches (and
occasionally updates to them)). He could have simply said "Mercurial
is set", and GitHub would have been out.

I was referring to continuous overhead (like pruning the repo);
whereas switching version control systems is a one-time effort only.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVFEdJAAoJEA7ziXlAzQ/vxq4H/1fh5hKDSRq6tSZqXloQIW/I
KiIVRFSdsREWR2I5clB1tNpqHcS5p9R7TX5+gZnh6bayLzI8iSNtPNS+X80HUaaY
BDkJJcq2mRPI2+f43MVPHTaS6IboSQ6Sm1mWlBEZpehMpyFmCLyKWDB6XWwZAdni
G9n3ufBm/hxNxO/tpmvUuxo/SbCYfJPIh1fVFv1ipZfobFSUI8W72wZDVbrMUTMp
sF5xajeo7uW3R8lv18iP+5mteI2NyV7cVa/y0KdmhCD6bhahL+UsUmPS00sY/5dB
Lf6LfSDTjcYFaS79WOJ7AemJZZlnIu98Fd0JJMbP9Qz9c0sDiw9eMiBXuZuRbwY=
=b7ra
-END PGP SIGNATURE-

-- 
-- 
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: Bug with renderoptions

[zeug]

Am 2015-03-26 13:47, schrieb Christian Brabandt:

was the new logo an official patch?


No, I found it on vim_dev (and got the permission of the author to 
include it). :-)



Is it possible
to get that also in the windowbar?


Hmm, it should; still, as I only replaced one image file, I wonder which 
one is responsible for the windowbar itself...?


Regards.

--
--
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: Preparations for moving to github

[Manuel Ortega]

On Thu, Mar 26, 2015 at 9:43 AM, Ingo Karkat  wrote:

>
>

> Bram already is a bottleneck in development; please don't make him

> work harder by adding yet more complexity in repo maintenance!
>
>

It's quite obvious that almost nobody on this list cares about adding
complexity for Bram; it they did, they would not be insisting that he
switch over to git rather than just moving the repo to BB and beind done
with it.

-Manny

-- 
-- 
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: Bug with renderoptions

[Christian Brabandt]

Am 2015-03-26 08:24, schrieb Christian Brabandt:

Am 2015-03-26 08:08, schrieb Peter Vrabel:

On 20/03/2015 17:55, Jon Schoning wrote:

On Saturday, March 7, 2015 at 3:06:09 PM UTC-6, Shiny Bling wrote:
FYI I just released 7.4.657 with Command-T plugin and ruby upgraded 
to 2.2.1.


It can be downloaded from
https://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.657_1.exe
Thanks for doing these builds!  Also really appreciate that now with 
DirectX enabled, the fonts look "much" better.



You are welcome! Bear in mind that the most gratitude should go to the
vim developers though ;)

I was myself surprised how much better fonts look with DirectX
enabled. I am using this font which looks amazing :
http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released


Hm, I have never used the new renderoption. So I just tried it
:set encoding=utf8
:set guifont=Envy_Code_R:h11:cANSI
:set rop=type:directx

And suddenly, no text is rendered at all. I can make this go away 
typing blindly

:set rop=

(System Vim 7.4.662 from https://tuxproject.de/projects/vim/, Windows 
7)

Am I missing something here? Is this a bug?


I am suspecting, this is because I use some fonts, that I can't install 
on my work station
(due to restricted access rights) and therefore I have to use 
registerfonts (a small utility
that makes them available for the current session to load those fonts, 
available here:

http://www.dailygyan.com/2008/05/how-to-install-fonts-in-windows-without.html
).
Because it works with the standard default fonts in Windows.

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.

Re: Preparations for moving to github

[Guyzmo]

Hi there,

On Thu, Mar 26, 2015 at 09:32:32AM -0400, Manuel Ortega wrote:
> On Thu, Mar 26, 2015 at 12:43 AM, Dominique Pellé  wrote:
> > Manuel Ortega  wrote:
>  > or find out when  a piece of code was changed and why.
> Bram can (and should) put older parts under github.com/vim/70 and
> github.com/vim/71, and then anyone who wants to go spelunking back in time
> can still do so.

usually a nice way of working that out is to use some branch-release
strategy. Basically, when you're working towards version N:

 - you use a branch `devel-N`, 
 - then when it's ready for freeze-time, you branch it as `freeze-N`
 - then when it's ready for release you squash all the commits of the
   branch within the release branch
 - then you fork the release branch towards `devel-N+1` and start over

that way, when you want to get the release branch you just git clone
(or fork) the `release` branch (or master or whatever the name you give 
it) but not the other ones. Until you don't fetch older branches, you're
all set.

That was just for the "getting all history" point. I still believe that
vim's history is not huge, and shouldn't be an issue. Just get mozilla's
sources and there you'll get some fun :-)

my 2 cents,

-- 
Guyzmo

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

expand("%") and utf-8 characters in directory names

[Charles Campbell]

Hello:

I tried a directory named "josé" and found that netrw wasn't handling it
well.  One of the reasons is expand("%"), which is used to get the full
path.  However, when in that directory, expand("%") shows
/home/cec/joe instead of the desired /home/cec/josé .  Do I need to
program around this or is this problem a bug with expand()?

Regards,
Chip Campbell


-- 
-- 
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: Bug with renderoptions (was: Re: [ANN] Vim for Windows build, contains all 3rd party dependencies)

[Charles Cooper]

On Thursday, March 26, 2015 at 3:24:43 AM UTC-4, Christian Brabandt wrote:
> Hm, I have never used the new renderoption. So I just tried it
> :set encoding=utf8
> :set guifont=Envy_Code_R:h11:cANSI
> :set rop=type:directx
> 
> And suddenly, no text is rendered at all. I can make this go away typing 
> blindly
> :set rop=
> 
> Am I missing something here? Is this a bug?

Have had good luck using the following setting copied from one of the posts 
around the time the option was introduced

set 
renderoptions=type:directx,gamma:1.0,contrast:0.2,level:1.0,geom:1,renmode:5,taamode: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.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: Preparations for moving to github

[James McCoy]

On Mar 25, 2015 7:18 PM, "Manuel Ortega"  wrote:
>
> On Tue, Mar 24, 2015 at 5:36 PM, Bram Moolenaar 
wrote:
>>
>>
>> Since Google Code is going to be shut down we need a new place for the
>> Vim repository.  Many users have given their opinion and github appears
>> to be the preferred site.
>
>
> Darn.
>
> It would be nice if, when this gets finalized, the new repo trims out
ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to
have to clone all that and carry it around on disk.

$ git clone https://github.com/vim/vim
...
$ cd vim
$ du -hs .git .
685M.git
47M .
$ git gc --aggressive
...
$ du -hs .git .
34M .git
47M .

For reference, are similar numbers for a fresh Mercurial clone:

$ du -hs .hg .
55M .hg
47M .

I'm not sure if there's something that can be done so that the initial git
clone has similar results as the post-gc results, but an extra 34M of disk
space isn't worth the added complexity of juggling multiple repos.

Note that I also find bisecting to be very useful and have used it many
times when working on Vim, so I am also in the camp of not hampering that
functionality because of a one time cost.

-- 
-- 
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: Preparations for moving to github

[Christian Brabandt]

Am 2015-03-25 21:48, schrieb Bram Moolenaar:

Christian Brabandt wrote:

[...]


@Bram, perhaps it is necessary to split the runtime directory into a
separate
github repository, so they could be easier handled.


How is that easier?  Most users will want just one repo to pull from 
and

rebuild their local Vim, possibly with some local changes.


Well, it could be co-maintained, taking burden from you to merge runtime 
file changes,

or documentation updates and you could concentrate on the code.

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.

Re: Preparations for moving to github

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26-Mar-2015 14:32, Manuel Ortega wrote:
> It's smaller than Linux, therefore it's not too big?  It's far too
> big for the kind of thing it is.  It's a plain text editor; a user
> shouldn't have 50MB worth of useless things (much from *eleven*
> years ago) hanging around.

With the broadband connections that most of us now fortunately have,
50 MB is nothing. People stream / download entire HD movies all the
time. Java projects using Maven routinely download half of the
Internet to get to a build :-)

> Surely nobody needs 7.0 or 7.1 for bisection anymore.  7.3, OK.
> *Maybe* 7.2.  And anyway, bisection doesn't require that it all be
> in one repo (unless one believes the ability to "hg bisect" is a
> requirement of bisecting, which it is not).

I find the information when something was last changed very valuable.

> Bram can (and should) put older parts under github.com/vim/70 
>  and github.com/vim/71 
> , and then anyone who wants to go
> spelunking back in time can still do so.
> 
> It's time to weigh the benefits of keeping ancient code in the main
> repo against the benefits of a small repo.  Keeping the *whole*
> history benefits a very small number of people on very rare
> occasions.  Making a smaller repo benefits everyone on nearly all
> occasions, and at most mildly inconveniences the very few people on
> those very rare occasions.

I'd argue the other way: Most people don't care about the full
download (which needs to be done only once on initial checkout). There
may be some poor fellows with poor connections; if you or some other
volunteer would like to provide lighter repo versions, just do so.
Bram already is a bottleneck in development; please don't make him
work harder by adding yet more complexity in repo maintenance!

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVFAzlAAoJEA7ziXlAzQ/voX0H/24Ep5qaSKLGaXYl1GV9cdG1
PB1a+YbT93NxKes/9SrLt/N2yChauyUliY76c69MHyT4wBCTQ7PFul0tT69mJJYr
YyB7d81Js0vzJbba8/3b6lzxWgXZwfdMZhY/evjLAONWOz9kDZYURSif0O4uWm1T
pfZBqm/IeJuWPO2zglfVtlt8cjoHxvXtJ63DI//TJUkFX6wXV9VqucAXEstvHhar
q3oXCxWqrx/t4P0ZBRWNKH/bQKX2gmYgefAPsrZBg9VWqV//PgViG0DAQLFr2iAW
48nDkSg4EUahbLyFmWbjLjKP0m69+xlbP97hi7fNO0VVIlMnakrhK0q7bB23qFo=
=dMfm
-END PGP SIGNATURE-

-- 
-- 
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: Preparations for moving to github

[Manuel Ortega]

On Thu, Mar 26, 2015 at 12:43 AM, Dominique Pellé  wrote:

> Manuel Ortega  wrote:
> >
> > It would be nice if, when this gets finalized, the new repo trims out
> > ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to
> > have to clone all that and carry it around on disk.  Yes, I know about
> > shallow clones, but they're pretty wonky, especially wrt making PRs from
> a
> > shallow clone to the main repo (not that Bram is going to look at them).
> >
> > -Manny
>
> I disagree.  Keep the whole history:
>
> * the whole history would bloat if had many revisions of binary files,
>   but that's not the case, so it should not take much more space to
>   keep the whole history.
> * Vim is not that big. At least it's much smaller than Linux where
>   all history is kept in git.
>

It's smaller than Linux, therefore it's not too big?  It's far too big for
the kind of thing it is.  It's a plain text editor; a user shouldn't have
50MB worth of useless things (much from *eleven* years ago) hanging around.

Especially when 10% of that consists of patches to remedy accidental
breakages of "tiny" builds :)

* The whole history is useful at least for bisections, or find out when
>   a piece of code was changed and why.


Surely nobody needs 7.0 or 7.1 for bisection anymore.  7.3, OK.  *Maybe*
7.2.  And anyway, bisection doesn't require that it all be in one repo
(unless one believes the ability to "hg bisect" is a requirement of
bisecting, which it is not).

 > or find out when  a piece of code was changed and why.

Bram can (and should) put older parts under github.com/vim/70 and
github.com/vim/71, and then anyone who wants to go spelunking back in time
can still do so.

It's time to weigh the benefits of keeping ancient code in the main repo
against the benefits of a small repo.  Keeping the *whole* history benefits
a very small number of people on very rare occasions.  Making a smaller
repo benefits everyone on nearly all occasions, and at most mildly
inconveniences the very few people on those very rare occasions.

Actually I would be fine with the following:  perhaps there can be one
giant development repo, and one "distribution" repo that only contains
7.4's history.  The latter would get changes to the former merged in
(perhaps automatically).  While that was impossible with Hg (I think), this
should be possible if the switch to git becomes official, right?

-Manny

-- 
-- 
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: Bug with renderoptions

[Christian Brabandt]

Am 2015-03-26 12:54, schrieb z...@tuxproject.de:

Am 2015-03-26 08:24, schrieb Christian Brabandt:

(System Vim 7.4.662 from https://tuxproject.de/projects/vim/, Windows 
7)

Am I missing something here? Is this a bug?


Gentle reminder: I'm the author of your builds, so if I made a mistake
during compilation, I'm willing to fix it. :-)
Keeping an eye on this topic.



Thanks for your builds! BTW: was the new logo an official patch? Is it 
possible

to get that also in the windowbar?

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.

Re: Bug with renderoptions (was: Re: [ANN] Vim for Windows build, contains all 3rd party dependencies)

[zeug]

Am 2015-03-26 08:24, schrieb Christian Brabandt:

(System Vim 7.4.662 from https://tuxproject.de/projects/vim/, Windows 
7)

Am I missing something here? Is this a bug?


Gentle reminder: I'm the author of your builds, so if I made a mistake 
during compilation, I'm willing to fix it. :-)

Keeping an eye on this topic.

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

Bug with renderoptions (was: Re: [ANN] Vim for Windows build, contains all 3rd party dependencies)

[Christian Brabandt]

Am 2015-03-26 08:08, schrieb Peter Vrabel:

On 20/03/2015 17:55, Jon Schoning wrote:

On Saturday, March 7, 2015 at 3:06:09 PM UTC-6, Shiny Bling wrote:
FYI I just released 7.4.657 with Command-T plugin and ruby upgraded 
to 2.2.1.


It can be downloaded from
https://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.657_1.exe
Thanks for doing these builds!  Also really appreciate that now with 
DirectX enabled, the fonts look "much" better.



You are welcome! Bear in mind that the most gratitude should go to the
vim developers though ;)

I was myself surprised how much better fonts look with DirectX
enabled. I am using this font which looks amazing :
http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released


Hm, I have never used the new renderoption. So I just tried it
:set encoding=utf8
:set guifont=Envy_Code_R:h11:cANSI
:set rop=type:directx

And suddenly, no text is rendered at all. I can make this go away typing 
blindly

:set rop=

(System Vim 7.4.662 from https://tuxproject.de/projects/vim/, Windows 7)
Am I missing something here? Is this a bug?

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.

Re: Preparations for moving to github

[LCD 47]

On 25 March 2015, Ben Fritz  wrote:
> On Wednesday, March 25, 2015 at 12:18:46 PM UTC-5, LCD 47 wrote:
> > On 25 March 2015, Ben Fritz wrote:
> > > On Wednesday, March 25, 2015 at 10:21:41 AM UTC-5, Bruno Sutic
> > > wrote:
> > > > I'm curious, when a switch is made, will Github's "pull request"
> > > > feature be used? Or will code contributions still be done with
> > > > patches via mailing list?
> > > >
> > > > I'd guess a move to "pull request" workflow will be done since
> > > > it's so effortless on github, but maybe I'm jumping the gun
> > > > here.
> > >
> > > I'd like to take this a step further:
> > >
> > > If pull requests will NOT be used, then does GitHub offer anything
> > > at all that we cannot get elsewhere? I.e. does it give any
> > > benefits beyond the fact that a lot of people are using Git?
> > >
> > > If Bram starts using pull requests, sure GitHub makes sense
> > > because a lot of people already have accounts there. But if
> > > not...BitBucket supports Git, Kiln supports Git and also adds the
> > > grouping of multiple repositories into one project, and there may
> > > be others.
> > >
> > > I think it would be nice to have an "official" Mercurial mirror,
> > > which isn't possible at GitHub. And I think an official mirror
> > > will be harder to maintain if we need to use multiple sites for
> > > it, especially if each site has a separate bug tracker.
> >
> > Mirroring can be done with a hook, either client-side (a
> > post-commit Git hook on Bram's machine that commits and pushes to
> > Mercurial), or server-side (a webhook on GitHub).
> >
> > Having multiple bug trackers is probably a bad idea, but bug
> > trackers can be disabled on the mirror sites.
> >
>
> I'm sure a hook would make it much easier for Bram to maintain a
> mirror.  Would it actually work on the server side, though, since it
> requires a plugin to be installed to actually push from git to Hg or
> vice versa?

It might.  It's a common problem, if you google for "deployment from
GitHub" there are >1 mil. results.  GitHub has ready-made "webhooks" for
all sort of transfer tasks and notifications, there were ~100 of them
last time I checked, and I think you can even add your own (based, of
course, on GitHub's API).  But I'd say simple is likely to be better
than complex.  A client-side script on Bram's machine (and on all
commiters', if any other than Bram) would be more robust, and would work
just as well.

In principle it's possible to use git-hg bridges to work on Git
repositories with Mercurial, and the other way around.  It mostly
works, but I wouldn't trust that for a repository as complex as Vim's.
What I had in mind was more mundane: a single set of files that would
be both a Git and a Mercurial repository.  Git and Mercurial could
be made to ignore each other, by adding .git to .hgignore and by
adding .hg to .gitignore.  Then a post-commit hook in Git could simply
commit the changes it just, err, committed to Mercurial.  Some minimal
porcelain code could make sure only commits to the master branch would
get mirrored, so that things like squashes and amends could happen
undisturbed in feature branches.  Tags could be mirrored the same
way (although I don't remember if that could be done from the same
post-commit hook).

Then the actual pushing of the Mercurial side of the repository to
Bitbucket (or whatever) could be done, say, every 15 minutes from cron.
Pushing a repository without changes is harmless, and a failed push
would just be retried at the next cron run.  There's no need for the
cron job to be aware when or how the repository gets updated.

This would be simple and robust.  It only needs minimal discipline
from the commiters, and doesn't need maintenance.  I doubt you can do
substantially better with a webhook on the server side.

> I agree multiple bug trackers would be a bad idea, but I also think
> going to ONE location for both bug tracker and the repository is ideal.
> 
> If Bram is using pull requests then maybe it's worth the extra hassle,
> due to having so many users already on GitHub. But if Bram is not going
> to use pull requests, then I think finding a provider that supports the
> following features would be best:
> 
>  * Ability to link a git and Mercurial repository together under one
>project/folder
>  * Ability to have a shared issue tracker.
> 
> Optional: automatic mirroring/conversion/syncing between the two systems
> 
> I don't think BitBucket can do linked/organized repositories (there is
> an open issue:
> https://bitbucket.org/site/master/issue/2323/create-a-way-to-group-repositories)
> and I KNOW GitHub doesn't support Mercurial. I *think* Kiln can do these
> things (but maybe not the automatic mirror unless they re-enable their
> Harmony feature). Does anyone know of other sites that can do all these
> things and make it easy?

/lcd

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the