Merge pull request #984 from mgalgs/typo

Fix typo in magit-insert-unpushed-cherries
magit-refresh-buffer: make sure BUFFER is non-nil

In `magit-refresh-buffer' make sure BUFFER is non-nil, instead of
using `current-buffer' instead of BUFFER.  This makes using that
buffer nicer than just passing BUFFER or else `current-buffer' to
`with-current-buffer'.
magit-refresh-buffer: reduce nesting
magit-refresh-buffer: update commit marker later

In `magit-refresh-buffer' call `magit-refresh-marked-commits-in buffer'
right after `magit-highlight-section'.  Therefor call it becomes the
very last step of refreshing; however the real point is not to do it
in between some unrelated steps (which are related to each other, just
not the commit marker).
magit-refresh-buffer: actually sync point in other windows

`magit-refresh-buffer' did already attempt to update the "window local"
point in other windows showing the same buffer.  However it failed to
request all such windows from `get-buffer-window-list'; it only
requested windows of the current frame, which in most cases equals to
the selected window.  Now we process windows from all frames.

This fixes the special case mentioned by me in issue #687.  At least
in most cases, that is when this function is *actually* called.
magit-refresh-buffer: remove bogus entry from window-buffer

In `magit-refresh-buffer' remove bogus entry from the list returned by
function `window-buffer', which effectively did throw away all the work
done further up in this function.

In most cases this did not happen because there was no such bogus entry
in `window-buffer'.  However when a command did move to some other
buffer and did only then refresh the buffer we ended up with such an
entry.  The entry is created when switching away from the buffer.
Refreshing is done by first erasing the buffer and then rebuilding it
from scratch.  Erasing the buffer causes the markers in the entry to
become invalid and since we have already switched away from the buffer
earlier then rebuilding the buffer contents neither creates a new entry
nor updates the markers in the existing entry.

This fixes issue #687.
magit-refresh-buffer: also restore the window-start

This fixes the issue of which #978 is a special case.
Merge branch 'pr/window-point'
define unrecord-window-buffer if Emacs doesn't have it
fix "pasto"
Revert "define unrecord-window-buffer if Emacs doesn't have it"

This reverts commits 0238526b184609c796af9d64dcc6f26e2df58a2d
and commit d77dd3644e9c73bc0760d7b0d89d92c792099c75.
assert unrecord-window-buffer is defined before using it
magit-display-process: use pop-to-buffer instead of display-buffer

Prior to commit e26c9c7 `magit-display-process' used `display-buffer'
and `magit-run*' used `pop-to-buffer' for timed display of the same
buffer.  The latter code was merged into `magit-display-process', which
resulted in `display-buffer' always being used.

This commit changes it to always use `pop-to-buffer'.

Fixes #987.
add new functions magit-{region,section}-siblings
magit-{,un}stage: allow un-/staging region of files

Note that this will un-/stage the file on the current line even when
point is at its very beginning.  So it behaves more like e.g. dired
than the un-/staging of a region within a hunk.  Also both mark and
point have to be on a file *heading*.
Merge branch 'pr/stage-region'
add option magit-item-highlight-face

Add option `magit-item-highlight-face' to once and for all satisfy all
users, hopefully.  Actually, that is not possible; so what this actually
does, is to allow users to customize the appearance of the highlighting
without imposing any limitations.

The previous attempt implemented in at least the commits 66a0644,
d14a3f9 (with discussion), and d14a3f9; and discussed in the issues #743
and #865 failed.  They fixed it for some users and in turn broke it for
others.  The primary goal of this change is to help users help
themselves, in case they don't like the defaults.

The new option `magit-item-highlight-face' is necessary because face
inheritance has serious limitations when a theme is used.  It is not
possible for the user to "unset" a face attribute that was previously
set by the theme.  All that is possible is to *change* it to some other
value.  "Make unset" isn't available as a value.

This option also makes it possible to automatically set the default of
option `magit-diff-use-overlays' to nil in *one particular* case: when
`magit-item-highlight-face's value is `bold'.  (We previously tried
something similar, but that failed because of another limitation of
faces, :set-after only works for options, not faces).

This commit also changes the appearance of some faces, which might
disappoint some users.  There simply isn't anything we can do to make
this look good out of the box for everyone.  Unfortunately for some
people that will mean that we have switched from a default that worked
for them to one that doesn't.  I hope that, when pointed to this
message, it becomes obvious, that it isn't as easy as one might have
thought, and that we had to make compromises.

The following considerations went into choosing the colors used for
various themes:

* Being at least _usable_ in (hopefully) all cases is more important
  than being _pretty_ in most cases.  We are not in the business of
  designing consistent color themes.

* Inherit from default faces, hoping that doing so, results in
  consistent, semantically sound, and possibly even pretty colors.
  If that is not so that is the mistake of the theme authors.

* The colors red and green, in all its variations, have to be avoided
  because those colors are also used to indicate removed and added lines
  in diffs.

* Therefore inherit from default faces that, in the default theme (both
  the dark and light variant), don't use such colors.  Of course some
  third-party theme might have changed these faces to use red or green;
  we simply cannot do anything about that.

* The faces we inherit from also have to be semantically close to
  "highlight".  Which gives us `highlight', `region', and
  `secondary-selection'.

* `region' cannot be used because it is also used for... the region,
  which is useful when staging just a portion of a hunk, precisely *the
  region*.

* `highlight' cannot be used because it is green.

* `secondary-selection' and only that remains.  Use it.  It might not
  be pretty even when using the default theme, but if it is good enough
  for the designers of the default theme then it is good enough for us.
  Besides we don't have another option.

So make `magit-item-highlight' inherit from `secondary-selection' and
make `magit-item-mark' (which previously inherited from the former)
inherit from `highlight'.  It's okay for `magit-item-mark' to be green;
only commits can be marked, and commits don't appear next to added (or
removed, or unmodified) lines.
Merge branch 'pr/bold-highlight'
Fix option of git ls-files in magit-revert-buffer
Merge pull request #995 from shigi/fix-ls-files-option

Fix option of git ls-files in magit-revert-buffer