björn wrote:
> Finally, I really think we need to do something about the smaller
> sized icons: they are completely illegible.

I believe this is an important point.

If you look at XCode's documen icons at 16x16 (screenshot below, to
the left) you will see that you can tell at a glance whether the file
is .C source code, .H header, or anything else of import.  The large
(relatively to the icon size) and colored text, "C" or "H", helps a lot.

Larger icons can still use the Preview paradigm (blank paper + app
icon + type text below) but IMHO the smaller icons should follow what
XCode does.

If we want people to be able to tell the files that are associated
with Vim from those associated with XCode, we can come up with a
different graphical hint, such as a colored border--this is just the
first idea that came to my mind:


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

Tobia

On 1 Dec 2008, at 11:07, Tobia Conforto wrote:

> björn wrote:
>> Finally, I really think we need to do something about the smaller
>> sized icons: they are completely illegible.
>
> I believe this is an important point.
>
<snip/>
> If we want people to be able to tell the files that are associated
> with Vim from those associated with XCode, we can come up with a
> different graphical hint, such as a colored border--this is just the
> first idea that came to my mind:
>

I'm not szo sure that it's important. What's important to me is that the
file is a C source file, or a BASH script, or a SQL script. I can make a
choice about which application to open them with, once I know what the
file type IS

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

Andrew Long wrote:
>> If we want people to be able to tell the files that are associated
>> with Vim from those associated with XCode, we can come up with a
>> different graphical hint, such as a colored border
>
> I'm not szo sure that it's important. What's important to me is that
> the file is a C source file, or a BASH script, or a SQL script. I
> can make a choice about which application to open them with, once I
> know what the file type IS

Absolutely.
Maybe it wasn't clear from my post, butI agree that the file type
comes first.
XCode-like colors (C is blue, H is red...) help with that.


Tobia

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

> > Finally, I really think we need to do something about the smaller  
> > sized icons: they are completely illegible.
>
> I believe this is an important point.
>
> If you look at XCode's documen icons at 16x16 (screenshot below, to  
> the left) you will see that you can tell at a glance whether the file  
> is .C source code, .H header, or anything else of import.  The large  
> (relatively to the icon size) and colored text, "C" or "H", helps a lot.

I agree XCode's 16x16 icons are nice. The main reason why I didn't try
to go with 16x16 icons similar to them is that I couldn't come up with
a way to handle longer extensions (e.g. "html").

> Larger icons can still use the Preview paradigm (blank paper + app  
> icon + type text below) but IMHO the smaller icons should follow what  
> XCode does.

It's not just the "Preview paradigm": Lots of other apps do this, too.
Examples include Safari, CSSEdit, Instruments, Pages, Keynote,
QuickTime Player, iCal, Coda, etc. Some of those programs leave the
extension text out in the 16x16 variant and include only the icon
(Instruments, CSSEdit).

I think the 32x32 variant is still legible, so we're only talking
about 16x16 here.

XCode's approach works fine with 1-char extensions (h, c), ok with 2-
char extensions (mm, rb, ...), not-so-great with three chars (e.g.
expfile.icns in the XCode bundle), not-at-all with 4-char extensions
(nasmfile.icns).

> If we want people to be able to tell the files that are associated  
> with Vim from those associated with XCode, we can come up with a  
> different graphical hint, such as a colored border--this is just the  
> first idea that came to my mind:

Perhaps we could also put the green square behind the letters (with a
very low contrast). But: It's different from all other apps, and I
need a good suggestion how to handle document types with a long
extension that don't have an obvious shorter version ("Python" can
become "Py" without problems, but what about, say, "html", "xhtml",
"dylan", "fscript", "applescript").

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

On 2008-12-02, at 16:11, Rick wrote:

