Am Thursday 11 December 2003 22:24 schrieb Georg Baum:
We
could simplify the code if LyX would use the LaTeX names for length
variables and not col% etc.
OTOH the % makes it easy to remove those units (which is necessary in some
cases, cf. qt2/lengthcombo.C:61).
Jürgen, tex2lyx produces a
Kayvan A. Sylvan wrote:
Create a new document.
Insert-Note-LyX Note
put anything in the note.
Save the document.
Quit.
LyX crashes.
A separate problem.
Now, use LyX to open the same document. On the console, you will
see:
InsetCollapsable::Read: Missing 'status'-tag!
Juergen Spitzmueller wrote:
Am Thursday 11 December 2003 22:24 schrieb Georg Baum:
We
could simplify the code if LyX would use the LaTeX names for length
variables and not col% etc.
OTOH the % makes it easy to remove those units (which is necessary
in some cases, cf.
Angus Leeming wrote:
OTOH the % makes it easy to remove those units (which is necessary
in some cases, cf. qt2/lengthcombo.C:61).
It wouldn't be so hard so handle the latex strings either. We just
need to put the code in one place and then re-use it.
You're right, it certainly isn't.
BTW
InsetBranch is now working fully.
I've minimized the BranchList and LColor APIs.
I've overhauled the Branches code in both frontends.
Result: much cleaner code with 120 lines biting the dust.
Patch attached FYI.
--
Angus
branches.diff.bz2
Description: BZip2 compressed data
The branches code enable the user to create a custom color for each
branch. That is, new colors are defined for a particular buffer.
However, these colors are stored in the system-wide lcolors variable.
That's a design flaw.
It seems to me that there are two possible solutions.
1. Add an
On Sat, 13 Dec 2003, Angus Leeming wrote:
Christian Ridderström wrote:
So far it seems clear as crystal, but looking at the enum names and
the strings for the user commands I get confused. Which one is
supposed to define(*) the intended behaviour of the LFUN?
That's clear. LyX acts on
Christian Ridderström wrote:
duh... unless we suddenly entered a world without software bugs, how
can you say that the code defines the intended behaviour?
If you're going to be rude, I'll keep my comments to myself in future.
--
Angus
[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. LFUN_INSET_MINIPAGE should be removed, too.
I
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.
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 users,
On Sun, Dec 14, 2003 at 04:50:42PM +, Angus Leeming spake thusly:
The branches code enable the user to create a custom color for each
branch. That is, new colors are defined for a particular buffer.
However, these colors are stored in the system-wide lcolors variable.
That's a design
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
Martin Vermeer wrote:
The branches code enable the user to create a custom color for each
branch. That is, new colors are defined for a particular buffer.
However, these colors are stored in the system-wide lcolors
variable. That's a design flaw.
It seems to me that there are two possible
On Sun, 14 Dec 2003, Angus Leeming wrote:
Christian Ridderström wrote:
duh... unless we suddenly entered a world without software bugs, how
can you say that the code defines the intended behaviour?
If you're going to be rude, I'll keep my
Hi
After reading a question in the user's list, I thought I'd put page on
lfuns in the wiki (not in the devel-section), so I'd like to get the
spelling correct... what do you say:
LFUN or lfun
minibuffer or mini-buffer
Although this is not important, using a consistent
Am Thursday 11 December 2003 22:24 schrieb Georg Baum:
> We
> could simplify the code if LyX would use the LaTeX names for length
> variables and not "col%" etc.
OTOH the % makes it easy to remove those units (which is necessary in some
cases, cf. qt2/lengthcombo.C:61).
> Jürgen, tex2lyx
Kayvan A. Sylvan wrote:
> Create a new document.
> Insert->Note->LyX Note
> put anything in the note.
> Save the document.
> Quit.
>
> LyX crashes.
A separate problem.
> Now, use LyX to open the same document. On the console, you will
> see:
>
> InsetCollapsable::Read: Missing 'status'-tag!
>
Juergen Spitzmueller wrote:
> Am Thursday 11 December 2003 22:24 schrieb Georg Baum:
>> We
>> could simplify the code if LyX would use the LaTeX names for length
>> variables and not "col%" etc.
>
> OTOH the % makes it easy to remove those units (which is necessary
> in some cases, cf.
Angus Leeming wrote:
> > OTOH the % makes it easy to remove those units (which is necessary
> > in some cases, cf. qt2/lengthcombo.C:61).
>
> It wouldn't be so hard so handle the latex strings either. We just
> need to put the code in one place and then re-use it.
You're right, it certainly
InsetBranch is now working fully.
I've minimized the BranchList and LColor APIs.
I've overhauled the Branches code in both frontends.
Result: much cleaner code with 120 lines biting the dust.
Patch attached FYI.
--
Angus
branches.diff.bz2
Description: BZip2 compressed data
The branches code enable the user to create a custom color for each
branch. That is, new colors are defined for a particular buffer.
However, these colors are stored in the system-wide lcolors variable.
That's a design flaw.
It seems to me that there are two possible solutions.
1. Add an
On Sat, 13 Dec 2003, Angus Leeming wrote:
> Christian Ridderström wrote:
> > So far it seems clear as crystal, but looking at the enum names and
> > the strings for the user commands I get confused. Which one is
> > supposed to "define"(*) the intended behaviour of the LFUN?
>
> That's clear.
Christian Ridderström wrote:
> duh... unless we suddenly entered a world without software bugs, how
> can you say that the code defines the intended behaviour?
>
If you're going to be rude, I'll keep my comments to myself in future.
--
Angus
[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. LFUN_INSET_MINIPAGE should be removed, too.
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.
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
On Sun, Dec 14, 2003 at 04:50:42PM +, Angus Leeming spake thusly:
> The branches code enable the user to create a custom color for each
> branch. That is, new colors are defined for a particular buffer.
> However, these colors are stored in the system-wide lcolors variable.
> That's a
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
Martin Vermeer wrote:
>> The branches code enable the user to create a custom color for each
>> branch. That is, new colors are defined for a particular buffer.
>> However, these colors are stored in the system-wide lcolors
>> variable. That's a design flaw.
>>
>> It seems to me that there are
On Sun, 14 Dec 2003, Angus Leeming wrote:
> Christian Ridderström wrote:
> > duh... unless we suddenly entered a world without software bugs, how
> > can you say that the code defines the intended behaviour?
> >
>
> If you're going to be rude, I'll keep
Hi
After reading a question in the user's list, I thought I'd put page on
lfuns in the wiki (not in the devel-section), so I'd like to get the
"spelling" correct... what do you say:
LFUN or lfun
minibuffer or mini-buffer
Although this is not important, using a consistent
32 matches
Mail list logo
