We don't push our code to a Maven repository, so there only reason
to construct source archives is to feed source files into the GWT
compiler. Move the source plugin onto only the packages that we
feed into the GWT code, allowing the others to skip this step.
This fixes a "bug" in a later change that adds the Prolog Cafe
translater to the build process. Without this change first, the
Prolog Cafe translator is firing twice for every Prolog source file
that is part of our standard build.
Change-Id: Iba38aa371ce7c8950ac30dc3cf06e01b465afb5a
Signed-off-by: Shawn O. Pearce <sop@google.com>
I meant to keep reusing the 2.1 version number for the entire
2.1 series during development, but botched it during the 2.1.4
development cycle and set it to 2.1.4-SNAPSHOT by mistake. Put
it back to 2.1-SNAPSHOT since 2.1.4 is released.
Change-Id: I37e206c0609bf3fd94a5aab8ea301c98b7fb013e
Signed-off-by: Shawn O. Pearce <sop@google.com>
There was some code duplication in these classes. This refactoring
removes the PatchScriptSettings and PrettySettings classes and uses
AccountDiffPreference instead.
Issue: bug 629
Change-Id: I57ab1522b0023503d0cbd29620236ea68b7717ed
Signed-off-by: Sasa Zivkov <zivkov@gmail.com>
On IE6 or IE8 we can't abuse an IFrame quite the same way as we
do on Mozilla, WebKit and Opera. IE requires us to initialize the
iframe by running a script that exports the iframe window back to
the parent before we can use its eval method.
Change-Id: Ia5e01a611ed9685a5fc5341a3f8a2446f7dcb9f4
Signed-off-by: Shawn O. Pearce <sop@google.com>
The prettify symbol 'PR' at the top level window object may conflict
with a name created by the optimized GWT compiler, resulting in
conflicting ideas about what the PR name really is and causing
crashes in particular browsers.
Move prettify into its own iframe, where it has its own top level
window object, and thus has its own isolated namespace.
Change-Id: I30523854067eb33250810e9d2f7e23b4c691541f
Signed-off-by: Shawn O. Pearce <sop@google.com>
Prettify converts a bare CR in the middle of a line of text into a
<br/>, which we later convert back into an LF. This skews all of the
line numbers through the rest of the file, resulting in a confusing
situation (due to the unexpected LF) as we try to map the formatted
HTML back into the SparseFileContent object we use for rendering.
Highlight bare CRs as spaces with whitespace error spans around them,
before we feed the text into prettify. This ensures we won't get
back more lines than we fed in, so our formatting is still correct.
Change-Id: Ib2dc8b024a2211601a588fd0552c4963d5b6e028
Signed-off-by: Shawn O. Pearce <sop@google.com>
If syntax highlighting is enabled the visual tab markers might adopt
the surrounding code's coloring due to prettify pushing its own CSS
class inside of our vt span. Override all of the prettify classes
when inside of a vt span with our own concept of the correct color.
Change-Id: I15ed9eb7348d5c4fb26f98332caed0194c6daefe
Signed-off-by: Shawn O. Pearce <sop@google.com>
The parent commit should have included these new files, it references
them to pick up the translated strings for the tooltips.
Change-Id: I907436eeb9f717d6aed17757304e461fe888187c
Signed-off-by: Shawn O. Pearce <sop@google.com>
Sometime users are confused about why Gerrit shows a particular part
of the new file (which is always green) in red. Its a whitespace
error, a case that isn't normal. Explain it with a tooltip message.
Change-Id: Ide90f14c4a25eac5a2bcb1bc9f5e6d67e9ac4cb7
Signed-off-by: Shawn O. Pearce <sop@google.com>
Inserting the HTML entity confused the prettify engine when we were
running in debug hosted mode. Instead of the Unicode character we
expected, we got an ASCII "W".
Use the actual character in the source code rather than the entity,
this should reduce the risk that the prettify engine or the browser
will become confused and misrender it.
Also correct the coloring, now that its a real character prettify is
converting it into a class named 'pun', which is contained within
the 'vt' class we created. But if syntax highlighting is off that
'pun' class doesn't exist, so we need CSS selectors for both cases.
Change-Id: I8ac03bf00cd4493ea53dcf3573cc2ba92455dfbf
Signed-off-by: Shawn O. Pearce <sop@google.com>
This is the standard character to denote tabs in a file. Previously
I was using a border line because it meant the tab would copy as a
space when the user copied the line onto the clipboard, and they had
no way to disable the visual tab indications. Now that we can turn
off the tabs, its better to use a more widely recognized character.
Change-Id: Idd6ffd4aff1c09b67f66efaf893b16f67bf1107a
Signed-off-by: Shawn O. Pearce <sop@google.com>
Users can now set the size of tabs, the number of columns displayed,
and also toggle the various flags associated with our pretty printer
like syntax coloring or intraline difference.
Change-Id: Ic86894b76fdc7f7d5e8a494227e2e8a22dd3b1b1
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way a common section in the middle of a replace line still
works properly. For example consider:
common NEW common NEW
Because the line ends in NEW stuff, we'll apply wdi onto the entire
table cell, which can cause that middle common to be showed as
though it were also NEW. That's incorrect. By always applying the
wdc class we can ensure we style that middle common the right way.
Change-Id: Id3e551ce052df15e9dfea010ba6fb17f2cc1d64c
Signed-off-by: Shawn O. Pearce <sop@google.com>
We no longer have gaps, but instead have a nice contiguous
coloring region. The visual difference is night-and-day.
Change-Id: I3e80a5860e62472713424dece49a018d584b3b65
Signed-off-by: Shawn O. Pearce <sop@google.com>
Because we show tabs as red dotted lines, on a red background it
can be hard to see. Use the heavier black dotted lines when the
tab is within either a whitespace error region or within a deleted
character region of a line.
Change-Id: I7e317127659d19ba80c9c22e4b8245e467c64fad
Signed-off-by: Shawn O. Pearce <sop@google.com>
If an edit list is only deletion regions, the B side will wind up
with an empty range as there is no new content to include in the
file. This is a corner case that means we have to always return
false from contains(int) when there is no content.
Change-Id: I745fa9ce2071acc2aa83bd84909477afeef0c3d4
Signed-off-by: Shawn O. Pearce <sop@google.com>
When we added full file content syntax highlighting on the client
we broke the ignore whitespace feature, because the client was
trying to recreate the complete file content for the B side using
an edit list that came from the ignored whitespace difference,
but was building from a sparse file content of B which was computed
from the actual difference (that is, including whitespace).
Although it seems like the edit list used shouldn't matter, the line
indexes for the A side were thrown out of whack because different
line ranges of B matched against A when whitespace was ignored.
This caused us to be unable to locate a line of context in A that
we expected to be present while trying to complete the sparse file
content for B.
The entire whitespace ignore logic has been vastly simplified.
When packing content for B we now pack any context lines that
differ from their matching line in A, thus ensuring we get the
right variant for the side-by-side viewer to display.
When pretty formatting a file, we no longer try to apply the edit
list and hunk processing to the file contents, but instead do a
direct walk over the line ranges available in the SparseFileContent.
This lets us completely bypass the index lookups, eliminating the
possibility for the bug we saw above. It also simplifies the logic
quite a bit here, instead of trying to guess about what to format,
we just format everything available.
Change-Id: I24e0a8fab7fcbb85b6db6d35a9d04fe05d1b830d
Signed-off-by: Shawn O. Pearce <sop@google.com>
Since we don't render the syntax highlighting on the server, because
its just too damn slow, we don't need a full JavaScript language
implementation in our runtime directory. Drop that dependency to
save WAR file size and reduce the amount of code we have to keep
track of.
Change-Id: I937871a8053995f36b92a99b41bb5f6e97f0d1ed
Signed-off-by: Shawn O. Pearce <sop@google.com>
We don't have enough information to do a good job of highlighting
a plain text file. Since prettify will try anyway, it looks really
odd to read one of Gerrit's own Documentation/* files. Instead just
punt (for now) and don't try to syntax highlight it.
Also avoid files that lack a file extension, these might be normal
plain text files which we can't render magically.
Change-Id: Ib52e69d16aa9203c7977fbe040f9a09f456128b1
Signed-off-by: Shawn O. Pearce <sop@google.com>
Mozilla Rhino is just slow running the JavaScript for prettify.
Its quicker inside of most modern browsers, especially ones that
have a good JIT like Goole Chrome or Safari 4.
Move the rendering back onto the client side. To do this correctly
we have to ship the entire file to the client. So what we do is,
we send the entire "A" file, the old image, and only the new lines
from the "B" file, the new image. When formatting locally on the
client we recreate the full "B" file in order to syntax highlight it.
If a file is considered large, over 9000 lines, we still only send
part of the file and we disable the syntax highlighting. This way
the client doesn't get bogged down in rendering lots of text when
the file is something really massive.
Bug: issue 439
Change-Id: Ib70c6526af09f84ebbfe467cfbb27c75ca7c9ad7
Signed-off-by: Shawn O. Pearce <sop@google.com>
Whitespace errors weren't being displayed if they occurred within
a region that was highlighted for word difference on a line, due to
the word difference HTML code preventing the patterns from matching.
Bug: issue 445
Change-Id: If4f32352aa43d7517fe7cd3f20aa8982360800a0
Signed-off-by: Shawn O. Pearce <sop@google.com>
Because we can't use background colors to denote added or removed
lines in the unified patch view, turn off syntax highlighting so
we can color the text of added lines green and deleted lines red.
Bug: issue 448
Change-Id: I994758b93e4f8b5633cd61c13911280c0bd7aafa
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now highlight any changed words within a line replace edit,
making the actual changes stand out against the surrounding context
that makes up the line.
The highlight is computed by constructing a string that covers the
entire replaced region and then running the Myers diff algorithm
over the individual characters of those two regions.
To avoid tiny edits interleaved at every other character in a
sentance we combine two neighboring character edits together if
there are only 1 or 2 characters between them. There are probably
many ways to improve on this algorithm to avoid some nasty corner
display cases, but this rule is good enough for now.
The highlight data is computed and stored as part of the diff cache,
which requires a schema change in this commit. So existing diff
cache records will be flushed on the next server start, and they
will be recomputed on demand.
Bug: issue 169
Change-Id: I69142ebef600e8c3c65821272dad3ee04a497654
Signed-off-by: Shawn O. Pearce <sop@google.com>
By executing prettify over the entire file contents, rather than
on a single line at a time, we can be certain that multi-line
comments and strings are rendered correctly all of the time, even
if it starts or ends within a hidden context region.
With this change we move prettify to run only on the server, within
the Mozilla Rhino JavaScript engine, and send to the client only
fully formatted HTML line arrays for the two files. Like before,
the server only sends partial arrays, letting the client piece it
all together at display time.
In a future commit I plan to have the client format the file if we
are showing all lines from both sides. This way the RPC response
payload is smaller, and the server can offload the parsing and
formatting load to some clients.
While writing this change I considered using Pygments running inside
of Jython, but chose to stick with prettify in Rhino. Pygments ran
much slower for the same small file contents, and doesn't leave us
with the option to execute formatting on the client side.
As part of this change we now use the Mozilla chardet library to
detect the character set of the file contents we are about to render
as HTML. The chardet library is the same logic used inside of the
Mozilla browser family to detect the character set when it isn't
specified... so its pretty accurate for a wide range of files.
In the future we should also start to honor .gitattributes to get
the encoding.
Bug: issue 250
Bug: issue 251
Change-Id: I155bb7abc560f01a3597b3be678a76a5aa7f9e68
Signed-off-by: Shawn O. Pearce <sop@google.com>
Ian Wienand