> (Now that I've found Pathfinder my only beef with the Mac OS is  1)
> I can't stand how many applications, including some Mac specfic
> ones, like Safari will not maximize to full screen when the maximize
> button is hit

(I don't understand why so many people like to maximize windows. The
message part of my Mail window is 400 pixels wide, and my compose
window is about the same. Most websites with hard-widths have them set
at 700-800 pixels, and fluid-width pages are terrible to read at much
greater. It's impossible to visually scan wide text. So why waste 55%
of my display on a web page's background? (I'm on 1440x900.))

> 2) It's silly that you can only drag one corner to resize windows.
> (Finder also sucked the big one compared to linux file managers, but
> pathfinder makes up for it.)


(I use <http://www.atomicbird.com/mondomouse>, there are others.)



Jonathon Mah
me@...



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

Le 2 déc. 08 à 06:55, Jonathon Mah a écrit :

> On 2008-12-02, at 16:11, Rick wrote:
>
>> (Now that I've found Pathfinder my only beef with the Mac OS is  1)
>> I can't stand how many applications, including some Mac specfic
>> ones, like Safari will not maximize to full screen when the maximize
>> button is hit
>
> (I don't understand why so many people like to maximize windows. The
> message part of my Mail window is 400 pixels wide, and my compose
> window is about the same. Most websites with hard-widths have them set
> at 700-800 pixels, and fluid-width pages are terrible to read at much
> greater. It's impossible to visually scan wide text. So why waste 55%
> of my display on a web page's background? (I'm on 1440x900.))

simply because people don't use their display the way you do doesn't
mean there is no other way. I don't switch between applications the way
my wife does, but I quit trying to tell her the Best Way(r) because it
just doesn't work. I just try not to look at the screen while she uses
the mouse :-) And judging people's efficiency and productivity based on
assumptions gives you the same results as for optimizing software
without
benchmarking first: crap.

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

On Dec 2, 12:41 am, Rick <ric...@...> wrote:
> On Wed, Nov 19, 2008 at 1:59 PM, 703designs <thomasmal...@...> wrote:
>
> > I really wish that Apple gave us more choice in this respect...I may
> > end up running Linux on a ThinkPad (T) plus Windows virtualized for PS
> > and Illustrator. But I hate to have to leave Mac OS, and one killer
> > feature for Macs is font support.
>
> I've tried numerous times to stick to using Linux and always wind up feeling
> so much better when I switch back to OSX. Something just feels right when
> using my Mac. I can't even always put my finger on it, since I typically
> manage to get most things working how I like using Ubuntu or SuSE, it's just
> never the same though as how things 'feel' when using my mbp. OSX with
> Pathfinder installed (a must have finder replacement if you ask
mehttp://cocoatech.com/)
> is the closest thing to a perfect OS. (Now that I've
> found Pathfinder my only beef with the Mac OS is  1) I can't stand how many
> applications, including some Mac specfic ones, like Safari will not maximize
> to full screen when the maximize button is hit and 2) It's silly that you
> can only drag one corner to resize windows. (Finder also sucked the big one
> compared to linux file managers, but pathfinder makes up for it.)


I also use MondoMouse for resizing (and moving) windows from any
corner.  For maximizing I just use an applescript and bind it to a
hotkey. Most apps play nice with that approach - although I haven't
got an intelligent approach for handling multiple monitors as of yet
(i.e., maximize only to the monitor the window is on...).

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

Brian Wolven wrote:
> I also use MondoMouse for resizing (and moving) windows from any
> corner.  For maximizing I just use an applescript and bind it to a
> hotkey. Most apps play nice with that approach - although I haven't
> got an intelligent approach for handling multiple monitors as of yet
> (i.e., maximize only to the monitor the window is on...)

While we're on a OT thread :-) does anybody know a way to send the
current window to the back?  Meaning behind all other windows.  It's
the opposite of clicking on it, which will bring it to the front.

Some modifier + mouse click would be best, but a hotkey will do as well.


Tobia

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

2008/12/1 Nico Weber <nicolasweber@...>:
>
> I think the 32x32 variant is still legible, so we're only talking
> about 16x16 here.

