gitk: Synchronize highlighting in file view when scrolling diff

Whenever the diff pane scrolls, highlight the corresponding file in the
file list on the right.  For a large commit with many files and long
per-file diffs, this makes it easier to keep track of what you're looking
at.

This allows simplifying the prevfile and nextfile functions, because
all they have to do is scroll the diff pane.

In some situations we want to suppress this mechanism, for example when
clicking on a file in the file list to select it, or when searching in the
diff, in which case we want to highlight based on the current search hit
and not the top line visible. In these cases it's not sufficient to set
a "suppress" flag before scrolling and reset it afterwards, because the
scrolltext notification is sent deferred from a timer or some such; so we
need to remember the scroll position for which we want to suppress the
auto-highlighting until the next call to scrolltext; a bit ugly, but does
the job.

Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Highlight current search hit in orange

When searching for text in the diff, and there are multiple occurrences
of the search string, the current one is highlighted in orange, and the
other ones in yellow. This makes it much easier to understand what happens
when you then click the Search button or hit Ctrl-S repeatedly.

Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Highlight first search result immediately on incremental search

When typing in the "Search" field, select the current search result (so
that it gets highlighted in orange). This makes it easier to understand
what will happen if you then type Ctrl-S.

Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Work around empty back and forward images when buttons are disabled

On Mac, the back and forward buttons show an empty rectange instead of
a grayed-out arrow when they are disabled. The reason is a Tk bug on Mac
that causes disabled images not to draw correctly (not to draw at all,
that is); see
<https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.tcl/V-nW1JBq0eU>.

To work around this, we explicitly provide gray images for the disabled
state; I think this looks better than the default stipple effect that you
get on Windows as well, but that may be a matter of taste.

Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Refactor code for binding modified function keys

The function includes a workaround for systems where F* keys are mapped
to XF86_Switch_VT_* when modifiers are used.

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Use bindshiftfunctionkey to bind Shift-F5

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Fix crash when not using themed widgets

When configured not to use themed widgets gitk may crash on launch with
a message that says that the image "bm-left disabled bm-left-gray"
doesn't exist. This happens when the left and right arrow buttons are
created.

The crash can be avoided by configuring the buttons differently
depending on whether or not themed widgets are used. If themed widgets
are not used then only set the images to bm-left and bm-right
respectively, and keep the old behavior when themed widgets are used.

The previous behaviour was added in f062e50f to work around a bug in Tk
on OS X where the disabled state did not display properly. The buttons
may still not display correctly, however the workaround added in
f062e50f will still apply if gitk is used with themed widgets.

Make gitk not crash on launch when not using themed widgets.

Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Fix error message when clicking on a connecting line

When clicking on the line that connects two commit nodes, gitk
would bring up an error dialog saying "can't read "cflist_top":
no such variable".

This fixes a regression that was introduced with b967135 ("gitk:
Synchronize highlighting in file view when scrolling diff").

Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: When searching, only highlight files when in Patch mode

This fixes another regression that was introduced in b967135 ("gitk:
Synchronize highlighting in file view when scrolling diff"): when
searching for a string in tree mode, jumping to the next search hit
would highlight the "Comments" entry in the file list.

Signed-off-by: Stefan Haller <stefan@haller-berlin.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Update Swedish translation (296t)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Fix display of branch names on some commits

Sometimes the code that divides commits up into arcs creates two
successive arcs, but the commit between them (the commit at the end
of the first arc and the beginning of the second arc) has only one
parent and one child.  If that commit is also the head of one or more
branches, those branches get omitted from the "Branches" field in the
commit display.

The omission occurs because the commit gets erroneously identified as
a commit which is part-way along an arc in [descheads].  This fixes it
by changing the test to look at the arcouts array, which only contains
elements for the commits at the start or end of an arc.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Improve display of list of nearby tags and heads

This provides a control in the preferences pane for the limit on
how many tags or heads are displayed with the commit details under
the Branch(es), Precedes and Follows headings.  This limit is now
saved in ~/.gitk so that changes are persistent.

This also applies word-wrapping to the list of tags or heads under
the Branch, Precedes and Follows headings, so that long lists are
more readable.

Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Display important heads even when there are many

When there are more than $maxrefs descendant heads to display in the
Branches field of the commit display, we currently just display "many",
which is not very informative.  To make the display more informative,
we now look for "master" and whichever head is currently checked out,
and display them even if there are too many heads to display them all.
The display then looks like "Branches: master and many more (33)" for
instance.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge git://ozlabs.org/~paulus/gitk

* git://ozlabs.org/~paulus/gitk:
  gitk: Display important heads even when there are many
  gitk: Improve display of list of nearby tags and heads
  gitk: Fix display of branch names on some commits
  gitk: Update Swedish translation (296t)
  gitk: When searching, only highlight files when in Patch mode
  gitk: Fix error message when clicking on a connecting line
  gitk: Fix crash when not using themed widgets
  gitk: Use bindshiftfunctionkey to bind Shift-F5
  gitk: Refactor code for binding modified function keys
  gitk: Work around empty back and forward images when buttons are disabled
  gitk: Highlight first search result immediately on incremental search
  gitk: Highlight current search hit in orange
  gitk: Synchronize highlighting in file view when scrolling diff