Tommaso Cucinotta writes:
> Jean-Marc Lasgouttes wrote:
>>> Would the attached patch make sense to both of you?
>>>
> I had worked to a smaller patch concerning only regexp, in which I had
> introduced a REGEXP_CODE, and was using such code in insetAllowed(),
> and I could see regexp insets
Jean-Marc Lasgouttes wrote:
Would the attached patch make sense to both of you?
I had worked to a smaller patch concerning only regexp, in which I had
introduced a REGEXP_CODE, and was using such code in insetAllowed(), and
I could see regexp insets inside ERTs and URLs. Probably I can reb
Jean-Marc Lasgouttes writes:
> "Vincent van Ravesteijn - TNW" writes:
>> I wouldn't handle LFUN_REGEXP_MODE twice in one function. That's prone
>> to cause confusion later (I don't really understand the others that are
>> handled twice).
>
> Would the attached patch make sense to both of you?
>
"Vincent van Ravesteijn - TNW" writes:
> I wouldn't handle LFUN_REGEXP_MODE twice in one function. That's prone
> to cause confusion later (I don't really understand the others that are
> handled twice).
Would the attached patch make sense to both of you?
> More important, I'm still not sure why
F&*#&#*#*##*
the relevant line for this is in Inset.h:
///
bool insetAllowed(InsetCode) const { return !getLayout().isPassThru(); }
So, no inset is allowed in anything that has a passthru layout.
In these case cur.nextInset() will be zero.
The code would then be:
if (cur.nextInset())
>hmmm, looking at the preceding line:
>
>cur.insert(new InsetMathHull(cur.buffer(), hullRegexp));
>if (cur.nextInset()) {
>cur.nextInset()->edit(cur, true);
>cur.niceInsert(sel);
>}
>
>What happens now is that the cur.insert() call is made a
Vincent van Ravesteijn - TNW wrote:
if (cur.nextInset()) {
cur.nextInset()->edit(cur, true);
cur.niceInsert(sel);
}
prevents the crash, but the regexp inset seems to not have been
inserted
at all (or, if it is, then it is not shown and the cursor cannot
naviga
>> More important, I'm still not sure why we forbid the REGEXP_MODE in
>> ERTs. Why does LyX crash ?
>It's happening here: Text::regexpDispatch()
>
> cur.nextInset()->edit(cur, true);
>
>simply replacing with
>
>if (cur.nextInset()) {
>cur.nextInset()->edit(cur, true);
>cur.
Vincent van Ravesteijn - TNW wrote:
More important, I'm still not sure why we forbid the REGEXP_MODE in
ERTs. Why does LyX crash ?
It's happening here: Text::regexpDispatch()
cur.nextInset()->edit(cur, true);
simply replacing with
if (cur.nextInset()) {
cur.nextInset()->edit(cur, t
Jean-Marc Lasgouttes wrote:
ERT is built around the assumption that it does not contain insets.
This may be unfortunate, but we have to be careful.
An alternative possibility is to let the user specify the regular
expression by a special syntax in those insets only, e.g.:
Insert->URL, then type
> So, code is just MATH_CODE and you can have no special rules for regular
expressions opposed to math insets.
Being able to embed math also into ERT seems reasonable to me. Eg. I
have ERT insets that look like the following:
\begin{algorithm}
\FOR $\phi$ \in $\Phi$ \DO
$y_\phi$ := $\frac
>Finally, for the implementation right now, I propose to mimick what is
>done for the various LFUN_xxx_INSERT and use the "code" helper
variable.
This is not really possible as the RegExps are no real insets right now,
so there is no REGEXP_CODE and BufferView::regexpDispatch(..) now
creates a I
Le 01/02/2010 14:27, Vincent van Ravesteijn - TNW a écrit :
More important, I'm still not sure why we forbid the REGEXP_MODE in
ERTs. Why does LyX crash ? Why is this only happening for ERTs ? Aren't
there any other insets which can crash for the same reason ? Why
wouldn't it be possible to searc
Vincent van Ravesteijn - TNW wrote:
More important, I'm still not sure why we forbid the REGEXP_MODE in
ERTs.
Because that one would be the quickest way to avoid the crash for now,
but we would keep a "feature enhancement" ticket asking for supporting
regular expression also inside passthru ins
>Which other insets would be pass_thru ?
URLs and Program Listings and possibly Custom Insets defined by the user
(see lib/stdinsets.inc).
> > Compare with :
> >
> > text3@2659:
> >
> > if (cur.empty()
> > || !cur.inset().insetAllowed(code)
> > || cur.paragraph().layout().pass_
>>> Last, why is the status of LFUN_REGEXP_MODE handled in
BufferView.cpp
>>> while the dispatch is in Text3.cpp. Moreover, I would expect it to
be
>>> next to LFUN_MATH_MODE as they seem to be related.
>> Probably should be moved to Text3.cpp.
>For example, see attachment (behaviour is apparen
On 01/31/2010 06:17 PM, Tommaso Cucinotta wrote:
Vincent van Ravesteijn wrote:
By the way, are you sure that ERT is the only inset that should be
excluding, or does this hold for all passThru Insets ? Then you
should cur.paragraph().layout().pass_thru.
Not of course: what is pass_through?
It
Tommaso Cucinotta wrote:
Last, why is the status of LFUN_REGEXP_MODE handled in BufferView.cpp
while the dispatch is in Text3.cpp. Moreover, I would expect it to be
next to LFUN_MATH_MODE as they seem to be related.
Probably should be moved to Text3.cpp.
For example, see attachment (behaviour
Vincent van Ravesteijn wrote:
By the way, are you sure that ERT is the only inset that should be
excluding, or does this hold for all passThru Insets ? Then you
should cur.paragraph().layout().pass_thru.
Not of course: what is pass_through ? At a glance, it seems a
par-style/layout related thi
Tommaso Cucinotta schreef:
Vincent van Ravesteijn wrote:
!dynamic_cast(&cur.inset()));
I don't understand what this means. Is this the same as:
cur.inset().lyxCode() != ERT_CODE);
? If so, I'd favor this simple notation.
Yes, it is the same (language-level type recognition vs hand-code
Vincent van Ravesteijn wrote:
!dynamic_cast(&cur.inset()));
I don't understand what this means. Is this the same as:
cur.inset().lyxCode() != ERT_CODE);
? If so, I'd favor this simple notation.
Yes, it is the same (language-level type recognition vs hand-coded
lyx-specific one).
Foll
tomm...@lyx.org schreef:
Author: tommaso
Date: Sun Jan 31 22:38:18 2010
New Revision: 33302
URL: http://www.lyx.org/trac/changeset/33302
Log:
Inhibits insertion of Regexp insets within InsetERT context (and fixes #6495).
Modified:
lyx-devel/trunk/src/BufferView.cpp
Modified: lyx-devel/trunk
22 matches
Mail list logo
