We are on completely different ground if we start discussion about using XML as
native format. I'm sceptic that your approach would be used, but that was just
IMHO, we use pythonic lyx2lyx creature right now after all. At the moment
there is no one who really works on this goal and as you could
Op 27-12-2012 11:05, Juergen Spitzmueller schreef:
The branch, master, has been updated.
- Log -
commit 258280cecf0cf2e1f31e7f9136165a7dc494192d
Author: Juergen Spitzmueller sp...@lyx.org
Date: Thu Dec 27 11:05:39 2012 +0100
Vincent van Ravesteijn wrote:
I don't know whether it is possible, but is this kind of cases, I would
favor a method: Inset::forceLatexLanguage().
In other words, I don't like testing on specific type of insets. IMO,
the code must be structured such that we could remove the InsetArgument
Jürgen Spitzmüller wrote:
I don't know whether it is possible, but is this kind of cases, I would
favor a method: Inset::forceLatexLanguage().
In other words, I don't like testing on specific type of insets. IMO,
the code must be structured such that we could remove the
Vincent van Ravesteijn wrote:
I also want to round-trip through XML for 3-way diff/merge purposes,
but this is farther into the future. Everyone seems to agree that the
minimal existing diff functionality in LyX sucks,
.. because it gives a too optimal solution. I think I will need to tweak
I have 2 points:
1.) Could we please rename
Category Section
to
Category Section[[structure]]
That way we may translate it e.g. in German to Gliederung instead of
Abschnitt.
2.) The position of categories inside the available styles varies
Am Mittwoch, 26. Dezember 2012 um 14:02:55, schrieb Nico Williams
n...@cryptonector.com
On Dec 26, 2012 5:46 AM, Pavel Sanda sa...@lyx.org wrote:
The problem is that once we ship it under LyX flag officially we are
responsible to fix its bug and maintain it in future. That's why so
much
Kornel Benko wrote:
1.) Could we please rename
Category Section
to
Category Section[[structure]]
That way we may translate it e.g. in German to Gliederung instead
of Abschnitt.
Sectioning strikes me the better English term, and it would
Am Donnerstag, 27. Dezember 2012 um 11:57:08, schrieb Jürgen Spitzmüller
sp...@lyx.org
Jürgen Spitzmüller wrote:
I don't know whether it is possible, but is this kind of cases, I would
favor a method: Inset::forceLatexLanguage().
In other words, I don't like testing on
Am Donnerstag, 27. Dezember 2012 um 13:31:41, schrieb Jürgen Spitzmüller
sp...@lyx.org
Kornel Benko wrote:
1.) Could we please rename
Category Section
to
Category Section[[structure]]
That way we may translate it e.g. in German to
Kornel Benko wrote:
Sectioning strikes me the better English term, and it would solve the
problem.
OK, please.
I'd like to hear the opinon of a native speaker first.
I missed this one. But the sorting here is only alphabetic (in the
translated language) and only inside a category. (My
We already support some form of cross-referencing, but AFAICS this only
works for documents that are included in the same master document.
However, the cross-references dialog box allows to select any other
document.
It looks to me that we either have to disallow to refer to a label in a
Am Donnerstag, 27. Dezember 2012 um 13:49:32, schrieb Jürgen Spitzmüller
sp...@lyx.org
Kornel Benko wrote:
Sectioning strikes me the better English term, and it would solve the
problem.
OK, please.
I'd like to hear the opinon of a native speaker first.
According to LaTeX companion
Am Donnerstag, 27. Dezember 2012 um 13:57:27, schrieb Vincent van Ravesteijn
v...@lyx.org
We already support some form of cross-referencing, but AFAICS this only
works for documents that are included in the same master document.
However, the cross-references dialog box allows to select any
Kornel Benko wrote:
You mean inside some concrete layout-files?
Yes.
I had in mind to define somewhere a category-priority, (may it be in
preferences, or some category-config.layout file) This way there would be
no change to existing layouts. In case of nothing defined, we may stick to
On 12/23/2012 04:16 PM, Jürgen Spitzmüller wrote:
Richard Heck wrote:
Opinions? That would be relatively easy.
Certainly the safest way. Since we do not have any other really urgent fix, I
would probably go for this one.
Jürgen
I agree with Jürgen here.
--
José Matos
Le 26/12/12 13:13, Alessandro Di Federico a écrit :
Our plan is to make the user conference on Monday 13th of May, in the
afternoon. So we could have the dev meeting the previous day, on Sunday
12th of May.
Rough plan:
- Saturday May 11th: everyone arrives in Milan;
- Sunday May 12th: full day
Op 27-12-2012 16:26, Jean-Marc Lasgouttes schreef:
Le 26/12/12 13:13, Alessandro Di Federico a écrit :
Our plan is to make the user conference on Monday 13th of May, in the
afternoon. So we could have the dev meeting the previous day, on Sunday
12th of May.
Rough plan:
- Saturday May 11th:
On Thu, Dec 27, 2012 at 7:49 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
Kornel Benko wrote:
Sectioning strikes me the better English term, and it would solve the
problem.
OK, please.
I'd like to hear the opinon of a native speaker first.
I'd be happy to give my opinion but I don't know
On 12/26/2012 01:03 PM, Nico Williams wrote:
Granted, if I had a faithful XML schema equivalent of .lyx then
version changes could break my XSLs. But I could work around that via
XSLs to deal with version changes, but I think that's quite tolerable
(and no different than LyX's existing .lyx
On 12/27/2012 05:29 AM, Vincent van Ravesteijn wrote:
b) Changing .lyx to be native XML. I think the only way how to
get 100% faithful
and stable/robust conversion.
That might well be nice, but I don't need this and I'm NOT asking for
this, much less offering to implement this.
On 12/27/2012 12:15 PM, Scott Kostyshak wrote:
On Thu, Dec 27, 2012 at 7:49 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
Kornel Benko wrote:
Sectioning strikes me the better English term, and it would solve the
problem.
OK, please.
I'd like to hear the opinon of a native speaker first.
I'd
On Thu, Dec 27, 2012 at 4:29 AM, Vincent van Ravesteijn v...@lyx.org wrote:
I'm not proposing XML as the native format.
In my opinion, there is only a small step between having a faithful .lyx
format and a native LyX format.
But having a faithful XML version of .lyx is only a step in that
On Thu, Dec 27, 2012 at 11:22 AM, Richard Heck rgh...@lyx.org wrote:
On 12/26/2012 01:03 PM, Nico Williams wrote:
Granted, if I had a faithful XML schema equivalent of .lyx then version
changes could break my XSLs. But I could work around that via XSLs to deal
with version changes, but I think
On Thu, 2012-12-27 at 16:26 +0100, Jean-Marc Lasgouttes wrote:
Usually, the developers meetings run for a few days.I think that, if
possible several of us would like to arrive on frdiay or maybe even
thursday. Would that be possible?
No, it shouldn't be a problem, but at this point it's
So the voting seems to be that we should release a 2.0.5.1, with just
the fix for the babel issue. The question now is how, in git, to do this.
It's easy enough to do:
git checkout tags/2.0.5
This puts me in detached head, though, so I need to create a branch if
I want to save anything.
On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck rgh...@lyx.org wrote:
So the voting seems to be that we should release a 2.0.5.1, with just the
fix for the babel issue. The question now is how, in git, to do this.
It's easy enough to do:
git checkout tags/2.0.5
This puts me in detached
On 12/27/2012 03:27 PM, Nico Williams wrote:
On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck rgh...@lyx.org wrote:
So the voting seems to be that we should release a 2.0.5.1, with just the
fix for the babel issue. The question now is how, in git, to do this.
It's easy enough to do:
git
On 12/26/2012 11:56 AM, Jacob Bishop wrote:
Regarding an inquiry by Richard, I am happy to have any contributions
I make be included in LyX. Thus,
I hereby authorize my contributions to LyX to be licensed under GPL
version 2 or later.
Thanks, Jacob. I have added you to the list of
Le 27/12/12 20:44, Alessandro Di Federico a écrit :
On Thu, 2012-12-27 at 16:26 +0100, Jean-Marc Lasgouttes wrote:
Usually, the developers meetings run for a few days.I think that, if
possible several of us would like to arrive on frdiay or maybe even
thursday. Would that be possible?
No, it
Yes, that is what I am trying to achieve, but I was worried that
deleting the 2.0.5.1 branch would invalidate the tag. I guess not? I'm
definitely not a git expert.
Considering this, there is not much difference between a branch and a tag.
git prune will prune all unreachable objects using
On Dec 27, 2012 2:43 PM, Richard Heck rgh...@lyx.org wrote:
On 12/27/2012 03:27 PM, Nico Williams wrote:
On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck rgh...@lyx.org wrote:
So the voting seems to be that we should release a 2.0.5.1, with just
the
fix for the babel issue. The question now is
On Dec 27, 2012 3:07 PM, Vincent van Ravesteijn v...@lyx.org wrote:
You can correct almost everything with git. Just don't push a wrong tag,
...
Right, because deleting a branch or tag, or making a branch name refer to a
completely different line of commits (e.g., rebase) are destructive
Great. Thanks. I hope to be able to continue to contribute, even if it's
just a little bit now and then.
Jacob
We are on completely different ground if we start discussion about using XML as
native format. I'm sceptic that your approach would be used, but that was just
IMHO, we use pythonic lyx2lyx creature right now after all. At the moment
there is no one who really works on this goal and as you could
Op 27-12-2012 11:05, Juergen Spitzmueller schreef:
The branch, master, has been updated.
- Log -
commit 258280cecf0cf2e1f31e7f9136165a7dc494192d
Author: Juergen Spitzmueller
Date: Thu Dec 27 11:05:39 2012 +0100
Vincent van Ravesteijn wrote:
> I don't know whether it is possible, but is this kind of cases, I would
> favor a method: "Inset::forceLatexLanguage()".
>
> In other words, I don't like testing on specific type of insets. IMO,
> the code must be structured such that we could remove the
Jürgen Spitzmüller wrote:
> > I don't know whether it is possible, but is this kind of cases, I would
> > favor a method: "Inset::forceLatexLanguage()".
> >
> >
> >
> > In other words, I don't like testing on specific type of insets. IMO,
> > the code must be structured such that we could
Vincent van Ravesteijn wrote:
>> I also want to round-trip through XML for 3-way diff/merge purposes,
>> but this is farther into the future. Everyone seems to agree that the
>> minimal existing diff functionality in LyX sucks,
>
> .. because it gives a too optimal solution. I think I will need
I have 2 points:
1.) Could we please rename
Category Section
to
Category Section[[structure]]
That way we may translate it e.g. in German to "Gliederung" instead of
"Abschnitt".
2.) The position of categories inside the available styles varies
Am Mittwoch, 26. Dezember 2012 um 14:02:55, schrieb Nico Williams
> On Dec 26, 2012 5:46 AM, "Pavel Sanda" wrote:
> > The problem is that once we ship it under LyX flag officially we are
> > responsible to fix its bug and maintain it in future. That's why
Kornel Benko wrote:
> 1.) Could we please rename
> Category Section
> to
> Category Section[[structure]]
>
> That way we may translate it e.g. in German to "Gliederung" instead
> of "Abschnitt".
"Sectioning" strikes me the better English term, and
Am Donnerstag, 27. Dezember 2012 um 11:57:08, schrieb Jürgen Spitzmüller
> Jürgen Spitzmüller wrote:
> > > I don't know whether it is possible, but is this kind of cases, I would
> > > favor a method: "Inset::forceLatexLanguage()".
> > >
> > >
> > >
> > > In other words, I
Am Donnerstag, 27. Dezember 2012 um 13:31:41, schrieb Jürgen Spitzmüller
> Kornel Benko wrote:
> > 1.) Could we please rename
> > Category Section
> > to
> > Category Section[[structure]]
> >
> > That way we may translate it e.g. in
Kornel Benko wrote:
> > "Sectioning" strikes me the better English term, and it would solve the
> > problem.
>
> OK, please.
I'd like to hear the opinon of a native speaker first.
> I missed this one. But the sorting here is only alphabetic (in the
> translated language) and only inside a
We already support some form of cross-referencing, but AFAICS this only
works for documents that are included in the same master document.
However, the cross-references dialog box allows to select any other
document.
It looks to me that we either have to disallow to refer to a label in a
Am Donnerstag, 27. Dezember 2012 um 13:49:32, schrieb Jürgen Spitzmüller
> Kornel Benko wrote:
> > > "Sectioning" strikes me the better English term, and it would solve the
> > > problem.
> >
> > OK, please.
>
> I'd like to hear the opinon of a native speaker first.
According
Am Donnerstag, 27. Dezember 2012 um 13:57:27, schrieb Vincent van Ravesteijn
> We already support some form of cross-referencing, but AFAICS this only
> works for documents that are included in the same master document.
> However, the cross-references dialog box allows to select
Kornel Benko wrote:
> You mean inside some concrete layout-files?
Yes.
> I had in mind to define somewhere a category-priority, (may it be in
> preferences, or some category-config.layout file) This way there would be
> no change to existing layouts. In case of nothing defined, we may stick to
>
On 12/23/2012 04:16 PM, Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>> > Opinions? That would be relatively easy.
> Certainly the safest way. Since we do not have any other really urgent fix, I
> would probably go for this one.
>
> Jürgen
I agree with Jürgen here.
--
José Matos
Le 26/12/12 13:13, Alessandro Di Federico a écrit :
Our plan is to make the user conference on Monday 13th of May, in the
afternoon. So we could have the dev meeting the previous day, on Sunday
12th of May.
Rough plan:
- Saturday May 11th: everyone arrives in Milan;
- Sunday May 12th: full day
Op 27-12-2012 16:26, Jean-Marc Lasgouttes schreef:
Le 26/12/12 13:13, Alessandro Di Federico a écrit :
Our plan is to make the user conference on Monday 13th of May, in the
afternoon. So we could have the dev meeting the previous day, on Sunday
12th of May.
Rough plan:
- Saturday May 11th:
On Thu, Dec 27, 2012 at 7:49 AM, Jürgen Spitzmüller wrote:
> Kornel Benko wrote:
>> > "Sectioning" strikes me the better English term, and it would solve the
>> > problem.
>>
>> OK, please.
>
> I'd like to hear the opinon of a native speaker first.
I'd be happy to give my opinion
On 12/26/2012 01:03 PM, Nico Williams wrote:
Granted, if I had a faithful XML schema equivalent of .lyx then
version changes could break my XSLs. But I could work around that via
XSLs to deal with version changes, but I think that's quite tolerable
(and no different than LyX's existing .lyx
On 12/27/2012 05:29 AM, Vincent van Ravesteijn wrote:
b) Changing .lyx to be native XML. I think the only way how to
get 100% faithful
and stable/robust conversion.
That might well be nice, but I don't need this and I'm NOT asking for
this, much less offering to implement this.
On 12/27/2012 12:15 PM, Scott Kostyshak wrote:
On Thu, Dec 27, 2012 at 7:49 AM, Jürgen Spitzmüller wrote:
Kornel Benko wrote:
"Sectioning" strikes me the better English term, and it would solve the
problem.
OK, please.
I'd like to hear the opinon of a native speaker first.
On Thu, Dec 27, 2012 at 4:29 AM, Vincent van Ravesteijn wrote:
>> I'm not proposing XML as the native format.
>
> In my opinion, there is only a small step between having a "faithful .lyx
> format" and a "native LyX format".
But having a faithful XML version of .lyx is only a step
On Thu, Dec 27, 2012 at 11:22 AM, Richard Heck wrote:
> On 12/26/2012 01:03 PM, Nico Williams wrote:
>> Granted, if I had a faithful XML schema equivalent of .lyx then version
>> changes could break my XSLs. But I could work around that via XSLs to deal
>> with version changes,
On Thu, 2012-12-27 at 16:26 +0100, Jean-Marc Lasgouttes wrote:
> Usually, the developers meetings run for a few days.I think that, if
> possible several of us would like to arrive on frdiay or maybe even
> thursday. Would that be possible?
No, it shouldn't be a problem, but at this point it's
So the voting seems to be that we should release a 2.0.5.1, with just
the fix for the babel issue. The question now is how, in git, to do this.
It's easy enough to do:
git checkout tags/2.0.5
This puts me in "detached head", though, so I need to create a branch if
I want to save
On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck wrote:
> So the voting seems to be that we should release a 2.0.5.1, with just the
> fix for the babel issue. The question now is how, in git, to do this.
>
> It's easy enough to do:
> git checkout tags/2.0.5
> This puts me in
On 12/27/2012 03:27 PM, Nico Williams wrote:
On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck wrote:
So the voting seems to be that we should release a 2.0.5.1, with just the
fix for the babel issue. The question now is how, in git, to do this.
It's easy enough to do:
git
On 12/26/2012 11:56 AM, Jacob Bishop wrote:
Regarding an inquiry by Richard, I am happy to have any contributions
I make be included in LyX. Thus,
I hereby authorize my contributions to LyX to be licensed under GPL
version 2 or later.
Thanks, Jacob. I have added you to the list of
Le 27/12/12 20:44, Alessandro Di Federico a écrit :
On Thu, 2012-12-27 at 16:26 +0100, Jean-Marc Lasgouttes wrote:
Usually, the developers meetings run for a few days.I think that, if
possible several of us would like to arrive on frdiay or maybe even
thursday. Would that be possible?
No, it
Yes, that is what I am trying to achieve, but I was worried that
deleting the 2.0.5.1 branch would invalidate the tag. I guess not? I'm
definitely not a git expert.
Considering this, there is not much difference between a branch and a tag.
"git prune" will prune all unreachable objects using
On Dec 27, 2012 2:43 PM, "Richard Heck" wrote:
>
> On 12/27/2012 03:27 PM, Nico Williams wrote:
>>
>> On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck wrote:
>>>
>>> So the voting seems to be that we should release a 2.0.5.1, with just
the
>>> fix for the babel
On Dec 27, 2012 3:07 PM, "Vincent van Ravesteijn" wrote:
> You can correct almost everything with git. Just don't push a wrong tag,
...
Right, because deleting a branch or tag, or making a branch name refer to a
completely different line of commits (e.g., rebase) are destructive
Great. Thanks. I hope to be able to continue to contribute, even if it's
just a little bit now and then.
Jacob
68 matches
Mail list logo