We used to draw the pages to print ourselves, but it is a tedious and
error-prone task (and we did made mistakes) that Scintilla would do
better by itself. So, rewrite the GTK (e.g. non-external) print code
to use Scintilla's built-in capabilities of drawing the buffer's
content on the pages.
Not only this makes the code a lot simpler and shorter, but it gives a
more accurate render (proper handling of tab stops, wrapping on word
boundaries, no missing character when a wrapped line spans on multiple
pages, ...), and it is noticeably faster (around 3 times).
Additionally we now paginate properly, which fixes printing starting
after page 1 or printing non-contiguous pages (we used to always print
starting from page 1 and counting, no matter what pages were selected).
However, note that obviously the render is not the same, even though
it's quite similar.
f4eb89cd7d79738a9c6c45e29abdd9d15d22e4fd was partially wrong and
removed legitimate re-matches when two different matches ends at the
same position. Particularly, the replacement changes are reverted.
Interestingly, Perl and Python does not agree on how to do such
replacements. Python does what I did in the above-cited commit, e.g.
doesn't replace twice if the match end overlaps, but Perl does.
Perl looks more legitimate here since both Python and Perl does find
the overlapping matches when performing a search, so Python is the odd
guy here doing it differently on replace than it does upon search.
For example, replacing using the pattern "a?(?=b)" and the replacement
string "_":
Python: ababcdb -> _b_bcd_b
Perl: ababcdb -> __b__bcd_b
But finding using the same pattern on the same input gives the same
results on both:
Python: ababcdb -> ['a', '', 'a', '', '']
Perl: ababcdb -> ['a', '', 'a', '', '']
Anyway, GLib and us claim to support "Perl-compatible regular
expressions", so we gotta follow Perl, especially in such doubtful
situations.
Regular expressions might match empty ranges, which weren't handled
properly, but generally simply omitted.
For example, the regular expression "^$" (empty line) never matched
because we assumed empty results were not interesting, and actually
needed more care in the code. Alike, an expression matching only on
its lookahead part, like "a?(?=b)" against "b", would stop further
search, although it could even match a non-empty range if "ab" is
present later in the input. This last kind of expressions also lead
to double-replacement because they first matched "ab" and then "b"
alone when re-matching after the "a" replacement.
This commit fixes:
* searching when the matched range is empty;
* step-by-step search when matching an empty range;
* double replacement when the pattern re-matches an empty range
straight after a replacement;
* replacement to and empty string when the matching an empty range.
A know issue though is the step-by-step replacement that won't replace
an empty match but rather find the next match.
If a search matched the very last character of the document, next
search attempt started out of the document bounds. This even lead
to an infinite loop due to an improper sanity check.
By the way, this fixes matching of contiguous results, as the next
search used to improperly skip one character after the result.
Although this looks like a huge issue, it was actually visible almost
only on the match count since the whole matching line was printed.
Use the current document's directory unless the directory field has
already been edited and the current document has not changed.
Otherwise, prepend the current document's directory to the drop-down
history in case it is wanted.
This is useful to avoid losing the edited directory when it is less
likely the user wants to use the current document's directory.
Previously it was using a GLIB assertion which shouldn't be used
to detect a normal condition and so it caused a warning on the
console output when clicking "Reload" with an "untitled" document.
We explicitly use GModule's .pc since 7b2f0fe, and it provides the
appropriate flag: we don't need to add it ourselves anymore. Moreover,
since this flag is not needed (nor available) on all platforms (e.g.
Windows or MacOS X), it is safer to let GModule deal with adding it
anyway.
Scintilla deprecated SCI_GETUSEPALETTE and SCI_SETUSEPALETTE messages,
and since we don't build with deprecated API support they aren't
available anymore.
Previously, choosing another font and then pressing cancel would keep
the font selected rather than resetting it to the current editor font
because the dialog is not destroyed between showings.
Ensures all entries that get a clear icon added to the secondary position
also set the secondary icon to be activatable. This was probably
introducted during the Glade switch and could be fixed in the Glade file
but this fix ensures that even hard coded entries will always have their
clear icon activatable.
Since GLib 2.32, messages logged with levels INFO and DEBUG aren't
output by the default log handler unless the G_MESSAGES_DEBUG
environment variable contains the domain of the message or is set to
the special value "all".
Since we use INFO level messages for verbose mode, we need to make
sure this environment variable is properly set when in verbose mode.
If the caller doesn't want the list to be sorted, there is no need to
preserve the order in which the files were actually read, since that
order is undefined anyway.
GtkLabel may re-create its PangoLayout between calls leading to the
final layout used for rendering not to be set up with the appropriate
values for our sizing. Then, re-set up the layout each time we have to
deal with it and straight before GtkLabel renders it.
Since the license is a huge piece of text expected to possibly scroll
horizontally, and since most themes display the background of text
views in a different color than the default widget background color,
adding a shadow makes the edges more visible and the UI neater.
If the 'default' style isn't set to a named style, then probably the
filetype styles have been overridden with manual colors and may not
work properly with color schemes.
Note: HTML-based filetypes won't show a warning because they don't
have a 'default' style (they use 'html_default' instead).
This is a simple heuristic, but is worth having to avoid some
spurious bug reports when using the color schemes dialog.
Current color scheme was applied upon color scheme selection dialog
display because the GtkTreeView::cursor-changed signal is emitted when
the tree view is initially shown (since it actually gets the focus for
the first time), uselessly re-applying the current color scheme.
This is a performance issue because when many documents are open
updating the color scheme can take a few seconds.
Now we watch for the GtkTreeSelection::changed signal on the tree
view's selection, which is only emitted when the selected item actually
changes. We also connect to that signal after filling the tree so we
don't get notified on the initial selection setup.
