Hello

Has anybody had any success in merging the var-tabstops branch with
MacVim? I thought it would be easy, as the two branches must have a
common ancestor, but when I tried it gave me endless conflicts. What
am I missing? If anybody knows any better, any help is appreciated.

git://repo.or.cz/vim_extended.git/refs/heads/feat/var-tabstops

This is an unofficial branch which adds a 'tabstops' option, to set a
list of tab stops instead of a single value (for example, the first
stop at 8, then at 20, 50...) It's most useful when editing tab-
separated values or other tabular data, especially when combined with
some vimscript to auto-detect the optimal list of tab stops.

Tobia
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> > This did the trick for me (Python 2.6, transparency supported if
> > "experimental" renderer is enabled in the Advanced preferences):
>
> >  ./configure --enable-perlinterp --enable-pythoninterp
> > --enable-rubyinterp --with-features=huge --enable-cscope; make clean;
> > make
>
> > You really don't need all those extra flags you specified by the way.
>
> > Björn

Nice job!
Finally a 10.6 SDK version with transparency *and* python 2.6 ^^
--> proof: http://skitch.com/shirkrin/nes3d/fullscreen

And for all the curious out there my build steps:
- git clean -fxd
- ./configure --enable-perlinterp --enable-pythoninterp --enable-
rubyinterp --with-features=huge --enable-gui=macvim --with-
tlib=ncurses --enable-multibyte --with-python-config-dir=/System/
Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/
--with-macsdk=10.6
- Enable the 'experimental' renderer

Keep up the good work Björn!

Cheers,
Shirk


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

If anybody is interested, here is Václav Šmilauer's breakindent patch,
merged into the latest MacVim.

The breakindent patch adds a couple options to display "soft-wrapped"
lines flush left at the proper indentation level, instead of at column
1. Used together with showbreak, it can make editing source files with
long lines much easier.

In the screenshot, all lines starting with ¬ are actually wrapping
over from the previous line. I use this autocommand to detect when
shiftwidth has been changed from the default, and adjust the other
settings accordingly:

au FileType * if &sw<8 |setl bri lbr sbr=¬\  |let &l:brishift=&sw |endif

-Tobia

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi there,

I am trying to install vim_mac on my Mac OSX, but I have not been
successful.  Do I have to build the program using the source code, or
is there a .dmg file that will take care of things.  I have been
confused because it seems like the  MacVim 7.2 stable 1.2 should be
self-installing?  Or did I miss something.  I would really appreciate
any help.

-Erica

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

New renderer is lightning fast! Thanks Bjorn :D

(not stumbled into any glitches yet)

