NamePositionScopeMacroMap macros;
/// positions of child buffers in the buffer
- typedef map<Buffer const * const, DocIterator> BufferPositionMap;
struct ScopeBuffer {
ScopeBuffer() : buffer(nullptr) {}
ScopeBuffer(DocIterator const & s, Buffer const * b)
DocIterator scope;
Buffer const * buffer;
};
- typedef map<DocIterator, ScopeBuffer> PositionScopeBufferMap;
/// position of children buffers in this buffer
+ typedef map<Buffer const * const, DocIterator> BufferPositionMap;
BufferPositionMap children_positions;
/// map from children inclusion positions to their scope and their buffer
+ typedef map<DocIterator, ScopeBuffer> PositionScopeBufferMap;
PositionScopeBufferMap position_to_children;
/// Contains the old buffer filePath() while saving-as, or the
void updateData() const;
///
Buffer const * buffer_;
+ // FIXME This is probably a large part of why updateMacros is
+ // so expensive. We are, it would seem, recreating these objects
+ // from scratch each time through. That seems unnecessary, if what
+ // usually needs updating is just the pos_ member.
/// The position of the definition in the buffer.
/// There is no guarantee it stays valid if the buffer
/// changes. But it (normally) exists only until the
/// returns its defaults values and the user sees unfolded
/// macros.
mutable DocIterator pos_;
- ///
+ /// flag that tells us whether our cached info is valid. used
+ /// with lazy version.
mutable bool queried_ = false;
- ///
+ // At the moment, it seems to me as if most of the other members
+ // could be replaced by a pointer to the associated macro (and so
+ // that one eliminated. I.e.:
+ // InsetMathMacroTemplate const * const ourmacro_;
+ // docstring definition() { return ourmacro_->definition(); }
+ // etc.
+ /// the macro definition
mutable docstring definition_;
///
mutable size_t numargs_ = 0;
- ///
+ /// what we use (a kind of LyX macro) for display in the work area
mutable docstring display_;
///
latexkeys const * sym_ = nullptr;