Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Tue, Mar 28, 2006 at 02:46:52PM +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin It appears brute force is the only way here. See attached. You can apply to 1.4.x too, if you think it is necessary. It's in now. Log entry: * src/insets/insetcharstyle.C (InsetCharStyle::doDispatch): prevent non-standard paragraph layout from being pasted into charstyle inset * src/insets/insetcharstyle.h: disable non-standard layouts - Martin pgplMhIDnLVAg.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Tue, Mar 28, 2006 at 02:46:52PM +0200, Jean-Marc Lasgouttes Martin wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin It appears brute force is the only way here. See attached. You can apply to 1.4.x too, if you think it is necessary. Martin It's in now. Log entry: Have you seen this one? http://bugzilla.lyx.org/show_bug.cgi?id=2382 Maybe a more general solution is needed. JMarc
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Wed, Mar 29, 2006 at 12:10:34PM +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Tue, Mar 28, 2006 at 02:46:52PM +0200, Jean-Marc Lasgouttes Martin wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin It appears brute force is the only way here. See attached. You can apply to 1.4.x too, if you think it is necessary. Martin It's in now. Log entry: Have you seen this one? http://bugzilla.lyx.org/show_bug.cgi?id=2382 Maybe a more general solution is needed. Yes... but we must do two things: prevent the pasting of non-standard paragraphs, and prevent paragraphs to be edited to non-standard. The first really can only be done by intercepting LFUN_PASTE in the inset... or do you have a better idea? - Martin pgpH6DbFIUDkc.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
Martin Vermeer wrote: Maybe a more general solution is needed. Yes... but we must do two things: prevent the pasting of non-standard paragraphs, and prevent paragraphs to be edited to non-standard. Isn't it enough to reset the paste content to standdard generally if forceDefaultParagraph is true? Jürgen
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Wed, Mar 29, 2006 at 12:10:34PM +0200, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
...
Have you seen this one?
http://bugzilla.lyx.org/show_bug.cgi?id=2382
Maybe a more general solution is needed.
Like the attached? This solves also 2382 and a similar bug in Box.
(I think it is even formally correct. General paragraph layouts are
allowed when there is a parbox/minipage around it, in tabular and in
box.)
- Martin
Index: insettext.h
===
--- insettext.h (revision 13520)
+++ insettext.h (working copy)
@@ -143,6 +143,8 @@ public:
bool Wide() const { return wide_inset_; }
///
bool const Tall() const;
+ ///
+ void forceParagraphsToDefault(LCursor cur);
protected:
///
Index: insettabular.C
===
--- insettabular.C (revision 13520)
+++ insettabular.C (working copy)
@@ -745,6 +745,9 @@ void InsetTabular::doDispatch(LCursor
break;
}
cell(cur.idx())-dispatch(cur, cmd);
+ // Reset pasted paragraphs:
+ if (tabular.getPWidth(cur.idx()).zero())
+ cell(cur.idx())-forceParagraphsToDefault(cur);
break;
case LFUN_EMPH:
Index: insetbox.C
===
--- insetbox.C (revision 13520)
+++ insetbox.C (working copy)
@@ -198,6 +198,12 @@ void InsetBox::doDispatch(LCursor cur,
}
InsetCollapsable::doDispatch(cur, cmd);
break;
+ case LFUN_PASTE:
+ case LFUN_PASTESELECTION:
+ InsetCollapsable::doDispatch(cur, cmd);
+ if (!params_.inner_box)
+ forceParagraphsToDefault(cur);
+ break;
default:
InsetCollapsable::doDispatch(cur, cmd);
Index: insetert.C
===
--- insetert.C (revision 13520)
+++ insetert.C (working copy)
@@ -244,6 +244,7 @@ void InsetERT::doDispatch(LCursor cur,
// Since we can only store plain text, we must reset all
// attributes.
+ forceParagraphsToDefault(cur);
// FIXME: Change only the pasted paragraphs
BufferParams const bp = cur.buffer().params();
@@ -255,7 +256,6 @@ void InsetERT::doDispatch(LCursor cur,
ParagraphList::iterator const end = paragraphs().end();
for (ParagraphList::iterator par = paragraphs().begin();
par != end; ++par) {
- par-layout(layout);
// in case par had a manual label
par-setBeginOfBody();
pos_type const siz = par-size();
Index: insetcharstyle.C
===
--- insetcharstyle.C(revision 13520)
+++ insetcharstyle.C(working copy)
@@ -238,13 +238,7 @@ void InsetCharStyle::doDispatch(LCursor
case LFUN_PASTE:
case LFUN_PASTESELECTION: {
InsetCollapsable::doDispatch(cur, cmd);
- BufferParams const bp = cur.buffer().params();
- LyXLayout_ptr const layout =
- bp.getLyXTextClass().defaultLayout();
- ParagraphList::iterator const end = paragraphs().end();
- for (ParagraphList::iterator par = paragraphs().begin();
- par != end; ++par)
- par-layout(layout);
+ forceParagraphsToDefault(cur);
break;
}
default:
Index: insettext.C
===
--- insettext.C (revision 13520)
+++ insettext.C (working copy)
@@ -264,6 +264,18 @@ bool const InsetText::Tall() const
}
+void InsetText::forceParagraphsToDefault(LCursor cur)
+{
+ BufferParams const bp = cur.buffer().params();
+ LyXLayout_ptr const layout =
+ bp.getLyXTextClass().defaultLayout();
+ ParagraphList::iterator const end = paragraphs().end();
+ for (ParagraphList::iterator par = paragraphs().begin();
+ par != end; ++par)
+ par-layout(layout);
+}
+
+
void InsetText::doDispatch(LCursor cur, FuncRequest cmd)
{
lyxerr[Debug::DEBUG] BOOST_CURRENT_FUNCTION
pgpFe44C876L5.pgp
Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Tue, Mar 28, 2006 at 02:46:52PM +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> It appears brute force is the only way here. See attached. > > You can apply to 1.4.x too, if you think it is necessary. It's in now. Log entry: * src/insets/insetcharstyle.C (InsetCharStyle::doDispatch): prevent non-standard paragraph layout from being pasted into charstyle inset * src/insets/insetcharstyle.h: disable non-standard layouts - Martin pgplMhIDnLVAg.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Tue, Mar 28, 2006 at 02:46:52PM +0200, Jean-Marc Lasgouttes Martin> wrote: >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> Martin> It appears brute force is the only way here. See attached. >> You can apply to 1.4.x too, if you think it is necessary. Martin> It's in now. Log entry: Have you seen this one? http://bugzilla.lyx.org/show_bug.cgi?id=2382 Maybe a more general solution is needed. JMarc
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Wed, Mar 29, 2006 at 12:10:34PM +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> On Tue, Mar 28, 2006 at 02:46:52PM +0200, Jean-Marc Lasgouttes > Martin> wrote: > >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > >> > Martin> It appears brute force is the only way here. See attached. > >> You can apply to 1.4.x too, if you think it is necessary. > > Martin> It's in now. Log entry: > > Have you seen this one? > http://bugzilla.lyx.org/show_bug.cgi?id=2382 > > Maybe a more general solution is needed. Yes... but we must do two things: prevent the pasting of non-standard paragraphs, and prevent paragraphs to be edited to non-standard. The first really can only be done by intercepting LFUN_PASTE in the inset... or do you have a better idea? - Martin pgpH6DbFIUDkc.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
Martin Vermeer wrote: > > Maybe a more general solution is needed. > > Yes... but we must do two things: prevent the pasting of non-standard > paragraphs, and prevent paragraphs to be edited to non-standard. Isn't it enough to reset the paste content to standdard generally if forceDefaultParagraph is true? Jürgen
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Wed, Mar 29, 2006 at 12:10:34PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> Have you seen this one?
> http://bugzilla.lyx.org/show_bug.cgi?id=2382
>
> Maybe a more general solution is needed.
Like the attached? This solves also 2382 and a similar bug in Box.
(I think it is even formally correct. General paragraph layouts are
allowed when there is a parbox/minipage around it, in tabular and in
box.)
- Martin
Index: insettext.h
===
--- insettext.h (revision 13520)
+++ insettext.h (working copy)
@@ -143,6 +143,8 @@ public:
bool & Wide() const { return wide_inset_; }
///
bool const Tall() const;
+ ///
+ void forceParagraphsToDefault(LCursor & cur);
protected:
///
Index: insettabular.C
===
--- insettabular.C (revision 13520)
+++ insettabular.C (working copy)
@@ -745,6 +745,9 @@ void InsetTabular::doDispatch(LCursor &
break;
}
cell(cur.idx())->dispatch(cur, cmd);
+ // Reset pasted paragraphs:
+ if (tabular.getPWidth(cur.idx()).zero())
+ cell(cur.idx())->forceParagraphsToDefault(cur);
break;
case LFUN_EMPH:
Index: insetbox.C
===
--- insetbox.C (revision 13520)
+++ insetbox.C (working copy)
@@ -198,6 +198,12 @@ void InsetBox::doDispatch(LCursor & cur,
}
InsetCollapsable::doDispatch(cur, cmd);
break;
+ case LFUN_PASTE:
+ case LFUN_PASTESELECTION:
+ InsetCollapsable::doDispatch(cur, cmd);
+ if (!params_.inner_box)
+ forceParagraphsToDefault(cur);
+ break;
default:
InsetCollapsable::doDispatch(cur, cmd);
Index: insetert.C
===
--- insetert.C (revision 13520)
+++ insetert.C (working copy)
@@ -244,6 +244,7 @@ void InsetERT::doDispatch(LCursor & cur,
// Since we can only store plain text, we must reset all
// attributes.
+ forceParagraphsToDefault(cur);
// FIXME: Change only the pasted paragraphs
BufferParams const & bp = cur.buffer().params();
@@ -255,7 +256,6 @@ void InsetERT::doDispatch(LCursor & cur,
ParagraphList::iterator const end = paragraphs().end();
for (ParagraphList::iterator par = paragraphs().begin();
par != end; ++par) {
- par->layout(layout);
// in case par had a manual label
par->setBeginOfBody();
pos_type const siz = par->size();
Index: insetcharstyle.C
===
--- insetcharstyle.C(revision 13520)
+++ insetcharstyle.C(working copy)
@@ -238,13 +238,7 @@ void InsetCharStyle::doDispatch(LCursor
case LFUN_PASTE:
case LFUN_PASTESELECTION: {
InsetCollapsable::doDispatch(cur, cmd);
- BufferParams const & bp = cur.buffer().params();
- LyXLayout_ptr const layout =
- bp.getLyXTextClass().defaultLayout();
- ParagraphList::iterator const end = paragraphs().end();
- for (ParagraphList::iterator par = paragraphs().begin();
- par != end; ++par)
- par->layout(layout);
+ forceParagraphsToDefault(cur);
break;
}
default:
Index: insettext.C
===
--- insettext.C (revision 13520)
+++ insettext.C (working copy)
@@ -264,6 +264,18 @@ bool const InsetText::Tall() const
}
+void InsetText::forceParagraphsToDefault(LCursor & cur)
+{
+ BufferParams const & bp = cur.buffer().params();
+ LyXLayout_ptr const layout =
+ bp.getLyXTextClass().defaultLayout();
+ ParagraphList::iterator const end = paragraphs().end();
+ for (ParagraphList::iterator par = paragraphs().begin();
+ par != end; ++par)
+ par->layout(layout);
+}
+
+
void InsetText::doDispatch(LCursor & cur, FuncRequest & cmd)
{
lyxerr[Debug::DEBUG] << BOOST_CURRENT_FUNCTION
pgpFe44C876L5.pgp
Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin It appears brute force is the only way here. See attached. You can apply to 1.4.x too, if you think it is necessary. JMarc
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> It appears brute force is the only way here. See attached. You can apply to 1.4.x too, if you think it is necessary. JMarc
Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 01:00:53PM +0200, Martin Vermeer wrote:
+void resetParagraphStyles(LyXTextClass const textclass, size_t sel_index)
+{
+ ParagraphList plist = const_castParagraphList
(theCuts[sel_index].first);
+ ParagraphList::const_iterator const beg = plist.begin();
+ ParagraphList::const_iterator const end = plist.end();
+ ParagraphList::const_iterator it = beg;
+ for (; it != end; ++it) {
+ LyXLayout_ptr const p = textclass.defaultLayout();
Does this change between iterations?
+ lyx::pit_type pit = std::distance(beg, it);
+ plist[pit].layout(p);
Why not it-layout(p) ?
Andre'
Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 01:00:53PM +0200, Martin Vermeer wrote:
> +void resetParagraphStyles(LyXTextClass const & textclass, size_t sel_index)
> +{
> + ParagraphList & plist = const_cast &>(theCuts[sel_index].first);
> + ParagraphList::const_iterator const beg = plist.begin();
> + ParagraphList::const_iterator const end = plist.end();
> + ParagraphList::const_iterator it = beg;
> + for (; it != end; ++it) {
> + LyXLayout_ptr const & p = textclass.defaultLayout();
Does this change between iterations?
> + lyx::pit_type pit = std::distance(beg, it);
> + plist[pit].layout(p);
Why not it->layout(p) ?
Andre'
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Sat, Mar 25, 2006 at 12:20:02AM +0200, Martin Vermeer wrote: On Fri, Mar 24, 2006 at 10:47:11PM +0200, Martin Vermeer wrote: ... It appears brute force is the only way here. See attached. - Martin Committed to trunk with following log entry: Fix the bug reported by Markus Mayer, that paragraph styles like itemize too readily enter into charstyle insets. * insetcharstyle.C (InsetCharStyle::doDispatch): force pasted paragraphs to document default style * insetcharstyle.h: add forceDefaultParagraphs to true - Martin pgpFOlNRi5FJQ.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: Possible charstyle bug
On Sat, Mar 25, 2006 at 12:20:02AM +0200, Martin Vermeer wrote: > On Fri, Mar 24, 2006 at 10:47:11PM +0200, Martin Vermeer wrote: ... > It appears brute force is the only way here. See attached. > > - Martin Committed to trunk with following log entry: Fix the bug reported by Markus Mayer, that paragraph styles like itemize too readily enter into charstyle insets. * insetcharstyle.C (InsetCharStyle::doDispatch): force pasted paragraphs to document default style * insetcharstyle.h: add forceDefaultParagraphs to true - Martin pgpFOlNRi5FJQ.pgp Description: PGP signature
Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 04:55:21AM +0200, Martin Vermeer wrote: ... Ah. So we have to add a forceDefaultParagraphs = true definition... No, not enough. In ERT, we intercept LFUN_PASTE in the dispatch routine and reset the pasted paragraphs (these come from doInsertInset). The same problem exists for Note and Box. But there it isn't so obnoxious as one could imagine wanting to put multiple paragraphs with nonstandard layouts into one. For charstyle it makes no sense. I'll think of something ;-) - Martin pgpR2wNK5qdxa.pgp Description: PGP signature
Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 10:38:24AM +0200, Martin Vermeer wrote:
On Fri, Mar 24, 2006 at 04:55:21AM +0200, Martin Vermeer wrote:
...
Ah. So we have to add a forceDefaultParagraphs = true definition...
No, not enough. In ERT, we intercept LFUN_PASTE in the dispatch routine
and reset the pasted paragraphs (these come from doInsertInset).
The same problem exists for Note and Box. But there it isn't so
obnoxious as one could imagine wanting to put multiple paragraphs with
nonstandard layouts into one. For charstyle it makes no sense.
Came up with the attached patch. It adds a method to CutAndPaste for
resetting the paragraph styles in the cut buffer 0. For this, there is
now special code in insetert.C's dispatch of Paste, which I partly
removed according to the FIXME there. (There is font-related code that
has to stay.)
Now the insertion of an inset around a selection tests whether the
inset wants to force default paragraphs, and resets the cut buffer to
that before inserting. This avoids adding special dispatch/paste code to
every inset of that type, i.e., ERT, tabular, charstyle (new), and box.
Does this look like a sane approach?
- Martin
Index: CutAndPaste.C
===
--- CutAndPaste.C (revision 13467)
+++ CutAndPaste.C (working copy)
@@ -614,6 +614,22 @@ void pasteParagraphList(LCursor cur, P
}
+void resetParagraphStyles(LyXTextClass const textclass, size_t sel_index)
+{
+ ParagraphList plist = const_castParagraphList
(theCuts[sel_index].first);
+ ParagraphList::const_iterator const beg = plist.begin();
+ ParagraphList::const_iterator const end = plist.end();
+ ParagraphList::const_iterator it = beg;
+ for (; it != end; ++it) {
+ LyXLayout_ptr const p = textclass.defaultLayout();
+ lyx::pit_type pit = std::distance(beg, it);
+ plist[pit].layout(p);
+ plist[pit].setBeginOfBody();
+ plist[pit].params().clear();
+ }
+}
+
+
void pasteSelection(LCursor cur, size_t sel_index)
{
// this does not make sense, if there is nothing to paste
Index: CutAndPaste.h
===
--- CutAndPaste.h (revision 13467)
+++ CutAndPaste.h (working copy)
@@ -60,7 +60,8 @@ void pasteSelection(LCursor cur, size_
///
void pasteParagraphList(LCursor cur, ParagraphList const parlist,
textclass_type textclass);
-
+///
+void resetParagraphStyles(LyXTextClass const textclass, size_t);
/** Needed to switch between different classes. This works
* for a list of paragraphs beginning with the specified par.
Index: text3.C
===
--- text3.C (revision 13467)
+++ text3.C (working copy)
@@ -74,6 +74,7 @@ using lyx::cap::copySelection;
using lyx::cap::cutSelection;
using lyx::cap::pasteSelection;
using lyx::cap::replaceSelection;
+using lyx::cap::resetParagraphStyles;
using lyx::support::isStrUnsignedInt;
using lyx::support::token;
@@ -268,8 +269,14 @@ bool doInsertInset(LCursor cur, LyXTex
if (edit)
inset-edit(cur, true);
- if (gotsel pastesel)
+ if (gotsel pastesel) {
+ // Reset paragraph style on cut buffer 0:
+ if (inset-forceDefaultParagraphs(cur.idx())) {
+ resetParagraphStyles(cur.buffer().params()
+ .getLyXTextClass(), 0);
+ }
cur.bv().owner()-dispatch(FuncRequest(LFUN_PASTE));
+ }
return true;
}
Index: insets/insetert.C
===
--- insets/insetert.C (revision 13467)
+++ insets/insetert.C (working copy)
@@ -249,14 +249,10 @@ void InsetERT::doDispatch(LCursor cur,
ParagraphList::iterator const end = paragraphs().end();
for (ParagraphList::iterator par = paragraphs().begin();
par != end; ++par) {
- par-layout(layout);
- // in case par had a manual label
- par-setBeginOfBody();
pos_type const siz = par-size();
for (pos_type i = 0; i siz; ++i) {
par-setFont(i, font);
}
- par-params().clear();
}
break;
}
pgpph4SStVS4E.pgp
Description: PGP signature
[Patch in parent, n/t] Re: Possible charstyle bug
signature.asc Description: This is a digitally signed message part
Re: Possible charstyle bug
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Came up with the attached patch. It adds a method to Martin CutAndPaste for resetting the paragraph styles in the cut Martin buffer 0. I do not like much the fact that this code is added in CutAndPaste.C. It should live in some *funcs.C file. Of course, you do that because you access the cliboard directly. But again, this is wrong: it may happen that the theCuts[0] does not use the same textclass and thus the same default layout. What I propose is to run resetParagraphStyle on the whole LyXText after pasting. This cannot really hurt :) JMarc
Re: Possible charstyle bug
On Fri, 2006-03-24 at 15:11 +0100, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Came up with the attached patch. It adds a method to Martin CutAndPaste for resetting the paragraph styles in the cut Martin buffer 0. I do not like much the fact that this code is added in CutAndPaste.C. It should live in some *funcs.C file. Of course, you do that because you access the cliboard directly. But again, this is wrong: it may happen that the theCuts[0] does not use the same textclass and thus the same default layout. No, not in this case, when called from doInsertInset. What I propose is to run resetParagraphStyle on the whole LyXText after pasting. This cannot really hurt :) That's precisely what the insertert FIXME complained about ;-) Sure I can do it. Where do you want resetParagraphStyles to be relocated? - Martin signature.asc Description: This is a digitally signed message part
Re: Possible charstyle bug
Martin == Martin Vermeer [EMAIL PROTECTED] writes: But again, this is wrong: it may happen that the theCuts[0] does not use the same textclass and thus the same default layout. Martin No, not in this case, when called from doInsertInset. Yes, but you expose this function to all uses. What I propose is to run resetParagraphStyle on the whole LyXText after pasting. This cannot really hurt :) Martin That's precisely what the insertert FIXME complained about ;-) I see that now. But I do not think it matters much. Martin Sure I can do it. Where do you want resetParagraphStyles to be Martin relocated? Good question. What about putting it in anonymous namespace in text3.C? JMarc
[Patch] Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 03:49:10PM +0100, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
...
What I propose is to run resetParagraphStyle on the whole LyXText
after pasting. This cannot really hurt :)
Martin That's precisely what the insertert FIXME complained about ;-)
I see that now. But I do not think it matters much.
Martin Sure I can do it. Where do you want resetParagraphStyles to be
Martin relocated?
Good question. What about putting it in anonymous namespace in
text3.C?
That would be this patch.
Unless anyone sees a problem, this goes in soon.
- Martin
Index: text3.C
===
--- text3.C (revision 13473)
+++ text3.C (working copy)
@@ -250,6 +250,22 @@ void specialChar(LCursor cur, InsetSpe
}
+void resetParagraphStyles(LyXTextClass const textclass, ParagraphList
+ plist)
+{
+ ParagraphList::const_iterator const beg = plist.begin();
+ ParagraphList::const_iterator const end = plist.end();
+ ParagraphList::const_iterator it = beg;
+ for (; it != end; ++it) {
+ LyXLayout_ptr const p = textclass.defaultLayout();
+ lyx::pit_type pit = std::distance(beg, it);
+ plist[pit].layout(p);
+ plist[pit].setBeginOfBody();
+ plist[pit].params().clear();
+ }
+}
+
+
bool doInsertInset(LCursor cur, LyXText * text,
FuncRequest const cmd, bool edit, bool pastesel)
{
@@ -268,8 +284,15 @@ bool doInsertInset(LCursor cur, LyXTex
if (edit)
inset-edit(cur, true);
- if (gotsel pastesel)
+ if (gotsel pastesel) {
cur.bv().owner()-dispatch(FuncRequest(LFUN_PASTE));
+ if (inset-forceDefaultParagraphs(cur.idx())
+ inset-asTextInset()) {
+ resetParagraphStyles(
+ cur.buffer().params().getLyXTextClass(),
+ static_castInsetText *(inset)-paragraphs());
+ }
+ }
return true;
}
Index: insets/insetert.C
===
--- insets/insetert.C (revision 13473)
+++ insets/insetert.C (working copy)
@@ -249,14 +249,10 @@ void InsetERT::doDispatch(LCursor cur,
ParagraphList::iterator const end = paragraphs().end();
for (ParagraphList::iterator par = paragraphs().begin();
par != end; ++par) {
- par-layout(layout);
- // in case par had a manual label
- par-setBeginOfBody();
pos_type const siz = par-size();
for (pos_type i = 0; i siz; ++i) {
par-setFont(i, font);
}
- par-params().clear();
}
break;
}
pgpzzQGekW2L2.pgp
Description: PGP signature
Re: [Patch] Re: Possible charstyle bug
Am Freitag, 24. März 2006 20:22 schrieb Martin Vermeer: That would be this patch. Unless anyone sees a problem, this goes in soon. I don't see why the deleted lines in ERT are no longer necessary. Could you please explain? Georg
Re: [Patch] Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 08:44:46PM +0100, Georg Baum wrote: Am Freitag, 24. März 2006 20:22 schrieb Martin Vermeer: That would be this patch. Unless anyone sees a problem, this goes in soon. I don't see why the deleted lines in ERT are no longer necessary. Could you please explain? Hmmm, yes you're right. This only covers the case of inserting an inset, not manually pasting... The thinking goes on. - Martin pgpVUFRQSTDl1.pgp Description: PGP signature
[Patch] Re: [Patch] Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 10:47:11PM +0200, Martin Vermeer wrote:
On Fri, Mar 24, 2006 at 08:44:46PM +0100, Georg Baum wrote:
Am Freitag, 24. März 2006 20:22 schrieb Martin Vermeer:
That would be this patch.
Unless anyone sees a problem, this goes in soon.
I don't see why the deleted lines in ERT are no longer necessary. Could
you please explain?
Hmmm, yes you're right. This only covers the case of inserting an inset,
not manually pasting...
The thinking goes on.
It appears brute force is the only way here. See attached.
- Martin
Index: insetcharstyle.C
===
--- insetcharstyle.C(revision 13473)
+++ insetcharstyle.C(working copy)
@@ -14,7 +14,9 @@
#include insetcharstyle.h
+#include buffer.h
#include BufferView.h
+#include bufferparams.h
#include dispatchresult.h
#include funcrequest.h
#include FuncStatus.h
@@ -233,7 +235,18 @@
else
InsetText::doDispatch(cur, cmd);
break;
-
+ case LFUN_PASTE:
+ case LFUN_PASTESELECTION: {
+ InsetCollapsable::doDispatch(cur, cmd);
+ BufferParams const bp = cur.buffer().params();
+ LyXLayout_ptr const layout =
+ bp.getLyXTextClass().defaultLayout();
+ ParagraphList::iterator const end = paragraphs().end();
+ for (ParagraphList::iterator par = paragraphs().begin();
+ par != end; ++par)
+ par-layout(layout);
+ break;
+ }
default:
InsetCollapsable::doDispatch(cur, cmd);
break;
Index: insetcharstyle.h
===
--- insetcharstyle.h(revision 13473)
+++ insetcharstyle.h(working copy)
@@ -69,6 +69,8 @@
///
void getDrawFont(LyXFont ) const;
///
+ bool forceDefaultParagraphs(idx_type) const { return true; }
+ ///
int latex(Buffer const , std::ostream ,
OutputParams const ) const;
///
pgpCLRX9595A8.pgp
Description: PGP signature
Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 04:55:21AM +0200, Martin Vermeer wrote: ... > Ah. So we have to add a forceDefaultParagraphs = true definition... No, not enough. In ERT, we intercept LFUN_PASTE in the dispatch routine and reset the pasted paragraphs (these come from doInsertInset). The same problem exists for Note and Box. But there it isn't so obnoxious as one could imagine wanting to put multiple paragraphs with nonstandard layouts into one. For charstyle it makes no sense. I'll think of something ;-) - Martin pgpR2wNK5qdxa.pgp Description: PGP signature
Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 10:38:24AM +0200, Martin Vermeer wrote:
> On Fri, Mar 24, 2006 at 04:55:21AM +0200, Martin Vermeer wrote:
>
> ...
>
> > Ah. So we have to add a forceDefaultParagraphs = true definition...
>
> No, not enough. In ERT, we intercept LFUN_PASTE in the dispatch routine
> and reset the pasted paragraphs (these come from doInsertInset).
>
> The same problem exists for Note and Box. But there it isn't so
> obnoxious as one could imagine wanting to put multiple paragraphs with
> nonstandard layouts into one. For charstyle it makes no sense.
Came up with the attached patch. It adds a method to CutAndPaste for
resetting the paragraph styles in the cut buffer 0. For this, there is
now special code in insetert.C's dispatch of Paste, which I partly
removed according to the FIXME there. (There is font-related code that
has to stay.)
Now the insertion of an inset "around" a selection tests whether the
inset wants to force default paragraphs, and resets the cut buffer to
that before inserting. This avoids adding special dispatch/paste code to
every inset of that type, i.e., ERT, tabular, charstyle (new), and box.
Does this look like a sane approach?
- Martin
Index: CutAndPaste.C
===
--- CutAndPaste.C (revision 13467)
+++ CutAndPaste.C (working copy)
@@ -614,6 +614,22 @@ void pasteParagraphList(LCursor & cur, P
}
+void resetParagraphStyles(LyXTextClass const & textclass, size_t sel_index)
+{
+ ParagraphList & plist = const_cast(theCuts[sel_index].first);
+ ParagraphList::const_iterator const beg = plist.begin();
+ ParagraphList::const_iterator const end = plist.end();
+ ParagraphList::const_iterator it = beg;
+ for (; it != end; ++it) {
+ LyXLayout_ptr const & p = textclass.defaultLayout();
+ lyx::pit_type pit = std::distance(beg, it);
+ plist[pit].layout(p);
+ plist[pit].setBeginOfBody();
+ plist[pit].params().clear();
+ }
+}
+
+
void pasteSelection(LCursor & cur, size_t sel_index)
{
// this does not make sense, if there is nothing to paste
Index: CutAndPaste.h
===
--- CutAndPaste.h (revision 13467)
+++ CutAndPaste.h (working copy)
@@ -60,7 +60,8 @@ void pasteSelection(LCursor & cur, size_
///
void pasteParagraphList(LCursor & cur, ParagraphList const & parlist,
textclass_type textclass);
-
+///
+void resetParagraphStyles(LyXTextClass const & textclass, size_t);
/** Needed to switch between different classes. This works
* for a list of paragraphs beginning with the specified par.
Index: text3.C
===
--- text3.C (revision 13467)
+++ text3.C (working copy)
@@ -74,6 +74,7 @@ using lyx::cap::copySelection;
using lyx::cap::cutSelection;
using lyx::cap::pasteSelection;
using lyx::cap::replaceSelection;
+using lyx::cap::resetParagraphStyles;
using lyx::support::isStrUnsignedInt;
using lyx::support::token;
@@ -268,8 +269,14 @@ bool doInsertInset(LCursor & cur, LyXTex
if (edit)
inset->edit(cur, true);
- if (gotsel && pastesel)
+ if (gotsel && pastesel) {
+ // Reset paragraph style on cut buffer 0:
+ if (inset->forceDefaultParagraphs(cur.idx())) {
+ resetParagraphStyles(cur.buffer().params()
+ .getLyXTextClass(), 0);
+ }
cur.bv().owner()->dispatch(FuncRequest(LFUN_PASTE));
+ }
return true;
}
Index: insets/insetert.C
===
--- insets/insetert.C (revision 13467)
+++ insets/insetert.C (working copy)
@@ -249,14 +249,10 @@ void InsetERT::doDispatch(LCursor & cur,
ParagraphList::iterator const end = paragraphs().end();
for (ParagraphList::iterator par = paragraphs().begin();
par != end; ++par) {
- par->layout(layout);
- // in case par had a manual label
- par->setBeginOfBody();
pos_type const siz = par->size();
for (pos_type i = 0; i < siz; ++i) {
par->setFont(i, font);
}
- par->params().clear();
}
break;
}
pgpph4SStVS4E.pgp
Description: PGP signature
[Patch in parent, n/t] Re: Possible charstyle bug
signature.asc Description: This is a digitally signed message part
Re: Possible charstyle bug
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Came up with the attached patch. It adds a method to Martin> CutAndPaste for resetting the paragraph styles in the cut Martin> buffer 0. I do not like much the fact that this code is added in CutAndPaste.C. It should live in some *funcs.C file. Of course, you do that because you access the cliboard directly. But again, this is wrong: it may happen that the theCuts[0] does not use the same textclass and thus the same default layout. What I propose is to run resetParagraphStyle on the whole LyXText after pasting. This cannot really hurt :) JMarc
Re: Possible charstyle bug
On Fri, 2006-03-24 at 15:11 +0100, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> Came up with the attached patch. It adds a method to > Martin> CutAndPaste for resetting the paragraph styles in the cut > Martin> buffer 0. > > I do not like much the fact that this code is added in CutAndPaste.C. > It should live in some *funcs.C file. Of course, you do that because > you access the cliboard directly. But again, this is wrong: it may > happen that the theCuts[0] does not use the same textclass and thus > the same default layout. No, not in this case, when called from doInsertInset. > What I propose is to run resetParagraphStyle on the whole LyXText > after pasting. This cannot really hurt :) That's precisely what the insertert FIXME complained about ;-) Sure I can do it. Where do you want resetParagraphStyles to be relocated? - Martin signature.asc Description: This is a digitally signed message part
Re: Possible charstyle bug
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> But again, this >> is wrong: it may happen that the theCuts[0] does not use the same >> textclass and thus the same default layout. Martin> No, not in this case, when called from doInsertInset. Yes, but you expose this function to all uses. >> What I propose is to run resetParagraphStyle on the whole LyXText >> after pasting. This cannot really hurt :) Martin> That's precisely what the insertert FIXME complained about ;-) I see that now. But I do not think it matters much. Martin> Sure I can do it. Where do you want resetParagraphStyles to be Martin> relocated? Good question. What about putting it in anonymous namespace in text3.C? JMarc
[Patch] Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 03:49:10PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> >> What I propose is to run resetParagraphStyle on the whole LyXText
> >> after pasting. This cannot really hurt :)
>
> Martin> That's precisely what the insertert FIXME complained about ;-)
>
> I see that now. But I do not think it matters much.
>
> Martin> Sure I can do it. Where do you want resetParagraphStyles to be
> Martin> relocated?
>
> Good question. What about putting it in anonymous namespace in
> text3.C?
That would be this patch.
Unless anyone sees a problem, this goes in soon.
- Martin
Index: text3.C
===
--- text3.C (revision 13473)
+++ text3.C (working copy)
@@ -250,6 +250,22 @@ void specialChar(LCursor & cur, InsetSpe
}
+void resetParagraphStyles(LyXTextClass const & textclass, ParagraphList &
+ plist)
+{
+ ParagraphList::const_iterator const beg = plist.begin();
+ ParagraphList::const_iterator const end = plist.end();
+ ParagraphList::const_iterator it = beg;
+ for (; it != end; ++it) {
+ LyXLayout_ptr const & p = textclass.defaultLayout();
+ lyx::pit_type pit = std::distance(beg, it);
+ plist[pit].layout(p);
+ plist[pit].setBeginOfBody();
+ plist[pit].params().clear();
+ }
+}
+
+
bool doInsertInset(LCursor & cur, LyXText * text,
FuncRequest const & cmd, bool edit, bool pastesel)
{
@@ -268,8 +284,15 @@ bool doInsertInset(LCursor & cur, LyXTex
if (edit)
inset->edit(cur, true);
- if (gotsel && pastesel)
+ if (gotsel && pastesel) {
cur.bv().owner()->dispatch(FuncRequest(LFUN_PASTE));
+ if (inset->forceDefaultParagraphs(cur.idx()) &&
+ inset->asTextInset()) {
+ resetParagraphStyles(
+ cur.buffer().params().getLyXTextClass(),
+ static_cast(inset)->paragraphs());
+ }
+ }
return true;
}
Index: insets/insetert.C
===
--- insets/insetert.C (revision 13473)
+++ insets/insetert.C (working copy)
@@ -249,14 +249,10 @@ void InsetERT::doDispatch(LCursor & cur,
ParagraphList::iterator const end = paragraphs().end();
for (ParagraphList::iterator par = paragraphs().begin();
par != end; ++par) {
- par->layout(layout);
- // in case par had a manual label
- par->setBeginOfBody();
pos_type const siz = par->size();
for (pos_type i = 0; i < siz; ++i) {
par->setFont(i, font);
}
- par->params().clear();
}
break;
}
pgpzzQGekW2L2.pgp
Description: PGP signature
Re: [Patch] Re: Possible charstyle bug
Am Freitag, 24. März 2006 20:22 schrieb Martin Vermeer: > That would be this patch. > > Unless anyone sees a problem, this goes in soon. I don't see why the deleted lines in ERT are no longer necessary. Could you please explain? Georg
Re: [Patch] Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 08:44:46PM +0100, Georg Baum wrote: > Am Freitag, 24. März 2006 20:22 schrieb Martin Vermeer: > > That would be this patch. > > > > Unless anyone sees a problem, this goes in soon. > > I don't see why the deleted lines in ERT are no longer necessary. Could > you please explain? Hmmm, yes you're right. This only covers the case of inserting an inset, not manually pasting... The thinking goes on. - Martin pgpVUFRQSTDl1.pgp Description: PGP signature
[Patch] Re: [Patch] Re: Possible charstyle bug
On Fri, Mar 24, 2006 at 10:47:11PM +0200, Martin Vermeer wrote:
> On Fri, Mar 24, 2006 at 08:44:46PM +0100, Georg Baum wrote:
> > Am Freitag, 24. März 2006 20:22 schrieb Martin Vermeer:
> > > That would be this patch.
> > >
> > > Unless anyone sees a problem, this goes in soon.
> >
> > I don't see why the deleted lines in ERT are no longer necessary. Could
> > you please explain?
>
> Hmmm, yes you're right. This only covers the case of inserting an inset,
> not manually pasting...
>
> The thinking goes on.
It appears brute force is the only way here. See attached.
- Martin
Index: insetcharstyle.C
===
--- insetcharstyle.C(revision 13473)
+++ insetcharstyle.C(working copy)
@@ -14,7 +14,9 @@
#include "insetcharstyle.h"
+#include "buffer.h"
#include "BufferView.h"
+#include "bufferparams.h"
#include "dispatchresult.h"
#include "funcrequest.h"
#include "FuncStatus.h"
@@ -233,7 +235,18 @@
else
InsetText::doDispatch(cur, cmd);
break;
-
+ case LFUN_PASTE:
+ case LFUN_PASTESELECTION: {
+ InsetCollapsable::doDispatch(cur, cmd);
+ BufferParams const & bp = cur.buffer().params();
+ LyXLayout_ptr const layout =
+ bp.getLyXTextClass().defaultLayout();
+ ParagraphList::iterator const end = paragraphs().end();
+ for (ParagraphList::iterator par = paragraphs().begin();
+ par != end; ++par)
+ par->layout(layout);
+ break;
+ }
default:
InsetCollapsable::doDispatch(cur, cmd);
break;
Index: insetcharstyle.h
===
--- insetcharstyle.h(revision 13473)
+++ insetcharstyle.h(working copy)
@@ -69,6 +69,8 @@
///
void getDrawFont(LyXFont &) const;
///
+ bool forceDefaultParagraphs(idx_type) const { return true; }
+ ///
int latex(Buffer const &, std::ostream &,
OutputParams const &) const;
///
pgpCLRX9595A8.pgp
Description: PGP signature
Possible charstyle bug
Hi,
I think I may have found a bug in the way character styles are handled.
See attached sample document and sample styles.
If a character style is used in an itemize environment, LyX
genereates LaTeX code like this:
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{\begin{itemize}
\item command
\end{itemize}
} and then some more text
...
That's not the intention. There is no reason to repeat itemize inside
the command character style. It should have been
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{command} and then some more text
...
But not only does LyX generate a nested itemize structure, it also
displays it like that (no line breaks around command, but a - in
front of it to symbolize the 2nd level of itemize).
Regards,
Markus
#% Do not delete the line below; configure depends on this
# \DeclareLaTeXClass[article]{MM Article}
# Markus' Article textclass definition file.
# Author : Markus Mayer
Input article.layout
Input mm_charstyles.inc
# Textclass definition file for article.
# Character Styles definition
Format 2
CharStyle filename
LatexType Command
LatexName textsf
Font
Family Sans
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle variable
LatexType Command
LatexName textsf
Font
Family Sans
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle command
LatexType Command
LatexName texttt
Font
Family Typewriter
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle code
LatexType Command
LatexName texttt
Font
Family Typewriter
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
#LyX 1.4.0 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass mm_article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Standard
Enumeration test
\end_layout
\begin_layout Itemize
item 1
\end_layout
\begin_layout Itemize
item 2
\end_layout
\begin_layout Itemize
item 3 has a
\begin_inset CharStyle command
status inlined
\begin_layout Itemize
command
\end_layout
\end_inset
and then some more text
\end_layout
\begin_layout Itemize
item 4 has a
\begin_inset CharStyle filename
status inlined
\begin_layout Itemize
filename
\end_layout
\end_inset
and then some more text
\end_layout
\begin_layout Itemize
item 5
\end_layout
\begin_layout Standard
That's it.
\end_layout
\end_body
\end_document
charstyle-bug.tex
Description: TeX document
Re: Possible charstyle bug
Hi, I just tried editing the .lyx file manually changing \begin_inset CharStyle command status inlined \begin_layout Itemize command \end_layout \end_inset to \begin_inset CharStyle command status inlined \begin_layout Standard command \end_layout \end_inset and that fixed everything. The text is now displayed properly (no more hyphen to symbolize nested itemizing) and the LaTeX code is also correct. That means things go wrong when character styles are *added* to an itemize structure. Regards, Markus
Re: Possible charstyle bug
On Thu, Mar 23, 2006 at 01:31:03PM -0800, Markus Mayer wrote:
Hi,
I think I may have found a bug in the way character styles are handled.
See attached sample document and sample styles.
If a character style is used in an itemize environment, LyX
genereates LaTeX code like this:
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{\begin{itemize}
\item command
\end{itemize}
} and then some more text
...
That's not the intention. There is no reason to repeat itemize inside
the command character style. It should have been
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{command} and then some more text
...
Ah. So we have to add a forceDefaultParagraphs = true definition...
- Martin
pgpno73q80IKK.pgp
Description: PGP signature
Possible charstyle bug
Hi,
I think I may have found a bug in the way character styles are handled.
See attached sample document and sample styles.
If a character style is used in an "itemize" environment, LyX
genereates LaTeX code like this:
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{\begin{itemize}
\item command
\end{itemize}
} and then some more text
...
That's not the intention. There is no reason to repeat "itemize" inside
the "command" character style. It should have been
\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{command} and then some more text
...
But not only does LyX generate a nested "itemize" structure, it also
displays it like that (no line breaks around "command", but a "-" in
front of it to symbolize the 2nd level of itemize).
Regards,
Markus
#% Do not delete the line below; configure depends on this
# \DeclareLaTeXClass[article]{MM Article}
# Markus' Article textclass definition file.
# Author : Markus Mayer
Input article.layout
Input mm_charstyles.inc
# Textclass definition file for article.
# Character Styles definition
Format 2
CharStyle filename
LatexType Command
LatexName textsf
Font
Family Sans
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle variable
LatexType Command
LatexName textsf
Font
Family Sans
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle command
LatexType Command
LatexName texttt
Font
Family Typewriter
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
CharStyle code
LatexType Command
LatexName texttt
Font
Family Typewriter
EndFont
LabelFont
Family Roman
Color blue
EndFont
End
#LyX 1.4.0 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass mm_article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Standard
Enumeration test
\end_layout
\begin_layout Itemize
item 1
\end_layout
\begin_layout Itemize
item 2
\end_layout
\begin_layout Itemize
item 3 has a
\begin_inset CharStyle command
status inlined
\begin_layout Itemize
command
\end_layout
\end_inset
and then some more text
\end_layout
\begin_layout Itemize
item 4 has a
\begin_inset CharStyle filename
status inlined
\begin_layout Itemize
filename
\end_layout
\end_inset
and then some more text
\end_layout
\begin_layout Itemize
item 5
\end_layout
\begin_layout Standard
That's it.
\end_layout
\end_body
\end_document
charstyle-bug.tex
Description: TeX document
Re: Possible charstyle bug
Hi, I just tried editing the .lyx file manually changing \begin_inset CharStyle command status inlined \begin_layout Itemize command \end_layout \end_inset to \begin_inset CharStyle command status inlined \begin_layout Standard command \end_layout \end_inset and that fixed everything. The text is now displayed properly (no more hyphen to symbolize nested itemizing) and the LaTeX code is also correct. That means things go wrong when character styles are *added* to an itemize structure. Regards, Markus
Re: Possible charstyle bug
On Thu, Mar 23, 2006 at 01:31:03PM -0800, Markus Mayer wrote:
> Hi,
>
> I think I may have found a bug in the way character styles are handled.
> See attached sample document and sample styles.
>
> If a character style is used in an "itemize" environment, LyX
> genereates LaTeX code like this:
>
> \begin{itemize}
> \item item 1
> \item item 2
> \item item 3 has a \texttt{\begin{itemize}
> \item command
> \end{itemize}
> } and then some more text
> ...
>
> That's not the intention. There is no reason to repeat "itemize" inside
> the "command" character style. It should have been
>
> \begin{itemize}
> \item item 1
> \item item 2
> \item item 3 has a \texttt{command} and then some more text
> ...
>
Ah. So we have to add a forceDefaultParagraphs = true definition...
- Martin
pgpno73q80IKK.pgp
Description: PGP signature
