Uwe Stöhr wrote:
> It is not acceptable that this tex2lyx issue
> http://www.lyx.org/trac/ticket/6059
> eventually delays LyX 1.6.4. I therefore reverted now my controversial
> commit in branch and opt for the following solution that was basically
> proposed by Vincent:
1.6.4 is currently delayed
Pavel Sanda wrote:
> > All recent posts: http://wiki.lyx.org/Site/AllRecentChanges
> >
> > * http://wiki.lyx.org/LyX.NewInBranch162 . . . 2009-08-09 14:26 CEST by
> > vfr * http://wiki.lyx.org/LyX.NewInBranch161 . . . 2009-08-09 14:28 CEST
> > by vfr * http://wiki.lyx.org/LyX.NewInBranch . . . 2009
On 08/09/2009 09:41 PM, LyX Ticket Tracker wrote:
#6129: Show paragraph marks / pilcrows
-+--
Reporter: benm | Owner: lasgouttes
Type: enhancement | Status: new
Priority: normal | Mi
It is not acceptable that this tex2lyx issue
http://www.lyx.org/trac/ticket/6059
eventually delays LyX 1.6.4. I therefore reverted now my controversial commit in branch and opt for
the following solution that was basically proposed by Vincent:
- Use JMarc's solution as default.
- When this fail
On 08/09/2009 07:23 PM, Andre Poenitz wrote:
On Sun, Aug 09, 2009 at 11:45:29PM +0200, Vincent van Ravesteijn wrote:
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do this
for all operation that involves a Paragraph or an Inset copy.
2) set the buff
On Sun, Aug 09, 2009 at 11:45:29PM +0200, Vincent van Ravesteijn wrote:
>
>>>
>>> So we have two solutions:
>>> 1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do this
>>> for all operation that involves a Paragraph or an Inset copy.
>>> 2) set the buffer for all paragraphs and inse
Uwe Stöhr schreef:
> You misunderstood my concept. I only remove things that are
definitively
re-added by LyX, see above. Do you have an example where this is not
the
case?
Yes, I did. Thanks for explaining.
Does this mean you are pissed off by ma explanation or do you have an
example?
> You misunderstood my concept. I only remove things that are definitively
re-added by LyX, see above. Do you have an example where this is not the
case?
Yes, I did. Thanks for explaining.
Does this mean you are pissed off by ma explanation or do you have an example?
In case the first one
On 08/09/2009 06:59 PM, Andre Poenitz wrote:
On Sun, Aug 09, 2009 at 06:23:09PM -0400, rgheck wrote:
///
enum EndLabelType {
///
END_LABEL_NO_LABEL,
///
END_LABEL_BOX,
///
END_LABEL_FILLED_BOX,
///
END_LABEL_STATIC,
///
END_LABEL_ENUM_FIRST =
On Sun, Aug 09, 2009 at 04:35:15PM +0800, John McCabe-Dansted wrote:
> On Thu, Aug 6, 2009 at 8:23 PM, rgheck wrote:
> > On 08/04/2009 12:52 PM, John McCabe-Dansted wrote:
> >>
> >> I was thinking: if the LyX citation dialog:
> >> 1) had a link to
> >> - the file specified in the file={:} bibtex
On Sun, Aug 09, 2009 at 06:23:09PM -0400, rgheck wrote:
>
> ///
> enum EndLabelType {
> ///
> END_LABEL_NO_LABEL,
> ///
> END_LABEL_BOX,
> ///
> END_LABEL_FILLED_BOX,
> ///
> END_LABEL_STATIC,
> ///
> END_LABEL_ENUM_FIRST = END_LABEL_NO_LABEL,
> ///
>
On Sun, Aug 09, 2009 at 11:47:27PM +0200, Abdelrazak Younes wrote:
> On 09/08/2009 23:45, Vincent van Ravesteijn wrote:
>>
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do
this for all operation that involves a Paragraph or an Inset c
///
enum EndLabelType {
///
END_LABEL_NO_LABEL,
///
END_LABEL_BOX,
///
END_LABEL_FILLED_BOX,
///
END_LABEL_STATIC,
///
END_LABEL_ENUM_FIRST = END_LABEL_NO_LABEL,
///
END_LABEL_ENUM_LAST = END_LABEL_STATIC
};
What's the point of the last two?
On 09/08/2009 23:26, Abdelrazak Younes wrote:
On 09/08/2009 23:15, Edwin Leuven wrote:
abdel wrote:
But how should we mark those changes? A deletion and an insertion seem heavy to
me
it's better than nothing. if a co-author moves a paragraph i like to see it...
I agree but I would
On 09/08/2009 23:45, Vincent van Ravesteijn wrote:
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do
this for all operation that involves a Paragraph or an Inset copy.
2) set the buffer for all paragraphs and insets in updateLabel() as
this is guara
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do this
for all operation that involves a Paragraph or an Inset copy.
2) set the buffer for all paragraphs and insets in updateLabel() as this
is guaranted to be be called each time each time a new Parag
On Sun, Aug 09, 2009 at 08:59:47PM +0200, Abdelrazak Younes wrote:
> On 09/08/2009 20:50, Vincent van Ravesteijn wrote:
>> Abdelrazak Younes schreef:
>>> On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
> Hi,
>
> There used to be a recursive call to set
On 09/08/2009 23:37, Andre Poenitz wrote:
On Sun, Aug 09, 2009 at 06:19:43PM +0200, you...@lyx.org wrote:
Author: younes Date: Sun Aug 9 18:19:43 2009 New Revision: 30947 URL:
http://www.lyx.org/trac/changeset/30947
Log: Text::Inset(): now returns a reference in order to make clear
that th
On Sun, Aug 09, 2009 at 06:19:43PM +0200, you...@lyx.org wrote:
> Author: younes Date: Sun Aug 9 18:19:43 2009 New Revision: 30947 URL:
> http://www.lyx.org/trac/changeset/30947
>
> Log: Text::Inset(): now returns a reference in order to make clear
> that the owner is mandatory.
One of the thing
On 09/08/2009 23:15, Edwin Leuven wrote:
abdel wrote:
But how should we mark those changes? A deletion and an insertion seem heavy to
me
it's better than nothing. if a co-author moves a paragraph i like to see it...
I agree but I would prefer a button text..."> which will move the
On Sun, Aug 09, 2009 at 05:05:37PM +0200, you...@lyx.org wrote:
> Author: younes Date: Sun Aug 9 17:05:36 2009 New Revision: 30940 URL:
> http://www.lyx.org/trac/changeset/30940
>
> Log: General cleanup: Text is (or should be) nothing more than
> InsetText private implementation. We need access t
abdel wrote:
> But how should we mark those changes? A deletion and an insertion seem heavy
> to me
it's better than nothing. if a co-author moves a paragraph i like to see it...
On 09/08/2009 22:59, Vincent van Ravesteijn wrote:
Pavel Sanda schreef:
Abdelrazak Younes wrote:
On 09/08/2009 22:36, Edwin Leuven wrote:
The two features were developped by two different developpers
(Edwin for
LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about
Vincent van Ravesteijn wrote:
>> note we have LFUN_OUTLINE_DRAGMOVE now, which i suspect to be prone to
>> bugs
>> now, but would be good base for big enhacement - drag & drop inside
>> outliner.
>>
>> pavel
>>
> Yes, I was just wondering wether this function will get some use.
i put it in to
On 08/09/2009 04:25 PM, you...@lyx.org wrote:
Author: younes
Date: Sun Aug 9 22:25:20 2009
New Revision: 30961
URL: http://www.lyx.org/trac/changeset/30961
Log:
outline(): avoid paragraph copying by using RandomAccessList::splice().
Excellent. You can see here exactly the sort of thing we
On 09/08/2009 23:00, rgheck wrote:
On 08/09/2009 03:11 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around
paragraphs witho
On 08/09/2009 03:53 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around
paragraphs without ensuring that a decent buffer is
On 08/09/2009 03:11 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around
paragraphs without ensuring that a decent buffer is
Pavel Sanda schreef:
Abdelrazak Younes wrote:
On 09/08/2009 22:36, Edwin Leuven wrote:
The two features were developped by two different developpers (Edwin for
LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about it on the
list, but in retro
Abdelrazak Younes wrote:
> On 09/08/2009 22:36, Edwin Leuven wrote:
>>> The two features were developped by two different developpers (Edwin for
>>> LFUN_PARAGRAPH_MOVE*
>>>
>>
>> developed is a big word. i think we had some discussion about it on the
>> list, but in retrospect i think i sho
On 09/08/2009 22:36, Edwin Leuven wrote:
The two features were developped by two different developpers (Edwin for
LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about it on the list,
but in retrospect i think i should've used cut and paste. in particular bec
> The two features were developped by two different developpers (Edwin for
> LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about it on the list,
but in retrospect i think i should've used cut and paste. in particular because
now moving paragraphs is ignored by cha
On 09/08/2009 21:57, Vincent van Ravesteijn wrote:
I just fixed LFUN_PARAGRAPH_MOVE_DOWN LFUN_PARAGRAPH_MOVE_UP. Now we
just have to wait for the next one :-)
Abdel.
Can you then also explain me why this is not using the same code as
Text3.cpp:outline(OutlineUp).
The two features were d
On 09/08/2009 22:00, Kornel Benko wrote:
Sorry Abdel, but
No, I am sorry. Will fix it now.
Abdel.
Am Sonntag 09 August 2009 schrieb Vincent van Ravesteijn:
> > I just fixed LFUN_PARAGRAPH_MOVE_DOWN LFUN_PARAGRAPH_MOVE_UP. Now we
> > just have to wait for the next one :-)
> >
> > Abdel.
Sorry Abdel, but
...
In file included from /usr/src/lyx/lyx-devel/src/ParagraphList.h:17,
f
I just fixed LFUN_PARAGRAPH_MOVE_DOWN LFUN_PARAGRAPH_MOVE_UP. Now we
just have to wait for the next one :-)
Abdel.
Can you then also explain me why this is not using the same code as
Text3.cpp:outline(OutlineUp).
Vincent
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only
On 09/08/2009 21:33, Vincent van Ravesteijn wrote:
Nothing. But updateLabels() do a whole lot more than just updating
the labels.
, which indicates that we have been misusing the updateLabels for a
long time.
So, I would rather start cleaning up this mess rather than hiding this
by renaming
Nothing. But updateLabels() do a whole lot more than just updating the
labels.
, which indicates that we have been misusing the updateLabels for a long
time.
So, I would rather start cleaning up this mess rather than hiding this
by renaming the function.
Vincent
On 09/08/2009 21:18, Vincent van Ravesteijn wrote:
And the reason why you decided this?
To repeat myself over and over again. What has setBuffer to do with
labels that need to be updated ?
Nothing. But updateLabels() do a whole lot more than just updating the
labels. So to answer your ques
And the reason why you decided this?
To repeat myself over and over again. What has setBuffer to do with
labels that need to be updated ?
Vincent
Richard Heck wrote:
>> I see. Then someone needs the fix all cases where something is copied.
>>
> That was the intention. I guess we missed a few
i think its the time for John to run his keylogger script
on the new trunk again :)
pavel
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only
On 09/08/2009 21:07, Vincent van Ravesteijn wrote:
There was a large FIXME next to this call that this should be done in
the pasteSelectionHelper,
//FIXME: We should call setBuffer() on each inserted paragraph.
// instead, we call setBuffer() for the main inset at the beginning
// of update
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only at one place. That place would be so
On 08/09/2009 03:00 PM, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been
remov
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only at one place. That place would be somewhere in
CutAndPaste. There is no other reason
There was a large FIXME next to this call that this should be done in
the pasteSelectionHelper,
//FIXME: We should call setBuffer() on each inserted paragraph.
// instead, we call setBuffer() for the main inset at the beginning
// of updateLabels()
IIRC this was your FIXME ;-)
We cam
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of t
On 09/08/2009 20:50, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been
removed?
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of t
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of the buffer absence.
Try LFUN
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of the buffer absence.
Try LFUN_PARAGRAPH_MOVE_UP for example...
Abdel.
The rea
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed? Now
we get crashes with a lot of LFUNs because of the buffer absence. Try
LFUN_PARAGRAPH_MOVE_UP for example...
Abdel.
Pavel Sanda wrote:
> Pavel Sanda wrote:
> > hi,
> >
> > i would like lyx allowing removal of emergency files. i don't agree with
> > automatical removal as suggested in
> > http://bugzilla.lyx.org/show_bug.cgi?id=2120 ,
> > so the following patch implements one more confirmation dialog in case
>
Fixed now, sorry.
On 09/08/2009 18:57, Kornel Benko wrote:
Hi Abdel,
...
In file included from /usr/src/lyx/lyx-devel/src/Paragraph.cpp:45:
/usr/src/lyx/lyx-devel/src/Text.h: In constructor
‘lyx::Text::Text(lyx::InsetText*)’:
/usr/src/lyx/lyx-devel/src/Text.h:355: warning:
‘lyx::Text::autoB
Hi Abdel,
...
In file included from /usr/src/lyx/lyx-devel/src/Paragraph.cpp:45:
/usr/src/lyx/lyx-devel/src/Text.h: In constructor
‘lyx::Text::Text(lyx::InsetText*)’:
/usr/src/lyx/lyx-devel/src/Text.h:355: warning: ‘lyx::Text::autoBreakRows_’
will be initialized after
/usr/src/lyx/lyx-devel/src/
Pavel Sanda wrote:
> > Log:
> > Fix #6120. Selection not set when switching to a different tab.
> > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg153514.html
>
> Juergen?
OK.
Jürgen
sa...@lyx.org wrote:
> Author: sanda
> Date: Sun Aug 9 16:27:50 2009
> New Revision: 30933
> URL: http://www.lyx.org/trac/changeset/30933
>
> Log:
> Fix #6120. Selection not set when switching to a different tab.
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg153514.html
Juergen?
>
>
Vincent van Ravesteijn wrote:
> You were just describing the master/child concept.
Indeed. And that hidden buffers are crucial for this concept (not its current
UI implementation, but the concept).
Jürgen
Pavel Sanda wrote:
> > I forgot to say that I think that the current workaround should go to
> > branch too for now since it doesn't hardcode a certain value:
> > http://www.lyx.org/trac/changeset/30919
>
> +1. Juergen?
I already explained in the thread that I think we need another solution (if
p
Pavel Sanda wrote:
> Abdelrazak Younes wrote:
> >> i'm not sure view() is needed.
> >>
> >
> > It's not, a WorkArea has mandatorily a BufferView.
heh, but == NULL sometimes ;)
> thanks, i'll commit improved version.
> pavel
Am Sonntag 09 August 2009 schrieb Pavel Sanda:
> Abdelrazak Younes wrote:
> >>> but then the
> >>> hidden buffers will be closed automatically if the master is closed.
> >>
> >> but i dont see this. all hidden remain opened after closing master.
> >
> > If you don't see this, it's a bug. At least t
Am Sonntag 09 August 2009 schrieb Abdelrazak Younes:
> On 08/08/2009 19:46, Kornel Benko wrote:
> > But calling
> > Tools->Spellchecker...->Find Next
> > surprisingly moves to the next (identical) unknown word, (not next
> > unknown as I would expect)
>
> Hum, the button you are looking for is "Ign
but i dont see this. all hidden remain opened after closing master.
I see it too, so this is another bug.
ok, but please note that this bug should be closed when we actually have
fixed the problem which is - to rephrase - "using master with many childs
cant be closed easily". cant rememeb
On 09/08/2009 15:50, Abdelrazak Younes wrote:
On 08/08/2009 19:46, Kornel Benko wrote:
I allways get suggestions right-cliking on some misspelled word.
Then I guess you were just using aspell as, up to 1 minute ago,
hunspell suggestion was disabled :-)
I see now that there is a problem with
Abdelrazak Younes wrote:
>> i'm not sure view() is needed.
>>
>
> It's not, a WorkArea has mandatorily a BufferView.
thanks, i'll commit improved version.
pavel
Abdelrazak Younes wrote:
>>> but then the
>>> hidden buffers will be closed automatically if the master is closed.
>>>
>>
>> but i dont see this. all hidden remain opened after closing master.
>>
>
> If you don't see this, it's a bug. At least that how I implemented it a few
> years back
On 09/08/2009 15:52, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
As I stated in another bug, I really don't get the concept of working with
hidden buffers.
The only thing I can imagine is if you have master and childs,
yes thats my usecase
but then the
hidden buffers will
Uwe Stöhr wrote:
> I forgot to say that I think that the current workaround should go to
> branch too for now since it doesn't hardcode a certain value:
> http://www.lyx.org/trac/changeset/30919
+1. Juergen?
>
> regards Uwe
Vincent van Ravesteijn wrote:
> As I stated in another bug, I really don't get the concept of working with
> hidden buffers.
>
> The only thing I can imagine is if you have master and childs,
yes thats my usecase
>but then the
> hidden buffers will be closed automatically if the master is close
On 08/08/2009 19:46, Kornel Benko wrote:
But calling
Tools->Spellchecker...->Find Next
surprisingly moves to the next (identical) unknown word, (not next
unknown as I would expect)
Hum, the button you are looking for is "Ignore". But I agree this ui is
confusing... Maybe "Ignore" should be re
As I stated in another bug, I really don't get the concept of working
with hidden buffers.
My explanations did not help?
No. You were just describing the master/child concept. Or is the
"multi-part document" different from this ?
Also if the master is hidden?
(since my master ba
Vincent van Ravesteijn wrote:
> > As I stated in another bug, I really don't get the concept of working
> > with hidden buffers.
My explanations did not help?
> > The only thing I can imagine is if you have master and childs, but
> > then the hidden buffers will be closed automatically if the mas
Vincent van Ravesteijn schreef:
Pavel Sanda schreef:
v...@lyx.org wrote:
Author: vfr
Date: Fri Aug 7 01:17:16 2009
New Revision: 30882
URL: http://www.lyx.org/trac/changeset/30882
Log:
Fix bug #740: Wish for added menu item: File->Close all.
Vincent, all hidden buffer won't get close
Pavel Sanda schreef:
v...@lyx.org wrote:
Author: vfr
Date: Fri Aug 7 01:17:16 2009
New Revision: 30882
URL: http://www.lyx.org/trac/changeset/30882
Log:
Fix bug #740: Wish for added menu item: File->Close all.
Vincent, all hidden buffer won't get closed ?
the original report says the
v...@lyx.org wrote:
> Author: vfr
> Date: Fri Aug 7 01:17:16 2009
> New Revision: 30882
> URL: http://www.lyx.org/trac/changeset/30882
>
> Log:
> Fix bug #740: Wish for added menu item: File->Close all.
Vincent, all hidden buffer won't get closed ?
the original report says the usage (which is id
Justin Noel wrote:
> I do disagree, although I can't seem to change the status of the
> ticket. The view in mathed is more confusing then doing it in ERT.
> If you run through any example you will see that this workaround is
> not really effective.
it least please discuss the issue there. the vie
Jean-Marc Lasgouttes wrote:
> Pavel Sanda writes:
> > have you killed those components already? (i see outliner add but no
> > component deleted...)
>
> Hell froze over, I have killed some components.
thanks
pavel
Vincent van Ravesteijn wrote:
> > What were they trying to do here ? They know about the problem then if
> > they tinker with this ?
> >
> > Vincent
>
> http://qt.gitorious.org/+openbossa-developers/qt/openbossa-clone/commit/ffb
>b3c1a2aee4134dce80cd144a26bf32865b698?diffmode=sidebyside
This looks
On Thu, Aug 6, 2009 at 8:23 PM, rgheck wrote:
> On 08/04/2009 12:52 PM, John McCabe-Dansted wrote:
>>
>> I was thinking: if the LyX citation dialog:
>> 1) had a link to
>> - the file specified in the file={:} bibtex entry
>> - the url specified in the url={} (or maybe doi) entry
>> - raw bibt
81 matches
Mail list logo
