When breaking paragraph in an empty top-level paragraph, nothing
happens on screen but yet there is an undo step because the layout is
reset to what it already was.
Avoid this case.
Fixes bug #10089.
(cherry picked from commit 2ad52918da)
The existing code already avoids merging with typewriter font, but it does not work with LyX-Code, where the typewriter family is inherited. Therefore it is Cursor::real_current_font that must be tested.
Fixes bug #9987.
By initializing 'to' to a value, the code made it seem like that
value mattered. But the value is overwritten in getWord().
Further, now if 'to' is used before it is initialized, there might
be a useful compiler warning that could point to a bug.
A plausible scenario is that change tracking is used together with a versioning
system. In this case, parallel modifications might remove an \author line on one
side, and add another change of this author on the other side. This scenario
causes a bad merge after which the added change has no associated author. In
this case, LyX used to display a list of errors on opening and deliberately
removed the corresponding change tracking information.
* If ever a tracked change refers to an author that does not exist, then add a
dummy author. This dummy author is not saved to the file afterwards.
* Have a very clear error message on opening such a corrupt file.
Use the function support:truncateWithEllipsis() to shorten a docstring with
... at the end. Actually we use U+2026 HORIZONTAL ELLIPSIS instead of "..." when
automatically shortening strings. This is to be consistent with Qt's own
truncation and is much nicer on the screen.
This includes the bugs #9575 and #9572 regarding broken text elision in the
outliner.
Known issues (non-regressions):
* TocBackend::updateItem() should be rewritten to update all TOCs. (#8386)
* "..." should be replaced with … everywhere else on the interface (including
translation strings).
* We should prefer to rely on QFontMetrics::elidedText() to truncate strings
with an ellipsis whenever possible, or an equivalent for the buffer view
dependent on the font metrics. See the warning in src/support/lstrings.h.
These were all flagged by "(style) The scope of the variable 'x' can be reduced."
Narowing the scope improves readability, and if it is in a loop then the
compiler will be clever enough to produce efficient code, we do not need
manual optimization for POD types.
This is for people who cannot grasp the superior conventions of emacs ;)
A new argument "partial" has been added to word-upcase, word-lowcase
and word-capitalize that restores the old emacs-like behavior.
The (x)emacs bindings are updated to use the "partial" argument, and
also to bind correctly M-u and M-l (M-c is unfortunately not
available).
Fixes bug #2826.
Newer boost versions use complicated type traits for boost::next and
boost::prior, which do not work with the RandomAccessList iterators.
The long term solution is to use std::next and std::prev, for now supply
simple replacements for compilers that do not support C++11 yet.
* Remove the UndoKind parameter in the general interface
* move recordUndoInset to Cursor
* remove one variant of Undo::recordUndo.
* get rid of Text::recUndo.
The only real user was Text::insertStringAsLine, but this got changed
in commit 2c7152ab.
While not other place did read the value, there is a side effect of
setAutobreakRow that merges exiting paragraphs. However, this is used
in two situations
* some constructors, where the inset is empty;
* InsetTabular::toggleFixedWidth, which actually contains itself some
code to merge paragraphs.
Therefore the member and all associated code can be removed safely.
Rely only on InsetText::allowMultipar() to get this information.
Implement this method for InsetTabular and InsetBox.
Also rely on this method for disabling LFUN_PARAGRAPH_BREAK.
The old scheme was:
* multiple insertions are undone by groups of 20
* multiple deletions are undone in one big block
The new scheme is to stop merging undo elements after 2 seconds of elapsed time.
Moreover, the merging of undo elements stops when the cursor has moved. Potentially, this could allow to remove many of the finishUndo() calls.
Fixes bug #9204.
Previously, LyX did replace some words with typeset logos, and there was no
way to prvent this except putting them, in ERT (bug #4752). Now we have
special insets for these words, and standard text is left alone.
The old hyphen replacement code did not convert hyphens if the condition
style.pass_thru || runparams.pass_thru
was met. style.pass_thru got set from inset owner (isPassThru()). Therefore
we have to consider this for the new replacement code as well.
Previously, consecutive dashes in .lyx files were combined to endash and emdash
in some cases, and in other cases they were output as is. This made the code
complicated, and resulted in inconsitencies ((bug #3647).
Now, a dash in a .lyx file is always a dash in the output, for all flavours.
The special handling is moved to the input side, so that you still get an
endash if you type two hyphens. If needed, this can be changed or made
customizable without the need to update the file format again. Many thanks
for the fruitful mailing list dicsussion, which contributed significantly to
the final version.
lyxfind.cpp(findNextChange, findPreviousChange, findChange, selectChange): factor the change-selection part out of the change-finding part
Text.cpp (acceptOrRejectChanges): call only selectChange
The real problem is the encoding of latex_language: It is hardcoded to latin1,
but InsetListig uses the currently active encoding. Therefore, we cannot tell
whether any given character wil be encodable or not, and we should not prevent
non-ACII characters.
In the future, we need to make the encoding of latex_language dynamic, so that
it always represents the currently active encoding. Then, we could do the
correct check both for listings and ERT. For now, I simply disabled the
encoding check for listings, which also means that bug 9012 might occur in
other cases for listings, but this is less important than bug 9102.
The algorithm used for breaking a paragraph in LaTeX export is changed
for avoiding spurious blank lines causing too much vertical space.
This change is tied to the introduction of a new inset (with two
different specializations) helping in either outputing LaTeX paragraph
breaks or separating environments in LyX. Both of the above goals were
previously achieved by the ---Separator--- layout and can now be
accomplished by the new inset in a more natural way. As an example,
after leaving an environment by hitting the Return key for two times,
a third return automatically inserts a parbreak inset, which is
equivalent to the old separator layout, i.e., it also introduces a
blank line in the output. If this blank line is not wanted, the
parbreak separator can be changed to a plain separator by a right
click of the mouse. Of course, an environment can still be separated
by the following one by using the Alt+P+Return shortcut (or the
corresponding menu key), but now the plain separator inset is used
instead of the old separator layout, such that no blank line occurs in
the LaTeX output.
Old documents are converted such that the LaTeX output remains unchanged.
As a result of this conversion, the old separator layout is replaced by
the new parbreak inset, which may also appear in places where the old
algorithm was introducing blank lines while the new one is not.
Note that not all blank lines were actually affecting the LaTeX output,
because a blank line is simply ignored by the TeX engine when it occurs
in the so called "vertical mode" (e.g., after an alignment environment).
The old ---Separator--- layout is now gone and old layout files using it
are also automatically converted.
Round trip conversions between old and new format should leave a document
unchanged. This means that the new behavior about paragraph breaking is
not "carried back" to the old format. Indeed, this would need introducing
special LaTeX commands in ERT that would accumulate in roundtrip
conversions, horribly cluttering the document. So, when converting a
modified document to old formats, the LaTeX output may slightly differ in
vertical spacing if the document is processed by an old version of LyX.
In other words, forward compatibility is guaranteed, but not backwards.
In the current code each paragraph contains a map<Language,
WordList*>, which means that it contains a full copy of the language
object. Since these objects contain translation tables nowadays, this
is a very bad idea.
This patch simply replaces the Language key by a string.
When loading the Userguide on linux/x86_64, the total memory
consumption decreases from 36.27MB to 31.50MB.
Currently you can easily create an uncompilable document if you insert
non-ASCII characters in a pass-through paragraph (e.g. ERT inset or verbatim
style). This commit prevents entering these characters directly, but of
course they can still be inserted via tricks, e.g. changing a standard
paragraph to verbatim. A complete fix would handle this case as well,
and also change the fixed latin1 encoding of latex_language to a dynamic one,
so that a verbatim paragraph can contain any character that is encodable in
the encoding of its environment.
(unless it's already there, in which case it should move to the end of the next paragraph).
Change the preference setting name (mac_like_word_movement to mac_like_cursor_movement)
to better reflect its function.
Patch and description from Bennett Helm
This is mostly unused private class members.
There are also a few unused functions that got #if'ed out. I never know in this case whether the code should be nuked.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
Provide functions for translating to the LyX name
of an encoding from either a LaTeX name or an Iconv
name, with the possibility to specify the package.
This is in anticipation of changing to use the LyX
name of the encoding in the .lyx file format and
allowing multiple lib/encodings entries to have
the same LaTeX name (but different packages!).
The tex2lyx parser needs to worry about the iconv
name of the input encoding, so store that instead
of the latex name.
Only the first paragraph in those sequences goes into the TOC, since the environment is merged.
This is needed to handle the forthcoming beamer environments properly in the outliner.
In the existing code for setting layout of pragraph parameters,
Text::undoSpan is used to "guess" which paragraphs should be saved in Undo.
With this patch the approach is more precise: before every explicit change
to a paragraph, a Cursor::recordUndo call is inserted. This is much more robust than trying to guess.
In particular, we do not look at depth changes at all, since they are now
handled in updateBuffer since #8159 has been fixed.
While cppcheck did not turn out any suspicious error messages, using
the "performance" flag highlighted several nitpicks in three categories
* do not use it++ for iterators, ++it is better
* do not use size() to test for emptyness, empty() is here
* do not use "const T" as a function parameter, "const & T" is better
I doubt that any of these is a real performance problem, but the code is cleaner anyway.
Text::outerFont looks recursively for paragraphs before the current one
which has a lower depth. If such a paragraph cannot be found, depthHook
and outerHook return the current paragraph. As such, we end up in an
infinite loop. So, if we find a par_depth that was the same as the
previous one, we apparently can't find a suitable paragraph and we should
quit the loop.
