Posting here as well: a user raised on lyx-users the issue to have a
text-based editor for mathematical equations, and the attached patch
just handles this scenario as one more type of external-material that
you can insert by using Insert->File->External Material, and select
"Equation (LaTeX)",
On Mon, Feb 01, 2010 at 07:06:22PM +0100, Andre Poenitz wrote:
> [...]
> pulls in all Gui headers.
Note to self: Always read all mails before starting to answer.
Andre'
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
On Mon, Feb 01, 2010 at 07:00:48AM +0100, kor...@lyx.org wrote:
> Author: kornel
> Date: Mon Feb 1 07:00:46 2010
> New Revision: 33308
> URL: http://www.lyx.org/trac/changeset/33308
>
> Log:
> Make it compilable for QT4.3. (/usr/include/QtGui/qtreeview.h:51: error:
> forward declaration of ‘stru
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
On Monday 01 February 2010 12:36:45 Steve Litt wrote:
> Depends on the user. A lot of us read and create LyX programmatically or
> with a text editor.
I am well aware of that, and appendix of my PhD thesis was created that way.
:-)
I have used a python program to generate the whole lyx file and
Vincent van Ravesteijn - TNW wrote:
> A few issues concerning the Child documents pane:
>
> - I can't seem to figure out how to set the "Include to Output" field to
> yes. If I doubleclick the "No", the only thing that happens is that the
> radiobutton selection goes back to "Include all children
Juergen,
A few issues concerning the Child documents pane:
- I can't seem to figure out how to set the "Include to Output" field to
yes. If I doubleclick the "No", the only thing that happens is that the
radiobutton selection goes back to "Include all children" (while I
explicitly chose Includ
Manoj Rajagopalan wrote:
Hi all
Hi,
Could someone help me understand the difference between
LyXView::currentBufferView() and LyXView::documentBufferView()?
Thanks,
Manoj
currentBufferView() refers to the current BufferView, including for
example the one that is created when you use
>> 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.
Hi all
Could someone help me understand the difference between
LyXView::currentBufferView() and LyXView::documentBufferView()?
Thanks,
Manoj
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
Steve Litt wrote:
> In that case I have no opinion on LuaTeX because it doesn't affect me.
Note that, if we gonna support luatex, it will be supported as just another
backend (next to latex and xetex).
Jürgen
On Monday 01 February 2010 06:44:29 José Matos wrote:
> On Monday 01 February 2010 11:17:54 Peter Kümmel wrote:
> > I don't insist on 2.0. I only think to make the jump to 2.0 now is
> > without a reason. We missed the chance to name it 2.0 when releasing
> > 1.6, so why should we do it now. Assum
On Monday 01 February 2010 05:25:14 Jürgen Spitzmüller wrote:
> Steve Litt wrote:
> > OK, I guess my question is this: If LyX were using LuaTex, what would my
> > LyX document look like in Vim?
>
> A LuaTeX backend would not affect the content of the LyX file, apart from
> some
>
> \use_luatex
On Monday 01 February 2010 05:24:30 Vincent van Ravesteijn - TNW wrote:
> >OK, I guess my question is this: If LyX were using
> >LuaTex, what would my LyX document look like in Vim?
>
> I'd rather make sure you won't need vim anymore :).
>
> Vincent
That's not gonna work. One of my reasons for
On Monday 01 February 2010 11:17:54 Peter Kümmel wrote:
> I don't insist on 2.0. I only think to make the jump to 2.0 now is without
> a reason. We missed the chance to name it 2.0 when releasing 1.6, so why
> should we do it now. Assume we introduce a new file-format,would we relase
> 3.0 then?
José Matos wrote:
> On Friday 29 January 2010 22:38:05 Peter Kümmel wrote:
>> Read the "Table of contents" at
>> http://wiki.lyx.org/LyX/NewInLyX20
>>
>> most looks like "bug/missing-feature" fixing. This is maybe
>> only my perception, but imagine a "non-hacker/user-only" reads
>> this list, he wo
On Friday 29 January 2010 22:38:05 Peter Kümmel wrote:
> Read the "Table of contents" at
> http://wiki.lyx.org/LyX/NewInLyX20
>
> most looks like "bug/missing-feature" fixing. This is maybe
> only my perception, but imagine a "non-hacker/user-only" reads
> this list, he would wonder why we've deci
>OK, I guess my question is this: If LyX were using
>LuaTex, what would my LyX document look like in Vim?
I'd rather make sure you won't need vim anymore :).
Vincent
Steve Litt wrote:
> OK, I guess my question is this: If LyX were using LuaTex, what would my
> LyX document look like in Vim?
A LuaTeX backend would not affect the content of the LyX file, apart from some
\use_luatex 1
statement.
Jürgen
On Monday 01 February 2010 04:06:17 Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
> > > On Friday 29 January 2010 18:41:57 Peter Kümmel wrote:
> > >> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> > >
> > > This example has no content. I'd be interested to see a real LuaTeX
> > >
Edwin Leuven wrote:
> jürgen?
OK from me, as already stated.
Jürgen
jürgen?
http://www.lyx.org/trac/changeset/33088/lyx-devel/trunk
On 01/02/2010 10:18, Kornel Benko wrote:
Am Monday 01 February 2010 schrieb Enrico Forestieri:
On Mon, Feb 01, 2010 at 07:00:48AM +0100, kor...@lyx.org wrote:
Author: kornel
Date: Mon Feb 1 07:00:46 2010
New Revision: 33308
URL: http://www.lyx.org/trac/changeset/33308
Log:
Make it
Am Monday 01 February 2010 schrieb Enrico Forestieri:
> On Mon, Feb 01, 2010 at 07:00:48AM +0100, kor...@lyx.org wrote:
>
> > Author: kornel
> > Date: Mon Feb 1 07:00:46 2010
> > New Revision: 33308
> > URL: http://www.lyx.org/trac/changeset/33308
> >
> > Log:
> > Make it compilable for QT4.3. (
Guenter Milde wrote:
> > On Friday 29 January 2010 18:41:57 Peter Kümmel wrote:
> >> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> >
> > This example has no content. I'd be interested to see a real LuaTeX
> > document in its native format.
>
> AFAIK LuaTeX is an engine (TeX to PDF
On 2010-01-30, Steve Litt wrote:
> On Friday 29 January 2010 18:41:57 Peter Kümmel wrote:
>> Am Freitag, den 29.01.2010, 17:55 -0500 schrieb Steve Litt:
> This example has no content. I'd be interested to see a real LuaTeX
> document in its native format.
AFAIK LuaTeX is an engine (TeX to PDF con
On Mon, Feb 01, 2010 at 07:00:48AM +0100, kor...@lyx.org wrote:
> Author: kornel
> Date: Mon Feb 1 07:00:46 2010
> New Revision: 33308
> URL: http://www.lyx.org/trac/changeset/33308
>
> Log:
> Make it compilable for QT4.3. (/usr/include/QtGui/qtreeview.h:51: error:
> forward declaration of ‘str
On 31/01/2010 21:51, v...@lyx.org wrote:
Author: vfr
Date: Sun Jan 31 21:51:15 2010
New Revision: 33301
URL: http://www.lyx.org/trac/changeset/33301
Log:
Revert r33295. This seems to be a not so great idea. The assert already fires
when copying something.
You can tag an internal buffer as ful
39 matches
Mail list logo
