zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh Users <zsh-users@zsh.org>
Subject: Re: Somehow my prompt broke in 5.2
Date: Sun, 10 Jan 2016 12:11:43 -0800	[thread overview]
Message-ID: <160110121143.ZM1147@torch.brasslantern.com> (raw)
In-Reply-To: <CAKc7PVACN0V+7=W32w8cau1Ev0feS9Ctuc8piZavPJhnPOew4A@mail.gmail.com>

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@brasslantern.com> 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.


      reply	other threads:[~2016-01-10 20:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07  3:36 Jason L Tibbitts III
2016-01-07  4:44 ` Bart Schaefer
2016-01-07  6:52   ` Jason L Tibbitts III
2016-01-10  7:46   ` Sebastian Gniazdowski
2016-01-10 20:11     ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=160110121143.ZM1147@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).