Tommaso Cucinotta wrote:
Pavel Sanda ha scritto:
On a related note, I don't know why the C-S-f short-cut does not
appear in the menu', like it happens for the C-f one. Any clue ?
looks like a bug in our machinery. worth to report it in trac.
I'm scared it's instead a misuse of the
Tommaso Cucinotta wrote:
> Pavel Sanda ha scritto:
>>> On a related note, I don't know why the "C-S-f" short-cut does not
>>> appear in the menu', like it happens for the "C-f" one. Any clue ?
>>>
>> looks like a bug in our machinery. worth to report it in trac.
>>
> I'm scared it's
Tommaso Cucinotta wrote:
Pavel Sanda ha scritto:
On a related note, I don't know why the C-S-f short-cut does not
appear in the menu', like it happens for the C-f one. Any clue ?
looks like a bug in our machinery. worth to report it in trac.
I'm scared it's instead a misuse of the
Tommaso Cucinotta wrote:
> Pavel Sanda ha scritto:
>>> On a related note, I don't know why the "C-S-f" short-cut does not
>>> appear in the menu', like it happens for the "C-f" one. Any clue ?
>>>
>> looks like a bug in our machinery. worth to report it in trac.
>>
> I'm scared it's
Hello,
I don't remember to have answered to these, hope to not duplicate myself
(now I have a decent connection):
Vincent van Ravesteijn ha scritto:
- If Enter means searching, how can I then search for a string with
paragraph breaks. I can't enter an enter now.
the main purpose would be to
Hello,
I don't remember to have answered to these, hope to not duplicate myself
(now I have a decent connection):
Vincent van Ravesteijn ha scritto:
- If Enter means searching, how can I then search for a string with
paragraph breaks. I can't enter an enter now.
the main purpose would be to
Pavel Sanda ha scritto:
On a related note, I don't know why the C-S-f short-cut does not
appear in the menu', like it happens for the C-f one. Any clue ?
looks like a bug in our machinery. worth to report it in trac.
I'm scared it's instead a misuse of the machinery by myself. I have a
Vincent van Ravesteijn ha scritto:
Another remark:
If the Find LyX window is open, a lot of the accelerators are
hijacked. I can't use Alt-X (minibuffer), Alt-P (layout) anymore. I
think these should only be hijacked if one of the two embedded
workareas has the focus.
Hello,
if you update
Tommaso Cucinotta schreef:
Vincent van Ravesteijn ha scritto:
Another remark:
If the Find LyX window is open, a lot of the accelerators are
hijacked. I can't use Alt-X (minibuffer), Alt-P (layout) anymore. I
think these should only be hijacked if one of the two embedded
workareas has the
Tommaso Cucinotta schreef:
Vincent van Ravesteijn ha scritto:
Another remark:
If the Find LyX window is open, a lot of the accelerators are
hijacked. I can't use Alt-X (minibuffer), Alt-P (layout) anymore. I
think these should only be hijacked if one of the two embedded
workareas has the
Pavel Sanda ha scritto:
On a related note, I don't know why the "C-S-f" short-cut does not
appear in the menu', like it happens for the "C-f" one. Any clue ?
looks like a bug in our machinery. worth to report it in trac.
I'm scared it's instead a misuse of the machinery by myself. I
Vincent van Ravesteijn ha scritto:
Another remark:
If the Find LyX window is open, a lot of the accelerators are
hijacked. I can't use Alt-X (minibuffer), Alt-P (layout) anymore. I
think these should only be hijacked if one of the two embedded
workareas has the focus.
Hello,
if you update
Tommaso Cucinotta schreef:
Vincent van Ravesteijn ha scritto:
Another remark:
If the Find LyX window is open, a lot of the accelerators are
hijacked. I can't use Alt-X (minibuffer), Alt-P (layout) anymore. I
think these should only be hijacked if one of the two embedded
workareas has the
Tommaso Cucinotta schreef:
Vincent van Ravesteijn ha scritto:
Another remark:
If the Find LyX window is open, a lot of the accelerators are
hijacked. I can't use Alt-X (minibuffer), Alt-P (layout) anymore. I
think these should only be hijacked if one of the two embedded
workareas has the
Pavel Sanda ha scritto:
once you got commit access the situation will quite improve i think.
you probaly know - but just for sure - we have now bug sorted by components
(search is one of them) here: http://www.lyx.org/trac/wiki/Components
Thanks for the notification. I'm not sure all related
Vincent van Ravesteijn - TNW ha scritto:
I could reproduce this as: New, C-S-f, File-CloseBuffer. The attached
patch (you'll likely get offsets, I have other non-committed changes)
closes the dialog if it is open, when closing the document buffer
(and fixed this use-case). May I commit ?
Vincent van Ravesteijn - TNW ha scritto:
- i just got: lassert.cpp(21): ASSERTION view().currentMainWorkArea()
VIOLATED IN GuiWorkArea.cpp:1282 Assertion triggered in void
lyx::doAssert(const char*, const char*, long int) by failing check
false in file lassert.cpp:23
when clicking on the
Tommaso Cucinotta schreef:
Vincent van Ravesteijn - TNW ha scritto:
I could reproduce this as: New, C-S-f, File-CloseBuffer. The attached
patch (you'll likely get offsets, I have other non-committed changes)
closes the dialog if it is open, when closing the document buffer
(and fixed this
Tommaso Cucinotta wrote:
Thanks for the notification. I'm not sure all related bugs have the
component field properly set, however I can check these things when
on contrary i think most of them is correct. i have tried to improve
things in trac last weeks.
I'm back home (now I'm on too
Tommaso Cucinotta wrote:
However, please, Pavel, detail how to reproduce the bug you were
mentioning.
sorry, anyway Vincent made it clear already.
pavel
Pavel Sanda ha scritto:
once you got commit access the situation will quite improve i think.
you probaly know - but just for sure - we have now bug sorted by components
(search is one of them) here: http://www.lyx.org/trac/wiki/Components
Thanks for the notification. I'm not sure all related
Vincent van Ravesteijn - TNW ha scritto:
I could reproduce this as: New, C-S-f, File->CloseBuffer. The attached
patch (you'll likely get offsets, I have other non-committed changes)
closes the dialog if it is open, when closing the document buffer
(and fixed this use-case). May I commit ?
Vincent van Ravesteijn - TNW ha scritto:
- i just got: lassert.cpp(21): ASSERTION view().currentMainWorkArea()
VIOLATED IN GuiWorkArea.cpp:1282 Assertion triggered in void
lyx::doAssert(const char*, const char*, long int) by failing check
"false" in file lassert.cpp:23
when clicking on
Tommaso Cucinotta schreef:
Vincent van Ravesteijn - TNW ha scritto:
I could reproduce this as: New, C-S-f, File->CloseBuffer. The attached
patch (you'll likely get offsets, I have other non-committed changes)
closes the dialog if it is open, when closing the document buffer
(and fixed this
Tommaso Cucinotta wrote:
> Thanks for the notification. I'm not sure all related bugs have the
> "component" field properly set, however I can check these things when
on contrary i think most of them is correct. i have tried to improve
things in trac last weeks.
> I'm back home (now I'm on too
Tommaso Cucinotta wrote:
> However, please, Pavel, detail how to reproduce the bug you were
> mentioning.
sorry, anyway Vincent made it clear already.
pavel
Hello,
this is a patch for providing awareness, within LyXView, of the
distinction between:
- the currently selected buffer (i.e., document buf, search buf, replace
buf), retrieved using
LyXView::buffer()
- the buffer containing the actual document, retrieved using:
LyXView::mainBuffer()
Tommaso Cucinotta wrote:
this is a patch for providing awareness, within LyXView, of the
distinction between:
- the currently selected buffer (i.e., document buf, search buf, replace
buf), retrieved using
LyXView::buffer()
- the buffer containing the actual document, retrieved using:
Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
this is a patch for providing awareness, within LyXView, of the
distinction between:
- the currently selected buffer (i.e., document buf, search buf, replace
buf), retrieved using
LyXView::buffer()
- the buffer containing the actual
Hope now it's more clear.
I already said that the first thing I'd do is to adjust the comments to
mention the difference between normal buffers and buffers in embedded
workareas.
Moreover, a function called mainBuffer() with a comment returns the
document buffer is not very helpful. Then I'd
Tommaso Cucinotta wrote:
While on the GUI side this distinction used to exist through the
GuiView::currentWorkarea() vs GuiView::currentMainWorkArea() methods, on
the model side (LFUN implementation, i.e., from inside LyXFunc.cpp),
currently only the selected WA's buffer was visible,
BTW, some thoughts on the GUI naming:
* I don't think anyone except the developers and some Emacs users know what a
Buffer is. I think we need to come up with better GUI labels than Current
Buffer and All Open Buffers (I do not have anything specific to propose).
* Paragraph in the scope
Jürgen wrote:
A distinction such as Find Replace (Plain Text) ...
and Find Replace (Formatted Text)...
why not simply nuke the latter one?
Ed wrote:
Jürgen wrote:
A distinction such as Find Replace (Plain Text) ...
and Find Replace (Formatted Text)...
why not simply nuke the latter one?
s/latter/former/
edwin
Edwin Leuven wrote:
Jürgen wrote:
A distinction such as Find Replace (Plain Text) ...
and Find Replace (Formatted Text)...
why not simply nuke the latter one?
i wouldn't do this until we have something really usable instead...
my thinking went rather on Find Replace (Experimental )...
Edwin Leuven wrote:
A distinction such as Find Replace (Plain Text) ...
and Find Replace (Formatted Text)...
why not simply nuke the latter one?
You mean the former one? Please no. A small and fast search dialog is still
needed besides the rather complex (and slow) new dialog, IMHO.
A distinction such as Find Replace (Plain Text) ...
and Find Replace (Formatted Text)...
why not simply nuke the latter one?
Because we want to convert it into a small efficient search bar, without
the hassle of the advanced find feature.
Vincent
Pavel Sanda wrote:
i wouldn't do this until we have something really usable instead...
my thinking went rather on Find Replace (Experimental )... ;)
I know you are joking, but if it still deserves the attribute Experimental
at release time, I'll vote for disabling it.
Jürgen
hmm, wouldnt be better to let buffer() for the document
only and add rather different function for lyx find usage
(or buffer(with some params)) ?
I'd guess that for LyXFunc.cpp, we only need to change one line in
dispatch and one in getStatus, because in principle all LFUNs that are
handled
Vincent van Ravesteijn - TNW wrote:
hmm, wouldnt be better to let buffer() for the document
only and add rather different function for lyx find usage
(or buffer(with some params)) ?
I'd guess that for LyXFunc.cpp, we only need to change one line in
dispatch and one in getStatus, because
hmm, wouldnt be better to let buffer() for the document only and add
rather different function for lyx find usage (or buffer(with some
params)) ?
I'd guess that for LyXFunc.cpp, we only need to change one line in
dispatch and one in getStatus, because in principle all LFUNs that
are
Vincent van Ravesteijn - TNW wrote:
if i'm in find window and try to eg. vcs checkout then what?
if we disable it in getstatus we cant use vcs for main document?
Vcs checkout is handled in LyXFunc, so that will be the main/document
buffer by default. I think that should hold for all LFUNs
Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
While on the GUI side this distinction used to exist through the
GuiView::currentWorkarea() vs GuiView::currentMainWorkArea() methods, on
the model side (LFUN implementation, i.e., from inside LyXFunc.cpp),
currently only the selected WA's
Jürgen Spitzmüller ha scritto:
Pavel Sanda wrote:
i wouldn't do this until we have something really usable instead...
my thinking went rather on Find Replace (Experimental )... ;)
I know you are joking, but if it still deserves the attribute Experimental
at release time, I'll vote for
Vincent van Ravesteijn - TNW ha scritto:
Hope now it's more clear.
I already said that the first thing I'd do is to adjust the comments to
mention the difference between normal buffers and buffers in embedded
workareas.
Moreover, a function called mainBuffer() with a comment returns the
Tommaso Cucinotta wrote:
get any crash using it), however I still need some help for identifying
common use cases and possible issues or deviations from the expected
behaviour.
once you got commit access the situation will quite improve i think.
you probaly know - but just for sure - we have
Pavel Sanda wrote:
5 min playing:
another thing - we should rename the file from lyxfin to LyXFind.cpp to stick
to the same naming conventions for our tree.
pavel
Pavel Sanda schreef:
Pavel Sanda wrote:
5 min playing:
another thing - we should rename the file from lyxfin to LyXFind.cpp to stick
to the same naming conventions for our tree.
pavel
You mean that LyXFind.cpp implements the class LyXFind ?
Vincent
Vincent van Ravesteijn wrote:
Pavel Sanda schreef:
Pavel Sanda wrote:
5 min playing:
another thing - we should rename the file from lyxfin to LyXFind.cpp to
stick
to the same naming conventions for our tree.
pavel
You mean that LyXFind.cpp implements the class LyXFind ?
Pavel Sanda schreef:
5 min playing:
- dialog should have tickmark in menu as other panels like toc or browse source
have.
(see status flags)
- the insert-regexp in insert menu should be there? we are overcrowding this
menu
and this is not common inserted inset. also i doubt this should
Hello,
this is a patch for providing "awareness", within LyXView, of the
distinction between:
- the currently selected buffer (i.e., document buf, search buf, replace
buf), retrieved using
LyXView::buffer()
- the buffer containing the actual document, retrieved using:
LyXView::mainBuffer()
Tommaso Cucinotta wrote:
> this is a patch for providing "awareness", within LyXView, of the
> distinction between:
> - the currently selected buffer (i.e., document buf, search buf, replace
> buf), retrieved using
> LyXView::buffer()
> - the buffer containing the actual document, retrieved
Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
this is a patch for providing "awareness", within LyXView, of the
distinction between:
- the currently selected buffer (i.e., document buf, search buf, replace
buf), retrieved using
LyXView::buffer()
- the buffer containing the actual
>Hope now it's more clear.
I already said that the first thing I'd do is to adjust the comments to
mention the difference between normal buffers and buffers in embedded
workareas.
Moreover, a function called "mainBuffer()" with a comment "returns the
document buffer" is not very helpful. Then
Tommaso Cucinotta wrote:
> While on the GUI side this distinction used to exist through the
> GuiView::currentWorkarea() vs GuiView::currentMainWorkArea() methods, on
> the model side (LFUN implementation, i.e., from inside LyXFunc.cpp),
> currently only the selected WA's buffer was visible,
BTW, some thoughts on the GUI naming:
* I don't think anyone except the developers and some Emacs users know what a
"Buffer" is. I think we need to come up with better GUI labels than "Current
Buffer" and "All Open Buffers" (I do not have anything specific to propose).
* "Paragraph" in the
Jürgen wrote:
> A distinction such as "Find & Replace (Plain Text) ..."
> and "Find & Replace (Formatted Text)..."
why not simply nuke the latter one?
Ed wrote:
> Jürgen wrote:
> > A distinction such as "Find & Replace (Plain Text) ..."
> > and "Find & Replace (Formatted Text)..."
>
> why not simply nuke the latter one?
s/latter/former/
edwin
Edwin Leuven wrote:
> Jürgen wrote:
> > A distinction such as "Find & Replace (Plain Text) ..."
> > and "Find & Replace (Formatted Text)..."
>
> why not simply nuke the latter one?
i wouldn't do this until we have something really usable instead...
my thinking went rather on Find & Replace
Edwin Leuven wrote:
> > A distinction such as "Find & Replace (Plain Text) ..."
> > and "Find & Replace (Formatted Text)..."
>
> why not simply nuke the latter one?
You mean the former one? Please no. A small and fast search dialog is still
needed besides the rather complex (and slow) new
>> A distinction such as "Find & Replace (Plain Text) ..."
>> and "Find & Replace (Formatted Text)..."
>
>why not simply nuke the latter one?
>
Because we want to convert it into a small efficient search bar, without
the hassle of the advanced find feature.
Vincent
Pavel Sanda wrote:
> i wouldn't do this until we have something really usable instead...
> my thinking went rather on Find & Replace (Experimental )... ;)
I know you are joking, but if it still deserves the attribute "Experimental"
at release time, I'll vote for disabling it.
Jürgen
>hmm, wouldnt be better to let buffer() for the document
>only and add rather different function for lyx find usage
>(or buffer(with some params)) ?
>
I'd guess that for LyXFunc.cpp, we only need to change one line in
dispatch and one in getStatus, because in principle all LFUNs that are
handled
Vincent van Ravesteijn - TNW wrote:
> >hmm, wouldnt be better to let buffer() for the document
> >only and add rather different function for lyx find usage
> >(or buffer(with some params)) ?
> >
>
> I'd guess that for LyXFunc.cpp, we only need to change one line in
> dispatch and one in
>>>hmm, wouldnt be better to let buffer() for the document only and add
>>>rather different function for lyx find usage (or buffer(with some
>>>params)) ?
>>>
>>
>> I'd guess that for LyXFunc.cpp, we only need to change one line in
>> dispatch and one in getStatus, because in principle all
Vincent van Ravesteijn - TNW wrote:
> >if i'm in find window and try to eg. vcs checkout then what?
> >if we disable it in getstatus we cant use vcs for main document?
>
> Vcs checkout is handled in LyXFunc, so that will be the main/document
> buffer by default. I think that should hold for all
Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
While on the GUI side this distinction used to exist through the
GuiView::currentWorkarea() vs GuiView::currentMainWorkArea() methods, on
the model side (LFUN implementation, i.e., from inside LyXFunc.cpp),
currently only the selected WA's
Jürgen Spitzmüller ha scritto:
Pavel Sanda wrote:
i wouldn't do this until we have something really usable instead...
my thinking went rather on Find & Replace (Experimental )... ;)
I know you are joking, but if it still deserves the attribute "Experimental"
at release time, I'll vote
Vincent van Ravesteijn - TNW ha scritto:
Hope now it's more clear.
I already said that the first thing I'd do is to adjust the comments to
mention the difference between normal buffers and buffers in embedded
workareas.
Moreover, a function called "mainBuffer()" with a comment "returns
Tommaso Cucinotta wrote:
> get any crash using it), however I still need some help for identifying
> common use cases and possible issues or deviations from the expected
> behaviour.
once you got commit access the situation will quite improve i think.
you probaly know - but just for sure - we
Pavel Sanda wrote:
> 5 min playing:
another thing - we should rename the file from lyxfin to LyXFind.cpp to stick
to the same naming conventions for our tree.
pavel
Pavel Sanda schreef:
Pavel Sanda wrote:
5 min playing:
another thing - we should rename the file from lyxfin to LyXFind.cpp to stick
to the same naming conventions for our tree.
pavel
You mean that LyXFind.cpp implements the class LyXFind ?
Vincent
Vincent van Ravesteijn wrote:
> Pavel Sanda schreef:
>> Pavel Sanda wrote:
>>
>>> 5 min playing:
>>>
>>
>> another thing - we should rename the file from lyxfin to LyXFind.cpp to
>> stick
>> to the same naming conventions for our tree.
>>
>> pavel
>>
> You mean that LyXFind.cpp
Pavel Sanda schreef:
5 min playing:
- dialog should have tickmark in menu as other panels like toc or browse source
have.
(see status flags)
- the insert->regexp in insert menu should be there? we are overcrowding this
menu
and this is not common inserted inset. also i doubt this should
74 matches
Mail list logo
