>the next step in that patch would be to remove passing of
>the BufferView object to lyxfind.cpp (and corresponding
>putSelectionAt() and replace functionality), but limit it
>to exclusively returning the match (DocIterator and length,
>a bool does not suffice), or making some progress towards
>fin
On Wednesday 06 January 2010 13:03:26 Tommaso Cucinotta wrote:
> yes of couse. I keep wonderiing why software components communicate
> among each other by means of formatting/parsing human-readable strings !
> (similarly to kernel-space user-space comms that happens when you open
> `top' or gnom
Vincent van Ravesteijn - TNW wrote:
AFAICS, what is returned by an LFUN may be LFUN dependent.
So we have two options: 1) use the string-encoded return
mechanism, similarly to the current LFUN argument passing
(personally disliked); 2) use a basic DispatchResult class
with proper subclasses which
>> This particular version seems unnecessarily complex.
>> FuncRequest should just have a DispatchResult member.
>> The pointer member is asking for trouble, I think.
>
>AFAICS, what is returned by an LFUN may be LFUN dependent.
>So we have two options: 1) use the string-encoded return
>mechanism
rgheck wrote:
This particular version seems unnecessarily complex. FuncRequest
should just have a DispatchResult member. The pointer member is asking
for trouble, I think.
AFAICS, what is returned by an LFUN may be LFUN dependent. So we have
two options:
1) use the string-encoded return mechani
Vincent van Ravesteijn - TNW wrote:
I'd also want to figure out some way to allow just the
DispatchResult member to be modified, even when FuncRequest
is const.
You mean you want to declare it "mutable" ?
I thought to this option as well, but I think it would probably be even
worse as
On Tue, Jan 05, 2010 at 06:10:03PM +0100, Jean-Marc Lasgouttes wrote:
> "Vincent van Ravesteijn - TNW" writes:
> > So, why are we discussing it then .. Because we need it ?
> >
> > Isn't the use of cur.dispatched(), cur.undispatched(),
> > cur.result().dispatched() basically a work-around for miss
On 01/05/2010 10:58 AM, Vincent van Ravesteijn - TNW wrote:
I'd also want to figure out some way to allow just the
DispatchResult member to be modified, even when FuncRequest
is const.
You mean you want to declare it "mutable" ?
That is one possibility, though the way Tomasso ha
"Vincent van Ravesteijn - TNW" writes:
> So, why are we discussing it then .. Because we need it ?
>
> Isn't the use of cur.dispatched(), cur.undispatched(),
> cur.result().dispatched() basically a work-around for missing the
> DispatchResult which only works in places where there is a Cursor
> av
>>> 3) let the LFUN dispatch in lyxfind.cpp return the required
>>> information (match position and length) to the caller; for example,
>>> by means of a DispatchResult sub-class (any strong objection to
>>> adding a "DispatchResult &" to some of the existing ::dispatch()
>>> methods?
>>>
>> I
>I'd also want to figure out some way to allow just the
>DispatchResult member to be modified, even when FuncRequest
>is const.
You mean you want to declare it "mutable" ?
Vincent
On 01/05/2010 09:12 AM, Tommaso Cucinotta wrote:
Tommaso Cucinotta wrote:
3) let the LFUN dispatch in lyxfind.cpp return the required information
(match position and length) to the caller; for example, by means of
a DispatchResult sub-class (any strong objection to adding a
"DispatchRes
rgheck writes:
> On 01/04/2010 06:37 PM, Tommaso Cucinotta wrote:
>> 3) let the LFUN dispatch in lyxfind.cpp return the required
>> information (match position and length) to the caller; for example,
>> by means of a DispatchResult sub-class (any strong objection to
>> adding a "DispatchResult &"
Tommaso Cucinotta wrote:
3) let the LFUN dispatch in lyxfind.cpp return the required information
(match position and length) to the caller; for example, by means of
a DispatchResult sub-class (any strong objection to adding a
"DispatchResult &" to some of the existing ::dispatch() method
rgheck wrote:
On 01/05/2010 08:54 AM, Abdelrazak Younes wrote:
The multi-file search need not be, but could call that LFUN repeatedly.
Or rather call the Buffer method. Because we don't want to create a
BufferView for that search. Or we could also duplicate LFUN_FINDADV
in Buffer in addtio
On 01/05/2010 08:54 AM, Abdelrazak Younes wrote:
The multi-file search need not be, but could call that LFUN repeatedly.
Or rather call the Buffer method. Because we don't want to create a
BufferView for that search. Or we could also duplicate LFUN_FINDADV in
Buffer in addtion to BufferView
rgheck wrote:
On 01/05/2010 08:44 AM, Abdelrazak Younes wrote:
Tommaso Cucinotta wrote:
Abdelrazak Younes wrote:
You can use the paragraph id and the position in that paragraph.
Else there is the StableDocIterator IIRC.
I can see operator<<() but not operator>>(), both for
StableDocIterator a
On 01/05/2010 08:44 AM, Abdelrazak Younes wrote:
Tommaso Cucinotta wrote:
Abdelrazak Younes wrote:
You can use the paragraph id and the position in that paragraph.
Else there is the StableDocIterator IIRC.
I can see operator<<() but not operator>>(), both for
StableDocIterator and for CursorSl
Tommaso Cucinotta wrote:
Abdelrazak Younes wrote:
You can use the paragraph id and the position in that paragraph. Else
there is the StableDocIterator IIRC.
I can see operator<<() but not operator>>(), both for
StableDocIterator and for CursorSlice. I guess the operator<<()s are
there just for
On 01/04/2010 06:37 PM, Tommaso Cucinotta wrote:
3) let the LFUN dispatch in lyxfind.cpp return the required
information (match position and length) to the caller; for example, by
means of a DispatchResult sub-class (any strong objection to adding a
"DispatchResult &" to some of the existing ::
Abdelrazak Younes wrote:
You can use the paragraph id and the position in that paragraph. Else
there is the StableDocIterator IIRC.
I can see operator<<() but not operator>>(), both for StableDocIterator
and for CursorSlice. I guess the operator<<()s are there just for
debugging purposes, not r
Tommaso Cucinotta wrote:
Vincent van Ravesteijn - TNW wrote:
This is not only caused by the fact that you're using LFUN_BUFFER_SWITCH
instead of GuiView::setBuffer, but also by the fact that you now call
LFUN_FINDADV for each buffer, so it will be shown anyway when
dispatching this LFUN.
If you
Vincent van Ravesteijn - TNW wrote:
This is not only caused by the fact that you're using LFUN_BUFFER_SWITCH
instead of GuiView::setBuffer, but also by the fact that you now call
LFUN_FINDADV for each buffer, so it will be shown anyway when
dispatching this LFUN.
If you really want to search in
On 01/04/2010 09:00 AM, Vincent van Ravesteijn - TNW wrote:
If you really want to search in hidden buffers (and/or non-current
workareas) we either have to change some design, we can hide the buffer
again when nothing is found, or freeze the view for a moment such that
we can switch buffer witho
>> However, I'm not sure whether everyone likes this approach. Anyway, I
>> think the concept of the LFUN being dispatched or not is what you
>> need: did I get a result or didn't anything happen.
>just to mention that r32760 follows your advice (scopes and buffer
>switch handled in F&R widget).
Hello,
Vincent van Ravesteijn wrote:
Maybe it's already "wrong" to do this buffer management in lyxfind.cpp.
[...]
Well there is a way to do this. See the attached patch.
However, I'm not sure whether everyone likes this approach. Anyway, I
think the concept of the LFUN being dispatched or
On 02/01/2010 03:07, Vincent van Ravesteijn wrote:
Tommaso Cucinotta schreef:
However, in order to implement this, I would need to call the
GuiWorkArea * GuiView::workArea(Buffer & buffer)
on a related note, what is the "Buffer::gui_" field ? What is the
purpose of those "gui delegate" ? If
On Fri, Jan 01, 2010 at 05:09:24PM +0100, Tommaso Cucinotta wrote:
>>> GuiWorkArea * GuiView::workArea(Buffer & buffer)
> on a related note, what is the "Buffer::gui_" field ? What is the
> purpose of those "gui delegate" ? If I call "hasGuiDelegate()", is that
> equivalent to checking that th
Vincent van Ravesteijn wrote:
We use the LFUNs to communicate from the GUI to the core. So, it's not
necessary to communicate from a Widget (which has a view_ member) to
the GuiView by means of an LFUN.
3) then I would call a GuiView::findAdv() method, which would
implement the "scope" func
Tommaso Cucinotta schreef:
Vincent van Ravesteijn wrote:
So, if you think about this, you'd say that it's already "wrong" that
you want to have this information about a buffer in lyxfind.cpp.
Maybe it's already "wrong" to do this buffer management in lyxfind.cpp.
I'm sure it is wrong, I'm only
rgheck wrote:
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::masterBuf
Vincent van Ravesteijn wrote:
I guess the rationale is that we open all children automatically too.
So, if you're working on a multi-part document, you'd only have to
open the master to have all children, but then it's convenient that if
you close the master you'll also close all children.
So
On 01/01/2010 11:09 AM, Tommaso Cucinotta wrote:
on a related note, what is the "Buffer::gui_" field ? What is the
purpose of those "gui delegate" ? If I call "hasGuiDelegate()", is
that equivalent to checking that the buffer has an associated view
(workarea and bufferview) ?
No, I think hasG
On 01/01/2010 07:03 AM, Vincent van Ravesteijn wrote:
it seems the master changes according to the last-loaded master.
Also, when closing one of the two masters, its child is also closed.
This is expected, basically, at least the first part. That the child
closes whichever master closes is wro
Vincent van Ravesteijn wrote:
So, if you think about this, you'd say that it's already "wrong" that
you want to have this information about a buffer in lyxfind.cpp. Maybe
it's already "wrong" to do this buffer management in lyxfind.cpp.
I'm sure it is wrong, I'm only trying to proceed increment
However, I'd like to raise your attention to another issue: when
searching in S_OPEN_BUFFERS scope, currently I'm searching within both
explicitly open (and displayed) and hidden buffers. Apparently, from a
user perspective, it may seem more clear to search only within
explicitly (and display
Tommaso Cucinotta schreef:
rgheck wrote:
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation attempt should
give up with an error to the user (but it may not be easy to
identify an arbitrary "loop" in what is supposed to be a
Vincent van Ravesteijn - TNW wrote:
I prefer to use lyx::dispatch(FuncRequest(LFUN_BUFFER_SWITCH,
dest_buffer_->absFileName()));
or isn't that possible ?
I guess we try to keep the LyXView.h interface as small as possible.
SelectDocumentBuffer does nothing else
rgheck wrote:
I just tried, and we have segfault after 3) (infinite recursion in
Buffer::masterBuffer() [1]). Probably such operation attempt should
give up with an error to the user (but it may not be easy to identify
an arbitrary "loop" in what is supposed to be a DAG, with documents
that ar
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]). Pro
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 a
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
>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 inclu
>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(Buf
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, wh
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 thro
>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
>==
47 matches
Mail list logo
