On Thu, Dec 31, 2009 at 04:50:33AM +0100, rgh...@lyx.org wrote:
Author: rgheck
Date: Thu Dec 31 04:50:12 2009
New Revision: 32684
URL: http://www.lyx.org/trac/changeset/32684
Log:
Introduce a return value for mathmlize(). We will need this to be able
to defer labels.
I don't really like
An example of a bug entered using this button:
http://www.lyx.org/trac/ticket/6424
It appears that the backtrace shown there is not related to the bug. The
backtrace is different from the one I see when I follow the Keytest
Report link, it is not an assertion as the keyword indicates,
On Thu, Dec 31, 2009 at 7:08 PM, Vincent van Ravesteijn - TNW
v.f.vanraveste...@tudelft.nl wrote:
An example of a bug entered using this button:
http://www.lyx.org/trac/ticket/6424
It appears that the backtrace shown there is not related to the bug. The
backtrace is different from
Le 30/12/2009 23:50, Tommaso Cucinotta a écrit :
With the attached patch, the markDirty() is redirected on the Find WA
itself, which may actually be useless, but at the end a temporary dirty
buffer is ignored. However, other (mutating) LFUNs may instead operate
directly on the document buffer,
Pavel Sanda wrote:
we have to care what locale is set, i.e. when german ui is set we should search
in
german manuals - lfun help-open.
So, we have 2 possibilities:
1) introduce a simple Open All Manuals item in the Help Menu, which
calls help-open with a special argument (e.g., All),
Tommaso Cucinotta wrote:
Pavel Sanda wrote:
we have to care what locale is set, i.e. when german ui is set we should
search in
german manuals - lfun help-open.
So, we have 2 possibilities:
1) introduce a simple Open All Manuals item in the Help Menu, which calls
help-open with a
Author: tommaso
Date: Wed Dec 30 19:40:18 2009
New Revision: 32678
URL: http://www.lyx.org/trac/changeset/32678
Log:
Implemented the Current Buffer Current (Master) Document
scopes in the Advanced Find and Replace feature.
Modified: lyx-devel/trunk/src/frontends/LyXView.h
Author: tommaso
Date: Wed Dec 30 23:21:23 2009
New Revision: 32682
URL: http://www.lyx.org/trac/changeset/32682
Log:
Code cleanup.
Modified: lyx-devel/trunk/src/lyxfind.cpp
===
===
bool next_open_buffer(Buffer * p_buf) {
Author: tommaso
Date: Tue Dec 29 18:21:09 2009
New Revision: 32673
URL: http://www.lyx.org/trac/changeset/32673
Log:
Now, on C-S-f, only the findWA cursor remains visible and blinking,
as it should be (formerly, the replaceWA cursor used to remain
visible but non-blinking).
Modified:
Author: tommaso
Date: Tue Dec 29 18:21:09 2009
New Revision: 32673
URL: http://www.lyx.org/trac/changeset/32673
Log:
Now, on C-S-f, only the findWA cursor remains visible and blinking, as
it should be (formerly, the replaceWA cursor used to remain visible
but
non-blinking).
I find it utterly
On 12/31/2009 12:15 AM, Bo Peng wrote:
Is the file marked read-only?
Yes, but the values should still be populated to the dialogs, right?
At least the figure dialog displays filenames in this case. Or is this
a bug for the figure dialog?
You are right, I think, that the values
Is the file marked read-only?
Yes, but the values should still be populated to the dialogs, right?
At least the figure dialog displays filenames in this case. Or is
this
a bug for the figure dialog?
You are right, I think, that the values should still be there.
For me, they
Is the file marked read-only?
Yes, but the values should still be populated to the dialogs, right?
At least the figure dialog displays filenames in this case. Or is
this
a bug for the figure dialog?
You are right, I think, that the values should still be there.
For me, they
Pavel,
the attached patch enables me to toggle a buffer read-only even when it
is under svn control.
Is it ok with you ?
Vincent
svn-toggle-read-only-bug.patch
Description: svn-toggle-read-only-bug.patch
You are right, I think, that the values should still be there.
No, they are not, you're right.
So when a file is readonly, the desired behavior should be:
1. values are populated to the dialogs, (bug with insetInfo and insetLabel etc)
2. values should be grayed out and cannot be changed (bug
Vincent van Ravesteijn - TNW wrote:
I prefer to use lyx::dispatch(FuncRequest(LFUN_BUFFER_SWITCH,
dest_buffer_-absFileName()));
or isn't that possible ?
I'll try that and, if works, remove the new function.
Maybe it's good to say that we're are stepping
Tommaso Cucinotta wrote:
in my mind, I was distinguishing between a buffer, and a document,
composed of one or more buffers.
On a related note, can anyone tell me whether or not the
Buffer::allRelatives() method is supposed to contain also the buffer
on which it is called ? And, also, whether
On a related note, can anyone tell me whether or not the
Buffer::allRelatives() method is supposed to contain also
the buffer on which it is called ? And, also, whether it
includes cousins ?
Well, have a look at the Buffer::collectRelatives() function:
void Buffer::collectRelatives(BufferSet
On 12/31/2009 05:09 AM, Andre Poenitz wrote:
On Thu, Dec 31, 2009 at 04:50:33AM +0100, rgh...@lyx.org wrote:
Author: rgheck
Date: Thu Dec 31 04:50:12 2009
New Revision: 32684
URL: http://www.lyx.org/trac/changeset/32684
Log:
Introduce a return value for mathmlize(). We will need this to be
AFAIU, from Vincent's comments, perhaps such thing may be
obtained with something like:
p_buffer-masterBuffer()-allRelatives()
No, it does not include grand-children.
Is this a bug ?
Doesn't p_buffer-masterBuffer()-getChildren() do what you want (except
that the master is not included) ?
So when a file is readonly, the desired behavior should be:
1. values are populated to the dialogs,
I fixed this in r32694 in general.
(bug with insetInfo)
I fixed this in r32695.
(and insetLabel etc)
I fixed this in r32696.
2. values should be grayed out and cannot be changed
(bug with
On Thu, Dec 31, 2009 at 10:53:03AM -0500, rgheck wrote:
On 12/31/2009 05:09 AM, Andre Poenitz wrote:
On Thu, Dec 31, 2009 at 04:50:33AM +0100, rgh...@lyx.org wrote:
Author: rgheck
Date: Thu Dec 31 04:50:12 2009
New Revision: 32684
URL: http://www.lyx.org/trac/changeset/32684
Log:
+// The fonts we want to support are listed in lib/symbols
+void InsetMathFont::mathmlize(MathStream os) const
+{
+ // FIXME These are not quite right, because they do not nest
+ // correctly. A proper fix would presumably involve tracking
+ // the fonts already in effect.
+
As said.
rh
Vincent van Ravesteijn - TNW wrote:
This lead me to find the correct fix for bug #6332 in r32687.
So I propose to revert r32673 and to remove some extra lines. Is the
attached patch ok with you ?
yes, it's ok (no stale cursors), you can commit.
T.
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation attempt should give
up with
Tommaso Cucinotta schreef:
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation
On 12/31/2009 01:14 PM, Andre Poenitz wrote:
+// The fonts we want to support are listed in lib/symbols
+void InsetMathFont::mathmlize(MathStream os) const
+{
+ // FIXME These are not quite right, because they do not nest
+ // correctly. A proper fix would presumably involve
On 12/31/2009 02:45 PM, Tommaso Cucinotta wrote:
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]).
The crash comes when we try to access: cur-buffer():
0lyx::DocIterator::bufferDocIterator.h50
1lyx::MathData::detachMacroParametersMathData.cpp479
2lyx::MathData::updateMacrosMathData.cpp417
3lyx::Buffer::updateMacroInstancesBuffer.cpp2663
4
LyX accepts these commands and creates a MathSplit inset, but
compilation fails because mathtools.sty is not loaded via validate.
rh
On Thu, Dec 31, 2009 at 04:50:33AM +0100, rgh...@lyx.org wrote:
> Author: rgheck
> Date: Thu Dec 31 04:50:12 2009
> New Revision: 32684
> URL: http://www.lyx.org/trac/changeset/32684
>
> Log:
> Introduce a return value for mathmlize(). We will need this to be able
> to defer labels.
I don't
> An example of a bug entered using this button:
>http://www.lyx.org/trac/ticket/6424
>
It appears that the backtrace shown there is not related to the bug. The
backtrace is different from the one I see when I follow the "Keytest
Report" link, it is not an assertion as the keyword
On Thu, Dec 31, 2009 at 7:08 PM, Vincent van Ravesteijn - TNW <
v.f.vanraveste...@tudelft.nl> wrote:
> > An example of a bug entered using this button:
> >http://www.lyx.org/trac/ticket/6424
> >
>
> It appears that the backtrace shown there is not related to the bug. The
> backtrace is
Le 30/12/2009 23:50, Tommaso Cucinotta a écrit :
With the attached patch, the markDirty() is redirected on the Find WA
itself, which may actually be useless, but at the end a temporary dirty
buffer is ignored. However, other ("mutating") LFUNs may instead operate
directly on the document buffer,
Pavel Sanda wrote:
we have to care what locale is set, i.e. when german ui is set we should search
in
german manuals - lfun help-open.
So, we have 2 possibilities:
1) introduce a simple "Open All Manuals" item in the Help Menu, which
calls "help-open" with a special argument (e.g., All),
Tommaso Cucinotta wrote:
> Pavel Sanda wrote:
>> we have to care what locale is set, i.e. when german ui is set we should
>> search in
>> german manuals - lfun help-open.
>>
> So, we have 2 possibilities:
>
> 1) introduce a simple "Open All Manuals" item in the Help Menu, which calls
>
>Author: tommaso
>Date: Wed Dec 30 19:40:18 2009
>New Revision: 32678
>URL: http://www.lyx.org/trac/changeset/32678
>
>Log:
>Implemented the "Current Buffer" & "Current (Master) Document"
>scopes in the Advanced Find and Replace feature.
>
>Modified: lyx-devel/trunk/src/frontends/LyXView.h
>Author: tommaso
>Date: Wed Dec 30 23:21:23 2009
>New Revision: 32682
>URL: http://www.lyx.org/trac/changeset/32682
>
>Log:
>Code cleanup.
>
>Modified: lyx-devel/trunk/src/lyxfind.cpp
>===
===
> bool next_open_buffer(Buffer *
>Author: tommaso
>Date: Tue Dec 29 18:21:09 2009
>New Revision: 32673
>URL: http://www.lyx.org/trac/changeset/32673
>
>Log:
>Now, on C-S-f, only the findWA cursor remains visible and blinking,
>as it should be (formerly, the replaceWA cursor used to remain
>visible but non-blinking).
>Modified:
>>Author: tommaso
>>Date: Tue Dec 29 18:21:09 2009
>>New Revision: 32673
>>URL: http://www.lyx.org/trac/changeset/32673
>>
>>Log:
>>Now, on C-S-f, only the findWA cursor remains visible and blinking, as
>>it should be (formerly, the replaceWA cursor used to remain visible
but
>>non-blinking).
On 12/31/2009 12:15 AM, Bo Peng wrote:
Is the file marked read-only?
Yes, but the values should still be populated to the dialogs, right?
At least the figure dialog displays filenames in this case. Or is this
a bug for the figure dialog?
You are right, I think, that the values
>>> Is the file marked read-only?
>>>
>> Yes, but the values should still be populated to the dialogs, right?
>> At least the figure dialog displays filenames in this case. Or is
this
>> a bug for the figure dialog?
>>
>>
>You are right, I think, that the values should still be there.
>>> Is the file marked read-only?
>>>
>> Yes, but the values should still be populated to the dialogs, right?
>> At least the figure dialog displays filenames in this case. Or is
this
>> a bug for the figure dialog?
>>
>>
>You are right, I think, that the values should still be
Pavel,
the attached patch enables me to toggle a buffer read-only even when it
is under svn control.
Is it ok with you ?
Vincent
svn-toggle-read-only-bug.patch
Description: svn-toggle-read-only-bug.patch
>>>
>>You are right, I think, that the values should still be there.
>>
> No, they are not, you're right.
So when a file is readonly, the desired behavior should be:
1. values are populated to the dialogs, (bug with insetInfo and insetLabel etc)
2. values should be grayed out and cannot be
Vincent van Ravesteijn - TNW wrote:
I prefer to use lyx::dispatch(FuncRequest(LFUN_BUFFER_SWITCH,
dest_buffer_->absFileName()));
or isn't that possible ?
I'll try that and, if works, remove the new function.
Maybe it's good to say that we're are stepping
Tommaso Cucinotta wrote:
in my mind, I was distinguishing between a "buffer", and a "document",
composed of one or more buffers.
On a related note, can anyone tell me whether or not the
"Buffer::allRelatives()" method is supposed to contain also the buffer
on which it is called ? And, also,
>On a related note, can anyone tell me whether or not the
>"Buffer::allRelatives()" method is supposed to contain also
>the buffer on which it is called ? And, also, whether it
>includes "cousins" ?
>
Well, have a look at the Buffer::collectRelatives() function:
>void
On 12/31/2009 05:09 AM, Andre Poenitz wrote:
On Thu, Dec 31, 2009 at 04:50:33AM +0100, rgh...@lyx.org wrote:
Author: rgheck
Date: Thu Dec 31 04:50:12 2009
New Revision: 32684
URL: http://www.lyx.org/trac/changeset/32684
Log:
Introduce a return value for mathmlize(). We will need this to be
>AFAIU, from Vincent's comments, perhaps such thing may be
>obtained with something like:
>
> p_buffer->masterBuffer()->allRelatives()
>
No, it does not include grand-children.
Is this a bug ?
Doesn't p_buffer->masterBuffer()->getChildren() do what you want (except
that the master is not
>So when a file is readonly, the desired behavior should be:
>
>1. values are populated to the dialogs,
I fixed this in r32694 in general.
>(bug with insetInfo)
I fixed this in r32695.
> (and insetLabel etc)
I fixed this in r32696.
>2. values should be grayed out and cannot be changed
>(bug
On Thu, Dec 31, 2009 at 10:53:03AM -0500, rgheck wrote:
> On 12/31/2009 05:09 AM, Andre Poenitz wrote:
>> On Thu, Dec 31, 2009 at 04:50:33AM +0100, rgh...@lyx.org wrote:
>>
>>> Author: rgheck
>>> Date: Thu Dec 31 04:50:12 2009
>>> New Revision: 32684
>>> URL:
>
> +// The fonts we want to support are listed in lib/symbols
> +void InsetMathFont::mathmlize(MathStream & os) const
> +{
> + // FIXME These are not quite right, because they do not nest
> + // correctly. A proper fix would presumably involve tracking
> + // the fonts already in
As said.
rh
Vincent van Ravesteijn - TNW wrote:
This lead me to find the correct fix for bug #6332 in r32687.
So I propose to revert r32673 and to remove some extra lines. Is the
attached patch ok with you ?
yes, it's ok (no stale cursors), you can commit.
T.
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation attempt should give
up with
Tommaso Cucinotta schreef:
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation
On 12/31/2009 01:14 PM, Andre Poenitz wrote:
+// The fonts we want to support are listed in lib/symbols
+void InsetMathFont::mathmlize(MathStream& os) const
+{
+ // FIXME These are not quite right, because they do not nest
+ // correctly. A proper fix would presumably involve
On 12/31/2009 02:45 PM, Tommaso Cucinotta wrote:
While traveling, I was thinking to a couple of unusual use-cases:
1) create a.lyx and b.lyx
2) let a.lyx include b.lyx
3) let b.lyx include a.lyx
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]).
The crash comes when we try to access: cur->buffer():
0lyx::DocIterator::bufferDocIterator.h50
1lyx::MathData::detachMacroParametersMathData.cpp479
2lyx::MathData::updateMacrosMathData.cpp417
3lyx::Buffer::updateMacroInstancesBuffer.cpp2663
4
LyX accepts these commands and creates a MathSplit inset, but
compilation fails because mathtools.sty is not loaded via validate.
rh
62 matches
Mail list logo
