Janus Sandsgaard wrote:
Oooopps. Thant weekend was gone in 20 seconds. :-/
I know that feeling... ;-)
Alfredo
Since I haven't seen any posts that this is on bugzilla, I'll assume
that it's not and will file this as a bug.. hope this is OK.
Thanks,
nirmal
This is 'large' but mostly purely mechanical: rename
TextCursor::cursor to cursor_ and provide accessot functions.
Same for the selection anchor.
The idea is to encapsulate the cursor accesses from within LyXText to
make the shift to the global cursor easier.
Incidentilayy, this also fixes a
Andre Poenitz wrote:
This is 'large' but mostly purely mechanical: rename
TextCursor::cursor to cursor_ and provide accessot functions.
Same for the selection anchor.
Nice, I was also thinking about doing something like that.
The idea is to encapsulate the cursor accesses from within
On Tue, 13 Jan 2004, Nirmal Govind wrote:
Since I haven't seen any posts that this is on bugzilla, I'll assume
that it's not and will file this as a bug.. hope this is OK.
Sounds fine by me. (I'm still planning on reading your post before this
one, but hasn't gotten around to it yet :-/
On Tue, Jan 13, 2004 at 11:23:08AM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
This is 'large' but mostly purely mechanical: rename
TextCursor::cursor to cursor_ and provide accessot functions.
Same for the selection anchor.
Nice, I was also thinking about doing something
This makes room for another cursor slice at the bottom of the global
cursor which will contain the main LyXText's cursor in the end.
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
Andre Poenitz wrote:
This makes room for another cursor slice at the bottom of the global
cursor which will contain the main LyXText's cursor in the end.
Andre'
Care to explain to the uninitiated? (Me.)
--
Angus
On Tue, Jan 13, 2004 at 11:17:44AM +, Angus Leeming wrote:
Andre Poenitz wrote:
This makes room for another cursor slice at the bottom of the global
cursor which will contain the main LyXText's cursor in the end.
Andre'
Care to explain to the uninitiated? (Me.)
The global
Andre Poenitz wrote:
We are not too far from finishing that global cursor transition. I
had it already in a compilable but only semi-workable state. The
patches I am now sending are mechanical parts that remove a few of
the obstacles obfuscating the remaining path...
Thanks for the
Andre Poenitz wrote:
However, the current global cursor contains only slices for text
_insets_. The global cursor would need those on top of an additional
slice representing the cursor position in the main LyX text, too.
The patch does just that by allocating a (currently unused) cursor
On Tue, Jan 13, 2004 at 12:40:45PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
However, the current global cursor contains only slices for text
_insets_. The global cursor would need those on top of an additional
slice representing the cursor position in the main LyX text, too.
Andre Poenitz wrote:
No, the cursor top is its 'tip', i.e. in the insets.
But this new slice will be the position inside this tip, right? (when you
talk of main LyX text you refer to inner one?). Or maybe not. If you refer
to the root one, read on.
I don't understand why we have to distinguish
On Tue, Jan 13, 2004 at 01:01:38PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
No, the cursor top is its 'tip', i.e. in the insets.
But this new slice will be the position inside this tip, right?
No.
(when you talk of main LyX text you refer to inner one?). Or maybe
not. If
This unifies a few types used in LCursor and the math cursor.
Note that this unifies on the 'wrong side': paroffset_type should be
unsigned in the long run but there seems to be a place or two where
the core code relies on signedness (a downward counting loop most
likely).
It works as-is and
Andre Poenitz wrote:
This unifies a few types used in LCursor and the math cursor.
Note that this unifies on the 'wrong side': paroffset_type should be
unsigned in the long run but there seems to be a place or two where
the core code relies on signedness (a downward counting loop most
On Tue, Jan 13, 2004 at 12:26:08PM +, Angus Leeming wrote:
Andre Poenitz wrote:
This unifies a few types used in LCursor and the math cursor.
Note that this unifies on the 'wrong side': paroffset_type should be
unsigned in the long run but there seems to be a place or two where
CursorSlice is a proper superset of LyXCursor, so this is basically a
perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch] */*.[Ch]`
plus cvs rm lyxcursor.[Ch].
Andre'
Index: BufferView_pimpl.C
===
RCS file:
Andre Poenitz wrote:
CursorSlice is a proper superset of LyXCursor, so this is basically
a
perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch]
*/*.[Ch]` plus cvs rm lyxcursor.[Ch].
Andre'
Why is this here and not in cursor_slice.[Ch]?
Index: mathed/formula.C
Andre Poenitz [EMAIL PROTECTED] writes:
| CursorSlice is a proper superset of LyXCursor, so this is basically a
| perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch] */*.[Ch]`
| plus cvs rm lyxcursor.[Ch].
perl just must be the wrong tool for that :-)
sed -e
On Tue, Jan 13, 2004 at 02:04:58PM +, Angus Leeming wrote:
Andre Poenitz wrote:
CursorSlice is a proper superset of LyXCursor, so this is basically
a
perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch]
*/*.[Ch]` plus cvs rm lyxcursor.[Ch].
Andre'
Why is
On Tue, Jan 13, 2004 at 03:03:38PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| CursorSlice is a proper superset of LyXCursor, so this is basically a
| perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch] */*.[Ch]`
| plus cvs rm lyxcursor.[Ch].
Andre Poenitz [EMAIL PROTECTED] writes:
| I am not sure I get your point.
I am not a perl fan :-)
--
Lgb
This removes the local cursor.
It (temporarily) merges LyXText and TextCursor again. Plan is to move
the selection part to BufferView (near the LCursor).
[No reason to be happy yet, the selection is still local]
Andre'
--
Those who desire to give up Freedom in order to gain Security, will
This is yesterday's patch (fix LFUN_WORD{LEFT,RIGHT}SEL)
+ a fix to LFUN_WORDSEL (getWord)
+ some comments fixed.
Alfredo
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.275
Would it be better to use
\usepackage{parskip}
instead of
\setlength\parskip{\medskipamount}
\setlength\parindent{0pt}
?
[This was suggested in some local newsgroup. There is a slight
difference in the glue and some list related business I don't
understand in this package]
There would
On Tue, Jan 13, 2004 at 04:22:14PM +0100, Alfredo Braunstein wrote:
This is yesterday's patch (fix LFUN_WORD{LEFT,RIGHT}SEL)
+ a fix to LFUN_WORDSEL (getWord)
+ some comments fixed.
Doesn't look wrong.
Andre'
Andre Poenitz wrote:
This removes the local cursor.
It (temporarily) merges LyXText and TextCursor again. Plan is to move
the selection part to BufferView (near the LCursor).
Why is that move?
[No reason to be happy yet, the selection is still local]
one thing that bothers me is to have
Andre Poenitz [EMAIL PROTECTED] writes:
| Would it be better to use
| \usepackage{parskip}
| instead of
| \setlength\parskip{\medskipamount}
| \setlength\parindent{0pt}
Perhaps.
parskip.sty did not exist (I think) when that code was written.
--
Lgb
Sounds fine by me. (I'm still planning on reading your post before this
one, but hasn't gotten around to it yet :-/
:-) Thanks for checking it out, Christian..
I've filed it on bugzilla:
http://bugzilla.lyx.org/show_bug.cgi?id=1489
A rather long report, hopefully the reader won't get bored
On Tue, Jan 13, 2004 at 04:39:51PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
This removes the local cursor.
It (temporarily) merges LyXText and TextCursor again. Plan is to move
the selection part to BufferView (near the LCursor).
Why is that move?
Because localized
Andre Poenitz wrote:
On Tue, Jan 13, 2004 at 04:39:51PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
This removes the local cursor.
It (temporarily) merges LyXText and TextCursor again. Plan is to move
the selection part to BufferView (near the LCursor).
Why is that move?
Alfredo Braunstein wrote:
This is yesterday's patch (fix LFUN_WORD{LEFT,RIGHT}SEL)
+ a fix to LFUN_WORDSEL (getWord)
+ some comments fixed.
Alfredo
Index: lyxtext.h
===
RCS file:
Nirmal Govind wrote:
A rather long report, hopefully the reader won't get bored reading
it.. :-)
nirmal
Nirmal, attach the jpgs to the bugzilla page.
--
Angus
Angus Leeming [EMAIL PROTECTED] writes:
| This isn't how doxygen works.
void getWord(CursorSlice from, CursorSlice to,
lyx::word_location const);
| \param is used so:
| /** General description of the function. Followed by
| \param from start looking from
Angus Leeming wrote:
This isn't how doxygen works.
void getWord(CursorSlice from, CursorSlice to,
lyx::word_location const);
\param is used so:
/** General description of the function. Followed by
\param from start looking from here.
Alfredo Braunstein [EMAIL PROTECTED] writes:
See the difference?
| Barely ;-)
| Gimme good examples then! (grep for param in *.h for an explanation... quite
| a few use in the other way)
| I'll make the change, thanks.
| btw, why is it used as @param sometimes?
There is the javadoc syntax:
On Tue, Jan 13, 2004 at 05:24:48PM +0100, Alfredo Braunstein wrote:
Because localized selection data is as bad as a localized cursor
data for multiple view.
I mean the remerging of textcursor into lyxtext.
Because I needed access to BufferView::cursor from within
selStart/selEnd which did
On Tue, Jan 13, 2004 at 05:32:54PM +0100, Lars Gullik Bjønnes wrote:
RFC: Should be begin adding those \param stuff to _all_ functions
taking parameters? And use **UNDOC** (or some other marker) when we
have no documentation for it? Similar for method description? Would it
be helpful, or just
On Tue, Jan 13, 2004 at 05:42:03PM +0100, Lars Gullik Bjønnes wrote:
I am leaning towards javadoc... but have no strong opinion..
I don't care either.
Andre'
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jan 13, 2004 at 05:32:54PM +0100, Lars Gullik Bjønnes wrote:
RFC: Should be begin adding those \param stuff to _all_ functions
taking parameters? And use **UNDOC** (or some other marker) when we
have no documentation for it? Similar for method
On Tue, Jan 13, 2004 at 06:03:34PM +0100, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jan 13, 2004 at 05:32:54PM +0100, Lars Gullik Bjønnes wrote:
RFC: Should be begin adding those \param stuff to _all_ functions
taking parameters? And use **UNDOC** (or
On Tue, Jan 13, 2004 at 06:10:01PM +0100, Andre Poenitz wrote:
Words like '\param' clearly interfere with reading...
Indeed. It could be smart and look at the function code itself, if you
get into the habit of naming parameters even in prototypes/headers, then
doxygen could do it automatically.
On Tue, Jan 13, 2004 at 05:26:29PM +, John Levon wrote:
On Tue, Jan 13, 2004 at 06:10:01PM +0100, Andre Poenitz wrote:
Words like '\param' clearly interfere with reading...
Indeed. It could be smart and look at the function code itself, if you
get into the habit of naming parameters
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Andre'
--
Those who desire to give up Freedom in
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global
place (LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Andre'
What's the
On Tue, Jan 13, 2004 at 06:34:29PM +0100, Andre Poenitz wrote:
But no, we have BD instead :/
Whatever that is.
Bondage Discipline.
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
On Tue, Jan 13, 2004 at 05:48:58PM +, Angus Leeming wrote:
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global
place (LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices:
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Why do we need a stack
On Tue, Jan 13, 2004 at 07:08:35PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices:
Andre Poenitz wrote:
For this, the topmost anchor item would still suffice. However
that feature is a pain to use if there's no way back in case one
accidentally overshoots an inset boundary. To find the way back, we'd
need the stack.
Fair enough, I forgot that one.
Alfredo
Andre Poenitz wrote:
fullCursor is the full cursor, ie. the two stacks (cursor + anchor)
of CursorSlices.
cursor is the topmost slice of the cursor stack, i.e. the position
where the blinking thing is drawn on screen.
I understand that the naming is non-perfect here...
...and anchor
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
--
Lgb
Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a
| Buffer property, right? Eventually that is.
?? Ok... what is the anchor used for?
The start of any selection. It doesn't make sense to have more than
one
Lars Gullik Bjnnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
The selection runs from anchor to cursor.
Alfredo
Angus Leeming wrote:
The start of any selection. It doesn't make sense to have more than
one start point. Indeed emacs has only one per buffer too.
I'm not sure it doesn't make sense to have different selections in different
views...
Alfredo
On Tuesday 13 January 2004 02:19 pm, Alfredo Braunstein wrote:
Angus Leeming wrote:
The start of any selection. It doesn't make sense to have more than
one start point. Indeed emacs has only one per buffer too.
I'm not sure it doesn't make sense to have different selections in
different
Kuba Ober wrote:
A per-view selection has the potential of least confusion, methinks. I
mean we either have one selection per LyX instance, or one selection per
view. By extrapolation (tm :), the middle ground of one selection per
document is kind of artificial, methinks. It's like being
Am Montag, 12. Januar 2004 09:59 schrieb Andre Poenitz:
On Sun, Jan 11, 2004 at 03:55:00PM +0100, Georg Baum wrote:
Am Samstag, 10. Januar 2004 19:19 schrieb Angus Leeming:
Can you not pass the runparams to the inset::validate member functions
then?
Of course, but this requires
Am Sonntag, 11. Januar 2004 17:38 schrieb Angus Leeming:
Georg Baum wrote:
Problems/Questions:
1. Are relative filenames possible in all cases? A comment in
insetgraphics.C indicates that an absolute path is needed for zipped
files that are unzipped by LaTeX. Can we simply ignore the
Georg Baum wrote:
2. Assuming relative filenames are possible, where in the code
should we copy the EPS files? If we do it in exporter.C, we know
the destination directory, but not what files were generated. If
we do it in the graphics/external inset, we know what files were
generated,
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
| The selection runs from
Janus Sandsgaard wrote:
> Oooopps. Thant weekend was gone in 20 seconds. :-/
I know that feeling... ;-)
Alfredo
Since I haven't seen any posts that this is on bugzilla, I'll assume
that it's not and will file this as a bug.. hope this is OK.
Thanks,
nirmal
This is 'large' but mostly purely mechanical: rename
TextCursor::cursor to cursor_ and provide accessot functions.
Same for the selection anchor.
The idea is to encapsulate the cursor accesses from within LyXText to
make the shift to the global cursor easier.
Incidentilayy, this also fixes a
Andre Poenitz wrote:
> This is 'large' but mostly purely mechanical: rename
> TextCursor::cursor to cursor_ and provide accessot functions.
> Same for the selection anchor.
Nice, I was also thinking about doing something like that.
> The idea is to encapsulate the cursor accesses from within
On Tue, 13 Jan 2004, Nirmal Govind wrote:
> Since I haven't seen any posts that this is on bugzilla, I'll assume
> that it's not and will file this as a bug.. hope this is OK.
Sounds fine by me. (I'm still planning on reading your post before this
one, but hasn't gotten around to it yet :-/
On Tue, Jan 13, 2004 at 11:23:08AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > This is 'large' but mostly purely mechanical: rename
> > TextCursor::cursor to cursor_ and provide accessot functions.
> > Same for the selection anchor.
>
> Nice, I was also thinking about doing
This makes room for another cursor slice at the bottom of the global
cursor which will contain the main LyXText's cursor in the end.
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
Andre Poenitz wrote:
>
> This makes room for another cursor slice at the bottom of the global
> cursor which will contain the main LyXText's cursor in the end.
>
> Andre'
Care to explain to the uninitiated? (Me.)
--
Angus
On Tue, Jan 13, 2004 at 11:17:44AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This makes room for another cursor slice at the bottom of the global
> > cursor which will contain the main LyXText's cursor in the end.
> >
> > Andre'
>
> Care to explain to the uninitiated? (Me.)
Andre Poenitz wrote:
> We are not too far from finishing that global cursor transition. I
> had it already in a compilable but only semi-workable state. The
> patches I am now sending are mechanical parts that remove a few of
> the obstacles obfuscating the remaining path...
Thanks for the
Andre Poenitz wrote:
> However, the current global cursor contains only slices for text
> _insets_. The global cursor would need those on top of an additional
> slice representing the cursor position in the main LyX text, too.
>
> The patch does just that by allocating a (currently unused)
On Tue, Jan 13, 2004 at 12:40:45PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > However, the current global cursor contains only slices for text
> > _insets_. The global cursor would need those on top of an additional
> > slice representing the cursor position in the main LyX
Andre Poenitz wrote:
> No, the cursor top is its 'tip', i.e. in the insets.
But this new slice will be the position inside this tip, right? (when you
talk of main LyX text you refer to inner one?). Or maybe not. If you refer
to the root one, read on.
I don't understand why we have to
On Tue, Jan 13, 2004 at 01:01:38PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > No, the cursor top is its 'tip', i.e. in the insets.
>
> But this new slice will be the position inside this tip, right?
No.
> (when you talk of main LyX text you refer to inner one?). Or maybe
>
This unifies a few types used in LCursor and the math cursor.
Note that this unifies on the 'wrong side': paroffset_type should be
unsigned in the long run but there seems to be a place or two where
the core code relies on signedness (a downward counting loop most
likely).
It works as-is and
Andre Poenitz wrote:
>
> This unifies a few types used in LCursor and the math cursor.
>
> Note that this unifies on the 'wrong side': paroffset_type should be
> unsigned in the long run but there seems to be a place or two where
> the core code relies on signedness (a downward counting loop
On Tue, Jan 13, 2004 at 12:26:08PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This unifies a few types used in LCursor and the math cursor.
> >
> > Note that this unifies on the 'wrong side': paroffset_type should be
> > unsigned in the long run but there seems to be a place
CursorSlice is a proper superset of LyXCursor, so this is basically a
perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch] */*.[Ch]`
plus cvs rm lyxcursor.[Ch].
Andre'
Index: BufferView_pimpl.C
===
RCS file:
Andre Poenitz wrote:
>
> CursorSlice is a proper superset of LyXCursor, so this is basically
> a
> perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch]
> */*.[Ch]` plus cvs rm lyxcursor.[Ch].
>
> Andre'
Why is this here and not in cursor_slice.[Ch]?
Index: mathed/formula.C
Andre Poenitz <[EMAIL PROTECTED]> writes:
| CursorSlice is a proper superset of LyXCursor, so this is basically a
| perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch] */*.[Ch]`
| plus cvs rm lyxcursor.[Ch].
perl just must be the wrong tool for that :-)
sed -e
On Tue, Jan 13, 2004 at 02:04:58PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > CursorSlice is a proper superset of LyXCursor, so this is basically
> > a
> > perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch]
> > */*.[Ch]` plus cvs rm lyxcursor.[Ch].
> >
> >
On Tue, Jan 13, 2004 at 03:03:38PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | CursorSlice is a proper superset of LyXCursor, so this is basically a
> | perl -pi -e 's:LyXCursor:CursorSlice:g' `grep -l LyXCursor *.[Ch] */*.[Ch]`
> | plus cvs rm
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I am not sure I get your point.
I am not a perl fan :-)
--
Lgb
This removes the local cursor.
It (temporarily) merges LyXText and TextCursor again. Plan is to move
the selection part to BufferView (near the LCursor).
[No reason to be happy yet, the selection is still local]
Andre'
--
Those who desire to give up Freedom in order to gain Security, will
This is yesterday's patch (fix LFUN_WORD{LEFT,RIGHT}SEL)
+ a fix to LFUN_WORDSEL (getWord)
+ some comments fixed.
Alfredo
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.275
Would it be better to use
\usepackage{parskip}
instead of
\setlength\parskip{\medskipamount}
\setlength\parindent{0pt}
?
[This was suggested in some local newsgroup. There is a slight
difference in the glue and some list related business I don't
understand in this package]
There would
On Tue, Jan 13, 2004 at 04:22:14PM +0100, Alfredo Braunstein wrote:
> This is yesterday's patch (fix LFUN_WORD{LEFT,RIGHT}SEL)
> + a fix to LFUN_WORDSEL (getWord)
> + some comments fixed.
Doesn't look wrong.
Andre'
Andre Poenitz wrote:
> This removes the local cursor.
>
> It (temporarily) merges LyXText and TextCursor again. Plan is to move
> the selection part to BufferView (near the LCursor).
Why is that move?
> [No reason to be happy yet, the selection is still local]
one thing that bothers me is to
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Would it be better to use
>
| \usepackage{parskip}
>
| instead of
>
| \setlength\parskip{\medskipamount}
| \setlength\parindent{0pt}
Perhaps.
parskip.sty did not exist (I think) when that code was written.
--
Lgb
Sounds fine by me. (I'm still planning on reading your post before this
one, but hasn't gotten around to it yet :-/
:-) Thanks for checking it out, Christian..
I've filed it on bugzilla:
http://bugzilla.lyx.org/show_bug.cgi?id=1489
A rather long report, hopefully the reader won't get bored
On Tue, Jan 13, 2004 at 04:39:51PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > This removes the local cursor.
> >
> > It (temporarily) merges LyXText and TextCursor again. Plan is to move
> > the selection part to BufferView (near the LCursor).
>
> Why is that move?
Because
Andre Poenitz wrote:
> On Tue, Jan 13, 2004 at 04:39:51PM +0100, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > This removes the local cursor.
>> >
>> > It (temporarily) merges LyXText and TextCursor again. Plan is to move
>> > the selection part to BufferView (near the LCursor).
>>
Alfredo Braunstein wrote:
> This is yesterday's patch (fix LFUN_WORD{LEFT,RIGHT}SEL)
> + a fix to LFUN_WORDSEL (getWord)
> + some comments fixed.
>
> Alfredo
>
> Index: lyxtext.h
> ===
> RCS file:
Nirmal Govind wrote:
> A rather long report, hopefully the reader won't get bored reading
> it.. :-)
>
> nirmal
Nirmal, attach the jpgs to the bugzilla page.
--
Angus
Angus Leeming <[EMAIL PROTECTED]> writes:
| This isn't how doxygen works.
>
>> void getWord(CursorSlice & from, CursorSlice & to,
>> lyx::word_location const);
>
| \param is used so:
| /** General description of the function. Followed by
| \param from start
Angus Leeming wrote:
> This isn't how doxygen works.
>
>> void getWord(CursorSlice & from, CursorSlice & to,
>> lyx::word_location const);
>
> \param is used so:
> /** General description of the function. Followed by
> \param from start looking from here.
>
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>> See the difference?
>
| Barely ;-)
>
| Gimme good examples then! (grep for param in *.h for an explanation... quite
| a few use in the other way)
>
| I'll make the change, thanks.
>
| btw, why is it used as @param sometimes?
There is the javadoc
On Tue, Jan 13, 2004 at 05:24:48PM +0100, Alfredo Braunstein wrote:
> > Because localized selection data is as bad as a localized cursor
> > data for multiple view.
>
> I mean the remerging of textcursor into lyxtext.
Because I needed access to BufferView::cursor from within
selStart/selEnd
1 - 100 of 124 matches
Mail list logo
