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
