Dear all,
Trac is one of the hosted apps of sf.net so it took only a few mouse
clicks to install it. It is available now at
http://apps.sourceforge.net/trac/lyx/ , browse source already works.
I checked sf.net help and issue tracker. There is no simple way to
import bugzilla entries to sourcefor
Dear all,
http://lyx.sourceforge.net is up and running. I just changed one line
in farmconfig.php and added a .htaccess file. The content has not been
updated.
Although there are ssh access to user webspace, there is only sftp and
rsync access to project webspace. This makes it difficult to use
s
Jürgen Spitzmüller wrote:
Vincent van Ravesteijn - TNW wrote:
I'm a bit sceptical that someone did the effort to write a FIXME and to
change updateLabels according to this, just not to implement a for-loop of
one line of code. Why ? Maybe we miss something and we introduce another
bug.
Jürgen Spitzmüller wrote:
Richard Heck wrote:
My own sense is that both of these things need doing. Unless buffer_
gets set as soon as possible, there's always the chance that something
somewhere will trigger a crash.
the question is whether your solution is sufficient for now, or whet
Vincent van Ravesteijn - TNW wrote:
If this does the job for others, then someone can commit. I won't have
time until late tonight.
I have backported it to branch, and I can commit. I'd like to hear Vincent's
opinion first, though, since his approach (removing updateMacro calls) was
José Matos wrote:
On Friday 06 March 2009 13:57:34 Guenter Milde wrote:
But it really is:
like a footnote, the float definition can be inside a
paragraph while the output is moved to a different place by the tex
engine.
You can even see the difference:
* when you put the float inset i
On Sat, 7 Mar 2009, Pavel Sanda wrote:
does it help when your remove your ~/.lyx directory ?
LyX opens to the introductory document. When I open one of mine, the [Del]
key works as it should. I'm attaching my bind file (modified from the
emacs.bind); perhaps I messed it up inadvertently with
Rich Shepard wrote:
> Below is the information I sent to Juergen early this morning with the
> results of running 'lyx -dbg 4'. I hope you smart folks can figure out what
> broke and provide a fix. I, of course, will test anything you send my way.
does it help when your remove your ~/.lyx direct
On 2009-03-06, José Matos wrote:
> On Friday 06 March 2009 13:57:34 Guenter Milde wrote:
>> like a footnote, the float definition can be inside a
>> paragraph while the output is moved to a different place by the tex
>> engine.
>> You can even see the difference:
>> * when you put the float i
This is exactly what I would like to implement. Very similar to the way which
Semantik (which was KDissert) works. Once the data container is worked out, it
should be relatively easy to implement additional views. It is merely a visual
representation of the same data.
My biggest questions of
Juergen asked me to subscribe to this mail list and pass on to all of you
a strange (and new with 1.6.1) problem with the [Del] key. This is on
Slackware-12.2.
Despite \bind "Delete" being defined as 'char-delete-forward' in site.bind
and ~/.lyx/bind/my.bind, it's not working. When I press th
On Friday 06 March 2009 13:57:34 Guenter Milde wrote:
> But it really is:
>
> like a footnote, the float definition can be inside a
> paragraph while the output is moved to a different place by the tex
> engine.
>
> You can even see the difference:
>
> * when you put the float inset into its o
Ideally, the tool for organizing one's ideas before and during writing,
would enable the user to choose between an outline mode and a mind map
mode. Mind mapping tools such as xmind allow you to drag and drop your
various topics/concepts in order to modify their order and hierarchy on
the fly.
On Fri, Mar 06, 2009 at 06:52:41PM +0100, Pavel Sanda wrote:
> Andre Poenitz wrote:
> > the same way as LyX svn trunk is currently treated. You can push your
> > work pretty much in the same chunks as you would today.
>
> but the flamed point was not about _pushing_. rather it was about commit
> i
> I don't think this would be a good idea for a stable release.
>
> It is already postponed :-(
How about we decide, right now, to switch to sf.net? The subversion
repository will be ready in a few hours (it is at revision 13425 now)
and it should be a simple 'svn switch' to switch your local copy
Vincent van Ravesteijn - TNW wrote:
> Well, both should be fixed, the logic in updateLabels is bypassed by this
> call to updateMacros in setParent.
The question is: what is needed for 1.6.2? Richard's patch fixes the crash for
me, and this is all we need currently (if it does not introduce other
Bo Peng wrote:
> It was just a reminder that, if we eventually decide to migrate to sf,
> and there is no simple way to migrate new revisions, you will have to
> manually re-commit your patches.
I don't think this would be a good idea for a stable release.
> Actually, given the dire situation of
On Fri, Mar 6, 2009 at 11:47 AM, Jürgen Spitzmüller
wrote:
> Bo Peng wrote:
>> It would be easier for the final
>> migration if you guys can refrain from committing small patches for a
>> while. You **might** need to re-commit to the sf repository later.
>
> Well, if it turns out our show stopper
>> If this does the job for others, then someone can commit. I won't have
>> time until late tonight.
>
>I have backported it to branch, and I can commit. I'd like to hear Vincent's
>opinion first, though, since his approach (removing updateMacro calls) was
>quite different.
Well, both should b
Richard Heck wrote:
> My own sense is that both of these things need doing. Unless buffer_
> gets set as soon as possible, there's always the chance that something
> somewhere will trigger a crash.
the question is whether your solution is sufficient for now, or whether we
need additional work to
Andre Poenitz wrote:
> On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote:
> > > Not quite true. In a git world, a bug fixing would _always_ happen in a
> > > specific branch and be merged to the main repo when it's done;
> >
> > This is not that useful if we keep the one developer - one feat
Jürgen Spitzmüller wrote:
I have backported it to branch, and I can commit. I'd like to hear Vincent's
opinion first, though, since his approach (removing updateMacro calls) was
quite different.
My own sense is that both of these things need doing. Unless buffer_
gets set as soon as possib
Bo Peng wrote:
> It would be easier for the final
> migration if you guys can refrain from committing small patches for a
> while. You **might** need to re-commit to the sf repository later.
Well, if it turns out our show stopper bug gets fixed, I will need to set up
1.6.2 tomorrow. This means I
Richard Heck wrote:
> The attached patch (against trunk) fixes the bug for me. It just does
> what the FIXME said needed doing anyway.
Excellent. It works for me as well.
> If this does the job for others, then someone can commit. I won't have time
> until late tonight.
I have backported it to
On Fri, Mar 06, 2009 at 07:29:54AM -0600, Bo Peng wrote:
> > Not quite true. In a git world, a bug fixing would _always_ happen in a
> > specific branch and be merged to the main repo when it's done;
>
> This is not that useful if we keep the one developer - one feature
> developing model. Right n
The attached patch (against trunk) fixes the bug for me. It just does
what the FIXME said needed doing anyway. If this does the job for
others, then someone can commit. I won't have time until late tonight.
It seems clear that there's more to be done to clean this stuff up, but
perhaps this
Am 06.03.2009 um 16:10 schrieb Pavel Sanda:
Vincent van Ravesteijn - TNW wrote:
Uwe Stöhr wrote:
The mentioned open crash is a special one - only a few users use
branches and child documents together
I do not agree it is a special one.
I won't release 1.6.2 with such a severe bug. The cycl
Jürgen Spitzmüller wrote:
Uwe Stöhr wrote:
The release doesn't make anything worse but LyX in general much more
stable.
I don't take responsibility for a release which _knowingly_ includes a bug
that could destroy other people's work.
If you want LyX 1.6.2 to appear sooner, go ahead
Uwe Stöhr wrote:
> The release doesn't make anything worse but LyX in general much more
> stable.
I don't take responsibility for a release which _knowingly_ includes a bug
that could destroy other people's work.
If you want LyX 1.6.2 to appear sooner, go ahead and help us fix this bug.
Jürgen
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
Anyway, I'll use whatever is decided...
Really? I thought you were an old, lazy and stubborn guy...
Lazy is the operative word. I am not contributing that much, so I cannot
complain. At worst I'll send patches to the lis
> I was hit myself by that bug, and I almost lost a very important document
> _completely_ (btw, in my case, no branch, but a box inset was involved).
I never doubt that this bug is a must fix, but it is also in LyX 1.6.1 and waiting two weeks doesn't
improve anything. When this bug is fixed, Ly
Abdelrazak Younes writes:
>> Anyway, I'll use whatever is decided...
>>
> Really? I thought you were an old, lazy and stubborn guy...
Lazy is the operative word. I am not contributing that much, so I cannot
complain. At worst I'll send patches to the list so that others apply
them :)
JMarc
I am migrating our subversion repository to sourceforge.net
http://lyx.svn.sourceforge.net/viewvc/lyx/
This was meant to be a test migration but I realized that I do not
really want to repeat this process again, which involves 10T of data
and 10+ hours of work (3+ hrs dump, 3+ hrs sftp, still imp
Vincent van Ravesteijn - TNW wrote:
> >Uwe Stöhr wrote:
> >> The mentioned open crash is a special one - only a few users use
> >> branches and child documents together
>
> I do not agree it is a special one.
>
> >I won't release 1.6.2 with such a severe bug. The cycle until 1.6.3 is too
> >lon
Vincent van Ravesteijn - TNW wrote:
> Well, this must be fixed.. pretty soon.. I'm just scared to break anything
> with the updateMacros mechanism...
I can understand that. I looked into it and shuddered. Is anybody there who
actually understands the mechanism and why the calls are needed in all
>Uwe Stöhr wrote:
>> The mentioned open crash is a special one - only a few users use
>> branches and child documents together
I do not agree it is a special one.
>I won't release 1.6.2 with such a severe bug. The cycle until 1.6.3 is too
>long.
I agree, there are no critical bugs anymore to f
Abdelrazak Younes wrote:
>> IMHO, we do not have enough manpower to use the git model.
>>
>
> Well, we are not _forced_ to use only one merging per feature, this can be
> split into logical steps (at the intiative of the developer).
but this split is what makes revision numbers useful. i just
Uwe Stöhr wrote:
> The mentioned open crash is a special one - only a few users use branches
> and child documents together, while the other crashes we fixed affect much
> more people.
I was hit myself by that bug, and I almost lost a very important document
_completely_ (btw, in my case, no bran
On 2009-03-06, Charles de Miramon wrote:
> If I understand the corkboard approach, you start by writing random notes,
> an outline of your ideas, etc... Then you can shuffle it and link it and
> then you start to write your document.
But this can already be done with Branches:
* Put your ideas i
Bo Peng wrote:
Not quite true. In a git world, a bug fixing would _always_ happen in a
specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now, when you work on a feature, all others
are f
Jürgen Spitzmüller wrote:
> There is one outstanding issue which should be fixed, since it potentially
> results in really bad dataloss:
> http://bugzilla.lyx.org/show_bug.cgi?id=5813
>
> Apart from that, we are ready.
>
> Unfortunately, I'm totally blocked by real work, so I cannot look into the
On 2009-03-06, José Matos wrote:
> On Friday 06 March 2009 09:08:37 Guenter Milde wrote:
>> I'd rather like to see the difference made clear.
>> Layouts are "block elements", you cannot have two layouts in one
>> paragraph.
>> Insets are "inline elements" (even if they sometimes contain block
>>
> Not quite true. In a git world, a bug fixing would _always_ happen in a
> specific branch and be merged to the main repo when it's done;
This is not that useful if we keep the one developer - one feature
developing model. Right now, when you work on a feature, all others
are forced to check it o
Jean-Marc Lasgouttes wrote:
Pavel Sanda writes:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and gi
Jean-Marc Lasgouttes wrote:
> From what I understand about git, it is lost in the new world.
yes
pavel
Charles de Miramon writes:
> If I understand the corkboard approach, you start by writing random notes,
> an outline of your ideas, etc... Then you can shuffle it and link it and
> then you start to write your document.
I'll have to read about it, then/
JMatc
Pavel Sanda writes:
> Abdelrazak Younes wrote:
>> As for refering to a svn revision instead of a git branch, this is a
>> different mental model indeed, but not not a loss of function IMHO.
>
> to me this depends on what kind of development model you use and given
> the number of lyx developers
Jean-Marc Lasgouttes wrote:
> rgheck writes:
>
>> Jürgen Spitzmüller wrote:
>>> 2. implement the possibility to add comments to the outliner items.
>>> As Helge wrote, these will need to be stored in the document (as
>>> specific properties). I suppose this would be much easier to
>>> implement
Abdelrazak Younes wrote:
>> to me this depends on what kind of development model you use and given
>> the number of lyx developers and the way we proceed i think the
>> centralized
>> way is the better one.
>>
>
> So the LyX devs are a bunch of old, lazy and stubborn guys?
somehow i fail to fo
Pavel Sanda wrote:
Abdelrazak Younes wrote:
As for refering to a svn revision instead of a git branch, this is a
different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx developers and t
Abdelrazak Younes wrote:
> As for refering to a svn revision instead of a git branch, this is a
> different mental model indeed, but not not a loss of function IMHO.
to me this depends on what kind of development model you use and given
the number of lyx developers and the way we proceed i think
On Friday 06 March 2009 09:08:37 Guenter Milde wrote:
> I'd rather like to see the difference made clear.
>
> Layouts are "block elements", you cannot have two layouts in one
> paragraph.
>
> Insets are "inline elements" (even if they sometimes contain block
> elements.
No they are not. It is not
Jean-Marc Lasgouttes wrote:
lar...@gullik.org (Lars Gullik Bjønnes) writes:
Abdelrazak Younes writes:
| a bit like XML :-)
I clearly remember who helped shoot that one down.
Hmm, I feel a nice Friday thread brewing.
Usual suspects: me or André?
Abdel.
Guenter Milde writes:
> I'd rather like to see the difference made clear.
>
> Layouts are "block elements", you cannot have two layouts in one
> paragraph.
>
> Insets are "inline elements" (even if they sometimes contain block
> elements.
Yes, and HTML shows well this distinction. However, I hav
On 2009-03-06, Abdelrazak Younes wrote:
> Vincent van Ravesteijn wrote:
>> rgheck schreef:
>>> This is the same issue as with InsetOptArg. It shouldn't be an inset.
>>> It's a layout feature.
>>> Richard
>> That's why I would like to see this difference to disappear.
I'd rather like to see the
lar...@gullik.org (Lars Gullik Bjønnes) writes:
> Abdelrazak Younes writes:
> | a bit like XML :-)
>
> I clearly remember who helped shoot that one down.
Hmm, I feel a nice Friday thread brewing.
JMarc
Abdelrazak Younes writes:
| a bit like XML :-)
I clearly remember who helped shoot that one down.
--
Lgb
57 matches
Mail list logo
