What's the rationale behind not using a normal PATH?
703designs
really do wish that MacVim were set up this way. Why do you guys not
acknowledge a user's PATH? GVim works otherwise on Windows and Linux.
Thanks,
Thomas
703designs
PATH. Is there a simple way to make this the default behavior
from .vimrc?
Thanks,
Thomas
Ben Schmidt
> really do wish that MacVim were set up this way. Why do you guys not
> acknowledge a user's PATH? GVim works otherwise on Windows and Linux.
Why do people not understand how environment variables work? This is not
to do with Gvim, but the system. The place to set environment variables
on the Mac for GUI applications (those started via loginwindow, the
Finder, etc.) is ~/.MacOSX/environment.plist
http://developer.apple.com/qa/qa2001/qa1067.html
Just like on Windows you set environment variables in a standard system
place (System properties) you do the same on the Mac; it's just a
different place. On Linux, it's a different place again: you alter your
shell startup files, because everything, including the window manager,
usually, is started via a shell.
However, it seems many people on the Mac don't understand this, but
alter their shell startup files and expect every other app to somehow
magically pick up the variables even though they are not started via a
shell.
But I must admit, shell startup files are a convenient way to set
variables.
So MacVim has a workaround for this: turn on 'Launch Vim processes in a
login shell' in the preferences and it should work.
However, sometimes it doesn't, because people set their PATH in the
wrong shell startup scripts. For the default shell, bash, you should be
setting your PATH in ~/.profile not ~/.bashrc (likewise /etc/profile).
Most install scripts do this correctly, but for some reason a lot of
users don't.
It will work without doing anything if you start a (Mac)Vim instance
(directly or via the mvim script) in Terminal.app, since Terminal.app
starts a shell at which you type the commands and it reads its startup
files and Vim inherits the environment from that.
It's nothing to do with what we decide to 'acknowledge' it's to do with
what we're given by whatever process started (Mac)Vim instances.
Ben.
703designs
from the Linux world (at least I cut my Unix teeth in Linux), so this
is a surprise to me. I'll set my env vars properly now, thanks!
Thomas
On Nov 12, 10:13 pm, Ben Schmidt <mail_ben_schm...@yahoo.com.au>
wrote:
David Morel
Le 13 nov. 08 à 04:13, Ben Schmidt a écrit :
>
>> I'm using a custom-compiled GVim now strictly for this reason, but I
>> really do wish that MacVim were set up this way. Why do you guys not
>> acknowledge a user's PATH? GVim works otherwise on Windows and Linux.
>
> Why do people not understand how environment variables work? This is
> not
> to do with Gvim, but the system. The place to set environment
> variables
> on the Mac for GUI applications (those started via loginwindow, the
> Finder, etc.) is ~/.MacOSX/environment.plist
>
> http://developer.apple.com/qa/qa2001/qa1067.html
>
> Just like on Windows you set environment variables in a standard
> system
> place (System properties) you do the same on the Mac; it's just a
> different place. On Linux, it's a different place again: you alter
> your
> shell startup files, because everything, including the window manager,
> usually, is started via a shell.
>
> However, it seems many people on the Mac don't understand this, but
> alter their shell startup files and expect every other app to somehow
> magically pick up the variables even though they are not started via a
> shell.
Because this is the way most Unices do. And setting env variables in the
preferences isn't half as flexible as with a shell startup script, which
I (and others) are pretty used to editing, pre- or appending stuff to
the
$PATH and other variables thanks to shell expansion. Not executing a
shell
by default is a design decision from Apple, but wrt the way Unices
behave,
and what people expect generally, it might not be the brightest they
had.
Or did I miss something?
David
703designs
a target profile on startup (browse to the file of choice).
Thomass
PitPalme
On 13 Nov., 19:15, 703designs <thomasmal...@gmail.com> wrote:
> It would be very cool if we could add a preference in MacVim to source
> a target profile on startup (browse to the file of choice).
>
> Thomass
There's already the mentioned "~/.MacOSX/environment.plist" for
permanent, "not so volatile" enviroment values.
And for everything else using the preference "Launch Vim process in a
login shell" should be sufficient, as the appropriate shell rc/profile
file can be customized to (re)set environment variables ...
What's the purpose of this "profile" to be sourced?
--
Regards,
Pit
703designs
functionality? I can't check right now; I'm at work stuck on a Windows
box.
Thanks!
Thomas
Ted Pavlic
MacVim window), it will launch it via a login shell. If it doesn't use
the login shell that you want it to use, you can configure it (with a
hidden preference settable via "defaults"). In most cases, MacVim will
pick the correct shell.
You can see
:help macvim
for more information about MacVim (and its hidden preferences).
--Ted
703designs wrote:
>
> So the "launch vim in shell" preference would provide this
> functionality? I can't check right now; I'm at work stuck on a Windows
> box.
>
--
Ted Pavlic <t...@tedpavlic.com>
Ted Pavlic
a try. See:
http://phaseportrait.blogspot.com/2007/12/file-associations-and-path-with-macvim.html
It launches MacVim via mvim from a login shell. Once upon a time
(still?) it helped with file associations as well.
--Ted
703designs
Why need MVim.app when this can be an easily configurable setting in
Preferences? I'd be happy to help with any such development effort.
Thanks,
Thomas
On Nov 13, 2:41 pm, Ted Pavlic <t...@tedpavlic.com> wrote:
> Alternatively, you can give
>
> mvim.app
>
> a try. See:
>
Ted Pavlic
> Why need MVim.app when this can be an easily configurable setting in
> Preferences? I'd be happy to help with any such development effort.
mvim.app is a slight modification of gvim.app, and both of those were
available long before the MacVim preference.
So, for...most...intents and purposes, mvim.app is deprecated due to the
*relatively* new MacVim preference. Additionally, if you read the blog
post, the purpose off gvim.app and mvim.app had to do with File
Associations. The launching in a login shell was just a bonus.
--Ted
--
Ted Pavlic <t...@tedpavlic.com>
703designs
on the Mac.
Thanks,
Thomas
David P. Henderson
On 12 Nov 2008, at 23:51, David Morel wrote:
> Because this is the way most Unices do.
Mac OS X is not most unixen. Mac OS X was designed under the
expectation that the typical user would be operating from the GUI
exclusively, so given that consideration what exactly does a command
like pwd mean? Apple's decision is to treat pwd as the directory from
which an application is launched. This is the default behavior but
can be changed by application developers to reflect more complicated
needs for their applications.
> And setting env variables in the preferences isn't half as flexible
> as with a shell startup script, which I (and others) are pretty
> used to editing, pre- or appending stuff to the $PATH and other
> variables thanks to shell expansion.
How exactly is editing prefs not as easy as editing config files? Are
you operating under the misapprehension that prefs can only be edited
in the GUI? If so, see man defaults (does the right thing
automatically) or man plutil (need to understand plist format and
know what options exist). Apple did provide a perfectly acceptable
method of passing environment vars into apps in the form of ~/.MacOSX/
environment.plist see <http://developer.apple.com/documentation/
MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html> and
<http://developer.apple.com/qa/qa2001/qa1067.html>
> Not executing a shell by default is a design decision from Apple,
> but wrt the way Unices behave, and what people expect generally, it
> might not be the brightest they had. Or did I miss something?
You are making assumptions about the user base for whom Apple
designed Mac OS X, and it was not the typical unix/linux user. Mac OS
X used designed for Macintosh users, so yes, you did miss something.
The typical Mac user neither understands nor cares about the unix end
of things and doesn't need to, but the functionality is there for
those of us who do care about such things and all we need do is edit
a hidden file which is exactly what we are used to doing on more
standard unix/linux distributions. So it's really not all that
different from edit .*rc or other config files except that the file
is a plist formatted file rather than plain text.
I hope this helps clarify and enlighten us all.
Dave
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult." -- C. A. R.
"Tony" Hoare
Ted Pavlic
I think there's still a lot of confusion about exactly why the settings
set from the login shell carry over to so many applications in UNIX. It
is not conventional to wrap every single item in a login shell; such a
convention would be ludicrous.
As already discussed, if more people actually grok'ked what was going on
in their UNIX environments, they would have no problem with how things
must be done within MacVim.
703designs
developers first used Vim in the terminal If the Mac terminal were
better, I'd probably use Vim there (Xfce and Gnome both have superior
terminal emulators).
Thomas
Timothy Grant
>
> I think that the confusion really is due to the fact that many (most?)
> developers first used Vim in the terminal If the Mac terminal were
> better, I'd probably use Vim there (Xfce and Gnome both have superior
> terminal emulators).
Just curious, what do you find lacking in Terminal.app? I didn't like
it in the 10.3 series, but have found it quite competent in the most
recent incarnation of OSX.
--
Stand Fast,
tjg. [Timothy Grant]
703designs
more customizable, etc. to me and I think that's because the Terminal
is a very high priority on a Linux box. There's not much difference
between using GVim and Vim from the Terminal in Linux. I think that my
favorite is Konsole, although being a lifetime Mac user, I gravitate
to the simpler, cleaner interfaces of Gnome and Xfce.
Thomas
On Nov 18, 3:36 pm, "Timothy Grant" <timothy.gr...@gmail.com> wrote:
Ted Pavlic
> developers first used Vim in the terminal If the Mac terminal were
> better, I'd probably use Vim there (Xfce and Gnome both have superior
> terminal emulators).
While configuration is a bit of a mess, I find iTerm to be sturdy. It's
an open source app that is OS X native (and scriptable) with support for
tabs and full screen mode.
I use OnMyCommand to put "Open iTerm Here" in my context menu when I
right-click on any file or folder or folder background. Then iTerm
*usually* is my launcher of choice (that is, it's rare that I open
MacVim via the Finder).
(another note of interest: I have "vi" aliased to mvim so that "vi" and
"mvim" open gui MacVim and "vim" opens Terminal vim. My shell has "set
-o vi" and my VISUAL editor is set for mvim)
Ben Schmidt
>> I think that the confusion really is due to the fact that many (most?)
>> developers first used Vim in the terminal If the Mac terminal were
>> better, I'd probably use Vim there (Xfce and Gnome both have superior
>> terminal emulators).
>
> While configuration is a bit of a mess, I find iTerm to be sturdy. It's
> an open source app that is OS X native (and scriptable) with support for
> tabs and full screen mode.
Do any of these Mac emulators support such things as 256-colours and
mouse and so on? I think they're the kinds of things that make it feel
more integrated on Linux.
Ben.
Ted Pavlic
> mouse and so on? I think they're the kinds of things that make it feel
> more integrated on Linux.
I know of no Mac Terminal emulator (including iTerm and Terminal) that
does *not* support 256 colors. As far as I know, all of the popular
terminal emulators supports 256 colors.
(note: you'll need GNU ls if you want a color'ed ls. At least as of OS X
10.4, OS X's packaged /bin/ls doesn't support --color)
With regard to mouse, all of the Terminal emulators I know support
SYSTEM PASTEBOARD mousing. That is, I can highlight any text I want,
right-click-copy (or Cmd+C) and right-click-paste (or Cmd+V).
(similarly, I can use the pbcopy and pbpaste commands that come with OS X)
Kyle Lippincott
Matt Tolton
> does *not* support 256 colors. As far as I know, all of the popular
> terminal emulators supports 256 colors.
Are you sure about Terminal.app? Last I checked iTerm supported 256
but not Terminal.
Ben Schmidt
>> Do any of these Mac emulators support such things as 256-colours and
>> mouse and so on? I think they're the kinds of things that make it feel
>> more integrated on Linux.
>
> I know of no Mac Terminal emulator (including iTerm and Terminal) that
> does *not* support 256 colors. As far as I know, all of the popular
> terminal emulators supports 256 colors.
O, really? Maybe it's a new thing. I hacked my terminfo a while ago to
remove some feature I didn't like, I think, so maybe I didn't notice the
colours increase from 16 to 256 when it did. I'm pretty sure when I
first investigated it only supported 16. I'll have to look into it
again. It would be nice to get better looking colours for Vim (with the
help of that magic plugin someone made to make 256-colour terminals
mimic gvim, probably).
> (note: you'll need GNU ls if you want a color'ed ls. At least as of OS X
> 10.4, OS X's packaged /bin/ls doesn't support --color)
Yeah, that's a good thing!
> With regard to mouse, all of the Terminal emulators I know support
> SYSTEM PASTEBOARD mousing. That is, I can highlight any text I want,
> right-click-copy (or Cmd+C) and right-click-paste (or Cmd+V).
> (similarly, I can use the pbcopy and pbpaste commands that come with OS X)
Yeah, which really is no mouse support.
Ben.
Ted Pavlic
>> does *not* support 256 colors. As far as I know, all of the popular
>> terminal emulators supports 256 colors.
>
> O, really? Maybe it's a new thing. I hacked my terminfo a while ago to
> remove some feature I didn't like, I think, so maybe I didn't notice the
> colours increase from 16 to 256 when it did. I'm pretty sure when I
> first investigated it only supported 16. I'll have to look into it
> again. It would be nice to get better looking colours for Vim (with the
> help of that magic plugin someone made to make 256-colour terminals
> mimic gvim, probably).
They both claim to support xTerm-color, and I've taken them at their
word or it.
I've had no trouble in vim or pine (or ls); they seem to have a "full"
spectrum of color available. Of course, I've never really cared that
much about having more than 16 colors.
>> With regard to mouse, all of the Terminal emulators I know support
>> SYSTEM PASTEBOARD mousing. That is, I can highlight any text I want,
>> right-click-copy (or Cmd+C) and right-click-paste (or Cmd+V).
>> (similarly, I can use the pbcopy and pbpaste commands that come with OS X)
>
> Yeah, which really is no mouse support.
I'm not quite sure I understand. Terminal and iTerm provided everything
that GPM, the console mode mouse driver, provides. What more could be
possible with a *terminal* application? (e.g., is it possible to have a
Linux vim (not gvim) respond to the mouse?)
Ben Schmidt
>>> I know of no Mac Terminal emulator (including iTerm and Terminal) that
>>> does *not* support 256 colors. As far as I know, all of the popular
>>> terminal emulators supports 256 colors.
>> O, really? Maybe it's a new thing. I hacked my terminfo a while ago to
>> remove some feature I didn't like, I think, so maybe I didn't notice the
>> colours increase from 16 to 256 when it did. I'm pretty sure when I
>> first investigated it only supported 16. I'll have to look into it
>> again. It would be nice to get better looking colours for Vim (with the
>> help of that magic plugin someone made to make 256-colour terminals
>> mimic gvim, probably).
>
> They both claim to support xTerm-color, and I've taken them at their
> word or it.
:r !infocmp xterm-color
# Reconstructed via infocmp from file:
# /opt/local/share/terminfo/x/xterm-color
xterm-color|nxterm|generic color xterm,
am, km, mir, msgr, xenl,
colors#8, cols#80, it#8, lines#24, ncv@, pairs#64,
...
Doesn't look like 256 colours to me.
But I know 16 colours work, so I guess what's declared definitely isn't
all that accurate...so maybe it still does support 256. You definitely
can't assume that from merely xterm-color support, though. There is
xterm-16color and xterm-256color for greater colour support in xterm.
> I've had no trouble in vim or pine (or ls); they seem to have a "full"
> spectrum of color available. Of course, I've never really cared that
> much about having more than 16 colors.
>
>>> With regard to mouse, all of the Terminal emulators I know support
>>> SYSTEM PASTEBOARD mousing. That is, I can highlight any text I want,
>>> right-click-copy (or Cmd+C) and right-click-paste (or Cmd+V).
>>> (similarly, I can use the pbcopy and pbpaste commands that come with OS X)
>> Yeah, which really is no mouse support.
>
> I'm not quite sure I understand. Terminal and iTerm provided everything
> that GPM, the console mode mouse driver, provides. What more could be
> possible with a *terminal* application? (e.g., is it possible to have a
> Linux vim (not gvim) respond to the mouse?)
Yep, it sure is.
:help 'mouse'
All you need to do is set the mouse option appropriately (e.g. :set
mouse=a) and you get almost as much in terminal Vim as you get in gvim
(provided you use a terminal/software that supports it such as xterm,
gpm, etc.). Indeed, it works in xterm in X11 on the Mac. Definitely not
in Terminal.app.
Ben.
Robin
On Wed, Nov 19, 2008 at 1:21 PM, Ted Pavlic <t...@tedpavlic.com> wrote:
> They both claim to support xTerm-color, and I've taken them at their
> word or it.
xterm-color is 16 colors, 256 colors is supported as xterm-color256.
It allows more graded colorschemes that look closer to the GUI ones.
As far as I know (and I checked fairly recently) Terminal.app doesn't
support this, but iterm.app does.
>>> With regard to mouse, all of the Terminal emulators I know support
>>> SYSTEM PASTEBOARD mousing. That is, I can highlight any text I want,
>>> right-click-copy (or Cmd+C) and right-click-paste (or Cmd+V).
>>> (similarly, I can use the pbcopy and pbpaste commands that come with OS X)
>>
>> Yeah, which really is no mouse support.
>
> I'm not quite sure I understand. Terminal and iTerm provided everything
> that GPM, the console mode mouse driver, provides. What more could be
> possible with a *terminal* application? (e.g., is it possible to have a
> Linux vim (not gvim) respond to the mouse?)
There is a terminal specification for full mouse support - if you have
a terminal that supports it you can scroll with scroll-wheel in
terminal vim, drag split window dividors, "select" mode selections
graphcially with the mouse etc. It is very nice (see set mouse=a)
I have found Terminal.app sorely lacking - for the above features, but
also I find the fonts look pretty bad in Terminal. iTerm is great -
supporting everything I want, and also with intelligent select (double
click to select work), selection automatically copied (select with alt
if in vim to use terminal client selection rather than pass through to
vim select mode) so can double click paths then middle click to paste,
just like on a linux terminal.
The only thing is as mentioned the configuration system
(Profiles/bookmarks) is a bit obscure... but I would be lost with out
it and I don't know how anyway who works in the terminal alot can put
up with Terminal.app...
Cheers
Robin
Robin
> also I find the fonts look pretty bad in Terminal. iTerm is great -
> supporting everything I want, and also with intelligent select (double
> click to select work), selection automatically copied (select with alt
> if in vim to use terminal client selection rather than pass through to
> vim select mode) so can double click paths then middle click to paste,
> just like on a linux terminal
I should point out iTerm does support terminal mouse - I don't know if
I made that clear.
I don't know of any feature that is available in the popular linux
terminals that isn't in iTerm... (even has transparency, border vs
borderless option, show/hide scrollbar etc.)
Cheers
Robin
Ted Pavlic
> Doesn't look like 256 colours to me.
Ok. So I guess I don't know if I support 256 colors.... **BUT**:
> Yep, it sure is.
>
> :help 'mouse'
Mousing works in iTerm (but you're correct --- not in Terminal).
So, iTerm > Terminal. Not surprising.
Matt Tolton
I wouldn't go that far... Terminal.app is much faster at rendering
than iTerm. Enough faster that it's very noticeable to me, and makes
me not want to use iTerm.
Robin
Really? What sort of thing do you notice it on - I've never found
iterm to be slower (although I haven't used Terminal that much). There
was a recent release of iTerm which may have improved things.
How do you get an acceptable font display in Terminal? (It would be
useful for when I have to use other computers without iterm). When I
set the font to Bitstream Vera Mono - it just looks terrible, even
with antialiasing?
Robin
David Morel
>
> On Wed, Nov 19, 2008 at 3:40 PM, Matt Tolton <ma...@tolton.com> wrote:
>>
>>> So, iTerm > Terminal. Not surprising.
>>
>> I wouldn't go that far... Terminal.app is much faster at rendering
>> than iTerm. Enough faster that it's very noticeable to me, and makes
>> me not want to use iTerm.
>
> Really? What sort of thing do you notice it on - I've never found
> iterm to be slower (although I haven't used Terminal that much). There
> was a recent release of iTerm which may have improved things.
I noticed too, on some occasions, that displaying very heavy debug
output (while debugging heavily loaded webservers), iTerm had some
difficulty coping with the amount of data to cache. I believe this has
improved recently, since I stopped seeing the beachball. So maybe it's
time to give it a second try, especially since in terms of features it
beats Terminal easily.
David
Ben Schmidt
>>
>> :help 'mouse'
>
> Mousing works in iTerm (but you're correct --- not in Terminal).
>
> So, iTerm > Terminal. Not surprising.
Maybe I'll give iTerm another go. I tried it a few years ago but ditched
it because Terminal worked better with Unicode (or at least, worked
better with Unicode in combination with Vim for the languages I was
using at the time).
Ben.
Matt Tolton
> iterm to be slower (although I haven't used Terminal that much). There
> was a recent release of iTerm which may have improved things.
Last time I tried it, you could notice the rendering difference typing
ls -la on a directory with a few hundred files. Maybe the newer
version has improved, last time I tried was maybe 8-12 months ago.
>
> How do you get an acceptable font display in Terminal? (It would be
> useful for when I have to use other computers without iterm). When I
> set the font to Bitstream Vera Mono - it just looks terrible, even
> with antialiasing?
Personally, I prefer monaco to bitstream vera mono, so I guess this
doesn't affect me.
Tobia Conforto
> How do you get an acceptable font display in Terminal? When I set
> antialiasing
I guess it depends on your definition of acceptable, or what font
you're trying to use.
My first choice, coming from Linux, would have been 9x18.pcf, a
beautiful bitmap font from X11 misc. I wrestled with FontForge and
similar programs for a while, trying to convert it into a format
useable by Terminal or iTerm, but I failed miserably :-( You can find
traces of my struggle on FontForge's and Apple's mailing lists.
At last I settled with Andale Mono 15, un-antialiased. It's not as
nice as 9x18, but it does the job, and it looks the same on all
programs I've used it on (Terminal, iTerm, and MacVim.)
Another free nice font is Inconsolata, to be used antialiased: http://www.hashref.com/images/inconsolata.png
Are you having this problem only with Bistream Vera Mono? Do Apple's
font look different on iTerm than on Terminal? Maybe it's a problem
with the specific font, or the way it's been prepared for the Mac.
Most importantly, this is all not very relevant to MacVim ;-)
Tobia