On Nov 24, 1:33 am, Craig <craig.em...@...> wrote:
> I've seen some weird re-draw failures with 'experimental rendering' and
> vsplit.
> I'll supply a screenshot next time I'm on my Mac (it's @ work).
>
> -C
>
> 2009/11/22 björn <bjorn.winck...@...>
>
>
>
> > Hi Yongwei,
>
> > 2009/11/22 Yongwei Wu:
>
> > > One negative report on the new renderer: the option 'guifontwide'
> > > seems to have stopped working. :-(
>
> > Ah...yes, I did not yet get around to implementing it.  Thanks for the
> > reminder.
>
> > I'm sure there are plenty more things that I did not yet think of...if
> > anybody notices problems like this, just let me know and I'll try to
> > have them implemented in time for the next snapshot.
>
> > Björn
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

2009/11/24 Craig:
> I've seen some weird re-draw failures with 'experimental rendering' and
> vsplit.
> I'll supply a screenshot next time I'm on my Mac (it's @ work).

A screenshot won't be terribly helpful: try to come up with some
simple steps to reproduce the problem instead.

Thanks,
Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

2009/11/23 Tobia Conforto:
>
> Has anybody had any success in merging the var-tabstops branch with
> MacVim? I thought it would be easy, as the two branches must have a
> common ancestor, but when I tried it gave me endless conflicts. What
> am I missing? If anybody knows any better, any help is appreciated.
>
> git://repo.or.cz/vim_extended.git/refs/heads/feat/var-tabstops

Tobia,

The MacVim repo is not based on the vim_extended repo (it was created
after I set up the MacVim repo).  There was a discussion on vim_dev a
while back regarding rebasing MacVim.git on top of vim_extended.git
which would simplify the merging of unofficial patches, but  I find
this dask rather daunting.  As far as I can tell, the only way to
accomplish this is to apply all MacVim.git commits as a series of
patches on top of vim_extended.git and this way I'll loose all dates
when each MacVim commit was performed (they'll all have the same
date).

If somebody were to tell me how to "merge" the two repositories whilst
retaining all original commit information from the MacVim.git repo I'd
consider doing this, but until then it is easier for me to simply keep
things the way they are.

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Am 24.11.2009 um 16:59 schrieb Craig:

> If I open any file and then do
> :bel vert new
> or
> :vsplit
> the upper half of the initial buffer isn't redrawn properly
> This happens consistently.
:vsplit or :vnew split vertically - did you mean just :new?

Can't reproduce in in current git-built (10.6 SDK, experimental renderer +
transparency).
Neither vertical nor horizontal splits / new buffers cause any redrawing issues.

However I remember this behavior with pre-snapshot-51 git builds,
but it seems to be gone since then.

Cheers,
Shirk

--------------------------------------------------------------------------------\
--
BitSpin.org - don't get twisted up!
--------------------------------------------------------------------------------\
--

My keyboard goes dead when I'm using MacVim.  This has now happened
twice.  I have to logout and log back in to get the keyboard to work.

Has anyone else noticed this problem and is there a solution to it?

Thanks very much.


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Now I see.

I'm not sure what's the best way of doing it either, but your idea
sounds good. Did you investigate the possibility of faking the commit
dates?

Seeing as Git is a distributed system, I don't see why you shouldn't
be able to set arbitrary commit dates, with a custom rebasing script.
At worst, you'll have to compile a custom git, hacking around the
getdate() call, to accept a commandline parameter with the date to
use. Then, after the macvim patches are rebased on top of an old vim-
extended commit, automatic merges (both ways) will be possible. The
only real downside is that all commits would change hash.

In my case, I'll try to see if vim_extended tracks vim trunk someway,
then I'll format a patch from the branch I'm interested in and apply
it to macvim. That should be smoother.

Tobia
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Am 24.11.2009 um 19:30 schrieb Tobia Conforto:

>
> Now I see.
>
> I'm not sure what's the best way of doing it either, but your idea
> sounds good. Did you investigate the possibility of faking the commit
> dates?
>
> Seeing as Git is a distributed system, I don't see why you shouldn't
> be able to set arbitrary commit dates, with a custom rebasing script.
> At worst, you'll have to compile a custom git, hacking around the
> getdate() call, to accept a commandline parameter with the date to
> use. Then, after the macvim patches are rebased on top of an old vim-
> extended commit, automatic merges (both ways) will be possible. The
> only real downside is that all commits would change hash.
>
> In my case, I'll try to see if vim_extended tracks vim trunk someway,
> then I'll format a patch from the branch I'm interested in and apply
> it to macvim. That should be smoother.
>
> Tobia

Pleas, both of you -- stop reinventing the wheel!

Git has two tools working hand in hand to just do what is needed:

#1 is git format-patch which will transform a series of commits into
mailbox-formated
  messages containing the specified commit as a patch
#2 is git am which will import (re-apply) the patches in a given directory in
order.

git am has a switch to explicitly *not* use the original commit date:

        --ignore-date
            By default the command records the date from the e-mail message as
the commit author date, and uses the time of commit creation as the committer
date.
            This allows the user to lie about the author date by using the same
value as the committer date.

Which basically means - you can convert the whole vim_mac repo into patches (one
per commit).
Put them into a directory and then apply them to another repository using git
am.

If all goes well you will end up with a repository containing all patches with
their
respective author and original commit date.

Cheers,

--------------------------------------------------------------------------------\
--
BitSpinn.org - don't get twisted up!
--------------------------------------------------------------------------------\
--

2009/11/24 Birdie Edwards:
>
> My keyboard goes dead when I'm using MacVim.  This has now happened
> twice.  I have to logout and log back in to get the keyboard to work.
>
> Has anyone else noticed this problem and is there a solution to it?

I doubt MacVim has anything to do with this.  I'm guessing you have an
Apple wireless keyboard?  I have had similar experiences with those...

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

2009/11/24 Craig:
> If I open any file and then do
> :bel vert new
> or
> :vsplit
> the upper half of the initial buffer isn't redrawn properly
> This happens consistently.

Thanks for Craig, I can reproduce this.  I'll see what I can do...

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

2009/11/24 René Köcher:
>
> Pleas, both of you -- stop reinventing the wheel!
>
> Git has two tools working hand in hand to just do what is needed:
>
> #1 is git format-patch which will transform a series of commits into
mailbox-formated
>  messages containing the specified commit as a patch
> #2 is git am which will import (re-apply) the patches in a given directory in
order.

This is exactly what I was referring to in my email and what has
already been done [1].

> git am has a switch to explicitly *not* use the original commit date:
>
>       --ignore-date
>           By default the command records the date from the e-mail message as
the commit author date, and uses the time of commit creation as the committer
date.
>           This allows the user to lie about the author date by using the same
value as the committer date.
>
> Which basically means - you can convert the whole vim_mac repo into patches
(one per commit).
> Put them into a directory and then apply them to another repository using git
am.

Aha!  But here is a switch I did not know about!  Thanks for pointing
it out.  I'll look into this when I get the time.  But...this is not
something I enjoy doing so it will take a while before I get around to
fiddling around with this.  (And I know that there are multiple
conflicts due to the fact that I merge the latest runtime updates into
the "vim" branch in MacVim.git.)

Another problem is that Markus explicitly points out that he'll
rewrite the entire vim_mainline repository at some point in the future
[2] and I'm not sure what kind of problems this would cause me.

Björn


[1] http://repo.or.cz/w/MacVim_ext.git
[2] http://repo.or.cz/w/vim_mainline.git

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I was unaware of "mousekeys".  Thanks very much for the heads-up.  I
admit that I have trouble relating it to MacVim.  There is no key-
sequence in Vim that shuts down the keyboard? (which would be
bizarre).

Thanks again.

On Nov 25, 1:11 am, Tyson Roberts <nallo...@...> wrote:
> Make sure you aren't triggering mousekeys.  This toggles on some systems if
> you hit option 5 times in a short period (listen for a short ascending or
> descending sound).  I've had that happen to me, and it's annoying.
>
> You can find the option in Universal Access if you need to disable it.
>
> - Tyson
>
> On Wed, Nov 25, 2009 at 2:03 AM, Birdie Edwards <jsmg...@...> wrote:
>
> > My keyboard goes dead when I'm using MacVim.  This has now happened
> > twice.  I have to logout and log back in to get the keyboard to work.
>
> > Has anyone else noticed this problem and is there a solution to it?
>
> > Thanks very much.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Has anybody else noticed that some colors are off, between the classic renderer
and the experimental renderer?

DigitalColorMeter.app says that it's the classical renderer to be off... never
noticed it before though.

Tobia

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

2009/11/25 Tobia Conforto:
> Has anybody else noticed that some colors are off, between the classic
renderer and the experimental renderer?
>
> DigitalColorMeter.app says that it's the classical renderer to be off... never
noticed it before though.

Hi Tobia,

I did this more or less on purpose because there were some complaints
in the past that the colors looked too washed out with the default
renderer.

The default renderer uses "calibrated" colors (i.e. they should be
adapted to the display medium to look "best possible") whereas the
experimental renderer uses device dependent colors (i.e. just use
whatever RGB values that are specified). [1]

For example, if you have two monitors of different make/model then
colors in the default renderer will probably look more uniform across
screens.  On the other hand, if you measure RGB values with
DigitalColorMeter.app the values in the default renderer will not
match whatever colors you specify e.g. in ":hi" commands inside your
syntax files (like you noticed).

I'll leave it up to MacVim users to decide which works best -- at the
moment I'm only getting your reaction; I've yet to hear somebody say
calibrated colors look better.  Maybe somebody with dual displays have
something to say in favor of calibrated colors?

Björn

[1] See, e.g.  "Which Color Space Do I Use?":

http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/DrawColor/\
Tasks/UsingColorSpaces.html#//apple_ref/doc/uid/TP40001807

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 22 Nov 2009, at 02:10, björn wrote:

>
> Hi,
>
> I have uploaded a new snapshot of MacVim.app to
>
> http://code.google.com/p/macvim/wiki/Snapshot
>
> <snip/>
>
Bjorn

This snapshot is also not built for PPCs? I still have a Powerbook running
Tiger; do I have to stay with snapshot 49, or is it likely that your build will
work for PPC too?

Regards, Andy
--
Andrew Long
andrew dot long at mac dot com






--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi Björn, hi all,

> I'll leave it up to MacVim users to decide which works best -- at the
> moment I'm only getting your reaction; I've yet to hear somebody say
> calibrated colors look better.  Maybe somebody with dual displays have
> something to say in favor of calibrated colors?

Calibrated probably sounds good at first *but*:

- Most user displays are not calibrated.
- Vim colors on other platforms are not calibrated as far as I know. I
would expect the same behaviour all platforms if I use the same vimrc.
- Since Apple switched to Windows Gamma
(http://support.apple.com/kb/HT3712) in Snow Leopard, the device colors
should be the basically the same on all platforms on the same(!) monitor.
- Browsers use uncalibrated colors for CSS-Values and (some brwosers)
only correct the colors in images with specific profiles.
(http://regex.info/blog/photo-tech/color-spaces-page3 and
http://webkit.org/blog/73/color-spaces/)
- I come from a web-design and development perspective. So everything I
do has normally uncalibrated/sRGB output, so that images (probably
calibrated) and CSS and Flash (uncalibrated) match.
The HTML5 and the CSS specifications are assuming sRGB for the most part
(http://www.w3.org/TR/css3-color/).

So *I* would expect vim to show the same color as my browser on the same
color value.  ;-)

But seriously:
It doesn't matter that much in the end, because MacVim is only the best
text editor out there, but not an image editing solution.

Frank

--
frank hellenkamp | interface designer
solmsstraße 7 | 10961 berlin

+49.30.49 78 20 70 | tel
+49.173.70 55 781 | mbl
+49.3212.100 35 22 | fax
jonas@...

http://www.depagecms.net
http://immerdasgleiche.de
http://everydayisexactlythesame.net/

2009/11/25 Andrew Long:
>
> This snapshot is also not built for PPCs? I still have a Powerbook running
Tiger; do I have to stay with snapshot 49, or is it likely that your build will
work for PPC too?

Andrew,

It is difficult to compile a universal Vim binary with all features
that supports 10.4 -- 10.6, and including PPC increases the build time
a lot.  All in all, this means a lot of time for me spent on building
snapshots and this is time I just don't have.  So in the end I decided
to only build the snapshots for Intel 10.5+ from now on.

The stable build still runs on Tiger and it is of course always
possible to build your own custom version.

Björn

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 25 Nov 2009, at 19:03, björn wrote:

>
> 2009/11/25 Andrew Long:
>>
>> This snapshot is also not built for PPCs? I still have a Powerbook running
Tiger; do I have to stay with snapshot 49, or is it likely that your build will
work for PPC too?
>
> Andrew,
>
> It is difficult to compile a universal Vim binary with all features
> that supports 10.4 -- 10.6, and including PPC increases the build time
> a lot.  All in all, this means a lot of time for me spent on building
> snapshots and this is time I just don't have.  So in the end I decided
> to only build the snapshots for Intel 10.5+ from now on.
>
> The stable build still runs on Tiger and it is of course always
> possible to build your own custom version.

Right, thanks. I'll have fre time next week, so I'll give it a go

Regards, Andy
--
Andrew Long
andrew dot long at mac dot com






--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Wed, Nov 25, 2009 at 18:13, George V. Reilly <george@...> wrote:

> ld: warning: in /Library/Frameworks//Python.framework/Python, missing
> required architecture x86_64 in file

<snip>

> $ python --version
> Python 2.6.4
> This is the most recent Python 2.6 from python.org, instead of the stock one
> from Apple, which worked the last time I built MacVim a few weeks ago.

The python from python.org does not contain 64bit binaries so to use
this version you'll need to build a 32bit MacVim.

Cheers

Adam

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Nov 25, 2009, at 7:13 PM, George V. Reilly wrote:
> ld: warning: in /Library/Frameworks//Python.framework/Python, missing required
architecture x86_64 in file

That Python seems to be 32-bit only.
MacVim was configured for 64-bit build.

> This is the most recent Python 2.6 from python.org, instead of the stock one
from Apple, which worked the last time I built MacVim a few weeks ago.

The name of that image is python-2.6.4_macosx10.3.dmg.

It's possible the last time you tried to build MacVim it was still configured
for 32-bit build, so it worked with this 32-bit Python.

You'll need to decide whether you want 64-bit or 32-bit MacVim, then link it
with a matching Python.

	 Zvezdan



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---