On Wednesday 31 March 2004 02:18, Angus Leeming wrote:
> Converting now...
Is that some kind of indirect message to me? ;-)
--
José Abílio
LyX and docbook, a perfect match. :-)
Shalom Aviad,
LyX includes excellent Hebrew support written by Dekel Tsur (who's from
TAU, in fact). See his home page for instructions:
http://www.math.tau.ac.il/~dekelts/lyx/instructions2.html
If you want to use LyX for writing both English and Hebrew documents, you
might benefit from a soluti
Alfredo Braunstein wrote:
> The document scrolled down a bit for some reason (and the scrollbar
> is broken). But the line is there.
Thank you.
>> and the dialog is telling us that "Guideby" is unknown.
>
> THis went in when the PosIterator -> DocIterator switch, 'newlines'
> are not identified
Angus Leeming wrote:
> Load up the user guide. Note that it starts
> The LyX User's Guide
> by the LyX team
>
> Launch the spellchecker.
>
> Whoa. Without touching anything the document now starts
> by the LyX team
THe document scrolled down a bit for some reason (and th
Alfredo Braunstein wrote:
> [I don't know if this is understandable. I could try to explain it
> [better]
It's understandable. Thanks. (So it was my fault after all. Bummer.)
--
Angus
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>>> Incidentally, I've found another crash. Open up the document dialog
>>> and change text class. Start with the familiar ones and apply.
>>> Fine. Move down the list and apply. Keep doing this. Eventually
>>> you'll get an assert.
>
>> Confirmed.
Load up the user guide. Note that it starts
The LyX User's Guide
by the LyX team
Launch the spellchecker.
Whoa. Without touching anything the document now starts
by the LyX team
and the dialog is telling us that "Guideby" is unknown.
What happened to the first line
On Monday 08 March 2004 10:23, Juergen Spitzmueller wrote:
> Remember that
> citing is the most important feature for human scientists. You wouldn't
> take the argument "you can both write formulas with and without AMS, so
> let's decide", would you?
:-) That is _exactly_ why I am writing my "Lin
Janus Sandsgaard wrote:
> I love the idea. Go for it!
> Any idea when it can be implemented in LyX?
It is already in the development series. And there are mutterings that
we should start to think about bringing this (currently very
unstable) thing to the masses.
--
Angus
On Friday 05 March 2004 17:29, Juergen Spitzmueller wrote:
> This patch does not support all jurabib features, namely the citation
> commands \fullcite (cite the whole entry), \foot[full]cite[p|t|alt|alp]
> (wrap citation into a footnote)
If "\foot[full]cite[p|t|alt|alp]" is implemented will I th
On Friday 05 March 2004 17:29, Juergen Spitzmueller wrote:
> But it makes the use of jurabib possible
> in a reasonable way, a big step for LyX from a human scientist's view, IMO.
I fully agree. Representing social science I have been looking for something
like this. I am not sure if there are a
Aviad Heifetz wrote:
> Hello,
Hello, Aviad.
> Does LyX support right-to-left writing, like in Hebrew (assuming the
> fonts are already installed - I'm using Windows XP)
Have a look here:
http://www.math.tau.ac.il/~dekelts/lyx/
--
Angus
Hello,
Does LyX support right-to-left writing, like in Hebrew (assuming the fonts
are already installed - I'm using Windows XP)
Thanks,
Aviad
Andre Poenitz wrote:
> You could have avoided this confusion by e.g. using
>
> DocIterator(inset) as the begin iterator
>
> and
>
> DocIterator(inset, int dummy) as end iterator.
I didn't though that people got used to that convention in such a short life
of DocIterator/InsetIterator... a
Andre Poenitz wrote:
> So why is handling of this lfun not postponed until the right level came
> up?
>
> As far as I can tell there are two cases:
>
> 1. LFUN_TOGGLE is applied to the 'thing to the right'. Should be handled
> in LyXText::dipatch.
>
> 2. LFUN_TOGGLE is applied to an inset the c
Angus Leeming wrote:
> Converting now...
That'll be 'Committing now...'
--
Angus
On Tue, Mar 30, 2004 at 02:08:27PM +0200, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > Angus Leeming wrote:
> >
> >>> Just commit and we solve it later if there is any problem at all ;-)
> >>
> >> Hmmm. Your last commit means that now I don't even enter the loop.
> >
> >
> >
>
On Tue, Mar 30, 2004 at 02:05:31PM -0500, Angus Leeming wrote:
> Alfredo Braunstein wrote:
> > You mean BDCEAF ?
>
> Yes.
>
> > Yes, that would be a way to solve the problem. It shouldn't be too
> > hard methinks. I'll think about it tonight.
>
> Just comfort me. This isn't 'inset locking' is it
On Tue, Mar 30, 2004 at 01:32:43PM -0500, Angus Leeming wrote:
> [A: [B: ] [C: [D: ]] [E: ]] [F: ]
>
> A contains B, C, E.
> C contains D.
> A and F are on the same level.
>
> We want to iterate:
> A B D C E F
... or simply use
for (DocumentIterator it = ...; it; ++it)
i
On Tue, Mar 30, 2004 at 01:32:43PM -0500, Angus Leeming wrote:
> Actually, what we want is to iterate from the 'innermost' inset to the
> 'outermost'. Eg, if this is our structure:
>
> [A: [B: ] [C: [D: ]] [E: ]] [F: ]
>
> A contains B, C, E.
> C contains D.
> A and F are on the same level.
>
>
On Tue, Mar 30, 2004 at 03:12:22PM +0200, Jean-Marc Lasgouttes wrote:
> Andre> Not really. In fact, I'd drop insetAllowed at some point of
> Andre> time and rather 'allow' any kind of inset nesting but
> Andre> render/export 'illegal' combinations in some special way
> Andre> ('Inset type foo not a
On Tue, Mar 30, 2004 at 11:18:42AM -0500, Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
> > Angus Leeming wrote:
> >
> >> However, note the position of the cursor...
> >
> > The following works for me (LyXFunc.C):
>
> Many thanks, Alfredo. Lying in bed last night, I'd got as far working
>
On Tue, Mar 30, 2004 at 01:00:50PM +0200, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > We could add a bool DocumentIterator::contains(inset *) that checks the
> > stack for that particular inset. then
> >
> > + if (cur.contains(&*it))
> > +
Moved over to the Dialog-based scheme. Converting now...
--
Angus
doc.diff.bz2
Description: BZip2 compressed data
Alfredo Braunstein wrote:
>> Incidentally, I've found another crash. Open up the document dialog
>> and change text class. Start with the familiar ones and apply.
>> Fine. Move down the list and apply. Keep doing this. Eventually
>> you'll get an assert.
> Confirmed. It only happends with the clas
Angus Leeming wrote:
>> What about the following?
>
> Nice. Although getOutOf is a little too cute. I'd prefer getOutOfInset
> or even getCursorOutOfInset.
Ok.
> Incidentally, I've found another crash. Open up the document dialog
> and change text class. Start with the familiar ones and apply.
On Mon, Mar 29, 2004 at 06:48:06PM +, Angus Leeming wrote:
> I'm totally befuddled! How do I tell the outside world that the inset
> has handled a given LFUN?
As soon as it has a corresponding 'case:' branch in the dispatch and
does _not_ explicitly call 'undispatched()', it count as 'dispatch
On Mon, Mar 29, 2004 at 10:36:39AM +0200, Alfredo Braunstein wrote:
> >> PS: OT, should I rename iterators.[Ch] to pariterator.[Ch] to make things
> >> more uniform?
> >
> > Sort of. Actually, I am thinking of renaming 'insetiterator' to
> > something not having the 'inset' prefix for two reason:
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> Nonetheless, I'll commit and we can proceed from there.
>
> What about the following?
Nice. Although getOutOf is a little too cute. I'd prefer getOutOfInset
or even getCursorOutOfInset.
Incidentally, I've found another crash. Open up the do
Angus Leeming wrote:
> Nonetheless, I'll commit and we can proceed from there.
What about the following?
Alfredo
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.594
diff -u -p -u
I think that the various ChangeLog entries say it all really.
Committing now.
Angus
* ControlDocument.[Ch]: move all the 'apply' code into the core and
access it by dispatching the appropriate lfuns.
* lfuns.h:
* LyXAction.C: new lfuns LFUN_LANGUAGE_BUFFER, LFUN_TEXTCLASS_APPLY,
LFUN_TEXTCLASS_LO
Jean-Marc Lasgouttes wrote:
> What about removing all traces of the HELP variable in
> lib/Makefile.am?
Sorry, I have no access to cvs until weekend. I'll do it then.
Jürgen.
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>> You mean BDCEAF ?
>
> Yes.
>
>> Yes, that would be a way to solve the problem. It shouldn't be too
>> hard methinks. I'll think about it tonight.
>
> Just comfort me. This isn't 'inset locking' is it?
>
> Shudders.
>
I don't think so... thi
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Sun, Mar 28, 2004 at 08:27:18PM +0200, Alfredo Braunstein
Andre> wrote:
>> This is bunch of unsorted fixes mostly to C&P crashes.
>>
>> + add InsetText::insetAllowed with default to true (the main text
>> is an InsetText). Would
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> I'd just like to remind you of the 3 patches I send to the
Juergen> list recently. It would be nice if someone could review a
Juergen> patch/tell me if the proposed feature is wanted at
Juergen> all/whatever. I'd like to
Alfredo Braunstein wrote:
> You mean BDCEAF ?
Yes.
> Yes, that would be a way to solve the problem. It shouldn't be too
> hard methinks. I'll think about it tonight.
Just comfort me. This isn't 'inset locking' is it?
Shudders.
--
Angus
Angus Leeming wrote:
> Angus Leeming wrote:
>
>> Alfredo Braunstein wrote:
We could add a bool DocumentIterator::contains(inset *) that
checks the stack for that particular inset. then
+ if (cur.contains(&*it))
+
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>>> We could add a bool DocumentIterator::contains(inset *) that
>>> checks the stack for that particular inset. then
>>>
>>> + if (cur.contains(&*it))
>>> + cur.po
Alfredo Braunstein wrote:
>> We could add a bool DocumentIterator::contains(inset *) that checks
>> the stack for that particular inset. then
>>
>> + if (cur.contains(&*it))
>> + cur.pop();
>
> ... and cur.pop is
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>>> Just commit and we solve it later if there is any problem at all ;-)
>>
>> Hmmm. Your last commit means that now I don't even enter the loop.
>
>
>
>> Even changing to the explicit doesn't help:
>>
>> InsetBase & inset = owner->
Alfredo Braunstein wrote:
>>> Just commit and we solve it later if there is any problem at all
>>> ;-)
>>
>> Hmmm. Your last commit means that now I don't even enter the loop.
>>
>> Even changing to the explicit doesn't help:
>>
>> InsetBase & inset = owner->buffer()->inset();
>>
Angus Leeming wrote:
>> Just commit and we solve it later if there is any problem at all ;-)
>
> Hmmm. Your last commit means that now I don't even enter the loop.
> Even changing to the explicit doesn't help:
>
> InsetBase & inset = owner->buffer()->inset();
> InsetIterator
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> Would you like to test (see other mail with code) on your test
>> cases, or are you happy for me to commit?
>
> Just commit and we solve it later if there is any problem at all ;-)
Hmmm. Your last commit means that now I don't even enter the
Angus Leeming wrote:
> Would you like to test (see other mail with code) on your test cases,
> or are you happy for me to commit?
Just commit and we solve it later if there is any problem at all ;-)
Alfredo
Angus Leeming wrote:
> Everything else is unchanged. Could you try and break this?
Put your cursor in a second level inset (for instance in the green branch in
trial.lyx) and then all-insets-togle close.
(not actually tested with your new code because I have to run. If it works,
disregard the wh
Alfredo Braunstein wrote:
>>> Many thanks, Alfredo. Lying in bed last night, I'd got as far
>>> working out what was going on (cursor not being told where to go)
>>> but had no idea about how to handle it. As ever ;-)
>>
>> Actually, it doesn't quite work. We need to check whether the
>> dispatche
Angus Leeming wrote:
> Angus Leeming wrote:
>> Many thanks, Alfredo. Lying in bed last night, I'd got as far
>> working out what was going on (cursor not being told where to go)
>> but had no idea about how to handle it. As ever ;-)
>
> Actually, it doesn't quite work. We need to check whether th
Alfredo Braunstein wrote:
> Hum... there are cases in which this won't work: if the cursor is in
> some deep nesting, InsetIterator will check first the top one and
> the cursor won't be there, and so the cursor will never exit that
> top inset even if it is to be closed.
I have:
InsetIte
Alfredo Braunstein wrote:
> We could add a bool DocumentIterator::contains(inset *) that checks the
> stack for that particular inset. then
>
> + if (cur.contains(&*it))
> + cur.pop();
... and cur.pop is no good
Alfredo Braunstein wrote:
> The following works for me (LyXFunc.C):
>
> case LFUN_ALL_INSETS_TOGGLE: {
> string action;
> string const name = split(argument, action, ' ');
> InsetBase::Code const inset_code =
Angus Leeming wrote:
> Many thanks, Alfredo. Lying in bed last night, I'd got as far
> working out what was going on (cursor not being told where to go)
> but had no idea about how to handle it. As ever ;-)
Actually, it doesn't quite work. We need to check whether the
dispatched() the lfun and we
Andre Poenitz wrote:
>> Please note that the end iterator now is DocumentIterator(inset) or
>> DocumentIteratorEnd(inset), which was the begin() iterator before.
>
> Is there any place where we actually need the end() iterator +
> operator--() combo? The user code is not simpler after your change
> The most recent .NET compiler (7.1) has better standard conformance
> than gcc, according to an extensive test in a recent edition of the C++
> users journal. I believe you can download a non-optimising version with
> the .NET SDK for free on Microsoft's web-site.
>
Last time I tried the .NET fr
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> However, note the position of the cursor...
>
> The following works for me (LyXFunc.C):
Many thanks, Alfredo. Lying in bed last night, I'd got as far working
out what was going on (cursor not being told where to go) but had no
idea about how
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Can you explain why we invoke switchKeyMap if the inset is not a
>> collapable inset?
Andre> Can anybody explain what 'switchKeyMap' is good for at all and
Andre> why we can't simply run it in bv::update() and remove all these
Andre> '
> That's only for commerical Qt, obviously.
>
> Note that I'm currently working on getting a whole crosscompilation setup
> working with Qt enterprise 3.3.0 for windows, so I'll be making some rpms
> with distributable stuff (like updated crossmingw32) and will be willing
to
> compile stuff for any
On Mon, Mar 29, 2004 at 02:14:53PM +, Angus Leeming wrote:
> Angus Leeming wrote:
>
> > LFUN_VIEW_REFRESH perhaps?
> >
> > lv_.view()->redoCurrentBuffer();
> > buffer()->markDirty();
> > lv_.message(_("Document settings applied"));
>
> Actually, I think I'd like to re
On Mon, Mar 29, 2004 at 03:05:02PM +, Angus Leeming wrote:
> I'd like to change the name of this LFUN to LFUN_NEXT_INSET_TOGGLE, so
> that LFUN_INSET_TOGGLE becomes an LFUN handled by the insets and not
> visible to the outside world. Ok?
>
> case LFUN_INSET_TOGGLE:
> c
On Mon, Mar 29, 2004 at 05:20:37PM +0200, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Huh? toggleInset affects only collapsable insets:
>
> Angus> So the RTL stuff is actually applied only when nothing else is
> Angus> changed. It *can't* be
On Mon, Mar 29, 2004 at 03:38:54PM +, Angus Leeming wrote:
> Jean-Marc Lasgouttes wrote:
> > Angus> Can you explain why we invoke switchKeyMap if the inset is
> >>> not Angus> a collapable inset?
> >>>
> >>> It is some obscure RtL support thing. I do not know more about it.
> >
> > Angus> It
On Mon, Mar 29, 2004 at 01:10:58PM +0200, Alfredo Braunstein wrote:
> this patch
>
> 1) makes DocumentIterator (btw, too long name)
Change it to 'DocIterator' then. Would be consitent with the file name,
too.
> store an inset * member. With this we can come back from the
> past-the-last positio
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> right. But we really should fix the locations as well. Angus? Are
>> you listening?
>
| I am.
and ... ;-)
Seriously, we just need to fix place and date.
--
Lgb
Angus Leeming <[EMAIL PROTECTED]> writes:
| No reason other than I thought you wanted all boost changes to go
| through you.
It is more that I need to be aware of them.
--
Lgb
> "spitz" == spitz <[EMAIL PROTECTED]> writes:
spitz> CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel
spitz> Repository: lyx-devel/lib/help/ Changes by:
spitz> [EMAIL PROTECTED] 04/03/29 17:38:28
spitz> Removed files: lyx-devel/lib/help/: Bibtex.hlp Texinfo.hlp
spitz> Log message: re
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, Mar 27, 2004 at 02:01:27PM +0100, Alfredo Braunstein wrote:
>> Angus Leeming wrote:
>>
>> > void InsetFormulaMacro::write(Buffer const &, ostream & os) const
>> > {
>> > os << "FormulaMacro ";
>> > WriteStream wi(os, false, false
Angus Leeming wrote:
> However, note the position of the cursor...
The following works for me (LyXFunc.C):
case LFUN_ALL_INSETS_TOGGLE: {
string action;
string const name = split(argument, action, ' ');
Inset
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> What we expect is that we're left with
>> [Branch:red][Branch:yellow]
>> and indeed we are. Further, if we were to open the yellow branch
>> inset, we'd find that the green one was still open. Perfecto.
>> However, note the position of the cur
Angus Leeming wrote:
> What we expect is that we're left with
> [Branch:red][Branch:yellow]
> and indeed we are. Further, if we were to open the yellow branch
> inset, we'd find that the green one was still open. Perfecto.
> However, note the position of the cursor...
This seems to be that the cu
68 matches
Mail list logo
