magit-blame-{prev,next}-chunk

Always move to the previous/next chunk from *point*.  Previously that
was done interactively but non-interactively the POS argument had to
be provided.  Which is wrong for two reasons:  we did not use it
non-interactively, so even if this was a good idea in the first place
it would be of no use.  And then there is no reason for a movement
command to be have "move to next thing from point, except when I tell
you to move from somewhere else".  If one wants that - especially in
non-interactive use, one can just go to that other place *before*
going to the next thing,
magit-run-git-gui-blame: fix when linenum is missing

We can't guarantee that we'll always know which line number
we want to center the `git gui blame' process around.  This
fixes an error caused by attempting to pass nil as one of
the arguments to `start-file-process'.

Message-by: Adam Spiers <github@adamspiers.org> :-)
Reported-by: Adam Spiers <github@adamspiers.org>

Or

  "Make that lazy ass lisp reader do some work."
autoload commands that are useful outside a magit buffer

Add autoload cookies for commands that can be used when the current
buffer isn't a Magit buffer.
move bindings from magit-status-mode-map to magit-mode-map

Move some key bindings that do *not* depend on the existence certain
items (which might not exist in non-status buffers) from
`magit-status-mode-map' to `magit-mode-map'.
magit-wash-log: use author/date overlay only with oneline style

Do not display the author/date overlay for log style `long', only
for `oneline'.  When the style is `long' then displaying the overlay
fails *and* it is unnecessary because the author information is
already displayed in another fashion.
magit-wash-log: give the code some room to breath
magit-wash-log: remove an unnecessary let-bound variable

Instead of binding USE-AUTHOR-DATE to the value of

  (eq style 'oneline)

just perform that test twice.  That is cheap enough; it might be even
cheaper than a variable binding.  Regardless, I think it improves
readability a lot.
merge magit-wash-untracked-file into magit-wash-untracked-files
collect all status section inserters in one place

All of the sections created by these inserters are used in the "status"
buffer.  They can also be used in other Magit buffers but that doesn't
change the fact they are "status" sections.

Some of these inserters were defined as part of the "Status Mode"
toplevel section, while others where defined next to the lowlevel
functions they make use of.  There are two ways to make that
consistent... this commit implements on of them.

Because these inserters can also be used by other Magit modes besides
`magit-status-mode' create a new toplevel section "Status Sections"
instead of placing inside a subsection of "Status Mode".  Actually this
is done by promoting the existing subsection "Status Mode">"(sections)"
to a topsection; so the definitions that were already located there do
not have to be moved.

Because after moving `magit-insert-untracked-files' the toplevel section
"Untracked Files" only contains one function `magit-wash-untracked-files'
move that along with the former (which happens to be its only caller).

The definitions of the inserters are in the same order as the sections
are inserted in the "status" buffer.  Unfortunately that means that the
more noisy ones come first.  But that's just because nobody has bothered
cleaning them up yet.

Actually that is not quiet true.  The "line" sections are defined after
the "real" (multi-line and collapsible) sections.  But that is no
problem because the section is split into respective subsections "Line
Sections" and "Real Sections".
split the section "Stage and Unstage" into two

Split the section "Stage and Unstage" (a subsection of "Acting") into
two subsections "Stage" and "Unstage".  I admit this is completely
unnecessary but I have to satisfy my ocd.   :-)
deal with strange location of emacsclient on OS X

On OS X applications are often installed in strange "executable
directories".  The Finder presents these directories as actual
applications to the user who might be blissfully unaware that
clicking on it actually executes a binary inside the directory.

So they have been happily clicking on a flashy image to start
Emacs and we come along requiring emacsclient being on $PATH.

But it gets worse.  The emacsclient executable might not even be
located in the same subdirectory of the application directory:

  /Applications/Emacs.app/Contents/MacOS/emacs
  /Applications/Emacs.app/Contents/MacOS/bin/emacsclient

So we have to look for the emacsclient here too:

  (expand-file-name "bin" invocation-directory)

Also see:

  https://github.com/magit/magit/issues/862#issuecomment-24784266
magit-with-emacsclient: wait longer before resetting server-window

We have to reset the default value of `server-window' using a timer
(see comment close to this change).  Previously we waited 0.2 seconds
before doing so, but it seems that sometimes isn't enough.  Wait a full
second instead.
magit-blame-{prev,next}-chunk: use {previous,next}-single-property-change

Define `magit-blame-{prev,next}-chunk' using
`{previous,next}-single-property-change'.

This replaces a lot of broken code with the use of functions already
provided by Emacs.  The old code was broken in at least these ways:

* going backward always jumped to the beginning of the buffer (#937)
* going forward sometimes just moved a character forward
Merge branch 'pr/blame-moving'
magit-run-git-gui-blame: suppress error when not visiting a file

Suggested-By: Pieter Praet <pieter@praet.org>
Merge branch 'pr/no-linenum'
Merge branch 'pr/cookies'
Merge branch 'pr/no-overlay'
Merge branch 'ocd'

Conflicts:
	magit.el
move magit-grep to section "Miscellaneous Commands"