Enrico Forestieri wrote:
> On Thu, May 14, 2009 at 12:49:30PM +0200, Pavel Sanda wrote:
>> Abdelrazak Younes wrote:
>>> My idea was to do that optionally. We would have a generic Log viewer that
>>> will output the file on demand (Or from where you can copy the log content.
>> iirc Peter already h
Enrico Forestieri wrote:
> On Thu, May 14, 2009 at 09:12:44AM +0200, Abdelrazak Younes wrote:
>> Enrico Forestieri wrote:
>>> I don't think so. When I tested what was happening when not running in
>>> a terminal, I saw that Qt was not spawning the process, so I took care
>>> to not use the special
Vincent van Ravesteijn wrote:
The very annoying bug 5465 prevents one from scrolling down when you
come across a large inset. For example, a figure float with a few
subfloats in it, or a very long ERT, or a long table.
The reason is that the cursor cannot be accomodated on a certain row,
when
Is the attached ok ?
Vincent (not so experienced with math yet)
Index: src/mathed/InsetMathNest.cpp
===
--- src/mathed/InsetMathNest.cpp(revision 29669)
+++ src/mathed/InsetMathNest.cpp(working copy)
@@ -1519,7 +1519,
The very annoying bug 5465 prevents one from scrolling down when you
come across a large inset. For example, a figure float with a few
subfloats in it, or a very long ERT, or a long table.
The reason is that the cursor cannot be accomodated on a certain row,
when the inset spreads over the ful
Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> My idea was to do that optionally. We would have a generic Log viewer that
>> will output the file on demand (Or from where you can copy the log content.
>
> iirc Peter already have implemented such kind of log viewer for the latex
> compilation (p
Hi all,
This patch gives the user the possibility to finish a prematurily
finalized macro.
The first part makes sure that no undo is recorded when a macro is
edited, or, when a macro is resumed. The second part replaces the
existing (finalized) MathMacro by a new MathUnknownInset, which is n
Vincent van Ravesteijn wrote:
Steve Litt schreef:
On Thursday 14 May 2009 08:37:19 am Vincent van Ravesteijn - TNW wrote:
Guys,
Where can I hide to shame for writing this piece of code:
Text3.cpp:
465 TextMetrics & tm = bv->textMetrics(this);
466 if (!tm.contains(cur.pit())) {
467 lyx::
Steve Litt schreef:
On Thursday 14 May 2009 08:37:19 am Vincent van Ravesteijn - TNW wrote:
Guys,
Where can I hide to shame for writing this piece of code:
Text3.cpp:
465 TextMetrics & tm = bv->textMetrics(this);
466 if (!tm.contains(cur.pit())) {
467 lyx::dispatch(FuncRequest(LFUN_SCRE
On Thursday 14 May 2009 08:37:19 am Vincent van Ravesteijn - TNW wrote:
> Guys,
>
> Where can I hide to shame for writing this piece of code:
>
> Text3.cpp:
> 465 TextMetrics & tm = bv->textMetrics(this);
> 466 if (!tm.contains(cur.pit())) {
> 467 lyx::dispatch(FuncRequest(LFUN_SCREEN_SHOW_CURS
Hit alt p b, to start an empty bullet list.
Select several lines of text in a terminal window. (Tested on linux)
Use edit->paste special->selection
Note that each line is pasted with the correct list-item layout, except
that the bullets doesn't actually show on screen. Only the first item
has
Thank you all for such helpful responses :-)
I chose Qt Creator but am actually yet to compile LyX for myself.
Pavel:
I've been getting to know python and have had a look at the LFUNs.lxy
generation. My script parses the comments in LyXAction.cpp and outputs
a .lyx file. I'm still ironing out som
Vincent van Ravesteijn - TNW wrote:
Guys,
Where can I hide to shame for writing this piece of code:
Text3.cpp:
465 TextMetrics & tm = bv->textMetrics(this);
466 if (!tm.contains(cur.pit())) {
467 lyx::dispatch(FuncRequest(LFUN_SCREEN_SHOW_CURSOR));
468 tm = bv->textMetrics(this);
4
Hello,
I have a large LyX document and after conversion to LyX 1.6 (at least then I
noticed it for the first time), some longtables were broken (first data line
after heading was missing). A closer investigation showed that the in the
settings dialog of the header, "head" was selected. Deselect
Edwin Leuven wrote:
>> Where can I hide to shame for writing this piece of code:
>
> i suppose in the same cupboard as the rest of us?
But before you crawl there, put it in branch, please.
Jürgen
vincent wrote:
> Where can I hide to shame for writing this piece of code:
i suppose in the same cupboard as the rest of us?
Guys,
Where can I hide to shame for writing this piece of code:
Text3.cpp:
465 TextMetrics & tm = bv->textMetrics(this);
466 if (!tm.contains(cur.pit())) {
467 lyx::dispatch(FuncRequest(LFUN_SCREEN_SHOW_CURSOR));
468 tm = bv->textMetrics(this);
469 }
Anyway, I think bug #5888 is no
On Thu, May 14, 2009 at 12:49:30PM +0200, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
> > My idea was to do that optionally. We would have a generic Log viewer that
> > will output the file on demand (Or from where you can copy the log content.
>
> iirc Peter already have implemented such kind
Abdelrazak Younes wrote:
> My idea was to do that optionally. We would have a generic Log viewer that
> will output the file on demand (Or from where you can copy the log content.
iirc Peter already have implemented such kind of log viewer for the latex
compilation (probably in svn qprocess branc
Am Donnerstag, 14. Mai 2009 schrieb Jean-Marc Lasgouttes:
> uwesto...@lyx.org writes:
>
> > Author: uwestoehr
> > Date: Thu May 14 01:34:09 2009
> > New Revision: 29658
> > URL: http://www.lyx.org/trac/changeset/29658
> >
> > Log:
> > fix SCons after r29657
>
> Yes, sorry, I completely forgot abo
Enrico Forestieri wrote:
On Thu, May 14, 2009 at 09:12:44AM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
I don't think so. When I tested what was happening when not running in
a terminal, I saw that Qt was not spawning the process, so I took care
to not use the special devic
uwesto...@lyx.org writes:
> Author: uwestoehr
> Date: Thu May 14 01:34:09 2009
> New Revision: 29658
> URL: http://www.lyx.org/trac/changeset/29658
>
> Log:
> fix SCons after r29657
Yes, sorry, I completely forgot about that (and cmake too)
JMarc
On Thu, May 14, 2009 at 09:12:44AM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > I don't think so. When I tested what was happening when not running in
> > a terminal, I saw that Qt was not spawning the process, so I took care
> > to not use the special devices for redirection in t
Enrico Forestieri wrote:
I don't think so. When I tested what was happening when not running in
a terminal, I saw that Qt was not spawning the process, so I took care
to not use the special devices for redirection in that case.
I am a bit concerned about the possible performance impact due to th
24 matches
Mail list logo
