These features are active in DEVEL_VERSION when Debug is set to LATEX.
1. The TexRow information is prepended to the source panel.
2. Clicking on any line in the source triggers reverse search. (This would be an
interesting feature to implement on the user side, but we need a proper LFUN.)
The context menu did no longer work for some insets, since it requires the
cursor to be in front, and editXY() is also used to determine the inset for
the context menu. Now the cursor is corrected if needed.
These were found by cppcheck:
Member variable 'x' is not initialized in the constructor.
The crash #9788 would not have happened if this had been done earlier.
We introduce TocBuilder for building TOCs that take into account both float
insets and their captions.
* Floats without caption are shown with their content.
* Floats with a caption are shown with their caption, but clicking the entry now
correctly moves to the float and not to the caption.
* Subsequent captions produce additional entries in the TOC.
* Figures and subfigures are correctly ordered in the outliner.
* New TOC "senseless" for captions appearing alone (a bit like broken references
are still displayed in the menu and outliner).
* Disable LFUN_CAPTION_INSERT if there is already a caption in a listing
Known issues:
* Inconsistent output for includes located inside floats
* We should record the end of the float in addition of the beginning for a more
accurate cursor -> outliner entry conversion
This solves a few bugs related to the font not being set correctly.
For example, when putting a selection somewhere with
putSelectionAt(), the font was not reset so that before this commit
if the cursor was in an ERT, strange things could happen.
putSelectionAt() is notably used when highlighting the location
corresponding with a LaTeX error (GuiErrorList), when using find,
and when using the spellcheck. I could reproduce the bug using all
three of these.
Bug #9500 is an example of the type of bugs that this commit fixes.
The bug workaround added an extra repaint, which can be very bad when
editing large tables.
It turns out that the bug this is trying to fix is due to the handling
of LFUN_LINE_END in InsetMathGrid. Adding the same code as in
InsetMathNest fixes the problem.
The workaround can therefore be removed.
Currently, insets are notified that the cursor entered or leaved them in Cursor::dispatch. This is not the cas efor lfuns which are handled in BufferView.
Adding the proper code allows to fix many bugs where previews are not updated correctly.
This also reverts cf4f79f8, which was the same fix for a particular case.
Fixes bug #6173.
When editing a preview inset, or math, when we leave the inset, we
should update the preview. This update now happens for screen-up and
screen-down (commonly bound to Page Up and Page Down).
Note that this is only relevant if preview is turned on in
preferences.
This commit probably fixes other issues for any inset that defines
notifyCursorLeaves().
This fixes only part of #6173.
The computation of length on screen depend in particular of the computation of the size of an em. Many places of the code used to rely on the width of the M character, which is not really correct:
http://en.wikipedia.org/wiki/Em_%28typography%29
In digital typography, the best value to use is the point size of the font.
* Implement FontMetrics::em(), which returns the value in pixels of the EM unit.
Convert code to use it.
* Introduce Length::inPixel(MetricsBase const &), which takes the textwidth and em information from the MetricsBase object. Convert code to use it.
* Fix several places where Length::inPixel is used without a proper em value.
* add mathed_font_em() helper function. It should eventually be removed like some other functions in MathSupport.
* Add dummy implementation of FontMetrics to tex2lyx for linking purposes.
There are several places in the code where a row is painted with drawing disabled in the painter. The goal is only to recompute inset positions.
Such a case happens in BufferView::checkCursorScrollOffset, as part of the horizontal scrolling patch. Note that this particular piece of code should eventually be removed, since it is a performance problem.
It makes sense to consider that only a real painting of a row should change its status. However, I would not be surprised if this change would break other things.
Fixes: #9388
Rename recordUndoFullDocument to recordUndoFullBuffer.
Separate the notion of recording changes to paragraphs and recording changes in buffer parameters.
Audit every user of recordUndoFullDocument and replace it with either recordUndoBufferParams or recordUndoFullBuffer. Add comments to identify remaining work.
This implement horizontal scrolling of rows to allow editing insets
(math, tabular...) that are larger then the screen. The scrolling happens
as the cursor moves, in order to make sure that the cursor is always visible.
This effectively closes an 11 years old bug.
This feature is the result of the work of Hashini Senaratne as part of
Google Summer of Code 2013. The code has been cleaned-up for inclusion
and remaining bugs have been fixed.
Fixes bug: #1083.
* When doing a redraw with drawing disabled (to set inset positions properly), take horizontal scroll offset in account
* reset horizontal scroll offset when it is smaller than the left margin.
* when drawing a paragraph, do not modify x globally, only for the row that is offset.
The new code should feel a bit more natural. It avoids explicit pixel values for the margins and does not scroll in some cases where it is not necessary.
[This commit is the output of the "horizontal scrolling" GSoC 2013
project, by Hashini Senaratne. The code has been cleaned up, some
variables have been renamed and moved from the Cursor class to
BufferView::Private. This is the base from which I (jmarc) will polish
the feature for landing on master.
Below is the original commit log of Hashini, updated to reflect the
changes that have been done.]
This feature also applicable for other insets; graphics and labels.
This implementation is capable of scrolling a single row when reaching
its content which is beyond the screen limits, using left and right
arrow keys.
The attribute 'horiz_scroll_offset_' introduced in the
BufferView::Private class plays a main role in horizontal scrolling of
the wide rows that grow beyond the screen limits. This attribute
represents by how much pixels the current row that the text cursor
lies in should be get scrolled.
The main logic that is responsible for drawing the scrolled rows is
within the BufferView class, BufferView::checkCursorScrollOffset.
* The main logic is called via BufferView::draw.
* What this does is set the horiz_scroll_offset_ attribute in in order to
show the position that the text cursor lies in.
* To make sure that BufferView::draw gets involved when Update flag is
FitCursor, necessary changes are made in BufferView::processUpdateFlags.
Basically what the logic that used to set the horiz_scroll_offset_
does is,
* The row which the text cursor lies in is identified by a
CursorSlice that points to the beginning of the row. This is the
'rowSlice' variable used in BufferView::checkCursorScrollOffset. Acessors
are added to obtain this variable. Here row objects were not used to
identify the current row, because it appears that row objects can
disappear when doing a decoration update for example. This means that
comparing row pointers is not a good idea, because they can change
without notice.
* Stop calculations of horiz_scroll_offset_ variable, if metrics have not been
computed yet. Otherwise the calls to TextMetrics::parMetrics, calls
redoParagraph and may change the row heigths. Therefore vertical scrolling
feature may get disturbed. This is avoided.
* Using BufferView::::setCurrentRowSlice resets horiz_scroll_offset_
when changing cursor row. This is done in order to prevent unwanted
scrolling that happens when changing the selected row using up and
down arrow keys.
* Recompute inset positions before checking scoll offset of the row, by
painting the row insets with drawing disabled. This is done because the
position of insets is computed within the drawing procedure.
* Current x position of the text cursor is compared with the
horiz_scroll_offset_ value and the other variables like row.width(),
bv.workWidth(). Compute the new horiz_scroll_offset_ value in order
to show where the text cursor lies in. The basics conditions that we
check before recomputing it are, if the text cursor lies rightward to
the current right screen boundary, if the text cursor lies leftward
to the current left screen boundary, if the text cursor lies within
screen boundaries but the length of the row is less than the left
boundary of the screen (this happens when we delete some content of
the row using delete key or backspace key).
* Change update strategy when scrooll offset has changed. This allows to
redraw the row when no drawing was scheduled. By doing so, it was
possible to redraw a wide row when moving to the leftmost position of the
wide row, from the leftmost position of the row below, using the left
arrow key.
In TextMetrics::drawParagraph it is checked whether the current row is
what is drawing now. If it is so, the value used to the x value of the row
for drawing is adapted according to BufferView::horizScrollOffset.
The method used to pass boundary() was fixed to get row when cursor was in
a nested inset. This matter is considered in Cursor::textRow and it is
modified accordingly.
GuiWorkArea::Private::showCursor() is modified to show the cursor position
in a scrolled row.
Fix a crash reported in #7727. This happened because cur.pos() was reset before cur.pit(). In this case, cur.lastpos() will usually be wrong.
Fix bad behaviour when selecting at top level with several paragraphs.
Update documentation.
There are 3 possible actions (in order)
* select current cell
* select all calls of inset
* select the inset from outside (in the containing inset)
This fixes completely #7727.
This variable was introduced to guard against any bad consequence of the then-new right-to-left
languages support. Let's be bold and get rid of it altogether!
Now right to left support is always enabled.
Now the cursor in LyX jumps to the right spot instead of simply the
beginning of the paragraph. This is most useful for branch insets,
for example, which may contain long paragraphs.
If the reverse position corresponds to an inset, its paragraph id
does not follow the main text numbering. Typically, an inset has
only a few paragraph, so that we would jump near the beginning of
the document. In this way we at least jump at the beginning of the
inset.
for possible thread conflicts, of the sort Georg resolved at
6a30211f. I have made static variables const where possible,
and marked cases that looked potentially problematic with the
comment:
// FIXME THREAD
Many of these definitely are vulnerable to concurrent access, such
as the static variables declared at the start of output_latex.cpp.
Suppose, e.g., we were outputting latex and also displaying the
source of a different document.
I'd appreciate it if others could grep for "FIXME THREAD" and see
if some of these are harmless, or what.
* disable branch-add-insert in pass thru paragraphs
* when it is not possible to input a quote inset, insert a single
ascii quote when argument to quote-insert is "single"
* handle "mathspace" dialog in Text::getStatus
* disable insertion of newline inset in pass thru paragraphs
* handle "mathdelimiter" and "mathmatrix" dialogs in GuiView::getStatus.
Move the handling of branch-(de)activate(master) to Buffer. This code was moved to Bufferview in [3a03e71c/lyxgit] because a cursor was necessary to call Undo::recordUndoFullDocument(). However, it turns out that the undo code is already prepared to handle an empty cursor (and do nothing in this case).
Therefore we do that and move the branch code to Buffer where it belongs.
Note that there was a bug in the previous code that broke undo support: recordUndo should always be called _before_ doing any change.
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?
When using 'find' and a string is not found, this is not an error or a
surprising event. It is often expected (e.g. after searching through
the whole document for a certain string eventually you will get this
message). The exclamation mark should be reserved for messages that
are unexpected or that need extra attention, such as errors.
http://marc.info/?l=lyx-devel&m=133876924408431&w=2
The problem here is that the copy_params() routine in FindAndReplace.cpp
created a new DocumentClass, but it never updated its Buffer to reflect
that new DocumentClass. So its Paragraphs still contained points to the
Layouts in the old DocumentClass which, since ead697d4b6, gets garbage
collected once it is no longer needed. So the Layout doesn't exist, and
we crash.
objects. The problem that led to the leak is that these objects can be held in
memory long after the Buffer that created them is gone, mostly due to their
use in the CutStack. So they were previously held in a storage facility, the
DocumentClassBundle. Unfortunately, they were now being created too often,
especially by cloning. It's not really a leak, because they're accessible, but
we weren't ever destroying them.
This new approach uses a shared_ptr instead.
Thanks to Vincent for pointing out const_pointer_cast.
This reverts the previous fix in [0a33374c/lyxgit] and fixes it
differently.
We always have to call 'notifyCursorLeaves', but we only have to make sure
that we call the 'fixIfBroken()' functions first.
We rely on the 'or' operator to prevent us from calling
'notifyCursorLeaves' if one of the two cursors is broken. This doesn't
work when using the '|' operator. The compiler 'optimizes' the code in
such a way that we always call notifyCursorLeaves anyway. Using the '||'
operator fixes this.
LFUN_INSERT_PLAINTEXT is handled in GuiView because it might need to ask for a filename. But if the filename is given as a paramater we can handle it in BufferView immediately. Also, when we've asked for the filename in GuiView we should dispatch the LFUN to BufferView in order to properly use the Undo mechanism.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40377 a592a061-630c-0410-9148-cb99ea01b6c8
The trick is to rely on Cursor::selHandle instead of fiddling with the selection
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40372 a592a061-630c-0410-9148-cb99ea01b6c8
we will be cautious, of course). The problem was that we were issuing
the Buffer::changed() signal before we did updateBuffer(), and this
caused an inconsistency. The idea here is to defer issuing this signal
until we call processUpdateFlags(). We know we need a redraw if we've
deleted a whole paragraph.
This should work properly, so long as checkDepm is called from within
the dispatch mechanism. There may, however, be other paths, and I've
noted one explicitly with a FIXME in Text2.cpp. I've tested a few
different variations, however, and I haven't seen any problems. But if
we do run into problems, we can go ahead and do the update there that we
were previously doing in checkDepm itself.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40352 a592a061-630c-0410-9148-cb99ea01b6c8
- Interpret argument of LFUN_SPACE_INSERT correctly
- Use InsetMathSpace instead of InsetMathSpecialChar for "\ " (bug # 7728)
- Use InsetMathSpace instead of InsetMathChar for ~ (bug # 7728).
This fixes also the display in LyX (previously a literal ~ was displayed).
Using InsetMathSpace enables also the "Insert Formatting" menu entries.
No file format change is needed, since the LaTeX export is unchanged.
Note that there are still some bugs related to spaces in math:
#7746, #7747, #7749, #7842
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39947 a592a061-630c-0410-9148-cb99ea01b6c8
text which is not explicitly marked in a different language, irrespective
of the multilingual status, except for LTR<=>RTL changes.
See discussion in this thread:
http://thread.gmane.org/gmane.editors.lyx.devel/138380
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39702 a592a061-630c-0410-9148-cb99ea01b6c8
The patch fixes a case that I had forgotten. Namely, the case that when the height of a row was larger than the height of the screen and that the cursor is already visible. That's why I added a new if case to catch all situations in which the row height is larger than the height of the screen. If we then need scrolling we scroll to height/4 and 3*height/4. In the end, the height_/4 and 3*height_/4 should be replaced by the rowheights in the inset, but we need some extra infrastructure for that.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39697 a592a061-630c-0410-9148-cb99ea01b6c8
When a document is not multi-lingual the text contents is changed
to the new language. This should be recorded for Undo.
Because Undo wants a cursor the implemantation has to be
moved to the BufferView class.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39508 a592a061-630c-0410-9148-cb99ea01b6c8
- After introducing the displayed vertical alignment for tables, we met for the first time situations in which row.ascent is very large. To make sure the scrolling still works, we have to do the same as we did for rows with a large descent.
- change row.ascent into defaultRowHeight. Before the above mentioned change, row.ascent usually was approximately the same as defaultRowHeight (by chance). However, it is now clear we don't really want row.ascent here.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39486 a592a061-630c-0410-9148-cb99ea01b6c8
The PreviewLoader is created directly by Buffer on demand. The PreviewLoader cache was complex and unneeded because there is one and only one PreviewLoader per Buffer.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39276 a592a061-630c-0410-9148-cb99ea01b6c8
viewer to give us sensible information, but that information may be out-
generated. So we need to check and make sure the values we get are
valid.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38859 a592a061-630c-0410-9148-cb99ea01b6c8
We are missing the updateBuffer() call when we go through
mouseEventDispatch(). A consequence of the massive updateBuffer()
refactoring. Wish it had been caught before...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38667 a592a061-630c-0410-9148-cb99ea01b6c8
The one remaining question is whether we should also call resetAnchor()
at the end of setCursor().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38388 a592a061-630c-0410-9148-cb99ea01b6c8
preparatory to fixing #7080. Note that mathed uses the same routine, but
for a completely different purpose, so I did not rename it there. I have
seen no difference in behavior after testing, e.g., opening and
exporting Math.lyx, and also re-saving it and looking at the diff.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38109 a592a061-630c-0410-9148-cb99ea01b6c8
The execution order bv -> doc_bv -> buffer -> doc_buffer was artificial and not important AFAIU.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36734 a592a061-630c-0410-9148-cb99ea01b6c8
Restore the wrap-around question when no more hits found while searching with Advanced Search.
The dispatched() flag is used currently in FindAndReplace.cpp in order to discriminate between
match found and not found and, in the latter case, pop-up the wrap-around question dialog.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36279 a592a061-630c-0410-9148-cb99ea01b6c8
The dispatched() flag is used currently in FindAndReplace.cpp in order to discriminate between
match found and not found and, in the latter case, pop-up the wrap-around question dialog.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36277 a592a061-630c-0410-9148-cb99ea01b6c8
Buffer::errors("Parse") is called 7 times in the whole project. 4 times from GuiView and three times from functions in other classes, but which are (almost) only called from the GuiView.
Buffer::errors is used to signal the GUI that there might be an error occuring, but what sense does it make if it is only called from the Gui ?
Isn't it better to let the function return wether it succeeded or not and let the GuiView take action in doing something with the possible errors.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35911 a592a061-630c-0410-9148-cb99ea01b6c8
An example of a fatal function call is "gotoInset(this, NOTE_CODE, true)". Luckily we don't check for the contents in LFUN_NOTE_NEXT.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35860 a592a061-630c-0410-9148-cb99ea01b6c8
avoids multiple screen redraws in some cases.
If someone knows how to fix the FIXMEs in GuiErrorList and
GuiSpellcheker, I'd really appreciate it.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35651 a592a061-630c-0410-9148-cb99ea01b6c8
be telling us. I'm not sure why this wasn't being used any more.
If we find any missing updates, it may be because the inset dispatch
stuff wasn't doing its job.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35634 a592a061-630c-0410-9148-cb99ea01b6c8
* src/LyXAction.cpp: add ReadOnly flag to LFUN_UNDO and LFUN_REDO, since
we do not want the dispatch mechanism to mark buffer dirty after them.
* src/BufferView.cpp: handle "by hand" the activation of undo/redo
* src/Undo.cpp: add lyx_clean member to UndoElement and make sure to
maintain it with undo operations; add a new markDirty() member for UndoStack
* src/Buffer.cpp: when saving a document, mark the undo and redo stacks
elements as dirty.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35068 a592a061-630c-0410-9148-cb99ea01b6c8
reported by the caller. Otherwise, you could get the error message the
first time, and then it would succeed the second!!
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35019 a592a061-630c-0410-9148-cb99ea01b6c8
DispatchResult to store a flag that tells us whether we need a buffer
update or not.
So: If you find a missing one, go to an appropriate place in the
dispatch and call cur.forceBufferUpdate() or, if you don't have a cursor
but do have a DispatchResult, call dr.forceBufferUpdate().
There is one remaining call I could not move, in
TextMetrics::redoParagraph. But this looks like an emergency call when
the macro context has not been set. There are also a couple calls that
are connected with buffer creation that I commented out, since the same
call is done again almost immediately. But I'm not positive about those.
Now the nice thing would be to do the same for updateMacros().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34826 a592a061-630c-0410-9148-cb99ea01b6c8
Clear the mouse_hover state when closing the BufferView. Otherwise, there will be an invalid pointer stored in the Inset and crashing LyX when the Inset's destructor is called.
See also r33908, r34117, r34348, r34353, r34354, r34363 and bug #3900.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34365 a592a061-630c-0410-9148-cb99ea01b6c8
Now, we only want to let the last_inset_ pointer point at insets that accept the mouse_hover setting. Otherwise, the pointer is not cleared on deletion of the inset.
See also r33908, r34117, r34348, r34353 and bug #3900.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34354 a592a061-630c-0410-9148-cb99ea01b6c8
This is also in preparation of a decent fix for bug #3900.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34347 a592a061-630c-0410-9148-cb99ea01b6c8
Fix the regression introduced in r28397 while fixing bug #5573.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34296 a592a061-630c-0410-9148-cb99ea01b6c8
We need a way to test for the pointer to be valid before using it in updateHoveredInset(). For now, just set it to zero, so that this critical won't find its way into alpha-2.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34117 a592a061-630c-0410-9148-cb99ea01b6c8
Change inset-forall so that screen is not repainted at each iteration, since this lead to very slow opeartion on large files. This is not a problem for current uses, but can potentially lead to crashes.
See ticket #6641 for more thoughts and possible solutions.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34092 a592a061-630c-0410-9148-cb99ea01b6c8
When updating the screen, moving the mouse, or scrolling the buffer, we check whether the hovering status of the insets.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33908 a592a061-630c-0410-9148-cb99ea01b6c8
a lot of simplification is possible. Except some instability period...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33389 a592a061-630c-0410-9148-cb99ea01b6c8
Split LyXFunc::dispatch into a wrapper that does the actual screen updates and
a worker method that updates a DispatchResult object.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33226 a592a061-630c-0410-9148-cb99ea01b6c8
- Fix crash when performing word-replace while the cursor has a selection
in mathed (bug 6437)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33204 a592a061-630c-0410-9148-cb99ea01b6c8
current buffer and applies a given function at cursor position before the
inset. It is actually possible to filter on the type of inset.
Remove all index insets:
inset-forall Index delete-char-forward
Remove all (!!) insets:
inset-forall * delete-char-forward
Close all Notes (also works for a particular branch, for example)
inset-forall Note inset-toggle close
Close only yellow sticky notes
inset-forall Note:Note inset-toggle close
Of course, things may become weird:
Put LyX in an infinite loop if there is at least a Note
inset-forall Note char-backward
In this case, the code will stop after 1000 iterations.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32834 a592a061-630c-0410-9148-cb99ea01b6c8
- scopes now handled in FindAndReplaceWidget, while lyxfind.cpp only searches within single buffer
- cursor().result().dispatched() now encodes whether a match was found or not, after LFUN_WORD_FINDADV dispatch
- removed a few unneeded functions
- followed a few cosmetic advices
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32760 a592a061-630c-0410-9148-cb99ea01b6c8
Move the AtPoint handling into the Cursor dispatch machinery
Note that the call to Cursor::getStatus is in BufferView::getStatus, while
the call to Cursor::dispatch is still in LyXFunc::dispatch. This needs to be
fixed, but the code there is a bit fragile.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31969 a592a061-630c-0410-9148-cb99ea01b6c8
The solution is just to remove special code :)
I think there is a ticket for this, but I cannot find it.
Abdel, could you please validate my thinking?
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31869 a592a061-630c-0410-9148-cb99ea01b6c8
I still don't know why it is that bad that this call is made below, but this seems to fix the problem.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31758 a592a061-630c-0410-9148-cb99ea01b6c8
The list of dialog edited inset is now stored in BufferView.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31472 a592a061-630c-0410-9148-cb99ea01b6c8
* Add a recenter() call to BufferView::setCursorFromRow() in order to get the screen centered around the found position.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31455 a592a061-630c-0410-9148-cb99ea01b6c8
I tested this on Windows and Linux/X11 but not on Mac so...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31451 a592a061-630c-0410-9148-cb99ea01b6c8
* I transferred local function loadLayoutFile() in LyXFunc.cpp to a LayoutFileList::load().
Richard, as I am not into this layout thing, please check that these LFUNs still operate correctly (except from an embedded work area of course).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31412 a592a061-630c-0410-9148-cb99ea01b6c8
LFUN_BUFFER_PARAMS_APPLY has now a status (disabled if read-only).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31411 a592a061-630c-0410-9148-cb99ea01b6c8
