Now backspace and delete in text will select non-empty math and text insets
before deleting them. This is consistent with what happens in math already.
This is implemented for InsetText as well but can be disabled in case of
negative feedback.
This can be set for any sort of inset with the new virtual method
Inset::confirmDeletion.
New option "force" for the LFUN_*_DELETE_* commands, that bypasses the
confirmDeletion check.
Deriving from std::vector to provide helper functions appears a touch
excessive. Use typedef instead and move helper functions to the base class. New
header Toc.h provided to replace forward-declarations.
Remove TocIterator which is useless.
The recipe for reproducing this crash is to do a search and replace
that changes a string present in a collapsed inset, and then undo.
This is a followup to 17e435c4, which used editable() instead of
isActive(); this commit was amended at c2f785bd, since editable() is
not set properly in mathed.
Truth is, editable() is not the right property to test against, since
it is false for a collapsed inset, which does not prevent a cursor
from pointing inside. Therefore sanitize should not change the cursor
in this case.
Hopefuly, this is the last word on the subject. Alternative would be
to drop this if()-clause completely.
Fixes crash introduced in [17e435c4/lyxgit].
editable() is more related to Texted. It is false for closed collapsable insets
Eventually the two methods should be merged.
I thought I would need it to fix bug #9418, but once backwardInset() worked
it turned out that it is not needed. However, since it took me some time to
figure out the correct implementation I do not want to throw the result away.
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?
The code in DocIterator::sanitize now follows more closely the
previous StableDocIterator::asDocIterator code. In particular, it adds
the slices one by one, since fixIfBroken will chop the cursor
otherwise.
A dynamic_cast is necessary when:
- the object to be casted is from an external library because we can't add Qxxx::asXxxx() to Qt e.g.:
* QAbstractListModel to GuiIdListModel,
* QValidator to PathValidator,
* QWidget to TabWorkArea,
* QWidget to GuiWorkArea;
- the object is to be casted from an interface to the implementing class, because the Interface does not know by whom it is implemented:
* ProgressInterface to GuiProgress,
* Application to GuiApplication.
A dynamic_cast can be replaced by:
- already existing as***Inset() functions, e.g.:
* asHullInset(),
* asInsetMath()->asMacro(),
* asInsetText();
- a static_cast when we are sure this can't go wrong, e.g.:
* we are sure that CellData::inset->clone() is an InsetTableCell,
* in cases where we explicitly check it->lyxCode().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35855 a592a061-630c-0410-9148-cb99ea01b6c8
* Remove the EDITABLE enum,
* add functions hasSettings() for all insets.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29375 a592a061-630c-0410-9148-cb99ea01b6c8
* Buffer::nextWord(): new method to search for next word.
* DocIterator.cpp: new function isLetter() moved from GuiSpellchecker.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28963 a592a061-630c-0410-9148-cb99ea01b6c8
inset yet. The lastpos() position is only virtual to place the cursor
at a cell/paragraph end
* cleanups, documentation
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23354 a592a061-630c-0410-9148-cb99ea01b6c8
* completion support for mathed
* experimental completion support for text
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23104 a592a061-630c-0410-9148-cb99ea01b6c8
in any case does not make sense. It's not an index in the sense of DocIterator.
* cosmetics
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22908 a592a061-630c-0410-9148-cb99ea01b6c8
I'd really prefer if people would not add unused code to critical
paths..
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22534 a592a061-630c-0410-9148-cb99ea01b6c8
* DocIterator as MacroPosition
* Iterative search for macro in scope until a visible one is found.
This include the ability to resolve macro inside nested text insets.
* Speed up macro lookups by factor 2: only getMacro(name) call, no
further hasMacro(name) call before
* Both way child/master support
* Correct macro scope for multi-paragraph environments
* Correct macro scope for multi-depth-paragraphs
* Buffer::updateMacros made const
* Update macros when loaded (of master and child)
* Do not remove too many braces when unfolding a macro. This could
lead to a data loss because the relationship between arguments of
macros can be mixed up if nested macros are unfold at once.
* Reduce dependencies to MetricsInfo in MathMacro
* Update macros when needed. Normally it's done just before doing
metrics. But in cases without a brace around some constructs (like
\left(bla\right)) there is some help needed.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22241 a592a061-630c-0410-9148-cb99ea01b6c8
Now support/* should have no dependencies on src/* anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21851 a592a061-630c-0410-9148-cb99ea01b6c8
