Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Somehow my prompt broke in 5.2

On Jan 10,  8:46am, Sebastian Gniazdowski wrote:
} Subject: Re: Somehow my prompt broke in 5.2
} On 7 January 2016 at 05:44, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} >
} > Delete line 7 ( local -a msgs ) from VCS_INFO_nvcsformats and you
} > should be good to go.  If you have problems with WARN_CREATE_GLOBAL,
} > add that same line to Functions/VCS_Info/vcs_info instead.
} Would be cool if this could be somehow workarounded in .zshrc, so that
} one can have robust configuration that will work anywhere right after
} install.

This is the reason for $fpath and for the rigorous adherence to search
order that kept annoying Ray.  You make the fix to the function source,
put it in a directory under $HOME or in some well-known system location,
and make sure that directory appears in $fpath ahead of the standard
directory for the zsh install.

I personally have several such directories named with portions of the
zsh version string and sort fpath so that they're loaded in version
order.  That way I can add new functions at the version where the base
changes they require are present, and they're always in the fpath (just
later on) as new versions of the shell appear.

If you want something that works purely in .zshrc, you can do something
more fragile but along these lines:

autoload +X VCS_INFO_nvcsformats
functions[VCS_INFO_nvcsformats]=${functions[VCS_INFO_nvcsformats]/local -a msgs/}

(not thoroughly tested).

} One could at least add a warning to .zshrc that
} would somehow detect if modifications aren't in place for given zsh.

The problem is that every such modification would require its own bit of
custom test to detect, and some might not be detectable at all except
with user interaction.  Not only is it difficult to maintain all those
tests, it makes shell startup very slow.

Messages sorted by: Reverse Date, Date, Thread, Author