InsetOld::hasParagraphs->InsetOld::numParagraphs
Can I do it? hasParagraphs is never used in the code, and we need numParagraphs for having PosIterator/Cursor::operator-- PS: should I drop PosIterator and try to make Cursor::operator++/-- operative? Alfredo
Re: InsetOld::hasParagraphs->InsetOld::numParagraphs
Alfredo Braunstein wrote: > Can I do it? > > hasParagraphs is never used in the code, and we need numParagraphs > for having PosIterator/Cursor::operator-- Who could possibly object? Go for it. > PS: should I drop PosIterator and try to make Cursor::operator++/-- > operative? Why not make PosIterator fully functional and then think about implementing Cursor in terms of PosIterator? -- Angus
Re: InsetOld::hasParagraphs->InsetOld::numParagraphs
Angus Leeming wrote: >> hasParagraphs is never used in the code, and we need numParagraphs >> for having PosIterator/Cursor::operator-- > > Who could possibly object? Go for it. The ways of objections are misterious... ;-) I'll do it then. >> PS: should I drop PosIterator and try to make Cursor::operator++/-- >> operative? > > Why not make PosIterator fully functional and then think about I'm doing this already: I think PosIterator in the patch I sent yesterday is fully functional (the patch has some bugs in putting the selection at the end of a successful search but that's another story). [Btw, it should be super easy to implement regex searches right? It would suffice to implement operator* that gives pit->getChar(pos) if pos < size and some '\n' if pos == size. In that way one could also search for newlines etc. Methink.] > implementing Cursor in terms of PosIterator? My concern is that Andrà has already started implementing Cursor in his own way, and maybe his way is better. [In any case, they are very similar I think]. But I don't want to interfere with anybody's plans. If I could only get Andrà to comment what are his future plans on this... Alfredo
Re: InsetOld::hasParagraphs->InsetOld::numParagraphs
Alfredo Braunstein wrote: > [Btw, it should be super easy to implement regex searches right? It > [would > suffice to implement operator* that gives pit->getChar(pos) if pos < > size and some '\n' if pos == size. In that way one could also search > for newlines etc. Methink.] Great idea. ... it would returns 0 if no match is found. ... how about it returning META_INSET if you're searching for an inset of a particular 'flavour'? >> implementing Cursor in terms of PosIterator? > > My concern is that André has already started implementing Cursor in > his own way, and maybe his way is better. [In any case, they are > very similar I think]. Why not produce a rationale description of the differences between the two, where one is better than the other etc. > But I don't want to interfere with anybody's > plans. If I could only get André to comment what are his future > plans on this... I think that André has always valued your input. You're one of the few guys contributing code in areas he's interested in and he seems to value the company. At least that's how I read the comment at the end of this message: http://marc.theaimsgroup.com/?l=lyx-devel&m=105402651120545&w=2 -- Angus
Re: new layout files for g-brief2
Sorry, the apache died. Please try again. Felix Jean-Marc Lasgouttes wrote: >> "Felix" == Felix Kurth <[EMAIL PROTECTED]> writes: > > Felix> Hello I just created layout files and examples for the g-brief2 > Felix> latex style. This style is the successor of g-brief. Its more > Felix> flexible and looks nicer Please send me comments. Please > Felix> apply to lyx-cvs. > > Felix> You will find the files here: > Felix> http://www.fkurth.de/~felix/g-brief2.tgz > > I get 'connection refused'. > > JMarc -- Felix Kurth pgp public key: http://www.fkurth.de/keys/felix.fkurth.asc key fingerprint: D401 DCF8 2BF8 50DF 2FAD 8136 C29B 83EE C0A1 F2AD
compier warning question
If I were to compile this function with -DNDEBUG, I'd get a compiler
warning about 'control reaches the end of a non-void function'. It
seems ugly to shove a 'return arbitrary_value;' after the assert. Is
there Another Way?
int const store[] = { 1, 2, 3, 4, 5 };
int const store_size = sizeof(store) / sizeof(store[0]);
int find(int value) {
for (int i = 0; i < store_size; ++i) {
if (store[i] == value)
return i;
}
assert(0);
}
--
Angus
Re: compier warning question
On Fri, Oct 31, 2003 at 03:24:10PM +, Angus Leeming wrote: > If I were to compile this function with -DNDEBUG, I'd get a compiler > warning about 'control reaches the end of a non-void function'. It > seems ugly to shove a 'return arbitrary_value;' after the assert. Is > there Another Way? There's no other way without adding an assert_fail() or somesuch that has attribute__((noreturn)) on it ... john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: new layout files for g-brief2
> "Felix" == Felix Kurth <[EMAIL PROTECTED]> writes: Felix> Sorry, the apache died. Please try again. Thanks. Could you provide a small text for LaTeXConfig.lyx.in (see Help>LaTeX Configuration) explaining the difference between the two classes? If g-brief is the obsolete version, should it be highlighted in the class description? And finally, are the two classes compatible (is it possible to switch old docs to g-brief2?). JMarc
Re: PosIterator - design pattern discussion
On Thursday 30 October 2003 01:06 pm, Angus Leeming wrote: > Kuba Ober wrote: > > On Thursday 30 October 2003 11:26 am, Alfredo Braunstein wrote: > >> Angus Leeming wrote: > >> > Note that multiple BufferViews implies multiple Cursors. I'm sure > >> > that I would be pissed off if I replaced "brown" with "red" in > >> > one window and found that the cursor in my other BufferView had > >> > also changed position. > >> > >> That's a very good point. > > > > I think that the only real solution is that the tree must know of > > its iterators and adjust them if tree structure changes. > > > > I presume that it should call into existence a proper tree base > > classes for leafs and nodes. I wonder if they exist in the current > > design. [No time to look at the code, sorry :( ] > > > > Essentially, it should be tree's leaves and nodes which should be > > able to know which cursors point at them. Since there will be > > probably very few cursors in existence at any given time (say 10 or > > something of that order), it's conceiveable that: > > a) a tree element, upon each change, will look through the "global" > > list of cursors to see which cursors point to it > > b) it will adjust them per the pending change > > > > That also makes cursors invariants between changes to either tree > > elements or cursor position, and makes all cursors automatically > > always valid no matter what. > > > > Does it make any sense? Is that the direction you are going? Am I > > talking rubbish? I'm just a bystander and overseer, but I would like > > to know what pattern are you converging to in the long term. > > It's pseudo-rubbish in that the lyx data structure is a tree > in-concept only. It's actually a std::list where each > Paragraph contains a std::vector and an InsetList. Insets are > identified in the std::vector by chars with value 'META_INSET' > and a Buffer::inset_iterator class enables one to go from a > (ParagraphList::iterator, lyx::pos_type) pair to the inset of > interest. Why not make the tree structure explicit, with leaf and node base classes from which insets can derive? Wouldn't it make life much simpler? Cheers, Kuba Ober
Re: compier warning question
Angus Leeming <[EMAIL PROTECTED]> writes:
| If I were to compile this function with -DNDEBUG, I'd get a compiler
| warning about 'control reaches the end of a non-void function'. It
| seems ugly to shove a 'return arbitrary_value;' after the assert. Is
| there Another Way?
>
>
| int const store[] = { 1, 2, 3, 4, 5 };
| int const store_size = sizeof(store) / sizeof(store[0]);
>
| int find(int value) {
| for (int i = 0; i < store_size; ++i) {
| if (store[i] == value)
| return i;
| }
| assert(0);
| }
throw an exception. or call abort.
--
Lgb
Re: PosIterator - design pattern discussion
Kuba Ober <[EMAIL PROTECTED]> writes: | Why not make the tree structure explicit, with leaf and node base | classes from which insets can derive? Wouldn't it make life much | simpler? Moving towards that... slowly... -- Lgb
Re: PosIterator - design pattern discussion
> >> It's pseudo-rubbish in that the lyx data structure is a tree > >> in-concept only. It's actually a std::list where each > >> Paragraph contains a std::vector and an InsetList. Insets are > >> identified in the std::vector by chars with value > >> 'META_INSET' and a Buffer::inset_iterator class enables one to go > >> from a (ParagraphList::iterator, lyx::pos_type) pair to the inset > >> of interest. > > > > The inset lists are actually located in each paragraph (not that it > > matters, but...). > > I know. I even described it as such ;-) > > >> At least that is my understanding of things. > >> > >> Nonetheless, your basic idea is a good one. > > > > But some insets recursively contain a std::list etc. So > > it *is* a tree. > > Doh! I'll get back under my stone. Given all that, wouldn't be using explicit tree structures the simplest thing in order to clean the core up some? I mean, if we operate on a tree, why not have the proper tree base classes made, and have a basic cursor with virtual methods which by default only knows how to go around those tree elements (takes care of say removing a paragraph automatically). Now, for each type of node and leaf (i.e. each inset type), there would be a specialized cursor subclass that implement methods to navigate that inset. I know there was some discussion about many-insets-in-a-single-inset vs. single-inset-in-a-list-of-many and it was quite heated. But if all we need are some real down-to-earth tree structures, why not just use them explicitly? I guess the code would be way clearer that way. Anyway, knowing how things are these days, I presume it's not something that will happen for 1.4 :) And now you'd see me exercising my (unexistent) sprinting skills :) Cheers, Kuba Ober
Re: compier warning question
John Levon wrote: > On Fri, Oct 31, 2003 at 03:24:10PM +, Angus Leeming wrote: > >> If I were to compile this function with -DNDEBUG, I'd get a >> compiler warning about 'control reaches the end of a non-void >> function'. It seems ugly to shove a 'return arbitrary_value;' after >> the assert. Is there Another Way? > > There's no other way without adding an assert_fail() or somesuch > that has attribute__((noreturn)) on it ... Ok. Thanks. What would happen if I get through to the do-almost-nothing-but-set-attribute-noreturn assert? -- Angus
Re: Stlport+gcc-2.96 builds but does not run
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Index: src/debug.C | === | RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/debug.C,v | retrieving revision 1.39 | diff -u -p -r1.39 debug.C | --- src/debug.C 6 Oct 2003 15:42:13 - 1.39 | +++ src/debug.C 30 Oct 2003 16:06:52 - | @@ -123,4 +123,4 @@ void lyx_debug_trait::showTags(ostream & | os.flush(); | } | | -LyXErr lyxerr(std::cerr.rdbuf()); | +LyXErr lyxerr(0); I think we should add a default constructor that does this, so that we only use: LyXErr lyxerr; | Index: src/main.C | === | RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/main.C,v | retrieving revision 1.27 | diff -u -p -r1.27 main.C | --- src/main.C14 Oct 2003 21:30:20 - 1.27 | +++ src/main.C30 Oct 2003 16:06:52 - | @@ -13,6 +13,7 @@ | | #include "lyx_main.h" | #include "gettext.h" | +#include "debug.h" | #include "support/os.h" | | #ifdef HAVE_IOS | @@ -33,6 +34,9 @@ int main(int argc, char * argv[]) | | // initialize for internationalized version *EK* | locale_init(); | + | + // Initialize lyxerr here to work around a problem with STLport. | + lyxerr.rdbuf(std::cerr.rdbuf()); This is ok. Let's do this. -- Lgb
API for backends unification
The attached patch unifies the API used for the different backends in insets. In inset.h we have: int latex(Buffer const &, std::ostream &,LatexRunParams const &); int ascii(Buffer const &, std::ostream &,LatexRunParams const &); int linuxdoc(Buffer const &, std::ostream &,LatexRunParams const &); int docbook(Buffer const &, std::ostream &,LatexRunParams const &); that is, we use the LatexRunParams to carry the different running parameters. I have discussed this with Jean-Marc and Angus last July in Chemnitz, and if I understood well this was the path that Jean-Marc proposed. One of the advantages of this approach is that will five me docbook xml almost by free adopting a flavour approach. This is necessary for a real mathml support,as it is xml... The other advantage is the removal of nice from buffer, that is possible now. In the process I moved also the ascii generator for paragraphs to paragraph_funcs. That is we are moving all the functions not related with buffer out to the proper way. The only problematic bits are some of the ascii functions that are used elsewhere... Comments? -- José Abílio LyX and docbook, a perfect match. :-) patch-common.txt.gz Description: GNU Zip compressed data
Re: API for backends unification
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> The attached patch unifies the API used for the different Jose'> backends in insets. In inset.h we have: This looks good. Of course, the name LatexRunParams looks stupid now (because it is not for latex and not related to running either). Also, I see that you use only_body in some places. Could this go in the params too? JMarc
Re: API for backends unification
Jose' Matos wrote: > The attached patch unifies the API used for the different backends > in insets. > > In inset.h we have: > > int latex(Buffer const &, std::ostream &,LatexRunParams const &); > int ascii(Buffer const &, std::ostream &,LatexRunParams const &); > int linuxdoc(Buffer const &, std::ostream &,LatexRunParams const &); > int docbook(Buffer const &, std::ostream &,LatexRunParams const &); [snip...] > Comments? Good! Especially the getting rid of 'nice'. Could you see if you can can constify the non-const buffer member functions that alter 'nice' too. Maybe in a separate iteration of course... You should rename LatexRunParams though. ExportParams? And it really seems like parargraph_funcs.C is getting too big... -- Angus
Re: API for backends unification
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: > | Jose'> The attached patch unifies the API used for the different | Jose'> backends in insets. In inset.h we have: > | This looks good. Of course, the name LatexRunParams looks stupid now | (because it is not for latex and not related to running either). Agree. LatexRunParams should be renamed to OutputParams. And all variables therein related to _running_ latex should be moved out, if any. -- Lgb
Re: API for backends unification
On Friday 31 October 2003 16:28, Jean-Marc Lasgouttes wrote: > > "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: > > Jose'> The attached patch unifies the API used for the different > Jose'> backends in insets. In inset.h we have: > > This looks good. Of course, the name LatexRunParams looks stupid now > (because it is not for latex and not related to running either). Do not talk about names to me. ;-) There are lots of places with latex in the name and do not make sense, that I think my first patch to 1.5 will be a huge one to change that. ;-) > Also, I see that you use only_body in some places. Could this go in > the params too? Possibly, but I am not sure here, as this is a per buffer property, and it is only used in one place. In a sense, although it is not constant, even the ostream could go there because that is a running parameter. :-) To go really wild we could put there the buffer as well. :-) > JMarc One of the goals of this work is to simply the creation of new backends. It would be cool if LyX was able to produce its own man page without any external help. The same applies to html and xhtml + mathml. -- José Abílio LyX and docbook, a perfect match. :-)
Re: API for backends unification
Angus Leeming <[EMAIL PROTECTED]> writes: | Good! Especially the getting rid of 'nice'. Could you see if you can | can constify the non-const buffer member functions that alter 'nice' | too. Maybe in a separate iteration of course... > | You should rename LatexRunParams though. ExportParams? you could call it export... I feel output is closer. YMMV | And it really seems like parargraph_funcs.C is getting too big... Yes. -- Lgb
Re: API for backends unification
On Friday 31 October 2003 16:35, Angus Leeming wrote: > Jose' Matos wrote: > > > Comments? > > Good! Especially the getting rid of 'nice'. Could you see if you can > can constify the non-const buffer member functions that alter 'nice' > too. Maybe in a separate iteration of course... After this patch commit that is one of my next objectives. > You should rename LatexRunParams though. ExportParams? Jean-Marc what do you think? And now that we are discussing name is ascii acurate? Shouldn't it be text? > And it really seems like parargraph_funcs.C is getting too big... Agreed and I intend to move some of the paragraph functions to there: simpleTeXOnePar [other latex related functions] simpleLinuxDocOnePar simpleDocBookOnePar Then I have two possibilities: * move them to a single place: output_funcs.[Ch] * create one for each backend: output_latex.[Ch] output_text.[Ch] output_linuxdoc.[Ch] output_docbook.[Ch] -- José Abílio LyX and docbook, a perfect match. :-)
Re: API for backends unification
Jose' Matos wrote: > One of the goals of this work is to simply the > creation of new backends. It would be cool if LyX was > able to produce its own man page without any external > help. The same applies to html and xhtml + mathml. Hmmm. I thought that one of the goals of an LyX xml file format was to be able to move all these manipulators out of LyX and into stand-alone programs lyx2latex, lyx2ascii, lyx2xhtml, lyx2man etc, etc, etc. -- Angus
Re: API for backends unification
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: >> You should rename LatexRunParams though. ExportParams? Jose'> Jean-Marc what do you think? This is fine, as is OutputParams Jose'> And now that we are discussing name is ascii acurate? Jose'> Shouldn't it be text? Yes, text or plaintext would be better. JMarc
Re: API for backends unification
Jose' Matos wrote: > * create one for each backend: > output_latex.[Ch] > output_text.[Ch] > output_linuxdoc.[Ch] > output_docbook.[Ch] Yes please. -- Angus
Re: API for backends unification
On Friday 31 October 2003 16:59, Angus Leeming wrote: > > Hmmm. I thought that one of the goals of an LyX xml file format was > to be able to move all these manipulators out of LyX and into > stand-alone programs lyx2latex, lyx2ascii, lyx2xhtml, lyx2man etc, > etc, etc. That will be possible, sure, but when? I do not want to put all my eggs in one basket. :-) In this domain the cleaning of the lyx file format is allowing me to create a python library, an evolution of parser_tools.py, able to do something like that. Notice that this is just an idea, in other words "vaporware" ;-). -- José Abílio LyX and docbook, a perfect match. :-)
Re: Stlport+gcc-2.96 builds but does not run
On Thu, Oct 30, 2003 at 04:22:50PM +0100, Jean-Marc Lasgouttes spake thusly: > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > Lars> Ok, try this: > > Lars> remove the rdbuf initialization from debug.C and put it in > Lars> main.C instead: > > This works. Great! I was worried about this. - Martin pgp0.pgp Description: PGP signature
Re: API for backends unification
On Friday 31 October 2003 16:56, Jean-Marc Lasgouttes wrote: > > Jose'> Jean-Marc what do you think? > > This is fine, as is OutputParams Ok, OutputParams it will be. > Jose'> And now that we are discussing name is ascii acurate? > Jose'> Shouldn't it be text? > > Yes, text or plaintext would be better. I like plaintex, after it follows the tradition of the other backends: latex = La + TeX linuxdoc = linux + doc docbook = doc + book plaintext = plain + text ;-) > JMarc -- José Abílio LyX and docbook, a perfect match. :-)
[patch] more PosIterator
Not tested througly, but seems to work normally on standard operations.
(note that almost all the + are in the new files...)
Comments please?
BufferView_pimpl.C|2
Makefile.am |2
PosIterator.C | 151 ++
PosIterator.h | 66 ++
buffer.C | 13 +
buffer.h |5
insets/inset.h|4
insets/insetcollapsable.C | 42
insets/insetcollapsable.h | 10
insets/insettabular.C | 101 +
insets/insettabular.h | 10
insets/insettext.C| 76 ---
insets/insettext.h| 12 -
insets/updatableinset.C | 16 -
insets/updatableinset.h |9
iterators.C | 32 +++
iterators.h | 10
lyxfind.C | 476
++
lyxfind.h | 28 --
paragraph.C |8
paragraph.h |2
text.C|2
22 files changed, 520 insertions(+), 557 deletions(-)
? iterators.C-save
? iterators.h-save
? lyxfind.C-save
? lyxrow_funcs.C-bad1
? paragraph.C-bad1
? text.C-bad1
? text.C-good
? text.C-goood
? text3-save.C
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.450
diff -u -p -u -r1.450 BufferView_pimpl.C
--- BufferView_pimpl.C 29 Oct 2003 19:19:21 - 1.450
+++ BufferView_pimpl.C 31 Oct 2003 21:26:33 -
@@ -418,8 +418,6 @@ void BufferView::Pimpl::resizeCurrentBuf
bv_->text->fullRebreak();
update();
} else {
- lyxerr << "text not available!" << endl;
- lyxerr << "no text in cache!" << endl;
bv_->text = new LyXText(bv_, 0, false, bv_->buffer()->paragraphs());
bv_->text->init(bv_);
}
Index: Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/Makefile.am,v
retrieving revision 1.197
diff -u -p -u -r1.197 Makefile.am
--- Makefile.am 29 Oct 2003 10:47:12 - 1.197
+++ Makefile.am 31 Oct 2003 21:26:33 -
@@ -228,6 +228,8 @@ lyx_SOURCES = \
paragraph.h \
paragraph_pimpl.C \
paragraph_pimpl.h \
+ PosIterator.h \
+ PosIterator.C \
SpellBase.h \
ispell.C \
ispell.h \
Index: PosIterator.C
===
RCS file: PosIterator.C
diff -N PosIterator.C
--- /dev/null 1 Jan 1970 00:00:00 -
+++ PosIterator.C 31 Oct 2003 21:26:33 -
@@ -0,0 +1,151 @@
+/* \file PosIterator.C
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+
+#include
+
+#include "PosIterator.h"
+
+#include "buffer.h"
+#include "BufferView.h"
+#include "lyxtext.h"
+
+#include "paragraph.h"
+#include "cursor.h"
+#include "iterators.h"
+
+#include "insets/insettext.h"
+#include "insets/updatableinset.h"
+#include "insets/inset.h"
+
+
+using boost::prior;
+
+PosIterator & PosIterator::operator++()
+{
+ while (!stack_.empty()) {
+ PosIteratorItem & p = stack_.top();
+
+ if (p.pos < p.pit->size()) {
+ InsetOld * inset = p.pit->getInset(p.pos);
+ if (inset) {
+ParagraphList * pl = inset->getParagraphs(p.index);
+if (pl) {
+ p.index++;
+ stack_.push(PosIteratorItem(pl));
+ return *this;
+}
+ }
+ p.index = 0;
+ ++p.pos;
+ } else {
+ ++p.pit;
+ p.pos = 0;
+ }
+
+ if (p.pit != p.pl->end() || stack_.size() == 1)
+ return *this;
+
+ stack_.pop();
+ }
+ return *this;
+}
+
+
+PosIterator & PosIterator::operator--()
+{
+ while (!stack_.empty()) {
+ {
+ PosIteratorItem & p = stack_.top();
+ if (p.pos > 0) {
+--p.pos;
+InsetOld * inset = p.pit->getInset(p.pos);
+if (inset)
+ p.index = inset->numParagraphs();
+ } else {
+if (p.pit == p.pl->begin()) {
+ if (stack_.size() == 1)
+ return *this;
+ stack_.pop();
+ --stack_.top().index;
+} else {
+ --p.pit;
+ p.pos = p.pit->size();
+}
+ }
+ }
+ PosIteratorItem & p = stack_.top();
+ if (p.pos < p.pit->size()) {
+ InsetOld * inset = p.pit->getInset(p.pos);
+ if (inset && p.index > 0) {
+ParagraphList *
+ pl = inset->getParagraphs(p.index - 1);
+BOOST_ASSERT(pl);
+stack_.push(PosIteratorItem(pl, prior(pl->end()), pl->back().size()));
+ }
+ }
+ return *this;
+ }
+ return *this;
+}
+
+
+bool PosIterator::operator!=(PosIterator const & a) const
+{
+ return !operator==(a);
+}
+
+
+
+bool PosIterator::operator==(PosIterator const & a) const
+{
+
+ PosIteratorItem const & pa = a.stack_.top();
+ PosIteratorItem const & p = stack_.top();
+
+ return (pa.pl == p.pl && pa.pit == p.pit &&
+ (p.pit == p.pl->end() || pa.pos == p.pos));
+}
+
+
+bool PosIterator::at_end() const
+{
+ return pos() == pit()->size();
+}
+
+
+PosIterator::PosIterator(ParagraphList * pl, ParagraphList:
Re: InsetOld::hasParagraphs->InsetOld::numParagraphs
Angus Leeming wrote: > Alfredo Braunstein wrote: >> [Btw, it should be super easy to implement regex searches right? It >> [would >> suffice to implement operator* that gives pit->getChar(pos) if pos < >> size and some '\n' if pos == size. In that way one could also search >> for newlines etc. Methink.] > > Great idea. > > ... it would returns 0 if no match is found. Me not understand. Are you still talking about PosIterator::operator*() ? I thought simply that if we can make PosIterator like a normal char iterator in some way, then we can use some standard regex library... (you probably know exactly how and which, I don't) > ... how about it returning META_INSET if you're searching for an > inset of a particular 'flavour'? That's another thing that would be interesting: search for specific insets. One thing that needs to be think of is how the user would specify the inset type. The current implementation of PosIterator goes first to the inset position, then inside it. I don't know if this allows for all desirable complexity on search strings (I don't know if it's so suitable to search for "'foobar' inside a table" for instance. Hum... maybe yes). > Why not produce a rationale description of the differences between > the two, where one is better than the other etc. Seems that Cursor caches the insets and lyxtext on the path. It currently also uses paroffsets that are a bit slower. In any case, if the things I need gets implemented on Cursor, I imagine that we can simply substitute all PosIterator by Cursor and we are rolling... Regards, Alfredo
Re: Stlport+gcc-2.96 builds but does not run
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Thu, Oct 30, 2003 at 04:22:50PM +0100, Jean-Marc Lasgouttes spake thusly: | >> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > >> Lars> Ok, try this: >> >> Lars> remove the rdbuf initialization from debug.C and put it in >> Lars> main.C instead: >> >> This works. > | Great! I was worried about this. I have a patch ready, basically the same as JM provided, but some slight changes. -- Lgb
Re: prosper.layout
On Wed, Oct 29, 2003 at 01:51:14PM +0100, Christian Ridderström wrote: > > Quoting myself: "... Weiss's layout seems to work best at the moment." > > That probably refers to this layout: > http://www.md.kth.se/~chr/lyx/examples/prosper/layouts/prosper-by-Weiss.layout > Aroo? I don't recall making any layout called "prosper". A CU-thesis one, yes. A resume one, yes. The SliTeX-support one, sure. I'll have to take a look at that link... -- John Weiss
Re: prosper.layout
On Wed, Oct 29, 2003 at 08:57:30AM +, Jose' Matos wrote: > On Wednesday 29 October 2003 08:55, Andre Poenitz wrote: > > There is a prosper.layout from Dekel. Is there a specific reason we do > > not distribute this? > > And also another from John Weiss. > Christian some more bits about this soomewhere in the wiki. Oh which layout from me is it of which you speak? -- John Weiss
Re: prosper.layout
On Fri, Oct 31, 2003 at 11:55:48PM -0500, John Weiss wrote: > On Wed, Oct 29, 2003 at 01:51:14PM +0100, Christian Ridderström wrote: > > > > Quoting myself: "... Weiss's layout seems to work best at the moment." > > > > That probably refers to this layout: > > http://www.md.kth.se/~chr/lyx/examples/prosper/layouts/prosper-by-Weiss.layout > > > > Aroo? I don't recall making any layout called "prosper". > > A CU-thesis one, yes. A resume one, yes. The SliTeX-support one, > sure. > > I'll have to take a look at that link... Yup, "prosper.layout" is really a modified version of my old "slides.layout". It should be commented as such. P.S.: Please change all references to my email address from "[EMAIL PROTECTED]" to "[EMAIL PROTECTED]". IDSI's gone out of business. -- John Weiss