I like the newer 32x32 icons too...I find it easy to read the "VIM"
written on them.

> XCode's approach works fine with 1-char extensions (h, c), ok with 2-
> char extensions (mm, rb, ...), not-so-great with three chars (e.g.
> expfile.icns in the XCode bundle), not-at-all with 4-char extensions
> (nasmfile.icns).
>
>> If we want people to be able to tell the files that are associated
>> with Vim from those associated with XCode, we can come up with a
>> different graphical hint, such as a colored border--this is just the
>> first idea that came to my mind:
>
> Perhaps we could also put the green square behind the letters (with a
> very low contrast). But: It's different from all other apps, and I
> need a good suggestion how to handle document types with a long
> extension that don't have an obvious shorter version ("Python" can
> become "Py" without problems, but what about, say, "html", "xhtml",
> "dylan", "fscript", "applescript").

I can't think of any way to deal with the 16x16 icons in a consistent
way so I suggest we simply put the green diamond (without the "V") on
the 16x16 icon and leave out the extension.  (Even the "V" is hard to
distinguish at 16x16 which is why I think we should leave it out.)

The one-letter (and maybe two-letter) extensions could have icons
similar to the XCode ones, but as for the rest I think there is not
much we can do.  Maybe we can experiment with this more later on?

Björn

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

> The one-letter (and maybe two-letter) extensions could have icons
> similar to the XCode ones, but as for the rest I think there is not
> much we can do.  Maybe we can experiment with this more later on?

Sounds good. Let's get the original, blurry version merged first.
After that, I'll prepare a patch for the "nice 32x32" version, and
when that is merged, I'll see if I have come up with nice 16x16 until
then.

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

> I am hoping we won't find any major problems with this snapshot so
> that I can update the appcast in a couple of days.

Grabbed it from the appcast last night and ran into a strange problem,
my system.log has filled with 2GB of MacVim messages, all alike:

Vim[46889:713] Exception caught when processing command queue:
"connection is invalid"

Not sure what I may have done to trigger it, it happened overnight
when I left a MacVim window open.

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

2008/12/2 Brian Palmer <BackupBrian@...>:
>
> Grabbed it from the appcast last night and ran into a strange problem,
> my system.log has filled with 2GB of MacVim messages, all alike:
>
> Vim[46889:713] Exception caught when processing command queue:
> "connection is invalid"
>
> Not sure what I may have done to trigger it, it happened overnight
> when I left a MacVim window open.

Argh!  I thought I'd managed to work around that problem with snap 39.
  There should have been other messages logged as well though; can you
look for messages starting with "outputQueue(len:" and send it to me?
Also, any other messages except the above are of interest.  If there
are no other messages at all that would also be of interest to me (it
seems that this is the case, but please look before other messages
first).

Thanks,
Björn

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

For resizing you can also use Afloat (http://www.macupdate.com/
info.php/id/22237/afloat), which is even free.

On Dec 2, 4:20 pm, Brian Wolven <brian.wol...@...> wrote:
> On Dec 2, 12:41 am, Rick <ric...@...> wrote:
>
>
>
> > On Wed, Nov 19, 2008 at 1:59 PM, 703designs <thomasmal...@...> wrote:
>
> > > I really wish that Apple gave us more choice in this respect...I may
> > > end up running Linux on a ThinkPad (T) plus Windows virtualized for PS
> > > and Illustrator. But I hate to have to leave Mac OS, and one killer
> > > feature for Macs is font support.
>
> > I've tried numerous times to stick to using Linux and always wind up feeling
> > so much better when I switch back to OSX. Something just feels right when
> > using my Mac. I can't even always put my finger on it, since I typically
> > manage to get most things working how I like using Ubuntu or SuSE, it's just
> > never the same though as how things 'feel' when using my mbp. OSX with
> > Pathfinder installed (a must have finder replacement if you ask
mehttp://cocoatech.com/)
> > is the closest thing to a perfect OS. (Now that I've
> > found Pathfinder my only beef with the Mac OS is  1) I can't stand how many
> > applications, including some Mac specfic ones, like Safari will not maximize
> > to full screen when the maximize button is hit and 2) It's silly that you
> > can only drag one corner to resize windows. (Finder also sucked the big one
> > compared to linux file managers, but pathfinder makes up for it.)
>
> I also use MondoMouse for resizing (and moving) windows from any
> corner.  For maximizing I just use an applescript and bind it to a
> hotkey. Most apps play nice with that approach - although I haven't
> got an intelligent approach for handling multiple monitors as of yet
> (i.e., maximize only to the monitor the window is on...).
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi all,

