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
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
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 s
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 foc
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 foc
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
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 n
Tommaso Cucinotta wrote:
> However, please, Pavel, detail how to reproduce the bug you were
> mentioning.
sorry, anyway Vincent made it clear already.
pavel
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 lo
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 use-c
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 th
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 ?
>> - 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 advanced menu when no bu
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
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 b
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 implemen
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
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
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 ha
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 f
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 th
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 bu
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 LF
>>>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 LF
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,
>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 t
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
>> 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
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,
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 (Exper
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
Jürgen wrote:
> A distinction such as "Find & Replace (Plain Text) ..."
> and "Find & Replace (Formatted Text)..."
why not simply nuke the latter one?
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 scop
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, thr
>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
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 docume
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 usin
37 matches
Mail list logo
