Vincent van Ravesteijn wrote:
> Vincent van Ravesteijn schreef:
>> This patch will open a list (alike to the completion list) when pressing
>> the upper arrow in the command buffer.
>>
>> Especially in combination with the other patch I sent (remembering the
>> commands for the next session), I f
Vincent van Ravesteijn wrote:
> This patch will open a list (alike to the completion list) when pressing
> the upper arrow in the command buffer.
>
> Especially in combination with the other patch I sent (remembering the
> commands for the next session), I find this very useful.
>
> Objections or
This patch will open a list (alike to the completion list) when pressing
the upper arrow in the command buffer.
Especially in combination with the other patch I sent (remembering the
commands for the next session), I find this very useful.
Objections or ideas ?
Vincent
Jean-Marc Lasgouttes schreef:
I wasn't even talking about updateLabels() (which causes a half
second delay when you break a paragraph etc.).
Half a second delay? On a release build? I thought it was faster...
Maybe is it time to use
this profiler again...
Do you have a precise example?
JMar
LyX is currently listed as THE most popular download on
eeedownload.asus.com!!
rh
Did you check what exactly needs so long in updateMacros? It
essentially just looks at the insets of each paragraph. If there is
no macro definition, nothing is done. Otherwise, the macro table of
the buffer is updated. I don't see why updateMacros needs so much
more time than the updateLab
I wasn't even talking about updateLabels() (which causes a half
second delay when you break a paragraph etc.).
Half a second delay? On a release build? I thought it was faster...
Maybe is it time to use
this profiler again...
Do you have a precise example?
JMarc
Am 17.01.2009 um 22:58 schrieb Andre Poenitz:
On Sat, Jan 17, 2009 at 10:00:57PM +0100, Stefan Schimanski wrote:
Am 17.01.2009 um 20:33 schrieb Andre Poenitz:
On Sat, Jan 17, 2009 at 06:40:05PM +0100, Stefan Schimanski wrote:
Did you check what exactly needs so long in updateMacros? It
ess
Uwe Stöhr schrieb:
The attached patch fixes this.
Now it is attached.
regards Uwe
Index: insets/InsetSpecialChar.cpp
===
--- insets/InsetSpecialChar.cpp (revision 28224)
+++ insets/InsetSpecialChar.cpp (working copy)
@@ -222,7 +2
On Sat, Jan 17, 2009 at 10:00:57PM +0100, Stefan Schimanski wrote:
>
> Am 17.01.2009 um 20:33 schrieb Andre Poenitz:
>
>> On Sat, Jan 17, 2009 at 06:40:05PM +0100, Stefan Schimanski wrote:
>>> Did you check what exactly needs so long in updateMacros? It
>>> essentially
>>> just looks at the inset
The bugfix for http://bugzilla.lyx.org/show_bug.cgi?id=3560 introduces a regression. \...@ifstar is not
fully compatible with hyperref. When you use a menu separator in a section heading, like in the
German UserGuide and create PDF bookmarks, the document becomes uncompilable.
The attached patc
Am 17.01.2009 um 20:33 schrieb Andre Poenitz:
On Sat, Jan 17, 2009 at 06:40:05PM +0100, Stefan Schimanski wrote:
Did you check what exactly needs so long in updateMacros? It
essentially
just looks at the insets of each paragraph.
Which is still a bit.
If there is no macro
definition, not
On Sat, Jan 17, 2009 at 06:40:05PM +0100, Stefan Schimanski wrote:
> Did you check what exactly needs so long in updateMacros? It essentially
> just looks at the insets of each paragraph.
Which is still a bit.
> If there is no macro
> definition, nothing is done. Otherwise, the macro table of t
On 17/01/2009 18:40, Stefan Schimanski wrote:
Did you check what exactly needs so long in updateMacros? It
essentially just looks at the insets of each paragraph. If there is no
macro definition, nothing is done. Otherwise, the macro table of the
buffer is updated. I don't see why updateMacro
Jürgen Spitzmüller wrote:
rgheck wrote:
Jurgen, would you like this one for branch?
In general, I'd very much welcome this. However, we should probably rather
test a bit in trunk before committing. As the recent slowdown due to the
BibTeX parsing demonstrated, this stuff is not as ha
Uwe Stöhr wrote:
BiblioInfo.cpp ist not compilable in trunk:
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2146: syntax error
: missing
')' before identifier 'or'
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2065: 'or' :
undeclared iden
tifier
D:\LyXSVN\lyx-devel\src\BiblioInfo
Vincent van Ravesteijn wrote:
rgheck schreef:
Pavel Sanda wrote:
Richard Heck wrote:
Andre Poenitz wrote:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn
wrote:
For every letter I type in LyX, the updateMacros() function is
called from BufferView::processUpdateF
Am 17.01.2009 um 18:03 schrieb Vincent van Ravesteijn:
Stefan Schimanski schreef:
Am 17.01.2009 um 14:44 schrieb Andre Poenitz:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn
wrote:
For every letter I type in LyX, the updateMacros() function is
called
from BufferView::
On Sat, Jan 17, 2009 at 06:26:18PM +0100, Vincent van Ravesteijn wrote:
> Uwe Stöhr schreef:
>> BiblioInfo.cpp ist not compilable in trunk: [...]
>> D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(80) : warning C4552: '!' :
>> operator has n
>> o effect; expected operator with side-effect
>>
>> The reason
Vincent van Ravesteijn wrote:
>> The reason is that "ret" is nowehere declared. Richard, can you please
>> have a look?
i see ret defined just one line above your error.
> Are you sure it is not because Richard took a little step into a parallel
> university and wrote 'or' in stead of '||' ?
'
Uwe Stöhr schreef:
BiblioInfo.cpp ist not compilable in trunk:
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2146: syntax error
: missing
')' before identifier 'or'
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2065: 'or' :
undeclared iden
tifier
D:\LyXSVN\lyx-devel\src\BiblioIn
Stefan Schimanski schreef:
Am 17.01.2009 um 14:44 schrieb Andre Poenitz:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn wrote:
For every letter I type in LyX, the updateMacros() function is called
from BufferView::processUpdateFlags().
What does this function do ? The only
Am 17.01.2009 um 14:44 schrieb Andre Poenitz:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn
wrote:
For every letter I type in LyX, the updateMacros() function is called
from BufferView::processUpdateFlags().
What does this function do ? The only feature I see is that when
rgheck wrote:
> Jurgen, would you like this one for branch?
In general, I'd very much welcome this. However, we should probably rather
test a bit in trunk before committing. As the recent slowdown due to the
BibTeX parsing demonstrated, this stuff is not as harmless as it looks :-)
Perhaps you
BiblioInfo.cpp ist not compilable in trunk:
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2146: syntax error : missing
')' before identifier 'or'
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2065: 'or' : undeclared iden
tifier
D:\LyXSVN\lyx-devel\src\BiblioInfo.cpp(79) : error C2143
rgheck schreef:
Pavel Sanda wrote:
Richard Heck wrote:
Andre Poenitz wrote:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn
wrote:
For every letter I type in LyX, the updateMacros() function is
called from BufferView::processUpdateFlags().
What does this func
Pavel Sanda wrote:
Richard Heck wrote:
Andre Poenitz wrote:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn wrote:
For every letter I type in LyX, the updateMacros() function is called
from BufferView::processUpdateFlags().
What does this function do ? The
rgh...@lyx.org wrote:
Author: rgheck
Date: Sat Jan 17 01:16:31 2009
New Revision: 28193
URL: http://www.lyx.org/trac/changeset/28193
Log:
Improve the display of BibTeX info in InsetCitation by retrieving missing
fields from the crossref.
Jurgen, would you like this one for branch?
rh
Mod
Richard Heck wrote:
> Andre Poenitz wrote:
>> On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn wrote:
>>
>>> For every letter I type in LyX, the updateMacros() function is called
>>> from BufferView::processUpdateFlags().
>>>
>>> What does this function do ? The only feature I
Andre Poenitz wrote:
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn wrote:
For every letter I type in LyX, the updateMacros() function is called
from BufferView::processUpdateFlags().
What does this function do ? The only feature I see is that when
changing a math-macro
hi,
currently we do not allow create new file for external material and i think
it makes sense to allow it.
cf http://bugzilla.lyx.org/show_bug.cgi?id=3205
objections?
pavel
diff --git a/src/Format.cpp b/src/Format.cpp
index 6bd5ecb..f9518b8 100644
--- a/src/Format.cpp
+++ b/src/Format.cpp
@@ -32
On Sat, Jan 17, 2009 at 12:50:46PM +0100, Vincent van Ravesteijn wrote:
> For every letter I type in LyX, the updateMacros() function is called
> from BufferView::processUpdateFlags().
>
> What does this function do ? The only feature I see is that when
> changing a math-macro, all uses of the
Am 17.01.2009 um 12:39 schrieb Vincent van Ravesteijn:
Jürgen Spitzmüller schreef:
Stefan Schimanski wrote:
> I propose to backport the feature to branch. It probably applies
> directly without changes.
Probably, but not now. I'd like to restrict 1.6.1 to bug fixes.
(but you can keep it
Vincent van Ravesteijn wrote:
> Jurgen, Stefan,
>
> In the above mail, you sort of probably agreed to backport the "Copy as
> Ref" feature. Do you still want it in branch ? Stefan, do you want to do
> this or shall I ?
OK. However, I feel we should get back to the critical bugs after this.
Jürgen
For every letter I type in LyX, the updateMacros() function is called
from BufferView::processUpdateFlags().
What does this function do ? The only feature I see is that when
changing a math-macro, all uses of the macro are updated.
Is it really necessary to do this always ? As it is in a "nea
Jürgen Spitzmüller schreef:
Stefan Schimanski wrote:
> I propose to backport the feature to branch. It probably applies
> directly without changes.
Probably, but not now. I'd like to restrict 1.6.1 to bug fixes.
(but you can keep it in your tree for later, if you have branch).
Jürgen
Jurg
Jean-Marc Lasgouttes wrote:
> While I am not sure about whre you are headed, here is a patch that
> might help in the translation dept. It gets rid of the
> setDefaultLanguage thing, and reuses the trick currently used in
> i18nLibFileName that lets gettext itself tell us what is the currently
> lo
37 matches
Mail list logo
