Why InsetListings does not inherit from InsetFloat?
InsetListings has the look and the feel of a float, so isn't it so? Abdel.
Re: About macro and child buffers
I am sorry to say this only now but I am worried about future maintenance of the code. So, if you agree with me and you have the time, please try to do those change before 1.6.0. I know about the complexity. What I really want to do for some time is the following which dramatically reduces the complexity: Macros should be global, i.e. no scopes anymore. Scopes are there in TeX of course, but I don't think they are really essential for the usual user. This will make the code much much simpler. I was waiting for Manuel Pégourié-Gonnard to update his xargs to implement the needed semantics for LyX. He sent me a snapshot, but didn't release it yet. Stefan
Re: [patch BRANCH] insertInset
Jean-Marc Lasgouttes wrote:
Well, the first change is straight forward,
Right. See attached patch.
but I do not know what is
the right semantics to use for the second problem.
Me neither.
Jürgen
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 23533)
+++ src/Text3.cpp (Arbeitskopie)
@@ -272,6 +272,8 @@
lyx::dispatch(FuncRequest(LFUN_CUT));
gotsel = true;
}
+ bool const emptypar = cur.lastpos() == 0;
+ pos_type ins_pos = cur.pos();
text-insertInset(cur, inset);
if (edit)
@@ -281,8 +283,8 @@
// metrics might be invalid at this point (bug 4502)
cur.bv().updateMetrics();
lyx::dispatch(FuncRequest(LFUN_PASTE, 0));
-
- if (cur.lastpit() == 0) {
+
+ if ((cur.lastpit() == 0 || ins_pos != 0) !emptypar) {
// reset first par to default
Layout_ptr const layout =
cur.buffer().params().getTextClass().defaultLayout();
cangeset 23520
Hello Bernhard, could you please also add a description of bm.sty to the LaTeXConfig.lyx file and add bm to the checked packages in chkconfig.ltx? thanks and regards Uwe
changeset/23527
André, could you please also take care of SCons when deleting/adding/moving files. (I know that you don't use SCons, but I don't use Make but I take care of the Makefiles.) regards Uwe
Re: A few questions
On 6 March 2008 16:52:41 Pavel Sanda wrote: thank you for the detailed description, i'm starting have a clue what you have in mind. its clear these two things are orthogonal - at most bilingual mode could exercise your WM tool as a part of editing process. Perhaps. I will have to look at it closely first. There may be a way to extend that bilingual mode. in case you decide use LyX for your plans it maybe be good to outline the implemenation here on list before you appear with 100kb of code ;) Right. It will definitely not be a small piece of work. Cheers, Raymond
Re: Missing \end_layout
rgheck wrote:
I'm getting some errors when opening the User's Guide etc:
Unknown token, Undefinable structure, skipping.
Unknown token, \end_layout, skipping.
Paragraph ended in line 16837
Missing \end_layout.
Unknown token, subcaptionText, skipping.
Unknown token, Platypus, skipping.
Unknown token, \end_layout, skipping.
Paragraph ended in line 16868
Missing \end_layout.
Unknown token, subcaptionText, skipping.
Unknown token, Undefinable structure, skipping.
Unknown token, \end_layout, skipping.
Paragraph ended in line 1007
Missing \end_layout.
Paragraph ended in line 1024
Missing \end_layout.
Unknown token, subcaptionText, skipping.
Unknown token, \label{fig:Platypus} Platypus, skipping.
Unknown token, \end_layout, skipping.
Paragraph ended in line 1039
Missing \end_layout.
Looks like my conversion routine for subfloats is not yet perfect. José, could
you have a look at this too, when you fix revert_subfig?
Thanks,
Jürgen
Re: Missing \end_layout
On Friday 07 March 2008 11:50:05 Jürgen Spitzmüller wrote: Looks like my conversion routine for subfloats is not yet perfect. José, could you have a look at this too, when you fix revert_subfig? Sure. Thanks, Jürgen -- José Abílio
The wiki page Mac.Mac now requiers a password
Hi, I changed the wiki page Mac.Mac so that it now requires the usual password, i.e. the one mentioned in the file /home/lyx/www/pmwiki/passwords.txt on aussie (a.k.a. wiki.lyx.org etc). Whenever I add a password to a wiki page (which I generally would like to avoid), I try to make a note of it in this page. Currently the following pages are listed in that file: Âcat /home/lyx/www/pmwiki/passwords.txt ÂPages that should be password protected: * http://wiki.lyx.org/LyX/Welcome * http://wiki.lyx.org/Mac/Mac * http://wiki.lyx.org/Windows/Windows * http://wiki.lyx.org/Windows/LyX145 * http://wiki.lyx.org/Windows/LyX151 * http://wiki.lyx.org/Windows/LyX152 * http://wiki.lyx.org/PmWiki/* * http://wiki.lyx.org/Site/* * http://wiki.lyx.org/FAQ/ERT Best regards, Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Layout Categories
Am 06.03.2008 um 07:23 schrieb rgheck: This is in. See 23501-3. You want Layout::category(). inline: Bild 3.png Stefan
Re: Layout Categories
nice. would unnumbered not be better than starred?
Re: Layout Categories
Edwin Leuven [EMAIL PROTECTED] writes: nice. would unnumbered not be better than starred? Unnumbered sections, even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? JMarc
Re: Layout Categories
Am 07.03.2008 um 16:21 schrieb Jean-Marc Lasgouttes: Edwin Leuven [EMAIL PROTECTED] writes: nice. would unnumbered not be better than starred? Unnumbered sections, even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? Don't whether QComboBox supports tree models. One has to check. I can easily provide a model to it with a tree structure. Stefan
Re: Layout Categories
Am 07.03.2008 um 16:14 schrieb Edwin Leuven: nice. would unnumbered not be better than starred? Should we put a translation step in between the TextClass and the layout list? If yes, how? Just a big case distinction, mapping TextClass categories to visible category names? Stefan
Re: Layout Categories
Stefan Schimanski [EMAIL PROTECTED] writes: Should we put a translation step in between the TextClass and the layout list? If yes, how? Just a big case distinction, mapping TextClass categories to visible category names? You mean translation by gettext? Sure. But I am not sure this is what you mean. If it is for the name of starred sections, I think we should just change the name in the layout file and make just what appears in the layout file (like the Style entry) be visible in the combox. JMarc
Re: Layout Categories
Stefan Schimanski [EMAIL PROTECTED] writes: And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? Don't whether QComboBox supports tree models. One has to check. I can easily provide a model to it with a tree structure. A tree would be interesting indeed. JMarc
Re: Layout Categories
Am 07.03.2008 um 16:49 schrieb Jean-Marc Lasgouttes: Stefan Schimanski [EMAIL PROTECTED] writes: Should we put a translation step in between the TextClass and the layout list? If yes, how? Just a big case distinction, mapping TextClass categories to visible category names? You mean translation by gettext? Sure. I do that already. But I am not sure this is what you mean. If it is for the name of starred sections, I think we should just change the name in the layout file and make just what appears in the layout file (like the Style entry) be visible in the combox. Ok, that's what I meant. So the category there is supposed to be the string shown in the list. Stefan JMarc
Re: Layout Categories
Stefan Schimanski [EMAIL PROTECTED] writes: Ok, that's what I meant. So the category there is supposed to be the string shown in the list. Yes. JMarc
amsmaths.inc
Hello,
While creating a new layout, I had an error (\theoremstyle missing).
Jean-Marc pointed out that this was defined in amsthm.sty.
Checking AMS in Document-Settings is useless, this does not load
amsthm, only amsmath and amsfonts.
I guess that this patch
--- amsmaths.inc.orig 2008-03-07 18:52:57.501637000 +0100
+++ amsmaths.inc2008-03-07 17:43:27.94189 +0100
@@ -68,6 +68,7 @@
Series Bold
EndFont
Preamble
+ \usepackage{amsthm}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
EndPreamble
should have been applied long ago.
I understood that 1.6 will use a different syntax.
--
Jean-Pierre
Re: changeset/23527
On Fri, Mar 07, 2008 at 11:40:01AM +0100, Uwe Stöhr wrote: André, could you please also take care of SCons when deleting/adding/moving files. (I know that you don't use SCons, but I don't use Make but I take care of the Makefiles.) I'll try to do better in the future. Andre' PS: On the formal side, autotools are still the official toolchain, so that's the one (and only one) that has to be taken care of when making changes...
Re: Layout Categories
On Fri, Mar 07, 2008 at 04:34:25PM +0100, Stefan Schimanski wrote: Am 07.03.2008 um 16:21 schrieb Jean-Marc Lasgouttes: Edwin Leuven [EMAIL PROTECTED] writes: nice. would unnumbered not be better than starred? Unnumbered sections, even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? Don't whether QComboBox supports tree models. It does. You can plug in any QAbstractItemModel. Andre'
kb_action
What would be a good name for the 'kb_action' enum? It's a bit similar to 'InsetCode'... LFunCode? FunctionCode? FuncCode? Andre'
Re: kb_action
What would be a good name for the 'kb_action' enum? It's a bit similar to 'InsetCode'... LFunCode? +1 FunctionCode? FuncCode? p
Re: kb_action
Andre Poenitz wrote: What would be a good name for the 'kb_action' enum? It's a bit similar to 'InsetCode'... LFunCode? FunctionCode? FuncCode? FuncCode looks good, inline with FuncRequest. Abdel.
Re: Layout Categories
Am 07.03.2008 um 19:40 schrieb Andre Poenitz: On Fri, Mar 07, 2008 at 04:34:25PM +0100, Stefan Schimanski wrote: Am 07.03.2008 um 16:21 schrieb Jean-Marc Lasgouttes: Edwin Leuven [EMAIL PROTECTED] writes: nice. would unnumbered not be better than starred? Unnumbered sections, even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? Don't whether QComboBox supports tree models. It does. You can plug in any QAbstractItemModel. And then it makes what out of it? A QTreeView popup? A chained popup menu? Stefan
Re: amsmaths.inc
Jean-Pierre Chrétien wrote:
Hello,
While creating a new layout, I had an error (\theoremstyle missing).
Jean-Marc pointed out that this was defined in amsthm.sty.
Checking AMS in Document-Settings is useless, this does not load
amsthm, only amsmath and amsfonts.
I guess that this patch
--- amsmaths.inc.orig 2008-03-07 18:52:57.501637000 +0100
+++ amsmaths.inc2008-03-07 17:43:27.94189 +0100
@@ -68,6 +68,7 @@
Series Bold
EndFont
Preamble
+ \usepackage{amsthm}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
EndPreamble
should have been applied long ago.
Does this need to be included here, or in every theorem environment? If
in every one, then it probably ought to go in a more global sort of
Preamble declaration. Actually, I guess the other ones depend upon that
one, so that would be OK. But it's kind of fragile that way. So...
At present, each new global Preamble over-writes the previous one. This
is very counter-intuitive, so I'd propose this be changed, so that
Preamble sections ADD TO the existing preamble stuff, rather than
totally over-writing it. If necessary, we could also have a
PreambleReset declaration.
Thoughts?
rh
Re: cangeset 23520 - crash
Uwe Stöhr schrieb: Hello Bernhard, could you please also add a description of bm.sty to the LaTeXConfig.lyx I tried to open this document with current trunk and got a crash. The attached patch avoids the crash but someone familiar with InsetText.cpp should have a look at it. bernhard file and add bm to the checked packages in chkconfig.ltx? thanks and regards Uwe
Re: cangeset 23520 - crash
Uwe Stöhr schrieb:
Hello Bernhard,
could you please also add a description of bm.sty to the LaTeXConfig.lyx
I tried to open this document with current trunk and got a crash. The attached
patch avoids the
crash but someone familiar with InsetText.cpp should have a look at it.
bernhard
file and add bm to the checked packages in chkconfig.ltx?
thanks and regards
Uwe
Index: src/insets/InsetText.cpp
===
--- src/insets/InsetText.cpp(revision 23539)
+++ src/insets/InsetText.cpp(working copy)
@@ -142,12 +142,17 @@
ParagraphList pars = paragraphs();
// This is a gross hack...
- Layout old_layout = pars.begin()-layout();
+ Layout const * old_layout = 0;
+ if (pars.begin() != pars.end()) {
+ old_layout = pars.begin()-layout();
+ }
pars.clear();
pars.push_back(Paragraph());
pars.begin()-setInsetOwner(this);
- pars.begin()-setLayout(old_layout);
+ if (old_layout) {
+ pars.begin()-setLayout(*old_layout);
+ }
}
Re: cangeset 23520 - crash
Bernhard Roider wrote: Uwe Stöhr schrieb: Hello Bernhard, could you please also add a description of bm.sty to the LaTeXConfig.lyx I tried to open this document with current trunk and got a crash. The attached patch avoids the crash but someone familiar with InsetText.cpp should have a look at it. Smaller version: if (pars.empty()) return; Abdel.
Re: Why InsetListings does not inherit from InsetFloat?
On Fri, Mar 7, 2008 at 3:01 AM, Abdelrazak Younes [EMAIL PROTECTED] wrote: InsetListings has the look and the feel of a float, so isn't it so? Because we need to enter verbatim code in this inset, although InsetERT does a bad job in the handling of spaces and tabs. Bo
svnusers can now read passwords.txt (Was: The wiki page Mac.Mac now requiers a password)
This file /home/lyx/www/pmwiki/passwords.txt used to only be readable by members of the group 'wiki'. I've now changed this to 'svnusers'. So hopefully most developers can now read it. Best regards, /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
InsetText Crash
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor, and
from there in basic_string. So it looks as if there's an uninitialized
string in the Layout object, but I don't see how that could be. I think
the the paragraph in question is using emptyParagraphLayout, which is
simply a static and otherwise undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then HelpLaTeX Configuration to generate
the crash.
rh
Re: InsetText Crash
One more clue: It's a docstring, basic_stringwchar_t, according ot gdb.
rh
rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor,
and from there in basic_string. So it looks as if there's an
uninitialized string in the Layout object, but I don't see how that
could be. I think the the paragraph in question is using
emptyParagraphLayout, which is simply a static and otherwise undefined
Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then HelpLaTeX Configuration to generate
the crash.
rh
unrtf
hi,
if there are no objections i would like to add this convertor to configure
script.
pavel
diff --git a/lib/configure.py b/lib/configure.py
index 84bbbe6..76057ef 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -390,6 +390,9 @@ def checkConverterEntries():
checkProg('a LaTeX - RTF converter', ['latex2rtf -p -S -o $$o $$i',
'latex2rt -p -S -o $$o $$i'],
rc_entry = [ r'\converter latex rtf%% needaux' ])
#
+checkProg('a RTF - HTML converter', ['unrtf --html $$i $$o'],
+rc_entry = [ r'\converter rtf html%%' ])
+#
checkProg('a PS to PDF converter', ['ps2pdf13 $$i $$o'],
rc_entry = [ r'\converter ps pdf%% ' ])
#
Re: InsetText Crash
Ignore all of this: I finally figured out what the problem was.
rh
One more clue: It's a docstring, basic_stringwchar_t, according ot gdb.
rh
rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor,
and from there in basic_string. So it looks as if there's an
uninitialized string in the Layout object, but I don't see how that
could be. I think the the paragraph in question is using
emptyParagraphLayout, which is simply a static and otherwise
undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then HelpLaTeX Configuration to generate
the crash.
rh
Re: amsmaths.inc
Jean-Pierre Chrétien wrote:
I guess that this patch
--- amsmaths.inc.orig 2008-03-07 18:52:57.501637000 +0100
+++ amsmaths.inc2008-03-07 17:43:27.94189 +0100
@@ -68,6 +68,7 @@
Series Bold
EndFont
Preamble
+ \usepackage{amsthm}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
EndPreamble
should have been applied long ago.
Should that be \RequirePackage rather than \usepackage? Is there any
danger this would supersede an instance of \usepackage[options]{amsthm}
somewhere? I probably should know this but don't: if
\usepackage[options]{x} is followed by \usepackage{x}, are the options
still applied?
/Paul
Re: InsetText Crash
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
about something. The crash is probably a consequence of my attempt to work
on Paragraph.cpp, but I'm not sure exactly what's happened. The backtrace
gives me a crash in the Layout constructor, and from there in basic_string.
So it looks as if there's an uninitialized string in the Layout object, but
I don't see how that could be. I think the the paragraph in question is
using emptyParagraphLayout, which is simply a static and otherwise
undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar problems
elsewhere. If anyone has any ideas, I'd love to hear them.
Maybe the InsetText constructor constructs a paragraph that needs a
layout which in turn accesses parts of the non-yet-fully constructed
text ot paragraph.
Andre'
Re: InsetText Crash
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
about something. The crash is probably a consequence of my attempt to work
on Paragraph.cpp, but I'm not sure exactly what's happened. The backtrace
gives me a crash in the Layout constructor, and from there in basic_string.
So it looks as if there's an uninitialized string in the Layout object, but
I don't see how that could be. I think the the paragraph in question is
using emptyParagraphLayout, which is simply a static and otherwise
undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar problems
elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then HelpLaTeX Configuration to generate the
crash.
Hm... this new 'Software Exception' dialog is pretty efficient at
creating useless stack traces.. *sigh*
Andre'
Why InsetListings does not inherit from InsetFloat?
InsetListings has the look and the feel of a float, so isn't it so? Abdel.
Re: About macro and child buffers
I am sorry to say this only now but I am worried about future maintenance of the code. So, if you agree with me and you have the time, please try to do those change before 1.6.0. I know about the complexity. What I really want to do for some time is the following which dramatically reduces the complexity: Macros should be global, i.e. no scopes anymore. Scopes are there in TeX of course, but I don't think they are really essential for the usual user. This will make the code much much simpler. I was waiting for Manuel Pégourié-Gonnard to update his xargs to implement the needed semantics for LyX. He sent me a snapshot, but didn't release it yet. Stefan
Re: [patch BRANCH] insertInset
Jean-Marc Lasgouttes wrote:
> Well, the first change is straight forward,
Right. See attached patch.
> but I do not know what is
> the right semantics to use for the second problem.
Me neither.
Jürgen
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 23533)
+++ src/Text3.cpp (Arbeitskopie)
@@ -272,6 +272,8 @@
lyx::dispatch(FuncRequest(LFUN_CUT));
gotsel = true;
}
+ bool const emptypar = cur.lastpos() == 0;
+ pos_type ins_pos = cur.pos();
text->insertInset(cur, inset);
if (edit)
@@ -281,8 +283,8 @@
// metrics might be invalid at this point (bug 4502)
cur.bv().updateMetrics();
lyx::dispatch(FuncRequest(LFUN_PASTE, "0"));
-
- if (cur.lastpit() == 0) {
+
+ if ((cur.lastpit() == 0 || ins_pos != 0) && !emptypar) {
// reset first par to default
Layout_ptr const layout =
cur.buffer().params().getTextClass().defaultLayout();
cangeset 23520
Hello Bernhard, could you please also add a description of bm.sty to the LaTeXConfig.lyx file and add bm to the checked packages in chkconfig.ltx? thanks and regards Uwe
changeset/23527
André, could you please also take care of SCons when deleting/adding/moving files. (I know that you don't use SCons, but I don't use Make but I take care of the Makefiles.) regards Uwe
Re: A few questions
On 6 March 2008 16:52:41 Pavel Sanda wrote: > thank you for the detailed description, i'm starting have a clue what you > have in mind. > its clear these two things are orthogonal - at most bilingual mode could > exercise > your WM tool as a part of editing process. Perhaps. I will have to look at it closely first. There may be a way to extend that bilingual mode. > > in case you decide use LyX for your plans it maybe be good to outline the > implemenation here on list before you appear with 100kb of code ;) Right. It will definitely not be a small piece of work. Cheers, Raymond
Re: Missing \end_layout
rgheck wrote:
> I'm getting some errors when opening the User's Guide etc:
> Unknown token, Undefinable structure, skipping.
> Unknown token, \end_layout, skipping.
> Paragraph ended in line 16837
> Missing \end_layout.
> Unknown token, subcaptionText, skipping.
> Unknown token, Platypus, skipping.
> Unknown token, \end_layout, skipping.
> Paragraph ended in line 16868
> Missing \end_layout.
> Unknown token, subcaptionText, skipping.
> Unknown token, Undefinable structure, skipping.
> Unknown token, \end_layout, skipping.
> Paragraph ended in line 1007
> Missing \end_layout.
> Paragraph ended in line 1024
> Missing \end_layout.
> Unknown token, subcaptionText, skipping.
> Unknown token, \label{fig:Platypus} Platypus, skipping.
> Unknown token, \end_layout, skipping.
> Paragraph ended in line 1039
> Missing \end_layout.
Looks like my conversion routine for subfloats is not yet perfect. José, could
you have a look at this too, when you fix revert_subfig?
Thanks,
Jürgen
Re: Missing \end_layout
On Friday 07 March 2008 11:50:05 Jürgen Spitzmüller wrote: > Looks like my conversion routine for subfloats is not yet perfect. José, > could you have a look at this too, when you fix revert_subfig? Sure. > Thanks, > Jürgen -- José Abílio
The wiki page Mac.Mac now requiers a password
Hi, I changed the wiki page Mac.Mac so that it now requires the usual password, i.e. the one mentioned in the file /home/lyx/www/pmwiki/passwords.txt on aussie (a.k.a. wiki.lyx.org etc). Whenever I add a password to a wiki page (which I generally would like to avoid), I try to make a note of it in this page. Currently the following pages are listed in that file: Âcat /home/lyx/www/pmwiki/passwords.txt ÂPages that should be password protected: * http://wiki.lyx.org/LyX/Welcome * http://wiki.lyx.org/Mac/Mac * http://wiki.lyx.org/Windows/Windows * http://wiki.lyx.org/Windows/LyX145 * http://wiki.lyx.org/Windows/LyX151 * http://wiki.lyx.org/Windows/LyX152 * http://wiki.lyx.org/PmWiki/* * http://wiki.lyx.org/Site/* * http://wiki.lyx.org/FAQ/ERT Best regards, Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Layout Categories
Am 06.03.2008 um 07:23 schrieb rgheck: This is in. See 23501-3. You want Layout::category(). <> Stefan
Re: Layout Categories
nice. would "unnumbered" not be better than "starred"?
Re: Layout Categories
Edwin Leuven <[EMAIL PROTECTED]> writes: > nice. > > would "unnumbered" not be better than "starred"? "Unnumbered sections", even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? JMarc
Re: Layout Categories
Am 07.03.2008 um 16:21 schrieb Jean-Marc Lasgouttes: Edwin Leuven <[EMAIL PROTECTED]> writes: nice. would "unnumbered" not be better than "starred"? "Unnumbered sections", even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? Don't whether QComboBox supports tree models. One has to check. I can easily provide a model to it with a tree structure. Stefan
Re: Layout Categories
Am 07.03.2008 um 16:14 schrieb Edwin Leuven: nice. would "unnumbered" not be better than "starred"? Should we put a translation step in between the TextClass and the layout list? If yes, how? Just a big case distinction, mapping TextClass categories to visible category names? Stefan
Re: Layout Categories
Stefan Schimanski <[EMAIL PROTECTED]> writes: > Should we put a translation step in between the TextClass and the > layout list? If yes, how? Just a big case distinction, mapping > TextClass categories to visible category names? You mean translation by gettext? Sure. But I am not sure this is what you mean. If it is for the name of starred sections, I think we should just change the name in the layout file and make just what appears in the layout file (like the Style entry) be visible in the combox. JMarc
Re: Layout Categories
Stefan Schimanski <[EMAIL PROTECTED]> writes: >> And is it possible (optionally?), to show that as a hierarchical menu? >> Or a double-column think like the mac file selector? > > Don't whether QComboBox supports tree models. One has to check. I can > easily provide a model to it with a tree structure. A tree would be interesting indeed. JMarc
Re: Layout Categories
Am 07.03.2008 um 16:49 schrieb Jean-Marc Lasgouttes: Stefan Schimanski <[EMAIL PROTECTED]> writes: Should we put a translation step in between the TextClass and the layout list? If yes, how? Just a big case distinction, mapping TextClass categories to visible category names? You mean translation by gettext? Sure. I do that already. But I am not sure this is what you mean. If it is for the name of starred sections, I think we should just change the name in the layout file and make just what appears in the layout file (like the Style entry) be visible in the combox. Ok, that's what I meant. So the category there is supposed to be the string shown in the list. Stefan JMarc
Re: Layout Categories
Stefan Schimanski <[EMAIL PROTECTED]> writes: > Ok, that's what I meant. So the category there is supposed to be the > string shown in the list. Yes. JMarc
amsmaths.inc
Hello,
While creating a new layout, I had an error (\theoremstyle missing).
Jean-Marc pointed out that this was defined in amsthm.sty.
Checking AMS in Document->Settings is useless, this does not load
amsthm, only amsmath and amsfonts.
I guess that this patch
--- amsmaths.inc.orig 2008-03-07 18:52:57.501637000 +0100
+++ amsmaths.inc2008-03-07 17:43:27.94189 +0100
@@ -68,6 +68,7 @@
Series Bold
EndFont
Preamble
+ \usepackage{amsthm}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
EndPreamble
should have been applied long ago.
I understood that 1.6 will use a different syntax.
--
Jean-Pierre
Re: changeset/23527
On Fri, Mar 07, 2008 at 11:40:01AM +0100, Uwe Stöhr wrote: > André, > > could you please also take care of SCons when deleting/adding/moving files. > (I know that you don't use SCons, but I don't use Make but I take care of > the Makefiles.) I'll try to do better in the future. Andre' PS: On the formal side, autotools are still the official toolchain, so that's the one (and only one) that has to be taken care of when making changes...
Re: Layout Categories
On Fri, Mar 07, 2008 at 04:34:25PM +0100, Stefan Schimanski wrote: > > Am 07.03.2008 um 16:21 schrieb Jean-Marc Lasgouttes: > >> Edwin Leuven <[EMAIL PROTECTED]> writes: >> >>> nice. >>> >>> would "unnumbered" not be better than "starred"? >> >> "Unnumbered sections", even. >> >> And is it possible (optionally?), to show that as a hierarchical menu? >> Or a double-column think like the mac file selector? > > Don't whether QComboBox supports tree models. It does. You can plug in any QAbstractItemModel. Andre'
kb_action
What would be a good name for the 'kb_action' enum? It's a bit similar to 'InsetCode'... LFunCode? FunctionCode? FuncCode? Andre'
Re: kb_action
> What would be a good name for the 'kb_action' enum? > It's a bit similar to 'InsetCode'... > > LFunCode? +1 > FunctionCode? > FuncCode? p
Re: kb_action
Andre Poenitz wrote: What would be a good name for the 'kb_action' enum? It's a bit similar to 'InsetCode'... LFunCode? FunctionCode? FuncCode? FuncCode looks good, inline with FuncRequest. Abdel.
Re: Layout Categories
Am 07.03.2008 um 19:40 schrieb Andre Poenitz: On Fri, Mar 07, 2008 at 04:34:25PM +0100, Stefan Schimanski wrote: Am 07.03.2008 um 16:21 schrieb Jean-Marc Lasgouttes: Edwin Leuven <[EMAIL PROTECTED]> writes: nice. would "unnumbered" not be better than "starred"? "Unnumbered sections", even. And is it possible (optionally?), to show that as a hierarchical menu? Or a double-column think like the mac file selector? Don't whether QComboBox supports tree models. It does. You can plug in any QAbstractItemModel. And then it makes what out of it? A QTreeView popup? A chained popup menu? Stefan
Re: amsmaths.inc
Jean-Pierre Chrétien wrote:
Hello,
While creating a new layout, I had an error (\theoremstyle missing).
Jean-Marc pointed out that this was defined in amsthm.sty.
Checking AMS in Document->Settings is useless, this does not load
amsthm, only amsmath and amsfonts.
I guess that this patch
--- amsmaths.inc.orig 2008-03-07 18:52:57.501637000 +0100
+++ amsmaths.inc2008-03-07 17:43:27.94189 +0100
@@ -68,6 +68,7 @@
Series Bold
EndFont
Preamble
+ \usepackage{amsthm}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
EndPreamble
should have been applied long ago.
Does this need to be included here, or in every theorem environment? If
in every one, then it probably ought to go in a more global sort of
Preamble declaration. Actually, I guess the other ones depend upon that
one, so that would be OK. But it's kind of fragile that way. So...
At present, each new global Preamble over-writes the previous one. This
is very counter-intuitive, so I'd propose this be changed, so that
Preamble sections ADD TO the existing preamble stuff, rather than
totally over-writing it. If necessary, we could also have a
PreambleReset declaration.
Thoughts?
rh
Re: cangeset 23520 - crash
Uwe Stöhr schrieb: Hello Bernhard, could you please also add a description of bm.sty to the LaTeXConfig.lyx I tried to open this document with current trunk and got a crash. The attached patch avoids the crash but someone familiar with InsetText.cpp should have a look at it. bernhard file and add bm to the checked packages in chkconfig.ltx? thanks and regards Uwe
Re: cangeset 23520 - crash
Uwe Stöhr schrieb:
Hello Bernhard,
could you please also add a description of bm.sty to the LaTeXConfig.lyx
I tried to open this document with current trunk and got a crash. The attached
patch avoids the
crash but someone familiar with InsetText.cpp should have a look at it.
bernhard
file and add bm to the checked packages in chkconfig.ltx?
thanks and regards
Uwe
Index: src/insets/InsetText.cpp
===
--- src/insets/InsetText.cpp(revision 23539)
+++ src/insets/InsetText.cpp(working copy)
@@ -142,12 +142,17 @@
ParagraphList & pars = paragraphs();
// This is a gross hack...
- Layout old_layout = pars.begin()->layout();
+ Layout const * old_layout = 0;
+ if (pars.begin() != pars.end()) {
+ old_layout = ()->layout();
+ }
pars.clear();
pars.push_back(Paragraph());
pars.begin()->setInsetOwner(this);
- pars.begin()->setLayout(old_layout);
+ if (old_layout) {
+ pars.begin()->setLayout(*old_layout);
+ }
}
Re: cangeset 23520 - crash
Bernhard Roider wrote: Uwe Stöhr schrieb: Hello Bernhard, could you please also add a description of bm.sty to the LaTeXConfig.lyx I tried to open this document with current trunk and got a crash. The attached patch avoids the crash but someone familiar with InsetText.cpp should have a look at it. Smaller version: if (pars.empty()) return; Abdel.
Re: Why InsetListings does not inherit from InsetFloat?
On Fri, Mar 7, 2008 at 3:01 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > InsetListings has the look and the feel of a float, so isn't it so? Because we need to enter verbatim code in this inset, although InsetERT does a bad job in the handling of spaces and tabs. Bo
svnusers can now read passwords.txt (Was: The wiki page Mac.Mac now requiers a password)
This file /home/lyx/www/pmwiki/passwords.txt used to only be readable by members of the group 'wiki'. I've now changed this to 'svnusers'. So hopefully most developers can now read it. Best regards, /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
InsetText Crash
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor, and
from there in basic_string. So it looks as if there's an uninitialized
string in the Layout object, but I don't see how that could be. I think
the the paragraph in question is using emptyParagraphLayout, which is
simply a static and otherwise undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate
the crash.
rh
Re: InsetText Crash
One more clue: It's a docstring, basic_string, according ot gdb.
rh
rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor,
and from there in basic_string. So it looks as if there's an
uninitialized string in the Layout object, but I don't see how that
could be. I think the the paragraph in question is using
emptyParagraphLayout, which is simply a static and otherwise undefined
Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate
the crash.
rh
unrtf
hi,
if there are no objections i would like to add this convertor to configure
script.
pavel
diff --git a/lib/configure.py b/lib/configure.py
index 84bbbe6..76057ef 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -390,6 +390,9 @@ def checkConverterEntries():
checkProg('a LaTeX -> RTF converter', ['latex2rtf -p -S -o $$o $$i',
'latex2rt -p -S -o $$o $$i'],
rc_entry = [ r'\converter latex rtf"%%" "needaux"' ])
#
+checkProg('a RTF -> HTML converter', ['unrtf --html $$i > $$o'],
+rc_entry = [ r'\converter rtf html"%%"""' ])
+#
checkProg('a PS to PDF converter', ['ps2pdf13 $$i $$o'],
rc_entry = [ r'\converter ps pdf"%%" ""' ])
#
Re: InsetText Crash
Ignore all of this: I finally figured out what the problem was.
rh
One more clue: It's a docstring, basic_string, according ot gdb.
rh
rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor,
and from there in basic_string. So it looks as if there's an
uninitialized string in the Layout object, but I don't see how that
could be. I think the the paragraph in question is using
emptyParagraphLayout, which is simply a static and otherwise
undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate
the crash.
rh
Re: amsmaths.inc
Jean-Pierre Chrétien wrote:
I guess that this patch
--- amsmaths.inc.orig 2008-03-07 18:52:57.501637000 +0100
+++ amsmaths.inc2008-03-07 17:43:27.94189 +0100
@@ -68,6 +68,7 @@
Series Bold
EndFont
Preamble
+ \usepackage{amsthm}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
EndPreamble
should have been applied long ago.
Should that be \RequirePackage rather than \usepackage? Is there any
danger this would supersede an instance of \usepackage[options]{amsthm}
somewhere? I probably should know this but don't: if
\usepackage[options]{x} is followed by \usepackage{x}, are the options
still applied?
/Paul
Re: InsetText Crash
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
>
> I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
> about something. The crash is probably a consequence of my attempt to work
> on Paragraph.cpp, but I'm not sure exactly what's happened. The backtrace
> gives me a crash in the Layout constructor, and from there in basic_string.
> So it looks as if there's an uninitialized string in the Layout object, but
> I don't see how that could be. I think the the paragraph in question is
> using emptyParagraphLayout, which is simply a static and otherwise
> undefined Layout object:
>namespace {
>Layout const emptyParagraphLayout;
>}
> But why should this have an uninitialized member?
>
> Anyway, I'm quite puzzled by this and worried we'll find similar problems
> elsewhere. If anyone has any ideas, I'd love to hear them.
Maybe the InsetText constructor constructs a paragraph that needs a
layout which in turn accesses parts of the non-yet-fully constructed
text ot paragraph.
Andre'
Re: InsetText Crash
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
>
> I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
> about something. The crash is probably a consequence of my attempt to work
> on Paragraph.cpp, but I'm not sure exactly what's happened. The backtrace
> gives me a crash in the Layout constructor, and from there in basic_string.
> So it looks as if there's an uninitialized string in the Layout object, but
> I don't see how that could be. I think the the paragraph in question is
> using emptyParagraphLayout, which is simply a static and otherwise
> undefined Layout object:
>namespace {
>Layout const emptyParagraphLayout;
>}
> But why should this have an uninitialized member?
>
> Anyway, I'm quite puzzled by this and worried we'll find similar problems
> elsewhere. If anyone has any ideas, I'd love to hear them.
>
> Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate the
> crash.
Hm... this new 'Software Exception' dialog is pretty efficient at
creating useless stack traces.. *sigh*
Andre'