I have finally figured out why Vim processes were "leaking" when
Quickstart is enabled and pushed a patch which should fix this bug
(the problem was that the flag "isTerminating" was not being set early
enough so the processes didn't realize they should die).  It should
also mean that the following kind of messages won't fill up peoples
log files anymore:

   Exception caught when processing command queue: "connection is invalid"

If anybody who has this problem compiles their own binary then please
let me know asap if you are still seeing this problem.  Everybody else
should wait for the next snapshot.

Thanks to everybody who reported this problem.

Björn

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

Never looked into it. Apple + ` is pretty close though.

Thomas

On Dec 2, 10:59 am, Tobia Conforto <tobia.confo...@...> wrote:
> Brian Wolven wrote:
> > I also use MondoMouse for resizing (and moving) windows from any  
> > corner.  For maximizing I just use an applescript and bind it to a  
> > hotkey. Most apps play nice with that approach - although I haven't  
> > got an intelligent approach for handling multiple monitors as of yet  
> > (i.e., maximize only to the monitor the window is on...)
>
> While we're on a OT thread :-) does anybody know a way to send the  
> current window to the back?  Meaning behind all other windows.  It's  
> the opposite of clicking on it, which will bring it to the front.
>
> Some modifier + mouse click would be best, but a hotkey will do as well.
>
> Tobia
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Wed, Dec 3, 2008 at 9:20 AM, björn <bjorn.winckler@...> wrote:
>
> Hi all,
>
> I have finally figured out why Vim processes were "leaking" when
> Quickstart is enabled and pushed a patch which should fix this bug
> (the problem was that the flag "isTerminating" was not being set early
> enough so the processes didn't realize they should die).  It should
> also mean that the following kind of messages won't fill up peoples
> log files anymore:
>
>  Exception caught when processing command queue: "connection is invalid"
>
> If anybody who has this problem compiles their own binary then please
> let me know asap if you are still seeing this problem.  Everybody else
> should wait for the next snapshot.
>
> Thanks to everybody who reported this problem.
>

Thank you for this. I've been testing it for a couple of days and it
seems fixes the problem.

--
Kent

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

http://zanazan.am/vim/

I have yet to try it so I might be prematurely posting in regards to
this (I'm at work :P), but has anyone tried the patches at the link.

Either way if your an erlang hacker using vim send me an email I'd
like to hear about it, as i have no desire to learn emacs.

best

-john

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

Perhaps you should be mailing the general Vim list:

	 vim_use@googlegroups.com

  From headers of a message on that list:

List-Help: <mailto:vim_use+help@googlegroups.com>
List-Unsubscribe: <http://googlegroups.com/group/vim_use/subscribe>,
<mailto:vim_use+unsubscribe@googlegroups.com>

--Ted

johnbender wrote:
>
> http://zanazan.am/vim/
>
> I have yet to try it so I might be prematurely posting in regards to
> this (I'm at work :P), but has anyone tried the patches at the link.
>
> Either way if your an erlang hacker using vim send me an email I'd
> like to hear about it, as i have no desire to learn emacs.
>
> best
>
> -john
>
> >
>

--
Ted Pavlic <ted@...>

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

Hello! MacVim does a lot of things I wish I had previously, so thanks
so much for it. I did have a couple tweaks with the tab bar though.
First, I don't need the tab button so I disabled it. Second, the
starting width of the tab was a little small, so I resized it to
Terminal.app's 200px default. Third, I didn't like how the tabs were
truncated on the right side. That left me with tabs like:

| /U/S/e/P/f/l/...   | /U/S/e/P/f/l/...    | __init__.py |

Which weren't that helpful. Since it didn't look like PSMTabBarControl
actually exposes that, I hacked that in too. It'd be a lot better to
have these as .gvimrc options though, but I couldn't figure out how to
do that. One thing I definitely couldn't do was allowing you to tear
off a tab into it's own window. Is there an easy way to do that?

Anyway, here's the patch to do all these crazy things. Thanks!


diff --git a/src/MacVim/MMAppController.m b/src/MacVim/
MMAppController.m
index 91307d9..bb2d097 100644
--- a/src/MacVim/MMAppController.m
+++ b/src/MacVim/MMAppController.m
@@ -161,7 +161,7 @@ fsEventCallback(ConstFSEventStreamRef streamRef,
          [NSNumber numberWithBool:NO],   MMNoWindowKey,
          [NSNumber numberWithInt:64],    MMTabMinWidthKey,
          [NSNumber numberWithInt:6*64],  MMTabMaxWidthKey,
-        [NSNumber numberWithInt:132],   MMTabOptimumWidthKey,
+        [NSNumber numberWithInt:200],   MMTabOptimumWidthKey,
          [NSNumber numberWithInt:2],     MMTextInsetLeftKey,
          [NSNumber numberWithInt:1],     MMTextInsetRightKey,
          [NSNumber numberWithInt:1],     MMTextInsetTopKey,
diff --git a/src/MacVim/MMVimView.m b/src/MacVim/MMVimView.m
index 0836343..6968456 100644
--- a/src/MacVim/MMVimView.m
+++ b/src/MacVim/MMVimView.m
@@ -129,7 +129,7 @@ enum {
      [tabBarControl setCellOptimumWidth:
                                       [ud
integerForKey:MMTabOptimumWidthKey]];

-    [tabBarControl setShowAddTabButton:YES];
+    [tabBarControl setShowAddTabButton:NO];
      [[tabBarControl addTabButton] setTarget:self];
      [[tabBarControl addTabButton] setAction:@selector(addNewTab:)];
      [tabBarControl setAllowsDragBetweenWindows:NO];
diff --git a/src/MacVim/PSMTabBarControl/source/PSMAquaTabStyle.m b/
src/MacVim/PSMTabBarControl/source/PSMAquaTabStyle.
index dba0250..1a69657 100644
--- a/src/MacVim/PSMTabBarControl/source/PSMAquaTabStyle.m
+++ b/src/MacVim/PSMTabBarControl/source/PSMAquaTabStyle.m
@@ -288,7 +288,7 @@
      // Paragraph Style for Truncating Long Text
      if (!truncatingTailParagraphStyle) {
          truncatingTailParagraphStyle = [[[NSParagraphStyle
defaultParagraphStyle] mutableCopy] retain];
-        [truncatingTailParagraphStyle
setLineBreakMode:NSLineBreakByTruncatingTail];
+        [truncatingTailParagraphStyle
setLineBreakMode:NSLineBreakByTruncatingHead];
          [truncatingTailParagraphStyle
setAlignment:NSCenterTextAlignment];
      }
      [attrStr addAttribute:NSParagraphStyleAttributeName
value:truncatingTailParagraphStyle range:range];
diff --git a/src/MacVim/PSMTabBarControl/source/PSMMetalTabStyle.m b/
src/MacVim/PSMTabBarControl/source/PSMMetalTabStyl
index 3113480..85c59b7 100644
--- a/src/MacVim/PSMTabBarControl/source/PSMMetalTabStyle.m
+++ b/src/MacVim/PSMTabBarControl/source/PSMMetalTabStyle.m
@@ -302,7 +302,7 @@ void MyNSDrawWindowBackground(NSRect rect)
      // Paragraph Style for Truncating Long Text
      if (!truncatingTailParagraphStyle) {
          truncatingTailParagraphStyle = [[[NSParagraphStyle
defaultParagraphStyle] mutableCopy] retain];
-        [truncatingTailParagraphStyle
setLineBreakMode:NSLineBreakByTruncatingTail];
+        [truncatingTailParagraphStyle
setLineBreakMode:NSLineBreakByTruncatingHead];
          [truncatingTailParagraphStyle
setAlignment:NSCenterTextAlignment];
      }
      [attrStr addAttribute:NSParagraphStyleAttributeName
value:truncatingTailParagraphStyle range:range];
diff --git a/src/MacVim/PSMTabBarControl/source/PSMUnifiedTabStyle.m b/
src/MacVim/PSMTabBarControl/source/PSMUnifiedTab
index 2bd5976..5025a80 100644
--- a/src/MacVim/PSMTabBarControl/source/PSMUnifiedTabStyle.m
+++ b/src/MacVim/PSMTabBarControl/source/PSMUnifiedTabStyle.m
@@ -272,7 +272,7 @@
      // Paragraph Style for Truncating Long Text
      if (!truncatingTailParagraphStyle) {
          truncatingTailParagraphStyle = [[[NSParagraphStyle
defaultParagraphStyle] mutableCopy] retain];
-        [truncatingTailParagraphStyle
setLineBreakMode:NSLineBreakByTruncatingTail];
+        [truncatingTailParagraphStyle
setLineBreakMode:NSLineBreakByTruncatingHead];
      }
      [attrStr addAttribute:NSParagraphStyleAttributeName
value:truncatingTailParagraphStyle range:range];


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

Hi Erick,

On 07.12.2008, at 20:10, Erick Tryzelaar wrote:

> Hello! MacVim does a lot of things I wish I had previously, so thanks
> so much for it. I did have a couple tweaks with the tab bar though.
> First, I don't need the tab button so I disabled it. Second, the
> starting width of the tab was a little small, so I resized it to
> Terminal.app's 200px default. Third, I didn't like how the tabs were
> truncated on the right side. That left me with tabs like:
>
> | /U/S/e/P/f/l/...   | /U/S/e/P/f/l/...    | __init__.py |

See `:h guitablabel`

> One thing I definitely couldn't do was allowing you to tear
> off a tab into it's own window. Is there an easy way to do that?

No, that's not easy to do. See this thread:
http://groups.google.com/group/vim_mac/browse_thread/thread/9ce1cdbbefc27316/788\
9815165a94d21

Nico

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

On Sun, Dec 7, 2008 at 9:06 PM, Nico Weber <nicolasweber@...> wrote:
> See `:h guitablabel`

Thanks Nico. I was looking at that, but I couldn't get it to do what I
wanted. Unless there's something I missed, it looks like it's the tab
control that's stripping off the trailing characters. Is it possible
to detect the width of the control so that a vim function could
dynamically rewrite the title of the right size?

>> One thing I definitely couldn't do was allowing you to tear
>> off a tab into it's own window. Is there an easy way to do that?
>
> No, that's not easy to do. See this thread:
http://groups.google.com/group/vim_mac/browse_thread/thread/9ce1cdbbefc27316/788\
9815165a94d21

Oh, yeah, looks like a very hard problem. Nevermind then :)

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

Right.

On Dec 7, 10:31 am, Ted Pavlic <t...@...> wrote:
> Perhaps you should be mailing the general Vim list:
>
>         vim_use@googlegroups.com
>
>  From headers of a message on that list:
>
> List-Help: <mailto:vim_use+help@googlegroups.com>
> List-Unsubscribe: <http://googlegroups.com/group/vim_use/subscribe>,
> <mailto:vim_use+unsubscribe@googlegroups.com>
>
> --Ted
>
>
>
> johnbender wrote:
>
> >http://zanazan.am/vim/
>
> > I have yet to try it so I might be prematurely posting in regards to
> > this (I'm at work :P), but has anyone tried the patches at the link.
>
> > Either way if your an erlang hacker using vim send me an email I'd
> > like to hear about it, as i have no desire to learn emacs.
>
> > best
>
> > -john
>
> --
> Ted Pavlic <t...@...>
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Can vim-cocoa be run as console only?

Robert


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

Answered this myself by using /Applications/Vim.app/Contents/MacOS/Vim



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

Additionally, you can use a script (like the existing gvim and mvim
scripts) to call /App*/Vim ...

*) As a Terminal mode app when symlinked to vi or vim
*) As a GUI app when called otherwise

--Ted

R. Hicks wrote:
>
> Answered this myself by using /Applications/Vim.app/Contents/MacOS/Vim
>
>
>
> >
>

--
Ted Pavlic <ted@...>

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

Hi Erick,

Thanks for the patch.

2008/12/8 Erick Tryzelaar <erick.tryzelaar@...>:
>
> First, I don't need the tab button so I disabled it.

Ok, but I don't really see the need to have it disabled by default
since it hides itself when the tabline is filled up anyway.  If
anybody else disagrees with me, then please speak up (it would be easy
enough to add a user default to disable this button if some people
prefer not to have this button).

> Second, the
> starting width of the tab was a little small, so I resized it to
> Terminal.app's 200px default.

You don't need to modify the source code to do this.  Open Terminal and type:

defaults write org.vim.MacVim MMTabOptimumWidth 200

and restart MacVim (see ":h macvim-prefs" and ":h macvim|/mmtab").  (I
personally think 200px looks a bit too wide.)

> Third, I didn't like how the tabs were
> truncated on the right side. That left me with tabs like:
>
> | /U/S/e/P/f/l/...   | /U/S/e/P/f/l/...    | __init__.py |
>
> Which weren't that helpful. Since it didn't look like PSMTabBarControl
> actually exposes that, I hacked that in too. It'd be a lot better to
> have these as .gvimrc options though, but I couldn't figure out how to
> do that.

Yes, it does seem to make more sense to have the tab labels truncate
from the left instead of on the right.  Does anybody else care to
weigh in on this?  I'll have to try it out myself for a bit to see if
left truncation is better than right truncation before I'd merge this
change.

Thanks,
Björn

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

On Tue, Dec 9, 2008 at 11:55 AM, björn <bjorn.winckler@...> wrote:
>> First, I don't need the tab button so I disabled it.
>
> Ok, but I don't really see the need to have it disabled by default
> since it hides itself when the tabline is filled up anyway.  If
> anybody else disagrees with me, then please speak up (it would be easy
> enough to add a user default to disable this button if some people
> prefer not to have this button).

Oh sure, it was just something I wanted myself, I don't expect you you
actually integrate this patch, it was more just to demonstrate the
kind of functionality I was looking for. Having it be a user default
would be exactly what I'd be looking for.

>
>> Second, the
>> starting width of the tab was a little small, so I resized it to
>> Terminal.app's 200px default.
>
> You don't need to modify the source code to do this.  Open Terminal and type:
>
> defaults write org.vim.MacVim MMTabOptimumWidth 200
>
> and restart MacVim (see ":h macvim-prefs" and ":h macvim|/mmtab").  (I
> personally think 200px looks a bit too wide.)

That's great! I didn't know you could do that. I looked through the
":h macvim" docs, but I didn't see that listed. Thanks so much for
that.

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

> Yes, it does seem to make more sense to have the tab labels truncate
> from the left instead of on the right.  Does anybody else care to
> weigh in on this?  I'll have to try it out myself for a bit to see if
> left truncation is better than right truncation before I'd merge this
> change.

I agree that it makes more sense.

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