LyX 2.3.6.2 behaves similarly.
Chris
> Am 25.03.2021 um 11:57 schrieb LyX Ticket Tracker :
>
> #12214: Unexpected Advanced Search Dialog Behaviour
> +---
> Reporter: docc| Owner: kornel
> Type: defect | Status: ne
On Sun, Jun 21, 2015 at 10:02:52AM +, Moon, Jong-Myun wrote:
> Hello,
>
>
> First of all, thank you guys for the wonderful program.
>
>
> I guess I found a bug regarding the advanced search. After I tried to search
> for a math expression several times, when I cli
Hello,
First of all, thank you guys for the wonderful program.
I guess I found a bug regarding the advanced search. After I tried to search
for a math expression several times, when I clicked the advanced search button,
it pops up an empty window.
Also, when I first open LyX and recall the
2014-04-07 17:46 GMT+02:00 Pavel Sanda:
> Huh users are not able to CC themselves? I think we should allow them to
> edit CC field in trac, right?
>
Authenticated users should be able to add and remove themselves (but not
others) from CC. This is granted by TICKET_MODIFY, which is set for
authent
Scott Kostyshak wrote:
> On Mon, Apr 7, 2014 at 9:24 AM, Daniel Ferreira
> wrote:
>
> > I couldn't find a way to subscribe. I am logged in. Should I just make a
> > comment?
>
> I added you on the CC list.
Huh users are not able to CC themselves? I think we should allow them to edit
CC field i
On Mon, Apr 7, 2014 at 9:24 AM, Daniel Ferreira
wrote:
> I couldn't find a way to subscribe. I am logged in. Should I just make a
> comment?
I added you on the CC list.
Scott
Ok, thanks!
I couldn't find a way to subscribe. I am logged in. Should I just make a
comment?
Thanks
From: Tommaso Cucinotta
To: Daniel Ferreira ; "lyx-devel@lists.lyx.org"
Sent: Monday, April 7, 2014 5:55 AM
Subject: Re: lyx - advanced s
On 05/04/14 21:49, Daniel Ferreira wrote:
> I hope this is implemented in Lyx someday.
Indeed, we have a long-standing feature enhancement on our bug tracking system:
http://www.lyx.org/trac/ticket/4987
you can subscribe to that, in order to be notified of updates in this regard,
if you wish.
aniel Ferreira ; LyX Developers
Sent: Friday, April 4, 2014 8:11 PM
Subject: Re: lyx - advanced search - exclude notes?
Hi Daniel
It is probably not what you're looking for, but it is easy to delete
all notes. You could have a shortcut for that, then search, then
restore notes with ctrl +
a desirable feature, but not implemented as of yet.
>
> Thanks,
>
> T.
>
> On 04/04/14 02:19, Daniel Ferreira wrote:
>> Hello,
>> I would like to ask a question about Lyx search.
>> I reached your email through your contributions to the Advanced Search.
>>
&g
I reached your email through your contributions to the Advanced Search.
>
> I would like to know if there is some way to ignore content inside of Notes
> when doing a search in Lyx. (also, to search *only* in Notes)
>
> You mention this here:
> http://wiki.lyx.org/Devel/Advsear
On 07/04/13 09:34, Kornel Benko wrote:
> Am Sonntag, 7. April 2013 um 01:36:52, schrieb Tommaso Cucinotta
>
>> I came up with this trivial patch for the kind of scenario you proposed.
>> Simply,
>> export an regexp inset using the text, rather than math, "encoding" rules.
>> AFAICS, one might us
Am Sonntag, 7. April 2013 um 01:36:52, schrieb Tommaso Cucinotta
> So,
>
> I came up with this trivial patch for the kind of scenario you proposed.
> Simply,
> export an regexp inset using the text, rather than math, "encoding" rules.
> AFAICS, one might usefully be willing to write text (and s
On 06/04/13 20:04, Kornel Benko wrote:
>> However, when the regexp contains non-ASCII chars, then it's misinterpreted
>> in the text conversion. I suspect it's due to the fact that the regexp inset
>> has been essentially derived from a math inset, so it's not expecting any
>> non-ASCII stuff there
Am Samstag, 6. April 2013 um 19:32:58, schrieb Tommaso Cucinotta
> On 03/04/13 22:40, Kornel Benko wrote:
> > I want to find (as regular expression) the string "použiť". In tex, it looks
> > "použi\v{t}".
> > But the searched string (as it is diplayed while filling the search form)
> > it is
> >
On 03/04/13 22:40, Kornel Benko wrote:
> I want to find (as regular expression) the string "použiť". In tex, it looks
> "použi\v{t}".
> But the searched string (as it is diplayed while filling the search form) it
> is
> "\regexp{pou\check{z} it\mkern-5mu\mathchar19\endregexp{}}".
Ok, I could repr
On 03/04/13 22:29, Kornel Benko wrote:
> Am Mittwoch, 3. April 2013 um 20:32:22, schrieb Tommaso Cucinotta
>
>> I can run all of the findadv tests to check whether the patch broke anything.
>> That's even easier than entering with my head back into that spaghetti code
>> :-).
>
> I run them, an
asgouttes wrote:
>
>> >> I am not sure if it has anything to do with utf8. The expanded string
>> >> looks
>
>> >> like it is expanded for LaTeX. This looks quite wrong to me in context of
>
>> >> searching. Why is this done?
>
>>
f
> >> searching. Why is this done?
> >
> > This is how advanced search works.
>
> Confirm. This is how the current implementation works. Nonetheless,
> alternative (and more efficient) implementations of the idea might be
> possible.
>
> T.
I disag
Am Mittwoch, 3. April 2013 um 20:32:22, schrieb Tommaso Cucinotta
> On 31/03/13 12:38, Kornel Benko wrote:
> > Tommaso is ATM not very responsive. I am pretty confident,
> > That I have a patch, which does not affect any other parts
> > of advanced search.
>
> Hi
On 31/03/13 12:38, Kornel Benko wrote:
> Tommaso is ATM not very responsive. I am pretty confident,
> That I have a patch, which does not affect any other parts
> of advanced search.
Hi,
I can run all of the findadv tests to check whether the patch broke anything.
That's ev
On 02/04/13 10:28, Jean-Marc Lasgouttes wrote:
>> I am not sure if it has anything to do with utf8. The expanded string looks
>> like it is expanded for LaTeX. This looks quite wrong to me in context of
>> searching. Why is this done?
>
> This is how advanced search work
On 11/03/13 11:22, Kornel Benko wrote:
> Hi,
>
> advanced search in my document (for a non-existent string on all opened
> documents):
> takes 227 seconds. Moreover, at the end of search (dialog asking to start
> over)
> eats so much memory ( > 4GB), that my computer s
;ž". And more, if you want to match Chinese
characters.
I am not sure if it has anything to do with utf8. The expanded string looks
like it is expanded for LaTeX. This looks quite wrong to me in context of
searching. Why is this done?
This is how advanced search works. The argument is that ot
Am Sonntag, 31. März 2013 um 11:07:36, schrieb Richard Heck
>
> Oh, never mind, I remember it now. It looked fine to me.
>
> rh
Committed slightly modified version.
Kornel
signature.asc
Description: This is a digitally signed message part.
Helge Hafting wrote:
> On 29. mars 2013 13:38, Kornel Benko wrote:
>> I seem unable to find strings using non ascii chars (e.g. latin2)
>>
>> (Please try to use UTF-8 encoding to read this mail)
>>
>> The regex search string may be "pou.i.", so I was expecting to find
>>
>> e.g. "použiť". I have t
#x27;ll cc Tommaso and see if he has any
thoughts.
>
> Richard
Tommaso is ATM not very responsive. I am pretty confident,
That I have a patch, which does not affect any other parts
of advanced search.
Anybody against the commit?
Which patch was that?
Oh, never mind, I remember it now. It looked fine to me.
rh
ughts.
>
> Richard
Tommaso is ATM not very responsive. I am pretty confident,
That I have a patch, which does not affect any other parts
of advanced search.
Anybody against the commit?
Which patch was that?
rh
On 29. mars 2013 13:38, Kornel Benko wrote:
I seem unable to find strings using non ascii chars (e.g. latin2)
(Please try to use UTF-8 encoding to read this mail)
The regex search string may be "pou.i.", so I was expecting to find
e.g. "použiť". I have to use '..' to find this single chars. ("
sponsive. I am pretty confident,
That I have a patch, which does not affect any other parts
of advanced search.
Anybody against the commit?
Kornel
signature.asc
Description: This is a digitally signed message part.
I seem unable to find strings using non ascii chars (e.g. latin2)
(Please try to use UTF-8 encoding to read this mail)
The regex search string may be "pou.i.", so I was expecting to find
e.g. "použiť". I have to use '..' to find this single chars. ("pou..i..")
Also using such characters in the re
cd" in
the whole string, therefore
> we need only to make findForwardAdv() notice it and increment the
cursor position accordingly.
>
> The patch I attach her is a hack, I know. But at least it shows,
that somehow it should be possible.
>
> With this patch the advance
o make findForwardAdv() notice it and increment the cursor
> position accordingly.
>
> The patch I attach her is a hack, I know. But at least it shows, that somehow
> it should be possible.
>
> With this patch the advanced search is about 50 times faster.
> Could som
..
AT the first call, we already could know, the there is no "abcd" in the whole
string, therefore
we need only to make findForwardAdv() notice it and increment the cursor
position accordingly.
The patch I attach her is a hack, I know. But at least it shows, that somehow
it should
On 03/13/2013 05:55 AM, Kornel Benko wrote:
Am Dienstag, 12. März 2013 um 17:09:33, schrieb Pavel Sanda
> Kornel Benko wrote:
> > Than I tried lyx, as I most of the time use.
> > 1.) with own userdir
> > 2.) with some debug output.
> > MEMORY use!!!
>
> Isn't it only debug output flush
Am Dienstag, 12. März 2013 um 17:09:33, schrieb Pavel Sanda
> Kornel Benko wrote:
> > Than I tried lyx, as I most of the time use.
> > 1.) with own userdir
> > 2.) with some debug output.
> > MEMORY use!!!
>
> Isn't it only debug output flushed into debug window at the end?
> P
It may we
Kornel Benko wrote:
> Than I tried lyx, as I most of the time use.
> 1.) with own userdir
> 2.) with some debug output.
> MEMORY use!!!
Isn't it only debug output flushed into debug window at the end?
P
Am Dienstag, 12. März 2013 um 15:08:54, schrieb Richard Heck
> JMarc's post showed some heavy memory consumption in the BibTeX parser.
> I wasn't able to get any kind of hit when I put a breakpoint into
> InsetBibtex::parseBibTeX(). But maybe your file is different from any I
> tried. Can you s
Am Dienstag, 12. März 2013 um 15:08:54, schrieb Richard Heck
> On 03/12/2013 02:09 PM, Kornel Benko wrote:
> >
> > Am Dienstag, 12. März 2013 um 18:57:06, schrieb Kornel Benko
> >
> >
> > >
> >
> > > In order to measure the time, I have a konsole-window with "date"
> >
> > > Start the advaced se
On 03/12/2013 02:09 PM, Kornel Benko wrote:
Am Dienstag, 12. März 2013 um 18:57:06, schrieb Kornel Benko
>
> In order to measure the time, I have a konsole-window with "date"
> Start the advaced search.
> As soon, as the search ends, e.g. the expected dialog displays,
> I get the focus t
Am Dienstag, 12. März 2013 um 18:57:06, schrieb Kornel Benko
>
> In order to measure the time, I have a konsole-window with "date"
> Start the advaced search.
> As soon, as the search ends, e.g. the expected dialog displays,
> I get the focus to the konsole, insert
> From now on, the memory usag
t;
> >
> > ...
> >
> > > >
> >
> > > > add InsetBibtex::plaintext() again.
> >
> > > >
> >
> > > Can you post a backtrace showing where that is being called from? I
> >
> > > don't know what adv
being called from? I
> don't know what advanced search is doing exactly, but I know it
involves
> creating a temporary file of some sort.
Yes. This is the first one after using advanced search. There are more ...
#0 lyx::InsetBibtex::plaintext (this=0x2b1dd60, os=..., op=...,
max_le
Here is a streamlined version of the massif file that Kornel sent
privately to me. As far as I can see below, it only accounts for 50 to
100MB.
Comments in the output below (I replaced ugle basic_string<> expressions
with docstring).
JMarc
The memory is actually increasing and the largest s
being called from? I
> don't know what advanced search is doing exactly, but I know it
involves
> creating a temporary file of some sort.
Yes. This is the first one after using advanced search. There are more ...
#0 lyx::InsetBibtex::plaintext (this=0x2b1dd60, os=..., op=...,
max_le
Le 11/03/13 19:33, Kornel Benko a écrit :
Am Montag, 11. März 2013 um 17:46:50, schrieb Kornel Benko
I tried, but got only this output with
#valgrind --tool=massif ...
==21508== Massif, a heap profiler
==21508== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==21508== Using
Am Montag, 11. März 2013 um 19:28:47, schrieb Jean-Marc Lasgouttes
>
> Kornel Benko a écrit :
> >Interested in the valgrind output (267 kb)?
>
>
> Sure.
Aaah. I incidentally replaced it with output of 'valgrind --tool=massif'
But will make a new one. Tomorrow, OK?
> JMarc
Kornel
s
Am Montag, 11. März 2013 um 14:23:59, schrieb Richard Heck
> On 03/11/2013 12:46 PM, Kornel Benko wrote:
> >
...
> >
> > add InsetBibtex::plaintext() again.
> >
> Can you post a backtrace showing where that is being called from? I
> don't know what advanced
Kornel Benko a écrit :
>Interested in the valgrind output (267 kb)?
Sure.
JMarc
Am Montag, 11. März 2013 um 17:46:50, schrieb Kornel Benko
> > Another possibility is to use the 'massif' tool of valgrind. It will
> > tell you where the data is allocated.
>
> I will try this one also.
>
I tried, but got only this output with
#valgrind --tool=massif ...
==21508== M
o many leaks to find...
Yes, but probably the biggest would be enough. Nonetheless, there is
nothing bigger than 15kb.
Does not explain, what I was seeing if run alone. Rerunning again, no
such big leak. Maybe, I should
add InsetBibtex::plaintext() again.
Can you post a backtrace showing where t
Am Montag, 11. März 2013 um 15:33:36, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 14:42, Kornel Benko a écrit :
> > ==11211== LEAK SUMMARY:
> > ==11211== definitely lost: 33,700 bytes in 189 blocks
> > ==11211== indirectly lost: 59,454 bytes in 1,606 blocks
> > ==11211== possibly lost: 15,783 by
Am Montag, 11. März 2013 um 15:41:06, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 13:42, Kornel Benko a écrit :
> > > I tried the merged manual, and indeed it is very slow. Are you trying
> > > with stdlib-debug on?
> >
> > I don't think so. How can I check?
> >
> > In cmake I am creating a de
Le 11/03/2013 13:42, Kornel Benko a écrit :
> I tried the merged manual, and indeed it is very slow. Are you trying
> with stdlib-debug on?
I don't think so. How can I check?
In cmake I am creating a debug version, but without using LYX_STDLIB_DEBUG.
This means, the gcc does *not* have
-D_G
Le 11/03/2013 14:42, Kornel Benko a écrit :
==11211== LEAK SUMMARY:
==11211== definitely lost: 33,700 bytes in 189 blocks
==11211== indirectly lost: 59,454 bytes in 1,606 blocks
==11211== possibly lost: 15,783 bytes in 59 blocks
==11211== still reachable: 1,721,311 bytes in 8,392 blocks
==11211==
Am Montag, 11. März 2013 um 13:42:34, schrieb Kornel Benko
>
> Trying... takes nearly forever ... only 1 of my 4 cpu's is busy (100%) ...
>
> will mail again, when (and if?) the seach under valgrind ends.
>
> > JMarc
So, search finished, no visible memory lost.
The dialog
Opened files
Am Montag, 11. März 2013 um 12:43:30, schrieb Jean-Marc Lasgouttes
> Le 11/03/2013 12:22, Kornel Benko a écrit :
> > Hi,
> >
> > advanced search in my document (for a non-existent string on all opened
> > documents):
> >
> > takes 227 seconds. Moreover,
Le 11/03/2013 12:22, Kornel Benko a écrit :
Hi,
advanced search in my document (for a non-existent string on all opened
documents):
takes 227 seconds. Moreover, at the end of search (dialog asking to
start over)
I tried the merged manual, and indeed it is very slow. Are you trying
with
Hi,
advanced search in my document (for a non-existent string on all opened
documents):
takes 227 seconds. Moreover, at the end of search (dialog asking to start over)
eats so much memory ( > 4GB), that my computer starts to using swap disk.
Being warned on the plaintext problem, I checked
On 16/05/12 12:48, LyX Ticket Tracker wrote:
#8157: Advanced search chokes on Embedded manual
+---
Reporter: sanda | Owner: tommaso
Type: defect | Status: new
Priority: normal | Milestone:
Component: search | Version
Ok. Give me some days to find the time to compile from the source and do the
tests.
On Wednesday, October 05, 2011 06:03:44 PM Tommaso Cucinotta wrote:
> Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
> > 2) try to recompile LyX from the sources, to check whether the problem
> > still shows
Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
2) try to recompile LyX from the sources, to check whether the problem
still shows up on your system or not in the current trunk. Shortly
(but it's going to take half an hour or so):
svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-trunk
cd
Il 05/10/2011 20:37, Rudi Gaelzer ha scritto:
All right, I installed valgrind and ran it as per instructions.
When it finally opened the text, the process massif-amd64-li... was
using 13.5%MEM and the demand was increasing very slowly without any
operation on the text.
When I opened the A
by the massive buffer
modifications done by advanced search (this code is really weird to me,
BTW).
JMarc
Le 04/10/2011 16:33, Tommaso Cucinotta a écrit :
Thanks for looking at these. However, one of the biggest mess seems to
me the Undo related logic.
Let me report below my original question/doubts:
It look like I missed the original posting on this subject.
The questions look very interesting, I'
Il 04/10/2011 15:28, Jean-Marc Lasgouttes ha scritto:
Le 01/10/2011 02:04, Tommaso Cucinotta a écrit :
These are just cleanup ops that are not explicitly done on program exit,
but not a big deal, actually. They could help in having a better cleanup
of LyX at exit, but I'm not sure any of these d
Le 01/10/2011 02:04, Tommaso Cucinotta a écrit :
These are just cleanup ops that are not explicitly done on program exit,
but not a big deal, actually. They could help in having a better cleanup
of LyX at exit, but I'm not sure any of these deserves to be committed
(pls, comment).
I think such
Il 01/10/2011 19:01, Rudi Gaelzer ha scritto:
On Friday 30 September 2011 21:04:35 Tommaso Cucinotta wrote:
> For the increased memory usage notified by Rudi, if there were any
> problem with handling the Undo instances, then we should have seen
> something about Undo into the valgrind log. I
Il 30/09/2011 12:15, Jean-Marc Lasgouttes ha scritto:
What do we see?
1/ there is a continuous drift of memory use
2/ the most important part is the agregation of small allocations (not
very useful...)
3/ the second one is related to font loading by qt (remains stable)
4/ the third one is the
Le 30/09/2011 08:56, Tommaso Cucinotta a écrit :
Ok, please, find attached the obtained output parsed with ms_print.
Now, what do I do with this monster :-) ?
Where's the info about memory leaks ?
It is not necessarily a problem of memory leak (could be an ever-growing
cache, for example). Her
Le 29/09/11 01:13, Tommaso Cucinotta a écrit :
==26690== LEAK SUMMARY:
==26690== definitely lost: 12,126 bytes in 73 blocks
==26690== indirectly lost: 18,336 bytes in 571 blocks
==26690== possibly lost: 696,631 bytes in 2,590 blocks
==26690== still reachable: 898,279 bytes in 7,833 blocks
==26690
On Wednesday 28 September 2011 19:05:28 Tommaso Cucinotta wrote:
> Il 28/09/2011 20:40, Rudi Gaelzer ha scritto:
> > The document I'm working right now has thousands of formulas and I've
> > been using the advanced search pretty heavily. I can detect the
> > incre
Il 29/09/2011 00:30, Jean-Marc Lasgouttes ha scritto:
Le 29/09/2011 00:05, Tommaso Cucinotta a écrit :
Also, I noticed a monotonic memory usage increase while editing the
document and especially creating math insets and deleting them later. I
guess this is due to the Undo feature, that keeps sto
Le 29/09/2011 00:05, Tommaso Cucinotta a écrit :
Also, I noticed a monotonic memory usage increase while editing the
document and especially creating math insets and deleting them later. I
guess this is due to the Undo feature, that keeps storing (a copy of)
all the insets even though you delete
Il 28/09/2011 20:40, Rudi Gaelzer ha scritto:
The document I'm working right now has thousands of formulas and I've
been using the advanced search pretty heavily. I can detect the
increasing memory load even with the very simple text that I attached
(memory.lyx). I was continually
> >
> > While editing a text riddled with mathematical formulae, I had to use
> > advanced search several times to locate some mathematical expressions.
> > Suddenly, my system started to crawl. The reason was that lyx was
> > using almost all available memory.
Il 28/09/2011 16:36, Rudi Gaelzer ha scritto:
I don't know if this has already been reported. I made a quick scan
through both the user and devel lists and couldn't find anything related.
While editing a text riddled with mathematical formulae, I had to use
advanced search severa
-Original Message-
From: lyx-devel@lists.lyx.org on behalf of Tommaso Cucinotta
Sent: Sun 7/10/2011 2:20 AM
To: lyx-devel@lists.lyx.org
Subject: Re: Bug in "advanced search" in LyX 2.0.1, infinite loop
>Il 08/07/2011 15:19, Helge Hafting ha scritto:
>> While tr
Il 08/07/2011 15:19, Helge Hafting ha scritto:
While translating, I came a cross an infinite loop bug in the advanced
search.
hopefully, this was fixed in r39266. Thanks for report.
Bye,
Tommaso
To reproduce:
1. Enter some text, such as "a text text text a text"
2. Us
While translating, I came a cross an infinite loop bug in the advanced
search. To reproduce:
1. Enter some text, such as "a text text text a text"
2. Use advanced search and replace. Specifically, replace the
letter "a" with this math construct:
1
-
a+b
3
Il 23/05/2011 21:34, Tommaso Cucinotta ha scritto:
Il 23/05/2011 14:50, Abdel Younes ha scritto:
Maybe the solution is to create a special EmbeddedBuffer class that
will constantly refer to the document Buffer (const access to the
params, ref cache, etc). EmbeddedBuffer would inherit Buffer a
Il 23/05/2011 14:50, Abdel Younes ha scritto:
I don't think it would work. That buffer has no access to the bibliography or
reference info from the working buffer. Probably what you would need to do is
copy the reference cache and the bibinfo cache, though you'd also have to make
sure they w
On May 23, 2011, at 2:18 PM, Richard Heck wrote:
> On 05/23/2011 08:12 AM, Tommaso Cucinotta wrote:
>> Il 23/05/2011 08:22, LyX Ticket Tracker ha scritto:
>>> However, there are still things left that need to be copied. For instance,
>>> both Insert> Citation and Insert> Cross Reference do no
On 05/23/2011 08:12 AM, Tommaso Cucinotta wrote:
Il 23/05/2011 08:22, LyX Ticket Tracker ha scritto:
However, there are still things left that need to be copied. For
instance,
both Insert> Citation and Insert> Cross Reference do not seem to
work in
the search buffer. Shall I file separ
Il 23/05/2011 08:22, LyX Ticket Tracker ha scritto:
However, there are still things left that need to be copied. For instance,
both Insert> Citation and Insert> Cross Reference do not seem to work in
the search buffer. Shall I file separate reports for these?
do you know whether these we
I just placed a reminder for this into the Trac as #7137.
T.
Messaggio originale
Oggetto:Advanced Search: Main WA disappears on wrap-around dialog
Data: Tue, 30 Nov 2010 22:51:01 +0100
Mittente: Tommaso Cucinotta
A: LyX Developers
Hello,
while
Hello,
while using the advanced search with the trunk version, the main
document WA disappears while the wrap-around question dialog is shown.
I find this quite annoying, but I couldn't identify the reason of why
this happens, and how to possibly fix it.
Does anyone has a hint on whe
Edwin Leuven wrote:
> Pavel Sanda wrote:
> > its almost impossible to find way how to insert regular expression.
> > we should perhaps put it at least into normal insert menu?
>
> http://www.lyx.org/trac/changeset/35430
thanks,
pavel
Pavel Sanda wrote:
> its almost impossible to find way how to insert regular expression.
> we should perhaps put it at least into normal insert menu?
http://www.lyx.org/trac/changeset/35430
hi Edwin,
advanced search dialog has now one glitch after your work- its almost
impossible to find way how to insert regular expression. only after 10 mins of
searching through sources i found that it has been moved to context menu. i
guess only small fraction of people will find and we should
Hello Uwe,
are you going to integrate the lib/doc/AdvancedSearch.lyx manual into
lib/doc/UserGuide.lyx ?
Need anything from my side ?
T.
LyX Ticket Tracker wrote:
#3095: Integrate advanced search manual into our manuals
On 03/22/2010 05:04 PM, Edwin Leuven wrote:
i would suggest to do the following in terms of layout
http://dl.dropbox.com/u/359550/snap4.png
then the advanced and simple search dialogs are consistent and users
know what to expect. it also conforms to what people are known to
expect from most ot
On Sun, Mar 21, 2010 at 11:48 PM, Tommaso Cucinotta wrote:
> I'm on Linux Ubuntu 9.10, Qt "4.5.3really4.5.2-0ubuntu1" whatever it means.
> This is how it mixes bad with the View Source:
>
> http://retis.sssup.it/~tommaso/lyx-findadv-size.png
ok, but apart from when the window becomes very small
Edwin Leuven wrote:
windows, linux, mac? qt version?
I'm on Linux Ubuntu 9.10, Qt "4.5.3really4.5.2-0ubuntu1" whatever it means.
This is how it mixes bad with the View Source:
http://retis.sssup.it/~tommaso/lyx-findadv-size.png
yes, we should try, these extra scrollareas and nasty sizepoli
Edwin Leuven wrote:
i took the liberty to tweak the advanced search/replace dialog:
http://www.lyx.org/trac/changeset/33821
it should now properly size,
unfortunately, it does not, on my laptop. The vertical size does not
shrink below a quite large value, as usual. This causes the
i took the liberty to tweak the advanced search/replace dialog:
http://www.lyx.org/trac/changeset/33821
it should now properly size, and i added frames
some remaining comments
when using it i was missing a replace button.
now when one does a "find next" it is not clear what to do wh
Hello,
I had already seen your previous message about the same thing.
Actually, I noticed Abdel has already merged most of the code into
trunk, that's why the last wrap-related patch I sent you was against
trunk.
T.
Pavel Sanda ha scritto:
Hello Tommaso,
we have agreed that it would be goo
Jürgen Spitzmüller wrote:
Konrad Hofbauer wrote:
Do I understand correctly:
'Trunk' is now LyX 1.7, and 1.6.x is a branch [and stuff back-ported to
it (or not)]?
correct.
Don't hold your breath for a 1.6 backport, this won't happen. Too much
work already.
Abdel.
Tommaso Cucinotta wrote:
> Pavel Sanda ha scritto:
>> For the proper merge we need review the
>> current patch bit by bit.
keep your hats, Abdel started to work on it :)
p
Pavel Sanda ha scritto:
For the proper merge we need review the
current patch bit by bit.
I just verified that, with the recent introduction of the eventFilter,
the attached lines are not needed anymore in GuiWorkArea.cpp.
The boolean dialogMode_ is still retrieved by GuiView.cpp, but I
would
1 - 100 of 130 matches
Mail list logo
