m4_esyscmd_s is a macro only available in Autoconf 2.64, which despite
being released in 2009 is not available on a number of build targets for
the project (specifically CentOS/RHEL 6).
ca8e4c08a7 tries to remove the error produced with m4_pattern_allow,
but that just silences the sanity check.
Instead, replace m4_esyscmd_s with m4_esyscmd + manual removal of
newlines.
I break compatibility with Mac OS X again, that I don't have access
to. Result: Stuff break, and I have to fix it, so it will perhaps
work. At least, I hope it will work.
Yes, it's an awful hack, but IPC support (and fork support as well -
even FAQ mentions that, and suggests "restarting process" to solve the
problem (http://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures),
but let's ignore that for now) is simply broken in Cygwin. Having to try
to do exactly same thing in Cygwin, just so perhaps it will work is a
completely normal thing (not). I love Windows.
I commited executables in previous commit (removed using git push
--force - sorry, I wouldn't want to waste space in git repository), so I
think *.exe files should be forbidden to avoid any problems (there is no
reason to ever commit them)
Yes, hostname is broken under Cygwin, but for fish it's an issue, as it
makes fish_config more buggy than it needs to be (by making UTF-8 errors
according to Python).
Note that this will NOT get updated on every run - even if autoconf is run manually, the value may be cached. The PACKAGE_VERSION variable/symbol will not be reliable. Use FISH_BUILD_VERSION instead.
This commit hooks the Makefile up to generate a FISH_BUILD_VERSION
symbol and kills off PACKAGE_VERSION in .cpp files.
It also modifies the tarball generation script to add the necessary
version file for releases.
git.git's __git_ps1 doesn't have an upstream prefix. I'm not sure why
one was added to our __fish_git_prompt, but it certainly shouldn't
default to a space.
It reuses $__fish_git_prompt_char_stateseparator, since it has a
similar meaning and goes otherwise unused when
$__fish_git_prompt_show_informative_status is set.
This changes the defaults for several characters when
$__fish_git_prompt_show_informative_status is set so that the prompt
looks more like the typical informative prompt.
Before: (master >1<2|+3#4*5%6)
After: (master↑1↓2|●3✖4✚5…6)
The defaults were taken from magicmonty/bash-git-prompt
This makes $__fish_git_prompt_show_informative_status imply
$__fish_git_prompt_showupstream = "informative", while adding a none
option for showupstream to disable it if desired.
plus speling in documentation for bind.
Note that this commit does not re-enable the generation of the manpage for
test, which will therefore still fall through to the system manual page with
`man test`.
(Closes#91, #932)
Currently, control-E is bound to `end-of-line`.
This patch modifes the `end-of-line` procedure so that, if it is invoked when
the cursor is at the end of a command and there is pending completion text,
it will accept the completion text and move to the end. The behavior of
`end-of-line` will not otherwise be altered.
A few characters and colors got added without being added to the event
list for repainting.
Also sort and re-align list of characters in validate_chars.
The code invoked `git rev-parse` several times when the required
information could be collected all at once.
This is based on the following commits from git.git:
efaa0c1: bash prompt: combine 'git rev-parse' executions in the main code path
e3e0b93: bash prompt: combine 'git rev-parse' for detached head
0f37c12: bash prompt: use bash builtins to check for unborn branch for dirty state
dd0b72c: bash prompt: use bash builtins to check stash state
It's a one line function called in a single place. I suspect it only
existed because the bash equivalent __gitdir existed (it was more
complex), but that function no longer exists either, as of git.git
511ad15: "bash prompt: run 'git rev-parse --git-dir' directly instead
of __gitdir()"
