> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> Actually, it occurs after inserting something at the end of
Jean-Marc> the inset (inserting sets boundary to true).
Jean-Marc> Try the following patch.
I applied it.
JMarc
Try the following patch.
JMarc
Index: src/ChangeLog
===============
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2285
diff -u -p -r1.2285 ChangeLog
--- src/ChangeLog 20 Sep 2005 08:31:33 - 1.2285
+++ src/ChangeLog 20 Sep 2005 08:42:48 -
@@
[EMAIL PROTECTED] wrote:
Log message:
fix bug 2010 (boundary effects at the end of text insets)
Sorry, I had to reopen bug #2010. New test case:
1. New doc
2. Insert footnote
3. Enter "a" in footnote
4. Press cursor right
=> still inside the footnote
I tested various scenarios and
Georg Baum wrote:
> Jürgen,
>
> you destroyed non-ASCII characters in the Changelog. I would not expect
> that from somebody with umlauts in his name ;-) Can you please repair it?
You know, you start to hate them eventually.
Jürgen
[EMAIL PROTECTED] wrote:
http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ChangeLog?r1=1.2257&r2=1.2258
Jürgen,
you destroyed non-ASCII characters in the Changelog. I would not expect that
from somebody with umlauts in his name ;-) Can you please repair it?
Georg
>>>>> "lasgouttes" == lasgouttes <[EMAIL PROTECTED]> writes:
lasgouttes> CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel
lasgouttes> Repository: lyx-devel/src/ Changes by:
lasgouttes> [EMAIL PROTECTED] 05/07/28 16:36:17
lasgouttes> Modified fil
On Wed, Jul 06, 2005 at 08:56:40AM +, [EMAIL PROTECTED] wrote:
> Log message:
> get your ruler out, John! button insets are centered again [bug 1293]
Ah, gentle mockery ... thanks :)
john
> Jean-Marc Lasgouttes wrote:
> > leeming> Log message: Remove stub code that was actually
> disabling the
> > leeming> lyxsocket.
> >
> > Thanks. Question: why do you need to add with _WIN32? Isn't
> > this something we can test against?
>
> Probably, but let's see if this code compiles with M
Jean-Marc Lasgouttes wrote:
> leeming> Log message: Remove stub code that was actually disabling the
> leeming> lyxsocket.
>
> Thanks. Question: why do you need to add with _WIN32? Isn't
> this something we can test against?
Probably, but let's see if this code compiles with MSVC first. Rob Bear
>>>>> "leeming" == leeming <[EMAIL PROTECTED]> writes:
leeming> CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel
leeming> Repository: lyx-devel/src/ Changes by:
leeming> [EMAIL PROTECTED] 05/06/09 11:04:34
leeming> Modified files: lyx-deve
t; 04/11/17 01:54:18
>
| larsbj> Modified files: lyx-devel/src/: ChangeLog paragraph.h
| larsbj> pariterator.h
>
| larsbj> Log message: fix one ambiguity, and comment out a
| larsbj> un-implemented operator
>
| - bool isInset(lyx::pos_type pos) const { return getChar(pos)
On Fri, Oct 29, 2004 at 12:51:04PM +0300, Martin Vermeer wrote:
> Beautiful piece of work, José. Looks so much cleaner now.
Thanks, :-)
--
José Abílio Matos
LyX and docbook a perfect match. :-)
On Fri, Oct 29, 2004 at 11:00:03AM +0100, Angus Leeming wrote:
>
> Actually, José, I think that you can simplify insetcharstyle.C even
> further:
>
> int InsetCharStyle::linuxdoc(Buffer const & buffer, std::ostream & os,
> OutputParams const & params) const
> {
>
Martin Vermeer wrote:
> Beautiful piece of work, José. Looks so much cleaner now.
> On Thu, 2004-10-28 at 20:10, [EMAIL PROTECTED] wrote:
Actually, José, I think that you can simplify insetcharstyle.C even
further:
int InsetCharStyle::linuxdoc(Buffer const & buffer, std::ostream & os,
Beautiful piece of work, JosÃ. Looks so much cleaner now.
On Thu, 2004-10-28 at 20:10, [EMAIL PROTECTED] wrote:
...
- Martin
--
Martin Vermeer <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Thu, Oct 28, 2004 at 04:29:20PM +0300, Martin Vermeer wrote:
> Hmmm... did you look at the way " is used in the other layout
> files? And have a look at lyxlayout.C and lyxtextclass.C. Should we
> think about unifying this with your use of <> ? Can we (i.e., is <>
> sufficiently general for thi
On Thu, 2004-10-28 at 18:07, [EMAIL PROTECTED] wrote:
> CVSROOT: /usr/local/lyx/cvsroot
> Module name: lyx-devel
> Repository: lyx-devel/src/
> Changes by: [EMAIL PROTECTED] 04/10/28 15:07:45
>
> Modified files:
> lyx-devel/src/: ChangeLog buff
On Thu, 2004-10-28 at 12:53, Josà AbÃlio Oliveira Matos wrote:
> On Thu, Oct 28, 2004 at 09:42:29AM +0300, Martin Vermeer wrote:
> >
> > I don't remember, and I don't seem to have the AGU-Article dtd anymore.
>
> I think that I still have a copy that you sent me. :-)
>
> > Note that also the s
On Thu, Oct 28, 2004 at 09:42:29AM +0300, Martin Vermeer wrote:
>
> I don't remember, and I don't seem to have the AGU-Article dtd anymore.
I think that I still have a copy that you sent me. :-)
> Note that also the sectioning counter names differ from their LaTeX
> names. Are you sure you und
On Wed, 2004-10-27 at 23:20, Josà AbÃlio Oliveira Matos wrote:
> On Tue, Oct 26, 2004 at 10:49:29AM +0300, Martin Vermeer wrote:
> >
> > > Using pseudo code the it would be:
> > >
> > > Is there any label in paragraph?
> > > (Yes) then use it
> > > (No) else include the automatical
On Tue, Oct 26, 2004 at 10:49:29AM +0300, Martin Vermeer wrote:
>
> > Using pseudo code the it would be:
> >
> > Is there any label in paragraph?
> > (Yes) then use it
> > (No) else include the automatically generated.
>
> ...with # substitution if appropriate.
>
> That's p
On Tue, 2004-10-26 at 10:37, Josà AbÃlio Oliveira Matos wrote:
> On Tue, Oct 26, 2004 at 08:36:17AM +0300, Martin Vermeer wrote:
> >
> > As I understand it, the manual label overrides any automatic one. So in
> > this case the previous paragraph would have label para150 and the next
> > para152 (a
On Tue, Oct 26, 2004 at 08:36:17AM +0300, Martin Vermeer wrote:
>
> As I understand it, the manual label overrides any automatic one. So in
> this case the previous paragraph would have label para150 and the next
> para152 (and these change dynamically as you add and remove paragraphs)
> but the l
On Mon, 2004-10-25 at 21:55, Josà AbÃlio Oliveira Matos wrote:
> On Mon, Oct 25, 2004 at 05:15:39PM +0300, Martin Vermeer wrote:
> > >
> > > Then probably the first line inside the if should be instead:
> > >
> > > id += " " + bstyle->latexparam();
> >
> > No no... rather, keep it as it is
On Tue, 2004-10-26 at 01:00, Josà AbÃlio Oliveira Matos wrote:
> On Mon, Oct 25, 2004 at 05:15:39PM +0300, Martin Vermeer wrote:
> >
> > I still feel you're making this too complicated :-)
>
> Mais au contraire, mon cher ami. ;-)
>
> [This started as an simple answer and ended as a rant. Y
On Mon, Oct 25, 2004 at 05:15:39PM +0300, Martin Vermeer wrote:
>
> I still feel you're making this too complicated :-)
Mais au contraire, mon cher ami. ;-)
[This started as an simple answer and ended as a rant. You have been
warned... ;-)]
ids are attributes that are allowed in every ele
On Mon, Oct 25, 2004 at 05:15:39PM +0300, Martin Vermeer wrote:
> >
> > Then probably the first line inside the if should be instead:
> >
> > id += " " + bstyle->latexparam();
>
> No no... rather, keep it as it is, but shift it to inside the second
> if-statement, i.e., one line down.
O
On Mon, 2004-10-25 at 16:39, Josà AbÃlio Oliveira Matos wrote:
> On Mon, Oct 25, 2004 at 04:13:23PM +0300, Martin Vermeer wrote:
> >
> > At least this looks correct now... but can't you (referring to before
> > this proposed patch) just place the counters thingy *inside* the second
> > if-statemen
On Mon, Oct 25, 2004 at 04:13:23PM +0300, Martin Vermeer wrote:
>
> At least this looks correct now... but can't you (referring to before
> this proposed patch) just place the counters thingy *inside* the second
> if-statement? Again, what do I miss?
>
> Like this
>
> if (!bstyle->latexp
On Mon, 2004-10-25 at 15:38, Josà AbÃlio Oliveira Matos wrote:
> On Mon, Oct 25, 2004 at 03:25:50PM +0300, Martin Vermeer wrote:
> >
> > Wrong fix I think.
> >
> > What if style->latexparam() is non-empty, but does not contain a '#'?
> >
> > :-)
>
> I think that we need to agree on a common s
On Mon, Oct 25, 2004 at 03:25:50PM +0300, Martin Vermeer wrote:
>
> Wrong fix I think.
>
> What if style->latexparam() is non-empty, but does not contain a '#'?
>
> :-)
I think that we need to agree on a common syntax for string substitution
and place that on openTag. :-)
Second try, somet
On Mon, 2004-10-25 at 16:20, [EMAIL PROTECTED] wrote:
> CVSROOT: /usr/local/lyx/cvsroot
> Module name: lyx-devel
> Repository: lyx-devel/src/
> Changes by: [EMAIL PROTECTED] 04/10/25 13:20:02
>
> Modified files:
> lyx-devel/src/: ChangeLog output_docboo
On Mon, Oct 25, 2004 at 01:47:09PM +0300, Martin Vermeer wrote:
> >
> > Nothing, I think. I have reordered the code and, probably, before this
> > code chuncks were in different places.
> > As you clearly show this should be merged. Do you want me to do it?
>
> Yes, please.
Done, thanks.
On Mon, 2004-10-25 at 13:28, Josà AbÃlio Oliveira Matos wrote:
> On Mon, Oct 25, 2004 at 01:05:22PM +0300, Martin Vermeer wrote:
> > ma, 2004-10-25 kello 03:35, Josà AbÃlio Oliveira Matos kirjoitti:
> >
> > > Martin the code now should be a lot easier to read, I tried to maintain
> > > all the p
On Mon, Oct 25, 2004 at 01:05:22PM +0300, Martin Vermeer wrote:
> ma, 2004-10-25 kello 03:35, José Abílio Oliveira Matos kirjoitti:
>
> > Martin the code now should be a lot easier to read, I tried to maintain
> > all the previous features for AGU. I think also that we should set some kind
> > o
ma, 2004-10-25 kello 03:35, Josà AbÃlio Oliveira Matos kirjoitti:
> On Sun, Oct 24, 2004 at 01:14:56AM +0100, Josà AbÃlio Oliveira Matos wrote:
> >
> > I hope that Martin and Andreas find the code easier to understand now.
...
> Martin the code now should be a lot easier to read, I tried to
On Sun, Oct 24, 2004 at 01:14:56AM +0100, José Abílio Oliveira Matos wrote:
>
> I hope that Martin and Andreas find the code easier to understand now.
I have fixed the last know bugs for this code, and commited the fixes.
Andreas, I applied the fix to inset index, for that I created a ne
On Sun, Oct 24, 2004 at 02:02:40AM +, [EMAIL PROTECTED] wrote:
>
> Modified files:
> lyx-devel/src/: ChangeLog buffer.C output_docbook.C
> output_docbook.h paragraph.C sgml.C
> lyx-devel/src/insets/: ChangeLog insettext.C
&
Martin Vermeer wrote:
> On Thu, 2004-10-07 at 18:55, Angus Leeming wrote:
>> [EMAIL PROTECTED] wrote:
>> > Log message:
>> > Implement use of babel language in xindy.
>>
>> Incidentally, it would make sense to document use
>> of the $$lang parameter in lyxrc::getDescription
>> which is displayed
On Thu, 2004-10-07 at 18:55, Angus Leeming wrote:
> [EMAIL PROTECTED] wrote:
> > Log message:
> > Implement use of babel language in xindy.
>
> Incidentally, it would make sense to document use of the $$lang parameter
> in lyxrc::getDescription which is displayed in the xforms preferences
> dialog
[EMAIL PROTECTED] wrote:
> Log message:
> Implement use of babel language in xindy.
Incidentally, it would make sense to document use of the $$lang parameter
in lyxrc::getDescription which is displayed in the xforms preferences
dialog when your mouse goes over the 'index command' input widget...
On Tue, Aug 17, 2004 at 09:43:22AM +0100, Angus Leeming wrote:
> > If so: Why does hitting not select the Ok button in
> > the Insert label, inset Index etc dialog?
> > Clicking with mouse works...
>
> I don't know. Which frontend?
xforms.
xforms is broken anyway. It sometimes eats mouse drag
[EMAIL PROTECTED] wrote:
> Modified files:
> lyx-devel/src/: ChangeLog
>
> Log message:
> Forgot this.
>
> Angus, are you listening?
I am now. Been away for the w/e.
> If so: Why does hitting not select the Ok button in
> the Insert label, inset Index etc dialog?
Angus Leeming wrote:
> There doesn't seem to be any reason why operator-> is not const...
It returns a non-const pointer to a member. We could provide both versions,
but let's do it when we need it. (neither of them are strictly required)
> class FontIterator : std::iterator
> {
> LyXFon
[EMAIL PROTECTED] wrote:
> CVSROOT: /usr/local/lyx/cvsroot
> Module name: lyx-devel
> Repository: lyx-devel/src/
> Changes by: [EMAIL PROTECTED] 04/03/01 11:46:59
>
> Modified files:
> lyx-devel/src/: ChangeLog Makefile.am lyxtext.h text.C
> Adde
On Monday 15 December 2003 10:09, Juergen Spitzmueller wrote:
>
> > > In march 2002 (don't know the file format), the units have been renamed
> > > from "c%" to "col%" etc. See:
> > > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/lengthcommon.C.dif
> > >f? r1 =1.2&r2=1.3 I think lyx2lyx does
Angus Leeming wrote:
> Being absolutely serious here:
> why not remove the lyx2lyx conversion of minipages to the box inset
> between formats 223 and 225 and re-apply the patch to today's
> lyx2lyx, updating the file format at the same time.
This sounds like a good plan to me.
Jürgen.
Juergen Spitzmueller wrote:
> For the lfun stuff, we really need another lyx2lyx conversion step.
> lyx2lyx converts minipages to boxes between 223 and 225, but
> unfortunately it was possible to produce a minipage inset via
> minibuffer or tex2lyx in file format 225 (and 226) until my patch
> yes
Jose' Matos: wrote
> > See this testfile from Kornel:
> > http://marc.theaimsgroup.com/?l=lyx-devel&m=107072337127639&w=2
>
> Let us be a little pragmatic. :-)
> How many people are bitten by that? Could we tell those people to change
> the files by hand?
Perhaps. AFAICS it is sufficient to ma
On Monday 15 December 2003 08:46, Juergen Spitzmueller wrote:
>
> For the lfun stuff, we really need another lyx2lyx conversion step. lyx2lyx
> converts minipages to boxes between 223 and 225, but unfortunately it was
> possible to produce a minipage inset via minibuffer or tex2lyx in file
> format
Angus Leeming wrote:
> True enough, but please don't apply this patch until lyx2lyx can
> upgrade older files. Kayvan, for example, uses 1.4.x for his daily
> work and he's already having to work around collapseStatus horkage.
I'll apply the gnome/gtk and MINIPAGE_CODE stuff, since this is really
On Sun, Dec 14, 2003 at 07:08:41PM +0100, Juergen Spitzmueller spake thusly:
> Michael Schmitt wrote:
> > concerning the two changes in factory.C: Does it still make sense to
> > check for minipages? I think they should be handled completely by
> > lyx2lyx scripts. LFUN_INSET_MINIPAGE should be r
Michael Schmitt wrote:
> concerning the two changes in factory.C: Does it still make sense to
> check for minipages? I think they should be handled completely by
> lyx2lyx scripts. LFUN_INSET_MINIPAGE should be removed, too.
Yes, this makes sense (I left "minipage-insert" for convenience of old us
Michael Schmitt wrote:
> [EMAIL PROTECTED] wrote:
>
> > Log message:
> > Minipage is no more (long live the box inset)
>
> Hello,
>
> concerning the two changes in factory.C: Does it still make sense to
> check for minipages? I think they should be handled completely by
> lyx2lyx scripts. LFU
l.C
-src/insets/insetminipage.C
src/insets/insetnote.C
src/insets/insetoptarg.C
src/insets/insetpagebreak.C
Index: src/ChangeLog
===============
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.1752
diff -u -r1.1752 ChangeLog
---
On Thu, Dec 11, 2003 at 12:31:15PM +0100, Michael Schmitt wrote:
> [EMAIL PROTECTED] wrote:
>
> >Modified files:
> > lyx-devel/src/: ChangeLog lyxfunc.C
> >
> >Log message:
> > Enable all inset dialogs to be opened from the command line.
> >
&g
Michael Schmitt wrote:
> Just a short question: Why is one class called "InsetOld"? Does it
> mean that it will be removed eventually?
src/mathed/math_inset.h:class MathInset : public InsetBase {
src/insets/inset.h:class InsetOld : public InsetBase {
Yes. The Math insets all derive from MathInset
[EMAIL PROTECTED] wrote:
Modified files:
lyx-devel/src/: ChangeLog lyxfunc.C
Log message:
Enable all inset dialogs to be opened from the command line.
Just a short question: Why is one class called "InsetOld"? Does it mean
that it will be removed eventually?
Curious, Michael
ed files:
> | lyx-devel/src/: ChangeLog buffer.C buffer.h factory.C
> | lyx-devel/src/graphics/: ChangeLog PreviewLoader.C
> | lyx-devel/src/insets/: ChangeLog insetcite.C insetcite.h
> |
> | Log message:
> | Add a Buffer::fully_loaded member function, returning t
On Wednesday 08 October 2003 4:29 pm, [EMAIL PROTECTED] wrote:
> Log message:
> * lyxtext.h: make the paragraphs_ a pointer instead a ref to make the
> thing assignable.
Do you really need to '#include ' in insettabular.C in order to
setOwner?
In insettext.C I don't see why you are c
On Mon, Oct 06, 2003 at 03:37:11PM +0100, Angus Leeming wrote:
> [EMAIL PROTECTED] wrote:
> > Log message:
> > * metricsinfo.C: initialize LyXFont before changiging attribute.
> > (fixes the 'math in \emph is upright' bug)
>
> André, this strikes me as a rather fragile fix. If you're saying that
[EMAIL PROTECTED] wrote:
> Log message:
> * metricsinfo.C: initialize LyXFont before changiging attribute.
> (fixes the 'math in \emph is upright' bug)
André, this strikes me as a rather fragile fix. If you're saying that
augmentFont actually resets the font, then shouldn't the
font = LyX
On Wednesday 02 April 2003 6:37 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | John, I get this warning:
> |
> | ../../../../src/frontends/xforms/Menubar_pimpl.C: In member function `int
> |Menubar::Pimpl::create_submenu(long unsigned int, XFormsView*, const
> |
On wtorek 01 kwiecień 2003 09:29 am, Angus Leeming wrote:
> Kuba Ober wrote:
> > I guess that for all practical matters it's all about whether one wants
> > to refer to member variables as
> >
> > m_emergencyExit // m_ prepended
> >
> > or as
> >
> > this->emergencyExit
> >
> > I guess getting rid
John Levon <[EMAIL PROTECTED]> writes:
| On Tue, Apr 01, 2003 at 03:34:13PM +0200, Lars Gullik Bj?nnes wrote:
|
| > Right. And with gcc this will be version 3.4.
| >
| > Due this fall or something.
| >
| > Thanks for finding all these nice ansers.
|
| Well, I still didn't see a rationale :)
On Tue, Apr 01, 2003 at 03:34:13PM +0200, Lars Gullik Bj?nnes wrote:
> Right. And with gcc this will be version 3.4.
>
> Due this fall or something.
>
> Thanks for finding all these nice ansers.
Well, I still didn't see a rationale :)
john
Angus Leeming <[EMAIL PROTECTED]> writes:
| Actually, we'd better get used to this because compilers will eventually
| start insisting we do so. Here's the definitive answer posted by "White
| Wolf" on comp.lang.c++:
Right. And with gcc this will be version 3.4.
Due this fall or something.
T
Kuba Ober wrote:
> I guess that for all practical matters it's all about whether one wants to
> refer to member variables as
>
> m_emergencyExit // m_ prepended
>
> or as
>
> this->emergencyExit
>
> I guess getting rid of m_blah pollution (in case of my own code, at least)
> from the class decl
On czwartek 27 marzec 2003 07:00 pm, Angus Leeming wrote:
> On Thursday 27 March 2003 11:55 pm, John Levon wrote:
> > On Thu, Mar 27, 2003 at 11:42:29PM +, Angus Leeming wrote:
> > > template
> > > class B : public T
> > > {
> > > public:
> > > void foo()
> > > {
> > >
On Fri, Mar 28, 2003 at 12:00:06AM +, Angus Leeming wrote:
> Me neither and nor, it would appear do the folks on comp.lang.c++. Point your
> news reader there and have a look at the thread
> Why is "this->member_variable" better code than "member_variable"?
Looked.
So it must be a str
On Thursday 27 March 2003 11:55 pm, John Levon wrote:
> On Thu, Mar 27, 2003 at 11:42:29PM +, Angus Leeming wrote:
> > template
> > class B : public T
> > {
> > public:
> > void foo()
> > {
> > if (emergency_exit)
> > ...
> > }
> > };
> >
> > >
On Thu, Mar 27, 2003 at 11:42:29PM +, Angus Leeming wrote:
> template
> class B : public T
> {
> public:
> void foo()
> {
> if (emergency_exit)
> ...
> }
> };
>
> > And how would "this->" assist in telling the
> > compiler that it is from the
> | > | Are you saying that member variables must now be accessed with an
> | > | explicit "this->" ? Or only those in base classes? Or only those in
> | > | template classes?
> | >
> | > base classes.
> |
> | Templatized base classes though ? Or something. I'd love to see an
> | explanation (and
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Mar 27, 2003 at 10:31:14PM +0100, Lars Gullik Bj?nnes wrote:
|
| > | Are you saying that member variables must now be accessed with an explicit
| > | "this->" ? Or only those in base classes? Or only those in template
| > | classes?
| >
| > base
On Thu, Mar 27, 2003 at 10:31:14PM +0100, Lars Gullik Bj?nnes wrote:
> | Are you saying that member variables must now be accessed with an explicit
> | "this->" ? Or only those in base classes? Or only those in template
> | classes?
>
> base classes.
Templatized base classes though ? Or someth
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > | - if (emergency_exit_) {
| > | + if (this->emergency_exit_) {
| > |
| > | For the love of God, WHY? Lars, the latest and greatest doesn't
| > | necessarily mean that it's right. This is clearly ridiculous.
| >
| >
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > | - if (emergency_exit_) {
| > | + if (this->emergency_exit_) {
| > |
| > | For the love of God, WHY? Lars, the latest and greatest doesn't
| > | necessarily mean that it's right. This is clearly ridiculous.
| >
| >
Lars Gullik Bjønnes wrote:
> | - if (emergency_exit_) {
> | + if (this->emergency_exit_) {
> |
> | For the love of God, WHY? Lars, the latest and greatest doesn't
> | necessarily mean that it's right. This is clearly ridiculous.
>
> According to how the gurus interpret the C++ standard, this
Angus Leeming <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] wrote:
|
| > CVSROOT:/usr/local/lyx/cvsroot
| > Module name:lyx-devel
| > Repository: lyx-devel/src/frontends/controllers/
| > Changes by: [EMAIL PROTECTED] 03/03/27 18:38:24
| >
| > Modif
[EMAIL PROTECTED] wrote:
> CVSROOT: /usr/local/lyx/cvsroot
> Module name: lyx-devel
> Repository: lyx-devel/src/frontends/controllers/
> Changes by: [EMAIL PROTECTED] 03/03/27 18:38:24
>
> Modified files:
> lyx-devel/src/: ChangeLog lyxgluelength.h lyxlength.
On Wed, Mar 12, 2003 at 05:49:56PM +0100, Jean-Marc Lasgouttes wrote:
> What I do not know or use, though is pushToken. How do you use it?
pushToken just pushes back what you received. However, it has code that
will feed the contents out on the next nextToken but using split(blah, '
').
> Basica
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Wed, Mar 12, 2003 at 05:36:37PM +0100, Jean-Marc Lasgouttes
John> wrote: Therefore, whilst it's not particularly clean, my changes
John> do not introduce a new concept to the lyxlex_pimpl code. So
John> unless I've grossly misread thi
On Wed, Mar 12, 2003 at 05:36:37PM +0100, Jean-Marc Lasgouttes wrote:
> John> Therefore, whilst it's not particularly clean, my changes do not
> John> introduce a new concept to the lyxlex_pimpl code. So unless I've
> John> grossly misread this code, you're wrong ...
>
> It may be that I am wrong
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> Therefore, whilst it's not particularly clean, my changes do not
John> introduce a new concept to the lyxlex_pimpl code. So unless I've
John> grossly misread this code, you're wrong ...
It may be that I am wrong indeed. Am I right that
On Wed, Mar 12, 2003 at 11:21:10AM +0100, Jean-Marc Lasgouttes wrote:
> Why is this needed? There is absolutely not requirement in lyxlex that
> tags begin with \.
This is what I had assumed then I saw this :
459 if (c == '\\') { // first char == '\\'
460
On Tue, Mar 11, 2003 at 08:02:27PM +, John Levon wrote:
> > The base concept is that of a "document iterator". A document iterator
>
> So all the hard bits have to be done in one big patch.
Well, there are a quite a few small steps left, i.e. Lars' paragraph
iterators work could and should pr
On Tue, Mar 11, 2003 at 10:22:48AM +0100, Andre Poenitz wrote:
> I'll have a go.
Neat.
> John, you can avoid duplicated work
Oh, I have other things I want to do :)
john
On Tue, Mar 11, 2003 at 10:01:03AM +0100, Andre Poenitz wrote:
> You don't have raw Row * anymore.
>
> The base concept is that of a "document iterator". A document iterator
So all the hard bits have to be done in one big patch.
john
On Tue, Mar 11, 2003 at 10:15:56AM +0100, Andre' Poenitz wrote:
> > The one I'd like to get removed the most is META_HFILL, having that as
> > an inset would be great.
>
> And that's the tricky part to get right on screen, because "there are
> things to the right". Input/Output should be easy...
On Tue, Mar 11, 2003 at 10:17:20AM +0100, Lars Gullik Bjønnes wrote:
> Of course this will be all the metachars _except_ META_INSET...
>
> The one I'd like to get removed the most is META_HFILL, having that as
> an inset would be great.
And that's the tricky part to get right on screen, because "
John Levon <[EMAIL PROTECTED]> writes:
| On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
|
| > | Iteration through the whole doc happens only if the cursor is set bey
| > | mouseclick or similar.
| >
| > Not even then, since we then can find a row close to the click, at in
|
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Process can be repeated with other metachars. If it turns out that lots of
| these inset look similar, we'd try to factor out a common base
| class or even collect them in a single InsetMetaChar. If I think abut it,
| I'd even start with a single InsetMe
John Levon <[EMAIL PROTECTED]> writes:
| > Start with small steps, and put the 'real metachars' in an inset.
Of course this will be all the metachars _except_ META_INSET...
The one I'd like to get removed the most is META_HFILL, having that as
an inset would be great.
--
Lgb
On Tue, Mar 11, 2003 at 09:59:25AM +0100, Alfredo Braunstein wrote:
> > Modulo speed-up tricks, of course. But I'd bet a bottle of beer that
> > iteration through the whole doc is not noticable after a user-invoked
> > mouseclick.
>
> How brave you are. We do this already (I'll bet that more than
On Tue, Mar 11, 2003 at 09:02:37AM +, John Levon wrote:
> On Tue, Mar 11, 2003 at 09:53:13AM +0100, Andre Poenitz wrote:
>
> > > > Start with small steps, and put the 'real metachars' in an inset.
> >
> > We would create insethfill.[Ch] in src/insets, add it to Makefile.am
>
> Oh *that's* w
On Tue, Mar 11, 2003 at 08:52:23AM +, John Levon wrote:
> On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
>
> > | Iteration through the whole doc happens only if the cursor is set bey
> > | mouseclick or similar.
> >
> > Not even then, since we then can find a row close t
Andre Poenitz wrote:
> Modulo speed-up tricks, of course. But I'd bet a bottle of beer that
> iteration through the whole doc is not noticable after a user-invoked
> mouseclick.
How brave you are. We do this already (I'll bet that more than one time). ;)
Alfredo
On Tue, Mar 11, 2003 at 09:53:13AM +0100, Andre Poenitz wrote:
> > > Start with small steps, and put the 'real metachars' in an inset.
>
> We would create insethfill.[Ch] in src/insets, add it to Makefile.am
Oh *that's* what you meant by "real metachars". Sorry. That sounds
relatively possible
On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bjønnes wrote:
> | Iteration through the whole doc happens only if the cursor is set bey
> | mouseclick or similar.
>
> Not even then, since we then can find a row close to the click, at in
> worst case start from the row at top of screen.
Mod
On Tue, Mar 11, 2003 at 08:37:56AM +, John Levon wrote:
> Though lars is right about the current inset stuff commingling data
> and view in a bad way
Hm, I think the situation is currently improving in this area. Rapidly, if
I may add.
> > Start with small steps, and put the 'real metachars
1 - 100 of 177 matches
Mail list logo
