cursorup/down
- shouldn't these be handled by the BufferView? As opposed to right/left, they (should/used to) ignore the document structure. Right now they enter in insets ignoring it, but exit insets losing the x coordinate (by some dispatchresult flag I presume). Alfredo
Re: [patch] towards simplified left/right/up/down
Andre Poenitz wrote: > +cursorRight(bv()); note that cursorRight takes a bool argument. (Dunno what's for, though ;-) Alfredo
Re: [patch] remove InsetText::cx/xy
On Mon, Nov 17, 2003 at 07:16:15PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > not really needed. > > > > What's the current state of coordinate handling btw? > > My selection2.diff patch makes passing mouse events to the main LyXText in > coordinates relatives to the LyXText itself (like for insets right now), > i.e. no more as screen coordinates. This in particular means absolute doc > coordinates for the main LyXText. > > The rest is unchanged I think (i.e. insets keep their coords. as relative to > screen) I noticed some regression that might be related to the CursorItem::cached_y_ change. Simply move through the attached doc with to see what I mean. The interesting point comes when leaving the inner inset. And then we should make our minds up concerning tabulars. Is this a single inset with multiple cells (that's the 'mathed way') or is it two levels of insets (that's more or less what's implemented right now). In the light of IU and simplicity I lean towards the first option, but I am not sure. Behaviour would probably change then (i.e. multi-cell selection in the mathed way, not the current tabular way. I don't see that as disadvantage, but then I am not impartial...) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...) #LyX 1.4.0cvs created this file. For more info see http://www.lyx.org/ \lyxformat 225 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 1 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes 0 \end_header \begin_layout Standard s \end_layout \begin_layout Standard \begin_inset Boxed position "t" hor_pos "c" has_inner_box 1 inner_pos "t" use_parbox 0 width "10cm" special "none" height "1in" height_special "totalheight" collapsed false \begin_layout Standard ccds cs adc asd ca sdc as dc asd cas dc asd c asd csd c dasddasdc \end_layout \begin_layout Standard \begin_inset ovalbox position "t" hor_pos "c" has_inner_box 1 inner_pos "t" use_parbox 0 width "4cm" special "none" height "1in" height_special "totalheight" collapsed false \begin_layout Standard ascd \end_layout \end_inset scd \end_layout \end_inset \end_layout \begin_layout Standard c \end_layout \end_document
Re: some current bugs
On Mon, Nov 17, 2003 at 07:21:22PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Alfredo is still trying to be nice. We have to work on that...
>
> So I can become an angry caveman too? ;-)
Would be a step forward on the UIU trail ("user interface unification")
Andre'
Re: tex2lyx and optional arguments
On Mon, Nov 17, 2003 at 08:58:36PM +0100, Georg Baum wrote: > Am Montag, 17. November 2003 09:52 schrieb Andre Poenitz: > > Looks good. Is this ready for 'commit'? > > Yes. Maybe with the size() -> !empty() change suggested by Angus. BTW, this > construct is used at a few other places in tex2lyx, some from me, some from > others. Feel free to correct that. For vectors it's more or less a matter of style, but !empty() is somehow more explicit... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: cursorup/down
On Tue, Nov 18, 2003 at 09:19:16AM +0100, Alfredo Braunstein wrote: > - shouldn't these be handled by the BufferView? Maybe. I am not sure, though. > As opposed to right/left, they (should/used to) ignore the document > structure. Getting up/down (sort of) right was _the_ problem when glueing the mathed shards together. It currently is some mixture based on inset nesting and setting by coordinate. As the outer world is a bit simpler I'd expect we could get away with a pure nesting based solution. > Right now they enter in insets ignoring it, but exit insets losing the x > coordinate (by some dispatchresult flag I presume). The target x is BufferView::target_x_. Maybe its not updated often enough... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] towards simplified left/right/up/down
On Tue, Nov 18, 2003 at 09:24:45AM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > +cursorRight(bv()); > > note that cursorRight takes a bool argument. (Dunno what's for, though ;-) funny. I copied this from somewhere else. So the argument doesn't look terribly important, does it? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] remove InsetText::cx/xy
Andre Poenitz wrote: > On Mon, Nov 17, 2003 at 07:16:15PM +0100, Alfredo Braunstein wrote: >> Andre Poenitz wrote: >> >> > not really needed. >> > >> > What's the current state of coordinate handling btw? >> >> My selection2.diff patch makes passing mouse events to the main LyXText >> in coordinates relatives to the LyXText itself (like for insets right >> now), i.e. no more as screen coordinates. This in particular means >> absolute doc coordinates for the main LyXText. >> >> The rest is unchanged I think (i.e. insets keep their coords. as relative >> to screen) > > I noticed some regression that might be related to the > CursorItem::cached_y_ change. Simply move through the attached doc > with to see what I mean. The interesting point comes when > leaving the inner inset. I see it, though I don't get why is it related to cached_y. Does use coordinates? I thought that moved using solely document structure. If I understand correctly, the problem is that we don't 'clear' the text->cursor information when we pop or push the LCursor. For instance: select something inside the inset, then click outside, then enter the inset by or , and you will see the old selection. > And then we should make our minds up concerning tabulars. Is this a > single inset with multiple cells (that's the 'mathed way') or is it two > levels of insets (that's more or less what's implemented right now). If it is only one inset, then we will have to take care of all dispatching down (i.e. a bit of code duplication). > In the light of IU and simplicity I lean towards the first option, but I > am not sure. Behaviour would probably change then (i.e. multi-cell > selection in the mathed way, not the current tabular way. I don't see > that as disadvantage, but then I am not impartial...) I will experiment a little with 1.3.2 to make my mind. Alfredo
Re: [patch] towards simplified left/right/up/down
Andre Poenitz wrote: > On Tue, Nov 18, 2003 at 09:24:45AM +0100, Alfredo Braunstein wrote: >> Andre Poenitz wrote: >> >> > +cursorRight(bv()); >> >> note that cursorRight takes a bool argument. (Dunno what's for, though >> ;-) > > funny. I copied this from somewhere else. So the argument doesn't look > terribly important, does it? A value actually seems to allows entering insets. (note that it seems we still have the problem with exiting I mentioned in the other thread) Alfredo
Re: [patch] remove InsetText::cx/xy
On Tue, Nov 18, 2003 at 09:50:32AM +0100, Alfredo Braunstein wrote: > > I noticed some regression that might be related to the > > CursorItem::cached_y_ change. Simply move through the attached doc > > with to see what I mean. The interesting point comes when > > leaving the inner inset. > > I see it, though I don't get why is it related to cached_y. Does use > coordinates? No. It was just that I was looking for someone else to blame. > I thought that moved using solely document structure. Me too. > If I understand correctly, the problem is that we don't 'clear' the > text->cursor information when we pop or push the LCursor. > For instance: select something inside the inset, then click outside, then > enter the inset by or , and you will see the old selection. Ah yes. So we > > And then we should make our minds up concerning tabulars. Is this a > > single inset with multiple cells (that's the 'mathed way') or is it two > > levels of insets (that's more or less what's implemented right now). > > If it is only one inset, then we will have to take care of all dispatching > down (i.e. a bit of code duplication). Not much, if any at all. Have a look at math_gridinset.C to get animpression what is needed. > > In the light of IU and simplicity I lean towards the first option, but I > > am not sure. Behaviour would probably change then (i.e. multi-cell > > selection in the mathed way, not the current tabular way. I don't see > > that as disadvantage, but then I am not impartial...) > > I will experiment a little with 1.3.2 to make my mind. Good. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [Patch] XML sanitation part II
On Mon, Nov 17, 2003 at 11:16:57PM +0200, Martin Vermeer spake thusly:
> My primary objective with this is to parametrize the docbook list code
> by moving stuff from LyX to the .layout files. (Yes, this makes them a
> little messier looking right now. Doesn't bother the end user nor the
> LaTeX-only user.)
>
> This is not finished yet: inside simpleDocBookOnePar there is the
> listitem/para stuff still irritatingly hardwired. (In AGU this takes
> the form .)
Here is the slightly improved version. Now also listitem/para inside
simpleDocBookOnePar is fully parametrized: it takes the default layout
name (para for docbook, p for AGU) to build the innermost tags in list
items. I suspect this must be generally valid (?)
Does this more clearly illustrate the idea?
Check-in later today, shout to object ;-)
- Martin
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
Index: lib/layouts/db_stdlists.inc
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/layouts/db_stdlists.inc,v
retrieving revision 1.4
diff -u -p -r1.4 db_stdlists.inc
--- lib/layouts/db_stdlists.inc 15 Sep 2003 15:20:18 - 1.4
+++ lib/layouts/db_stdlists.inc 18 Nov 2003 08:27:06 -
@@ -11,18 +11,23 @@ Input stdlists.inc
Style Itemize
LatexType Item_Environment
LatexName itemizedlist
+ ItemTag listitem
End
Style Enumerate
LatexType Item_Environment
LatexName orderedlist
+ ItemTag listitem
End
Style Description
LatexType Item_environment
LatexName variablelist
+ InnerTag varlistentry
+ LabelTag term
+ ItemTag listitem
End
# maybe List is the same as simplelist (I need to check it).
Index: src/lyxlayout.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlayout.C,v
retrieving revision 1.23
diff -u -p -r1.23 lyxlayout.C
--- src/lyxlayout.C 14 Nov 2003 14:05:03 - 1.23
+++ src/lyxlayout.C 18 Nov 2003 08:27:06 -
@@ -82,6 +82,8 @@ enum LayoutTags {
LT_TOPSEP,
LT_TOCLEVEL,
LT_INNERTAG,
+ LT_LABELTAG,
+ LT_ITEMTAG,
LT_INTITLE // keep this last!
};
@@ -145,6 +147,7 @@ bool LyXLayout::Read(LyXLex & lexrc, LyX
{ "innertag", LT_INNERTAG },
{ "intitle",LT_INTITLE },
{ "itemsep",LT_ITEMSEP },
+ { "itemtag",LT_ITEMTAG },
{ "keepempty", LT_KEEPEMPTY },
{ "labelbottomsep", LT_LABEL_BOTTOMSEP },
{ "labelcounter", LT_LABELCOUNTER },
@@ -153,6 +156,7 @@ bool LyXLayout::Read(LyXLex & lexrc, LyX
{ "labelsep", LT_LABELSEP },
{ "labelstring",LT_LABELSTRING },
{ "labelstringappendix", LT_LABELSTRING_APPENDIX },
+ { "labeltag", LT_LABELTAG },
{ "labeltype", LT_LABELTYPE },
{ "latexfooter",LT_LATEXFOOTER },
{ "latexheader",LT_LATEXHEADER },
@@ -337,6 +341,16 @@ bool LyXLayout::Read(LyXLex & lexrc, LyX
case LT_INNERTAG:
if (lexrc.next())
innertag_ = lexrc.getString();
+ break;
+
+ case LT_LABELTAG:
+ if (lexrc.next())
+ labeltag_ = lexrc.getString();
+ break;
+
+ case LT_ITEMTAG:
+ if (lexrc.next())
+ itemtag_ = lexrc.getString();
break;
case LT_PREAMBLE:
Index: src/lyxlayout.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlayout.h,v
retrieving revision 1.17
diff -u -p -r1.17 lyxlayout.h
--- src/lyxlayout.h 14 Nov 2003 14:05:03 - 1.17
+++ src/lyxlayout.h 18 Nov 2003 08:27:06 -
@@ -65,6 +65,10 @@ public:
///
std::string const & innertag() const { return innertag_; }
///
+ std::string const & labeltag() const { return labeltag_; }
+ ///
+ std::string const & itemtag() const { return itemtag_; }
+ ///
std::string const & labelstring_appendix() const {
return labelstring_appendix_;
}
@@ -211,6 +215,10 @@ private:
std::string latexparam_;
/// Internal tag to use (e.g., for sect header)
std::string innertag_;
+ /// Internal tag to use e.g. to surround varlistentry label)
+ std::string labeltag_;
+ /// Internal tag to surround the item text in a list)
+ std:
Re: cursorup/down
Andre Poenitz wrote: > On Tue, Nov 18, 2003 at 09:19:16AM +0100, Alfredo Braunstein wrote: >> - shouldn't these be handled by the BufferView? > > Maybe. I am not sure, though. > >> As opposed to right/left, they (should/used to) ignore the document >> structure. > > Getting up/down (sort of) right was _the_ problem when glueing the > mathed shards together. It currently is some mixture based on inset > nesting and setting by coordinate. As the outer world is a bit simpler > I'd expect we could get away with a pure nesting based solution. > >> Right now they enter in insets ignoring it, but exit insets losing the x >> coordinate (by some dispatchresult flag I presume). > > The target x is BufferView::target_x_. Maybe its not updated often > enough... Mmm... but we don't use x_target_ at all IIUC. We simply return with DISPATCHED_RIGHT/LEFT when exiting and inset. This is why I think that we should handle it directly in the BufferView. [I think that the problem with target_x_ is that it is updated *too much*, and thus it is completely in-sync with the cursor (and thus useless). I'll have a look at it.] Alfredo
Re: [Patch] XML sanitation part II
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Mon, Nov 17, 2003 at 11:16:57PM +0200, Martin Vermeer spake thusly: | >> My primary objective with this is to parametrize the docbook list code >> by moving stuff from LyX to the .layout files. (Yes, this makes them a >> little messier looking right now. Doesn't bother the end user nor the >> LaTeX-only user.) >> >> This is not finished yet: inside simpleDocBookOnePar there is the >> listitem/para stuff still irritatingly hardwired. (In AGU this takes >> the form .) > | Here is the slightly improved version. Now also listitem/para inside | simpleDocBookOnePar is fully parametrized: it takes the default layout | name (para for docbook, p for AGU) to build the innermost tags in list | items. I suspect this must be generally valid (?) > | Does this more clearly illustrate the idea? > | Check-in later today, shout to object ;-) Object! I am all for cleaning up and parametization. But I am not quite sure what implications this will have. What I do not like (seemingly) is that docbook get it cleaned up, latex stays ugly. We need to have solutions that make the .layout format better and that works with all first-class output formats. How does this listitem stuff fit with LaTeX? Does it fit at all? -- Lgb
Re: cursorup/down
On Tue, Nov 18, 2003 at 10:01:35AM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > On Tue, Nov 18, 2003 at 09:19:16AM +0100, Alfredo Braunstein wrote: > >> - shouldn't these be handled by the BufferView? > > > > Maybe. I am not sure, though. > > > >> As opposed to right/left, they (should/used to) ignore the document > >> structure. > > > > Getting up/down (sort of) right was _the_ problem when glueing the > > mathed shards together. It currently is some mixture based on inset > > nesting and setting by coordinate. As the outer world is a bit simpler > > I'd expect we could get away with a pure nesting based solution. > > > >> Right now they enter in insets ignoring it, but exit insets losing the x > >> coordinate (by some dispatchresult flag I presume). > > > > The target x is BufferView::target_x_. Maybe its not updated often > > enough... > > Mmm... but we don't use x_target_ at all IIUC. We simply return with > DISPATCHED_RIGHT/LEFT when exiting and inset. The containing inset should have a look at BufferView::target_x_ when dispatching this. > This is why I think that we should handle it directly in the BufferView. This is one option, which should work with the kind of rectangular structure we have in the outer world. It's not sufficient for math, though. But we don't care about that right now... > [I think that the problem with target_x_ is that it is updated *too much*, > and thus it is completely in-sync with the cursor (and thus useless). I'll > have a look at it.] Might be true... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: cursorup/down
Alfredo Braunstein wrote: > Mmm... but we don't use x_target_ at all IIUC. We simply return with > DISPATCHED_RIGHT/LEFT when exiting and inset. ugh: FINISHED_UP/DOWN Alfredo
Re: [patch] remove InsetText::cx/xy
Andre Poenitz wrote: >> If I understand correctly, the problem is that we don't 'clear' the >> text->cursor information when we pop or push the LCursor. >> For instance: select something inside the inset, then click outside, then >> enter the inset by or , and you will see the old selection. > > Ah yes. So we I was kind of hoping you finished this phrase ;-) What should we do? My idea is that when pushing or popping we should update also the text->cursor info. The problem is that this is done in insets/ and in cursor.C, where we don't exactly have the information to do this. We could search for the inset in the containing insettext (not a very nice thing to do in insets/ at least) On the end, maybe we should implement cursor on top of a PosIterator + tip inset. (but after we have only one slice for tables)? Alfredo
Re: [patch] remove InsetText::cx/xy
On Tue, Nov 18, 2003 at 10:54:06AM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> If I understand correctly, the problem is that we don't 'clear' the > >> text->cursor information when we pop or push the LCursor. > >> For instance: select something inside the inset, then click outside, then > >> enter the inset by or , and you will see the old selection. > > > > Ah yes. So we > > I was kind of hoping you finished this phrase ;-) Ups. Aehm... so we should reset it somehow? Don't ask me how. Reseting the selection in the edit() call might already help a bit. > What should we do? My idea is that when pushing or popping we should > update also the text->cursor info. The problem is that this is done in > insets/ and in cursor.C, where we don't exactly have the information > to do this. > > We could search for the inset in the containing insettext (not a very > nice thing to do in insets/ at least) > > On the end, maybe we should implement cursor on top of a PosIterator + > tip inset. That's the long term goal, yes. This is directly usable for IU. > (but after we have only one slice for tables)? I wait for the result of your examinations here ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
was: [patch] remove InsetText::cx/xy. is: up/down in insets
Andre Poenitz wrote: >> > In the light of IU and simplicity I lean towards the first option, but >> > I am not sure. Behaviour would probably change then (i.e. multi-cell >> > selection in the mathed way, not the current tabular way. I don't see >> > that as disadvantage, but then I am not impartial...) Tables have a lot of problems with selection (like being forced to use the mouse, insert of a multi-cell cut actually silently overrides). So you are not comparing exactly with a high standard. ;-) >> >> I will experiment a little with 1.3.2 to make my mind. > > Good. Done. My feeling: tabular's way seems more structured but harder to use. (for instance you lose your x_target etc) And it has these strange extra cursor positions. Mathed's way seems better in general. If the only possible drawbacks are selections, then I'd say go for it... (but of course, I'm not the only one here ;-) Alfredo
Re: was: [patch] remove InsetText::cx/xy. is: up/down in insets
Alfredo Braunstein wrote: > If the only possible drawbacks are selections, then I'd say go for > it... > > (but of course, I'm not the only one here ;-) Don't forget that the main motivation for _all_ these changes is a desire for clean and understandable code. Mathed certainly fits the bill there. Moreover, a single implementation is less code to maintain. I think that we can bring our users along with us if this entails a change in the way the tables are navigated, so long as the replacement is still 'natural'. Regards, -- Angus
Re: was: [patch] remove InsetText::cx/xy. is: up/down in insets
On Tue, Nov 18, 2003 at 11:16:30AM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> > In the light of IU and simplicity I lean towards the first option, but > >> > I am not sure. Behaviour would probably change then (i.e. multi-cell > >> > selection in the mathed way, not the current tabular way. I don't see > >> > that as disadvantage, but then I am not impartial...) > > Tables have a lot of problems with selection (like being forced to use the > mouse, insert of a multi-cell cut actually silently overrides). Note that this is not necessary (neither with the one nor with the two slice approach. It just happens that the current (1.3.x) implementation is not optimal) > So you are not comparing exactly with a high standard. ;-) > > >> > >> I will experiment a little with 1.3.2 to make my mind. > > > > Good. > > Done. > > My feeling: tabular's way seems more structured but harder to use. Ok. Same for me. > (for instance you lose your x_target etc) That again is an implementation detail that's not technically necessary > And it has these strange extra cursor positions. Mathed's way seems > better in general. If the only possible drawbacks are selections, > then I'd say go for it... As I said, I am a bit biased here. But I've created quite a few tables inside mathed (i.e. abused mathed) just to be able to use mathed style editing instead of the usual tabular editing. Most notable, structural changes (add/delete/swap row/columns) is much simpler to access there..) > (but of course, I'm not the only one here ;-) Well. The rest's seems to be gone to hibernation... Andre'
[patch 13x] autogen.sh accepts autoconf 2.58
Jean-Marc, Debian unstable now uses autoconf 2.58 by default. The attached patch tells autogen.sh to allow its use. All works perfectly. Ok to apply to the 1.3.x series? Angus ps, I don't have the 1.4.x tree checked out here. Could someone apply the patch to that for me please?Index: autogen.sh === RCS file: /usr/local/lyx/cvsroot/lyx-devel/autogen.sh,v retrieving revision 1.42.2.4 diff -u -p -r1.42.2.4 autogen.sh --- autogen.sh 14 Apr 2003 16:46:49 - 1.42.2.4 +++ autogen.sh 18 Nov 2003 10:27:51 - @@ -19,7 +19,7 @@ case $autoversion in rm -f lib/reLyX/configure.ac EXTRA_ACINCLUDE_FILES="lyxinclude213.m4" ;; -*2.5[23467]) +*2.5[234678]) rm -f acconfig.h rm -f configure.in cp config/configure.ac . @@ -29,7 +29,7 @@ case $autoversion in ;; *) echo "This autoconf version is not supported by LyX." - echo "LyX only supports autoconf 2.13 and 2.5[23467]." + echo "LyX only supports autoconf 2.13 and 2.5[234678]." exit ;; esac Index: ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v retrieving revision 1.906.2.27 diff -u -p -r1.906.2.27 ChangeLog --- ChangeLog 7 Nov 2003 15:12:17 - 1.906.2.27 +++ ChangeLog 18 Nov 2003 10:27:51 - @@ -1,3 +1,7 @@ +2003-11-18 Angus Leeming <[EMAIL PROTECTED]> + + * autogen.sh: accept autoconf 2.58 as a supported version. + 2003-11-07 Ronald Florence <[EMAIL PROTECTED]> * README.MacOSX: small update
Re: [patch 13x] autogen.sh accepts autoconf 2.58
On Tue, Nov 18, 2003 at 10:37:20AM +, Angus Leeming wrote: > ps, I don't have the 1.4.x tree checked out here. Could someone apply > the patch to that for me please? Done.
Re: [Patch] XML sanitation part II
On Tue, Nov 18, 2003 at 10:12:31AM +0100, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Mon, Nov 17, 2003 at 11:16:57PM +0200, Martin Vermeer spake thusly:
> |
> >> My primary objective with this is to parametrize the docbook list code
> >> by moving stuff from LyX to the .layout files. (Yes, this makes them a
> >> little messier looking right now. Doesn't bother the end user nor the
> >> LaTeX-only user.)
> >>
> >> This is not finished yet: inside simpleDocBookOnePar there is the
> >> listitem/para stuff still irritatingly hardwired. (In AGU this takes
> >> the form .)
> >
> | Here is the slightly improved version. Now also listitem/para inside
> | simpleDocBookOnePar is fully parametrized: it takes the default layout
> | name (para for docbook, p for AGU) to build the innermost tags in list
> | items. I suspect this must be generally valid (?)
> >
> | Does this more clearly illustrate the idea?
> >
> | Check-in later today, shout to object ;-)
>
> Object!
>
> I am all for cleaning up and parametization. But I am not quite sure
> what implications this will have. What I do not like (seemingly) is
> that docbook get it cleaned up, latex stays ugly. We need to have
> solutions that make the .layout format better and that works with all
> first-class output formats.
>
> How does this listitem stuff fit with LaTeX? Does it fit at all?
>
> --
> Lgb
listitem doesn't exist in LaTeX. It is the tags surrounding an item's
text in an item environment.
For LaTeX we have
\item some item text for itemize or enumerate
\item[label]some item text for description
So we can say that, by analogy,
InnerTag (empty)
LabelTag \item[...] for description, otherwise empty
ItemTag(empty) for all
Generically:
\begin{LatexName}
item text for itemize/enum
label_textitem text for description
...
\end{LatexName}
For LaTeX, all of this seems currently to be hardwired.
Sure it could be parametrized too... but how? And to what advantage?
All LaTeX document classes handle this pretty much in an identical
way.
Of course this might open up the way to supporting some optional
packages like Carlisle's environment thing.
Or get rid of the body_pos ugliness. The really right solution would
be a description label inset as José remarked -- but that's not for 1.4
I think.
Open to suggestions.
- Martin
pgp0.pgp
Description: PGP signature
Re: [patch 13x] autogen.sh accepts autoconf 2.58
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc, Debian unstable now uses autoconf 2.58 by default. Angus> The attached patch tells autogen.sh to allow its use. All works Angus> perfectly. Angus> Ok to apply to the 1.3.x series? Yes. JMarc
Re: [patch 13x] autogen.sh accepts autoconf 2.58
Andre Poenitz wrote: > On Tue, Nov 18, 2003 at 10:37:20AM +, Angus Leeming wrote: >> ps, I don't have the 1.4.x tree checked out here. Could someone >> apply the patch to that for me please? > > Done. Vielen Dank. -- Angus
Re: [patch 13x] autogen.sh accepts autoconf 2.58
Jean-Marc Lasgouttes wrote: > Angus> Jean-Marc, Debian unstable now uses autoconf 2.58 by default. > Angus> The attached patch tells autogen.sh to allow its use. All > works Angus> perfectly. > Angus> Ok to apply to the 1.3.x series? > Yes. Merci beaucoup! -- Angus
Re: cursorup/down
Andre Poenitz wrote:
>> [I think that the problem with target_x_ is that it is updated *too
>> [much*,
>> and thus it is completely in-sync with the cursor (and thus useless).
>> I'll have a look at it.]
>
> Might be true...
It was.
This patch solves this, + some bv() -> true (except in moveUp/Down, where it
was set to false to allow entering insets)
[another problem: we should set x_target in absolute coordinates, but we do
it within LyXText, and LyXText doesn't kown it's own absolute x coords.
Maybe it should?]
Alfredo
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.22
diff -u -p -u -r1.22 cursor.C
--- cursor.C 14 Nov 2003 18:15:58 - 1.22
+++ cursor.C 18 Nov 2003 11:15:47 -
@@ -120,7 +120,7 @@ void LCursor::push(UpdatableInset * inse
{
lyxerr << "LCursor::push() inset: " << inset << endl;
data_.push_back(CursorItem(inset));
- cached_y_ = bv_->top_y() + innerInset()->y();
+ updatePos();
}
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.502
diff -u -p -u -r1.502 text2.C
--- text2.C 17 Nov 2003 20:28:09 - 1.502
+++ text2.C 18 Nov 2003 11:15:52 -
@@ -257,7 +257,7 @@ void LyXText::toggleInset()
&& inset_owner->owner()->isOpen()) {
finishUndo();
inset_owner->owner()->close(bv());
- bv()->getLyXText()->cursorRight(bv());
+ bv()->getLyXText()->cursorRight(true);
bv()->updateParagraphDialog();
}
return;
@@ -1175,7 +1175,7 @@ void LyXText::setSelectionRange(lyx::pos
selection.cursor = cursor;
while (length--)
- cursorRight(bv());
+ cursorRight(true);
setSelection();
}
@@ -1340,7 +1340,6 @@ void LyXText::setCursor(LyXCursor & cur,
}
// now get the cursors x position
cur.x(int(getCursorX(pit, row, pos, boundary)));
- bv()->x_target(cur.x());
}
@@ -1405,6 +1404,7 @@ void LyXText::setCursorIntern(paroffset_
pos_type pos, bool setfont, bool boundary)
{
setCursor(cursor, par, pos, boundary);
+ bv()->x_target(cursor.x());
if (setfont)
setCurrentFont();
}
@@ -1620,7 +1620,7 @@ DispatchResult LyXText::moveRightIntern(
return DispatchResult(false, FINISHED_RIGHT);
if (activate_inset && checkAndActivateInset(front))
return DispatchResult(true, true);
- cursorRight(bv());
+ cursorRight(true);
if (!selecting)
clearSelection();
return DispatchResult(true);
@@ -1632,7 +1632,7 @@ DispatchResult LyXText::moveLeftIntern(b
{
if (cursor.par() == 0 && cursor.pos() <= 0)
return DispatchResult(false, FINISHED);
- cursorLeft(bv());
+ cursorLeft(true);
if (!selecting)
clearSelection();
if (activate_inset && checkAndActivateInset(front))
@@ -1645,7 +1645,7 @@ DispatchResult LyXText::moveUp()
{
if (cursorRow() == firstRow())
return DispatchResult(false, FINISHED_UP);
- cursorUp(bv());
+ cursorUp(false);
clearSelection();
return DispatchResult(true);
}
@@ -1655,7 +1655,7 @@ DispatchResult LyXText::moveDown()
{
if (cursorRow() == lastRow())
return DispatchResult(false, FINISHED_DOWN);
- cursorDown(bv());
+ cursorDown(false);
clearSelection();
return DispatchResult(true);
}
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.182
diff -u -p -u -r1.182 text3.C
--- text3.C 17 Nov 2003 20:28:10 - 1.182
+++ text3.C 18 Nov 2003 11:15:54 -
@@ -1585,13 +1585,13 @@ DispatchResult LyXText::dispatch(FuncReq
case LFUN_FINISHED_LEFT:
lyxerr << "swallow LFUN_FINISHED_LEFT" << endl;
if (rtl())
- cursorRight(bv);
+ cursorRight(true);
break;
case LFUN_FINISHED_RIGHT:
lyxerr << "swallow LFUN_FINISHED_RIGHT" << endl;
if (!rtl())
- cursorRight(bv);
+ cursorRight(true);
break;
case LFUN_FINISHED_UP:
@@ -1600,7 +1600,7 @@ DispatchResult LyXText::dispatch(FuncReq
case LFUN_FINISHED_DOWN:
lyxerr << "swallow LFUN_FINISHED_DOWN" << endl;
- cursorRight(bv);
+ cursorRight(true);
break;
default:
Re: cursorup/down
On Tue, Nov 18, 2003 at 12:22:38PM +0100, Alfredo Braunstein wrote: > > Might be true... > > It was. > > This patch solves this, + some bv() -> true (except in moveUp/Down, where it > was set to false to allow entering insets) Good. > [another problem: we should set x_target in absolute coordinates, but > we do it within LyXText, and LyXText doesn't kown it's own absolute > x coords. Maybe it should?] Absolute document coordinates? Would be feasible. bv->text gets 0,0, the rest could be computed for y_top in the inset's draw(). [I wish we had a LyXText::draw...] What's the current plan with respect to absolute coordinates anyway? That 'absolute coordinates for text' could serve as a stepping stone, couldn't it? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: cursorup/down
Andre Poenitz wrote: >> [another problem: we should set x_target in absolute coordinates, but >> we do it within LyXText, and LyXText doesn't kown it's own absolute >> x coords. Maybe it should?] > > Absolute document coordinates? Would be feasible. bv->text gets 0,0, the > rest could be computed for y_top in the inset's draw(). Yes... (in this case we only need the x coord, but it's the same thing) > [I wish we had a LyXText::draw...] > > What's the current plan with respect to absolute coordinates anyway? > That 'absolute coordinates for text' could serve as a stepping stone, > couldn't it? I think you're right. Alfredo
Re: [Patch] XML sanitation part II
> Generically:
>
> \begin{LatexName}
>
> item text for itemize/enum
>label_textitem text for description
>...
>
> \end{LatexName}
No, that would be
\begin{LatexName}
item text for itemize/enum
...
label_textitem text for description
...
\end{LatexName}
(but of course both item types would not occur together in the
same environment)
- Martin
pgp0.pgp
Description: PGP signature
Re: [patch] towards simplified left/right/up/down
On Tue, Nov 18, 2003 at 09:46:46AM +0100, Andre Poenitz wrote: > > > +cursorRight(bv()); > > > > note that cursorRight takes a bool argument. (Dunno what's for, though ;-) > > funny. I copied this from somewhere else. So the argument doesn't look > terribly important, does it? It was, at least. The bug above is from when the bv argument was removed from these methods; somebody wasn't quite careful enough in removing the bv()'s. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [patch] towards simplified left/right/up/down
John Levon wrote: > It was, at least. The bug above is from when the bv argument was removed > from these methods; somebody wasn't quite careful enough in removing > the bv()'s. Somebody strikes again! Alfredo
Bug ??
Hello: Im not sure it is a bug but in any case I need some help. Im just in the begining of using Lyx, version 1.3.3 I can't centered images inserted through float system and I can't find how to move it from the left side. It is a bug or something wrong with my procedure ? Thanks a lot Josef Carel
Re: Bug ??
On Tue, Nov 18, 2003 at 09:26:51PM +0200, Josef Carel spake thusly: > Hello: > Im not sure it is a bug but in any case I need some help. > Im just in the begining of using Lyx, version 1.3.3 > > I can't centered images inserted through float system and > I can't find how to move it from the left side. > > It is a bug or something wrong with my procedure ? > > Thanks a lot > > Josef Carel Hi, you should center the paragraph containing the image. Place the cursor beside the image and center the paragraph through its menu. - Martin pgp0.pgp Description: PGP signature
Re: tex2lyx and optional arguments
Am Dienstag, 18. November 2003 09:37 schrieb Andre Poenitz:
> On Mon, Nov 17, 2003 at 08:58:36PM +0100, Georg Baum wrote:
> > Am Montag, 17. November 2003 09:52 schrieb Andre Poenitz:
> > > Looks good. Is this ready for 'commit'?
> >
> > Yes. Maybe with the size() -> !empty() change suggested by Angus. BTW,
> > this construct is used at a few other places in tex2lyx, some from me,
> > some from others.
>
> Feel free to correct that.
See attached.
Georg
Index: src/tex2lyx/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/ChangeLog,v
retrieving revision 1.41
diff -u -p -r1.41 ChangeLog
--- src/tex2lyx/ChangeLog 2003/11/05 10:14:12 1.41
+++ src/tex2lyx/ChangeLog 2003/11/18 21:11:29
@@ -1,3 +1,16 @@
+2003-11-18 Georg Baum <[EMAIL PROTECTED]>
+
+ * tex2lyx.C:
+ * tex2lyx.h:
+ * text.C: Read a list of commands and their arguments from a reLyX
+ compatible syntax file in order to parse optional argumnts correctly.
+ * preamble.C:
+ * table.C:
+ * text.C:
+ * tex2lyx.C:
+ * texparser.C
+ * math.C: change size() to !empty() where it was used as bool
+
2003-11-03 Georg Baum <[EMAIL PROTECTED]>
* math.C:
Index: src/tex2lyx/math.C
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/math.C,v
retrieving revision 1.12
diff -u -p -r1.12 math.C
--- src/tex2lyx/math.C 2003/11/05 10:14:12 1.12
+++ src/tex2lyx/math.C 2003/11/18 21:11:29
@@ -121,7 +121,7 @@ void parse_math(Parser & p, ostream & os
}
else if (t.cat() == catComment) {
- if (t.cs().size())
+ if (!t.cs().empty())
cerr << "Ignoring comment: " << t.asInput();
else
// "%\n" combination
Index: src/tex2lyx/preamble.C
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/preamble.C,v
retrieving revision 1.17
diff -u -p -r1.17 preamble.C
--- src/tex2lyx/preamble.C 2003/11/05 10:14:12 1.17
+++ src/tex2lyx/preamble.C 2003/11/18 21:11:31
@@ -131,7 +131,7 @@ void handle_package(string const & name,
h_language = name;
h_quotes_language = name;
} else {
- if (options.size())
+ if (!options.empty())
h_preamble << "\\usepackage[" << options << "]{" << name << "}\n";
else
h_preamble << "\\usepackage{" << name << "}\n";
@@ -146,7 +146,7 @@ void end_preamble(ostream & os, LyXTextC
<< "\\lyxformat 225\n"
<< "\\textclass " << h_textclass << "\n"
<< "\\begin_preamble\n" << h_preamble.str() << "\n\\end_preamble\n";
- if (h_options.size())
+ if (!h_options.empty())
os << "\\options " << h_options << "\n";
os << "\\language " << h_language << "\n"
<< "\\inputencoding " << h_inputencoding << "\n"
@@ -319,7 +319,7 @@ LyXTextClass const parse_preamble(Parser
trim(name);
int nargs = 0;
string opts = p.getOpt();
- if (opts.size()) {
+ if (!opts.empty()) {
istringstream is(string(opts, 1));
//cerr << "opt: " << is.str() << "\n";
is >> nargs;
@@ -361,13 +361,13 @@ LyXTextClass const parse_preamble(Parser
h_preamble << "\\begin{" << name << "}";
}
- else if (t.cs().size())
+ else if (!t.cs().empty())
h_preamble << '\\' << t.cs();
}
p.skip_spaces();
// Force textclass if the user wanted it
- if (forceclass.size()) {
+ if (!forceclass.empty()) {
h_textclass = forceclass;
}
string layoutfilename = LibFileSearch("layouts", h_textclass, "layout");
@@ -377,7 +377,7 @@ LyXTextClass const parse_preamble(Parser
}
LyXTextClass textclass;
textclass.Read(layoutfilename);
- if (! h_papersides.size()) {
+ if (h_papersides.empty()) {
ostringstream ss;
ss << textclass.sides();
h_papersides = ss.str();
Index: src/tex2lyx/table.C
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/table.C,v
retrieving revision 1.23
diff -u -p -r1.23 table.C
--- src/tex2lyx/table.C 2003/11/05 10:14:12 1.23
+++ src/tex2lyx/table.C 2003/11/18 21:11:32
@@ -299,7 +299,7 @@ void handle_tabular(Parser & p, ostream
Context & context)
{
string posopts = p.getOpt();
- if (posopts.size())
+ if (!posopts.empty())
cerr << "vertical tabular positioning '" << posopts << "' ignored\n";
vectorcolinfo;
@@ -484,9 +484,9 @@ void handle_tabular(Parser & p, ostream
os << " leftline=\"true\"";
if (colinfo[col].rightline)
os << " rightline=\"true\"";
- if (colinfo[col].width.size())
+ if (!colinfo[col].width.empty())
os << " width=\"" << colinfo[col].width << "\"";
- if (colinfo[col].special.size())
+ if (!colinfo[col].special.empty())
os << " special=\"" << colinfo[col].special << "\"";
os << ">\n";
}
Index: src/tex2lyx/tex2lyx.C
===
RCS file: /cvs/lyx/lyx-devel/src/tex2lyx/tex2lyx.C,v
retrieving revision 1.53
diff -u -p -r1.53 tex2lyx.C
--- src/tex2lyx/tex2lyx.C 2003/11/05 10:14:13 1.53
+++ src/tex2lyx/tex2lyx.C 2003/11/18 21:11:33
@@ -43,
Re: scrolling (three questions)
On Thursday 30 October 2003 2:00 pm, Ronald Florence wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > The fix is trivial (for Qt too) and requires that
> > LyX responds only to a subset of mouse events from the underlying
> > X11, MacOS or Win32 graphics libraries. In the xforms frontend we use
> > a timer, so:
> > // The timer runs for 200ms
> > static Timer timer(200);
> > if (timer.running())
> > return;
> > timer.start();
> > dispatch(mouse_event_to_the_lyx_core);
> >
> > This could go in, almost as is, to the mouseEventHandler in
> > QContentPane.C. Feel free to try ;-)
>
> Is this fix going into LyX-1.3.4?
In order for any fix to go in, I'd need to know the Qt equivalent of
XEvent::xmotion.[x,y]. (Ie, the current position of the mouse cursor).
Thereafter, I'd anticipate that QContentPane::mouseMoveEvent woudl be
modified so that it looks something like the equivalent code in
XWorkArea::work_area_handler.
Maybe this information is e->x(), e->y(), but I'm not sure of the difference
anymore between X11's ev->xmotion.[x,y] and ev->xbutton.[x,y].
So, Qt gurus...
Angus
void QContentPane::mouseMoveEvent(QMouseEvent * e)
{
FuncRequest cmd
(LFUN_MOUSE_MOTION, e->x(), e->y(), q_motion_state(e->state()));
wa_->dispatch(cmd);
}
int XWorkArea::work_area_handler(FL_OBJECT * ob, int event,
FL_Coord, FL_Coord,
int key, void * xev)
{
XEvent * ev = static_cast(xev);
XWorkArea * area = static_cast(ob->u_vdata);
if (!area)
return 1;
switch (event) {
case FL_DRAG: {
if (!ev || !area->scrollbar)
break;
int const drag_x = ev->xmotion.x;
int const drag_y = ev->xmotion.y;
int const area_y = ob->y;
int const area_h = ob->h;
// Check if the mouse is above or below the workarea
if (drag_y <= area_y || drag_y >= area_y + area_h) {
// The mouse button is depressed and we are outside the
// workarea. That means we are simultaneously selecting
// text and scrolling the view.
// Use a Timeout to react to a drag events only every
// 200ms. All intervening events are discarded,
// allowing the user to control position easily.
static int const discard_interval = 200;
static Timeout timeout(discard_interval);
if (timeout.running())
break;
// The timeout is not running, so process the
// event, first starting the timeout to discard future
// events.
timeout.start();
}
static int x_old = -1;
static int y_old = -1;
static double scrollbar_value_old = -1.0;
double const scrollbar_value =
fl_get_scrollbar_value(area->scrollbar);
if (drag_x != x_old || drag_y != y_old ||
scrollbar_value != scrollbar_value_old) {
x_old = drag_x;
y_old = drag_y;
scrollbar_value_old = scrollbar_value;
lyxerr[Debug::WORKAREA] << "Workarea event: DRAG"
<< endl;
// It transpires that ev->xbutton.button == 0 when
// the mouse is dragged, so it cannot be used to
// initialise x_button_state and hence FuncRequest.
// The 'key' that is passed into the function does
// contain the necessary info, however.
// It is for this reason that x_button_state has
// been modified to work with key
// rather than ev->xbutton.button.
// Angus 15 Oct 2002.
FuncRequest cmd(LFUN_MOUSE_MOTION,
ev->xbutton.x - ob->x,
ev->xbutton.y - ob->y,
x_button_state(key));
area->dispatch(cmd);
}
break;
}
[patch] intro of absolute LyXText coords + some cursor fixing
This patch introduces document absolute coordinates in LyXText, and use them
to solve the target_x problem (almost all operation are still done as
before, but now we can possibly simplify/correct code using the absolute
coordinates, in small steps).
I've also tried to fix cursorNext/Previous, and did a lot of butchering
there, i.e. ended by rewriting the thing in its simplest form. [I won't
apply this patch unless it gets some review (in particular I need help to
know if some of the code removed was needed for some reason)]
The current situation of coordinates is not much changed:
- LyXText knows it own absolute coords
- Events are sent to LyXText in LyXText coordinates
- Paragraphs have LyXText xy coordinates
- rows have Paragraph xy coordinates
- Inset cache their screen coordinates (so they have absolute x coord and
almost the absolute coordinates inset.y() + bv->top_y())
- insets handles events in own coordinates, and inset::edit(bv, x, y) in
screen coordinates.
(corrections/aditions welcomed)
What this patch is supposed to cure:
- target_x handling
- cursorUp/Down entering/exiting insets (LFUN_FINISHED_UP/DOWN where not
handled correctly)
- pageUp/Down (take the userguide, press page down: scrolling gets stuck at
some point)
There's still the eternal problem with with full-row insets: if you have a
line like this
blah blah blah
BUTTON
-- - - - - - -
|here is some text
--- - - - - -
and you place the cursor at the end of the blah row, it goes automatically
to the next row, before BUTTON (i.e., we don't distinguish between the two
positions).
So say you are with the cursor in the last 't' of 'text', then you go up and
the cursor goes to before the B of BUTTON with x_target set appropriately
to the x coordinate of the 't'. If you try to go further up, the algorithm
tries to place the cursor at the end of the last blah, and so goes again to
the same position, i.e. we are stuck.
Solution: we have to distinguish between the two positions, IMO.
Alfredo
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.255
diff -u -p -u -r1.255 lyxtext.h
--- lyxtext.h 17 Nov 2003 14:28:17 - 1.255
+++ lyxtext.h 18 Nov 2003 22:39:15 -
@@ -461,13 +461,14 @@ public:
///
bool checkAndActivateInset(bool front);
+ struct Pos {
+ int x;
+ int y;
+ };
+ Pos pos_;
private:
- /** Cursor related data.
- Later this variable has to be removed. There should be now internal
- cursor in a text */
- ///
- ///TextCursor cursor_;
+
/// prohibit this as long as there are back pointers...
LyXText(LyXText const &);
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.503
diff -u -p -u -r1.503 text2.C
--- text2.C 18 Nov 2003 11:39:29 - 1.503
+++ text2.C 18 Nov 2003 22:39:19 -
@@ -74,8 +74,11 @@ LyXText::LyXText(BufferView * bv, InsetT
ParagraphList & paragraphs)
: height(0), width(0), inset_owner(inset), bv_owner(bv),
in_inset_(ininset), paragraphs_(¶graphs),
- cache_pos_(-1)
-{}
+ cache_pos_(-1)
+{
+ pos_.x = 0;
+ pos_.y = 0;
+}
void LyXText::init(BufferView * bview)
@@ -1404,7 +1407,7 @@ void LyXText::setCursorIntern(paroffset_
pos_type pos, bool setfont, bool boundary)
{
setCursor(cursor, par, pos, boundary);
- bv()->x_target(cursor.x());
+ bv()->x_target(cursor.x() + pos_.x);
if (setfont)
setCurrentFont();
}
@@ -1710,24 +1713,17 @@ void LyXText::cursorUp(bool selecting)
{
ParagraphList::iterator cpit = cursorPar();
Row const & crow = *cpit->getRow(cursor.pos());
-#if 1
- int x = bv()->x_target();
+ int x = bv()->x_target() - pos_.x;
int y = cursor.y() - crow.baseline() - 1;
setCursorFromCoordinates(x, y);
if (!selecting) {
int topy = bv()->top_y();
- int y1 = cursor.y() - topy;
- y -= topy;
+ int y1 = cursor.y() - pos_.y - topy;
+ y -= topy + pos_.y;
InsetOld * inset_hit = checkInsetHit(x, y1);
if (inset_hit && isHighlyEditableInset(inset_hit))
inset_hit->edit(bv(), x, y);
}
-#else
- lyxerr << "cursorUp: y " << cursor.y() << " bl: " <<
- crow.baseline() << endl;
- setCursorFromCoordinates(bv()->x_target(),
- cursor.y() - crow.baseline() - 1);
-#endif
}
@@ -1735,22 +1731,17 @@ void LyXText::cursorDown(bool selecting)
{
ParagraphList::iterator cpit = cursorPar();
Row const & crow = *cpit->getRow(cursor.pos());
-#if 1
- int x = bv()->x_target();
+ int x = bv()->x_target() - pos_.x;
int y = cursor.y() - crow.baseline() + crow.height() + 1;
setCursorFromCoordinates(x, y);
if (!selecting) {
int topy = bv()->top_y();
- int y1 = cursor.y() - topy;
- y -= topy;
+ int y1 = cursor.y() - pos_.y - topy;
+ y -= topy + pos_.y;
InsetOld * inset_hit = checkInsetHit(x, y1);
if (inset_hit && isHighlyEditableInset(inset_hit))
inset_hit->edit(bv(), x, y
