Bound to Ctrl/Cmd + left & right square brackets, depending on
your platform.
[sp: Added missing binds for . to allow shortcuts to work when
not focused in the commit message area.]
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Keeping POT up to date relative to the software is absolutely
necessary. What is unwarranted is updating language files at
the same time by running msgmerge without checking if there is
any outstanding translation work first. If we assume that the
translators do not have access to msgmerge, that is a good service
to them (the less they have to do, the better), but otherwise,
it is better to be leave po/${language}.po files alone.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I updated Japanese translation for the latest git-gui.
Signed-off-by: しらいしななこ <nanako3@bluebottle.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Peter Karlsson pointed out there is no value in translating the
string "Apple", as this is used as the dummy label for the Apple
menu on Mac OS X systems.
The Apple menu is actually not the menu with the Apple corporate
logo, but the menu next to it, which shows the name of the
application and is typically called the application menu. Most users
of git-gui see this menu titled as "Git Gui". The actual label of
this menu comes from our Info.plist file and cannot be specified
by any other means. Translating this string in the Tcl PO files
is not necessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To prepare msg files for Tcl scripts, the command that is set to MSGFMT
make variable needs to be able to grok "--tcl -l <lang> -d <here>" options
correctly. This patch simplifies the tests done in git-gui's Makefile to
directly test this condition. If the test run does not exit properly with
zero status (either because you do not have "msgfmt" itself, or your
"msgfmt" is too old to grok --tcl option --- the reason does not matter),
have it fall back to po/po2msg.sh
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The width of the commit message text area is currently hard-coded
to 75 characters. This value might be not optimal for some projects.
For instance users who would like to generate GNU-style ChangeLog
file from git commit message might prefer commit messages of width
no longer than 70 characters.
This patch adds a global and per repository option "Commit Message
Text Width", which could be used to change the width of the commit
message text area.
Signed-off-by: Adam Piątyszek <ediap@users.sourceforge.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In several places, only the background colour is set to an explicit
value, sometimes even "white". This does not work well with dark
colour themes.
This patch tries to set the foreground colour to "black" in those
situations, where an explicit background colour is set without defining
any foreground colour.
Signed-off-by: Philipp A. Hartmann <ph@sorgh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
'make' shows:
MSGFMT po/zh_cn.msg 368 translated, 2 fuzzy, 1 untranslated message.
1. update the zh_cn.po and translate the remaining messages in chinese
2. correct some of the previously mis-translated messages
3. add a list of word interpretation in the head as a guideline for
subsequent updatings and translations
Signed-off-by: eric miao <eric.miao@marvell.com>
Acked-by: Xudong Guan <xudong.guan@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mac OS X Tiger may have a msgfmt available but it doesn't understand
how to implement --tcl. Falling back to po2msg.sh on such systems
is a reasonable behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tries to commit their changes without actually staging
anything we used to display an informational dialog suggesting they
first stage those changes, then retry the commit feature.
Unfortunately I broke this in aba15f7 ("Ensure error dialogs always
appear over all other windows") and failed to fix it in the paper
bag fix that came one day after it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-gui: Focus insertion point at end of strings in repository chooser
git-gui: Avoid hardcoded Windows paths in Cygwin package files
git-gui: Default TCL_PATH to same location as TCLTK_PATH
git-gui: Paper bag fix error dialogs opening over the main window
When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most users set TCLTK_PATH to tell git-gui where to find wish, but they
fail to set TCL_PATH to the same Tcl installation. We use the non-GUI
tclsh during builds so headless systems are still able to create an
index file and create message files without GNU msgfmt. So it matters
to us that we find a working TCL_PATH at build time.
If TCL_PATH hasn't been set yet we can take a better guess about what
tclsh executable to use by replacing 'wish' in the executable path with
'tclsh'. We only do this replacement on the filename part of the path,
just in case the string "wish" appears in the directory paths. Most of
the time the tclsh will be installed alongside wish so this replacement
is a sensible and safe default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the main window is the only toplevel we have open then we
don't have a valid grab right now, so we need to assume the
best toplevel to use for the parent is ".".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We really only support Aspell, so showing the compatibility line from
ispell is of little value to end users.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has somehow managed to make us execute ispell instead
of aspell, even though our code is invoking aspell, and ispell is
not recognizing the aspell command line options we use to invoke
it then we don't want a giant usage message back from ispell.
Instead we show the ispell version number, letting the user know
we don't actually support that spell checker.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we feed a bad dictionary name to aspell on startup it may appear
to start (as Tcl found the executable in our $PATH) but it fails to
give us the version string. In such a case the close of the pipe
will report the exit status of the process (failure) and that is
an error in Tcl.
We now trap the subprocess failure and display the stderr message
from it, letting the user know why the failure is happening. We then
disable the spell checker, but keep our object instance so the user
can alter their preferred dictionary through the options dialog, and
possibly restart the spell checker.
I was also originally wrong to use "error" here for the display
of the problem to the user. I meant to use "error_popup", which
will open a message box and show the failure in a GUI context,
rather than killing git-gui and showing the message on the console.
Noticed by Ilari on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we reconnect to the spellchecker there is no reason to resetup
the binding for button 3 on our text widget to show the suggestion
list (if available).
Plus, by moving it out of _connect and into init we can now break
out of _connect earlier if there is something wrong with the pipe,
for example if the dictionary we were asked to load is not valid.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may or may not be using aspell here. About the only thing
we are using that is aspell specific (and not supported by ispell
or an ispell variant) is some command line options when we start
up aspell, and a forced encoding of UTF-8. Both of these can be
corrected and/or cleaned up by users through an aspell wrapper
script, or through further improvements to git-gui. There is no
reason to require our translated strings to reference a specific
spell checker, especially if that spell checker implementation is
not very suitable for the language being translated.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we somehow managed to get our spellchecker instance created but
aspell wasn't startable we may not finish _connect and thus may
find one or more of our fields was not initialized in the instance.
If we have an instance but no version, there is no reason to show
a version to the user in our about dialog. We effectively have no
spellchecker available.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal. Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
And markup one missing string for translation.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't need to fill this entire horizontal cavity, it looks really
bad on some platforms to stretch the widget out to fill the window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't want the list length, we need the string length.
Found due to a bad " character discovered in the text and
Tcl throwing 'unmatched open quote in list'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Many user friendly tools like word processors, email editors and web
browsers allow users to spell check the message they are writing
as they type it, making it easy to identify a common misspelling
of a word and correct it on the fly.
We now open a bi-directional pipe to Aspell and feed the message
text the user is editing off to the program about once every 300
milliseconds. This is frequent enough that the user sees the results
almost immediately, but is not so frequent as to cause significant
additional load on the system. If the user has modified the message
text during the last 300 milliseconds we delay until the next period,
ensuring that we avoid flooding the Aspell process with a lot of
text while the user is actively typing their message.
We wait to send the current message buffer to Aspell until the user
is at a word boundary, thus ensuring that we are not likely to ask
for misspelled word detection on a word that the user is actively
typing, as most words are misspelled when only partially typed,
even if the user has thus far typed it correctly.
Misspelled words are highlighted in red and are given an underline,
causing the word to stand out from the others in the buffer. This is
a very common user interface idiom for displaying misspelled words,
but differs from one platform to the next in slight variations.
For example the Mac OS X system prefers using a dashed red underline,
leaving the word in the original text color. Unfortunately the
control that Tk gives us over text display is not powerful enough
to handle such formatting so we have to work with the least common
denominator.
The top suggestions for a misspelling are saved in an array and
offered to the user when they right-click (or on the Mac ctrl-click)
a misspelled word. Selecting an entry from this menu will replace
the misspelling with the correction shown. Replacement is integrated
with the undo/redo stack so undoing a replacement will restore the
misspelled original text.
If Aspell could not be started during git-gui launch we silently eat
the error and run without spell checking support. This way users
who do not have Aspell in their $PATH can continue to use git-gui,
although they will not get the advanced spelling functionality.
If Aspell started successfully the version line and language are
shown in git-gui's about box, below the Tcl/Tk versions. This way
the user can verify the Aspell function has been activated.
If Aspell crashes while we are running we inform the user with an
error dialog and then disable Aspell entirely for the rest of this
git-gui session. This prevents us from fork-bombing the system
with Aspell instances that always crash when presented with the
current message text, should there be a bug in either Aspell or in
git-gui's output to it.
We escape all input lines with ^, as recommended by the Aspell manual
page, as this allows Aspell to properly ignore any input line that is
otherwise looking like a command (e.g. ! to enable terse output). By
using this escape however we need to correct all word offsets by -1 as
Aspell is apparently considering the ^ escape to be part of the line's
character count, but our Tk text widget obviously does not.
Available dictionaries are offered in the Options dialog, allowing
the user to select the language they want to spellcheck commit
messages with for the current repository, as well as the global
user setting that all repositories inherit.
Special thanks to Adam Flott for suggesting connecting git-gui
to Aspell for the purpose of spell checking the commit message,
and to Wincent Colaiuta for the idea to wait for a word boundary
before passing the message over for checking.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tk Framework moved its location in 10.5 compared to 10.4
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Tested-by: Seth Falcon <seth@userprimary.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In the multiple message case we remove the word "messages" from the
statistics output of msgfmt as it looks cleaner on the tty when you
are watching the build process. However we failed to strip the word
"message" when only 1 message was found to be untranslated or fuzzy,
as msgfmt does not produce the 's' suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The strings we were showing from po2msg didn't exactly match those
of msgfmt's --statistics output so we didn't show quite the same
results when building git-gui's message files. Now we're closer
to what msgfmt shows (at least for an en_US locale) so the make
output matches.
I noticed that the fuzzy translation count is off by one for the
current po/zh_cn.po file. Not sure why and I'm not going to try
and debug it at this time as the po2msg is strictly a fallback,
users building from source really should prefer msgfmt.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If msgfmt fails with exit code 127 that typically means the program
is not found in the user's PATH and thus cannot be executed by make.
In such a case we can try to fallback to the Tcl based po2msg program
that we distributed with git-gui, as it does a "good enough" job.
We still don't default to po2msg.sh however as it does not perform
a lot of the sanity checks that msgfmt does, and quite a few of
those are too useful to give up.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
