Re: [PATCH] Improve decimal alignment in tables
On 02/02/13 22:27, Pavel Sanda wrote: Martin Vermeer wrote: I added code to InsetMathNest to turn autocorrection off for cursor up or down (e.g., in an array), from the philosophy that having autocorrection on should be a conscious choice, not something you get stuck in. (Of course pressing the spacebar always gets you out). I don't know whether or not this new feature is a good idea... take it or leave it. But now I think with this patch both the code and its behaviour will be a little more transparent. It is alredy part of feature list of LyX 2.0, he "leave part" is not so easy now. Better to fix the remaining issue(s). Pavel I have a vague recollection of having been asked this bug question before, and giving a similar response / patch proposal, which was never committed ;-/ Martin
[PATCH]: \url crash bug (Re: [PATCH] Improve decimal alignment in tables)
Here is another patch to fix a TeX crash I ran into: if you have a text
containing a \url and you apply a text attribute (like 'small') to it,
you get it inserted inside the url:
{\small abc}\url{\small def}{\small ghi}
making TeX crash royally.
Martin
diff --git a/lib/layouts/stdinsets.inc b/lib/layouts/stdinsets.inc
index 2c4eb4f..1054254 100644
--- a/lib/layouts/stdinsets.inc
+++ b/lib/layouts/stdinsets.inc
@@ -387,6 +387,7 @@ InsetLayout "Flex:URL"
PassThru true
FreeSpacing true
ForceLTR true
+ ResetsFontfalse
Font
Family Typewriter
Color urltext
Re: [PATCH] Improve decimal alignment in tables
On 02/02/13 10:41, Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
Here is another patch from our own Martin Vermeer improving support for
aligning on decimal point in tables. Unfortunately, since I do not use this
at all, I am not able to see whether this is an improvement for all use
cases.
Please comment.
JMarc
Message original
Sujet: Re: Small LyX patch
Date : Fri, 01 Feb 2013 13:31:52 +0200
De : Martin Vermeer
Répondre ? : martin.verm...@aalto.fi
Pour : Jean-Marc Lasgouttes
On 29/01/13 15:33, Martin Vermeer wrote:
On 2013-01-29 11:22, Jean-Marc Lasgouttes wrote:
Le 29/01/2013 06:50, Martin Vermeer a écrit :
Talking about wish lists, here's another one: it's really nice that the
decimal alignment trick for tabular described in the literature in
implemented. However, it still doesn't cover a use case that I have run
into: aligning decimal numbers (like 123,45) with numbers without a
decimal comma (like 6789). The limitation is caused by two roles of the
decimal symbol being mixed up: 1) as an alignment marker, i.e.,
where to
put the inter-column marker &; and 2) as the decimal symbol to be
inserted, i.e., what goes into the @{,} in the tabular format string.
These two roles should be separated (and my use case would be
covered by
using and , respectively, and writing 123,,45 and 6789,)
This is beyond my knowledge...
JMarc
Sure... but someone wrote this code ;-)
That someone is IIRC Edwin.
Martin, when you made the mistake to appear here on list, could you have a look
at http://www.lyx.org/trac/ticket/7865 ?
Pavel
Sure Pavel, see attached.
Explanation: for some reason autocorrect() also appears in Cursor.cpp,
and the occurrences in Backspace and Delete silently turn
auto-correction off. So do the occurrences in Cursor Up and Cursor Down,
but I have not been able to have this code triggered from mathed... so I
just removed them.
I added code to InsetMathNest to turn autocorrection off for cursor up
or down (e.g., in an array), from the philosophy that having
autocorrection on should be a conscious choice, not something you get
stuck in. (Of course pressing the spacebar always gets you out). I don't
know whether or not this new feature is a good idea... take it or leave
it. But now I think with this patch both the code and its behaviour will
be a little more transparent.
...and I didn't remember my login details for lyx-devel :-)
Cheers
Martin
diff --git a/src/Cursor.cpp b/src/Cursor.cpp
index 4469875..23db7bc 100644
--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -1525,8 +1525,6 @@ void Cursor::insert(MathData const & ar)
bool Cursor::backspace()
{
- autocorrect() = false;
-
if (selection()) {
cap::eraseSelection(*this);
return true;
@@ -1577,7 +1575,6 @@ bool Cursor::backspace()
bool Cursor::erase()
{
- autocorrect() = false;
if (inMacroMode())
return true;
@@ -1632,7 +1629,6 @@ bool Cursor::up()
if (disp_.dispatched())
return true;
setCursor(save);
- autocorrect() = false;
return false;
}
@@ -1646,7 +1642,6 @@ bool Cursor::down()
if (disp_.dispatched())
return true;
setCursor(save);
- autocorrect() = false;
return false;
}
diff --git a/src/mathed/InsetMathNest.cpp b/src/mathed/InsetMathNest.cpp
index 86920e1..0b24a1d 100644
--- a/src/mathed/InsetMathNest.cpp
+++ b/src/mathed/InsetMathNest.cpp
@@ -706,6 +706,10 @@ void InsetMathNest::doDispatch(Cursor & cur, FuncRequest & cmd)
act == LFUN_UP_SELECT;
cur.selHandle(select);
+ // handle autocorrect:
+ cur.autocorrect() = false;
+ cur.message(_("Autocorrect Off ('!' to enter)"));
+
// go up/down
bool up = act == LFUN_UP || act == LFUN_UP_SELECT;
bool successful = cur.upDownInMath(up);
Re: lyx math autocorrection
On Mon, Jun 20, 2011 at 11:37:01AM +0200, Jean-Marc Lasgouttes wrote: > Le 18/06/2011 00:41, Uwe Stöhr a écrit : > >Am 17.06.2011 16:34, schrieb Jean-Marc Lasgouttes: > > > >>>I enabled the autocorrection mode for math in the preferences and > >>>therefore expect that > >>>autocorrection is by default on. But it is not. It only works if I > >>>enter "!" in an equation. But > >>>as soon as I leave the equation it is turn off again. So for every > >>>new equation or when I return > >>>to the equation, I again and again have to type ! to get it working. > >>>Is this a bug or intended? > >> > >>I think it is intended, because the autocorrection may stop on your toes. > > > >What do you mean with "stop on your toes"? > > I meant "step on your toes". > > >>But of course this could be changed. > > > > From the logic, as an average user I would expect that ofter enabling > >auto correction, this feature is always available. > > I do not have enough experience with the feature to understand > whether it can become more annoying than helpful. The change has > been added by Martin vermeer: > > r28008 | vermeer | 2009-01-06 10:44:47 +0100 (mar. 06 janv. 2009) | 4 lignes > > Make autocorrect (still disabled) better. Now switched > on/off by !/space. > > > We'd have to look at mailing list discussions around this date to > understand whether this was fixing a real need or just being overly > cautious. André, do you remember about it? > > JMarc (Overly?) cautious, I think. Someone (André?) turned it off because there were still some warts. I turned it conditionally on again because I judged it useful in spite of this. Martin
Re: #6261: Autocorrection problems
On Tue, 07 Dec 2010 03:49:12 + LyX Ticket Tracker wrote: > #6261: Autocorrection problems > -+-- > Reporter: sanda| Owner: lasgouttes > Type: defect | Status: new > Priority: normal | Milestone: 2.0.0 > Component: general | Version: 2.0.0svn > Severity: normal |Keywords: > -+-- > > Comment(by sanda): > > Martin, are you totally gone or can still look...? Actually I am pretty much gone... this error does not ring a bell. Martin
Re: Did I ever mention how much I like LyX?
On Fri, 12 Mar 2010 14:25:13 +1300 john wrote: > Steve Litt wrote: > > Hi all, > > > > Did I ever mention how much I like LyX? It's wonderful. I'm writing my new > > book right now, and LyX is so easy and transparent that I'm pounding out an > > average of 3,000 words per day. LyX just stays out of your way and let's > > you > > whomp out content. It's great. > > > > Thanks to the developers for making this great bookmaking software, and the > > community for making it better and providing information. > > > Amen to that! > It's my favourite piece of software and has been for more than a decade! > > John O'Gorman Hmm, yesterday I showed LyX to a colleague -- installed it and demoed it on her Ubuntu laptop, in the space of half an hour, quietly while both of us were listening to a seminar presentation. Smooth as silk. She was sold solid, started writing straightaway. Martin > > SteveT > > > > Steve Litt > > Recession Relief Package > > http://www.recession-relief.US > > Twitter: http://www.twitter.com/stevelitt > > > > > > > > >
Re: Branches…
On Tue, 02 Mar 2010 11:35:28 +0100 jezZiFeR wrote: > Dear listmembers, > > is is possible to print just branches, not the main text? To select > some branches und to compile just them? > > Thanks for your help > Jess Sure... just put the main text in a branch of its own, and disable it. Martin
Re: palabras que aparecen en inglés
On Thu, 26 Nov 2009 21:04:23 -0800 (PST) m s wrote: > > > --- El vie 27-nov-09, m s escribió: > > > De: m s > Asunto: > Para: lyx-devel@lists.lyx.org > Fecha: viernes, 27 de noviembre de 2009, 3:00 am > > > > > > > Quiero informarles que al escribir documento y también en el DVI las palabras > CONTENTS, CHAPTER y BIBLIOGRAPHY aparecen en inglés aunque el texto que > escribo esté en español. Cómo cambiar eso?. Tengo la versión LYX 1.6. You may want to check the menu Document -> Settings -> Language (in the Settings panel). It should be Spanish. Just writing the text in Spanish is not enough. You may want to save it as the class default if you write mostly Spanish documents. BTW this is a question for the user list. Hope this helps
Re: Beware! Arsene is coming !
On Wed, 26 Aug 2009 01:55:56 +0200 Jean-Marc Lasgouttes wrote: > Some people say that good things always come to an end, but this implies > that good things have to start at some point too. I am glad to announce > the birth of our third child Arsène (who is thus a boy, for those of you > who slept during French literature courses) this morning. > > I will skip the scary numbers and just mention that he is kind of perfect. > > Have a very nice day. > > JMarc So I should beware ;-) http://fr.wikipedia.org/wiki/Arpène_Lucien Congratulations Jean-Marc! And you Arsène of course... Martin
Re: Code swarm for LyX
On Fri, 14 Aug 2009 20:33:25 +0200 Lars Gullik Bjønnes wrote: > For your enjoyment: > > Attaching torrent to get it. What happened to the sound? ;-)
Re: r30564 - lyx-devel/trunk/src/insets
On Tue, 14 Jul 2009 15:47:25 +0200
Jean-Marc Lasgouttes wrote:
> Le 14 juil. 09 à 15:32, lasgout...@lyx.org a écrit :
> > + // FIXME this use of forceLTR is dubious
> > + // introduced in http://www.lyx.org/trac/changeset/21285
> > + if (getLayout().isForceLtr()) {
> > + // Force any new text to latex_language FIXME: This
> > + // should only be necessary in constructor, but new
> > + // paragraphs that are created by pressing enter at
> > + // the start of an existing paragraph get the buffer
> > + // language and not latex_language, so we take this
> > + // brute force approach.
> > + cur.current_font.setLanguage(latex_language);
> > + cur.real_current_font.setLanguage(latex_language);
> > + }
> > +
>
> I have copied the code above from InsetCollapsable, but I do not
> understand the logic.
> forceLTR is defined as:
> /// Force inset into LTR environment if surroundings are RTL?
> virtual bool forceLTR() const;
>
> I suspect the right thing to use is getLayout().isPassthru.
>
> Martin, do you remember why you chose that instead?
>
> JMarc
No... but as the comment says, it is probably overkill.
- Martin
Re: Add math autocorrect to RC file
On Tue, 23 Jun 2009 10:45:24 +0200 Jean-Marc Lasgouttes wrote: > Martin Vermeer writes: > >> this is due to the migration to our new server. please contact JMarc > >> for setting an account for you, it should be quite easy now. > > > > Perhaps... but doesn't look like I'll be contributing any time soon > > now. Real Life is rampant :-( > > So do you want an account? A @lyx.org mail address? Yes please... no please. > JMarc - Martin
Re: Add math autocorrect to RC file
On Sun, 14 Jun 2009 00:27:16 +0200 Pavel Sanda wrote: > Martin Vermeer wrote: > > On Wed, 14 Jan 2009 13:22:54 +0100 > > Pavel Sanda wrote: > > > > > Martin Vermeer wrote: > > > > As in the attached. This makes it possible to enable autocorrection in > > > > the preferences file. > > > > > > would it be possible to add some list of autocorrected things into some > > > of our manual? > > > > Hmmm, yes. > > Martin, i have added gui checkbox for autocorrection. would it be possible to > add some info > how this works in our manual? pavel > > > > it may be worth to add checkbox into preferences gui. > > > > That was the next step in my world domination plan ;-) > > > > Only, I'm rather lost with this qt stuff. > > > > > pavel > > > > - Martin Thanks Pavel. It works like this: for certain predefined key sequences like => typing the sequence will lead to a \Rightarrow appearing in Math. Unfortunately I don't have a working lyx in svn now... no working account. So I cannot check how it works. What I remember is that you can leave autocorrect mode by pressing and re-enter it by pressing . The sequences recognized are listed in lib/autocorrect. - Martin BTW Some guys at Turku University have implemented a facility for writing structured derivations (i.e., math text with collapsable subderivations etc. etc.) in LyX. Looks quite impressive. The source is here: http://users.abo.fi/psallasm/src/ Would there be an interest in having this in trunk? - Martin
Re: Amir Younes is born
On Mon, 13 Apr 2009 23:41:36 +0200 Abdelrazak Younes wrote: > As I leaked the highly important news that my wife was pregnant > (whatever JMarc says), I'd thought I should announce formally that this > state of affair finally led to a small cute little guy named Amir :-) > The mother (Aya) is doing very well. > > I guess this also means that this won't help my increasing absence in > LyX development :-) > > Cheers, > Abdel. Congratulations Abdel! Doesn't 'Amir' mean 'commander'? Is he already commanding you around? Cheers Martin
Re: Update on aussie phaseout and new server
On Mon, 16 Mar 2009 23:26:33 +0100 Jean-Marc Lasgouttes wrote: > > Question: how is this server maintained? Do we have good reasons to be > confident that it will stay afloat better than aussie did? Actually aussie did pretty well given its age. Perhaps we owe Trolltech a note of thank you. > JMarc - Martin
Re: LyX sourceforge.net subversion repository
On Sat, Mar 07, 2009 at 01:53:36PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz > > writes: > > | On Sat, Mar 07, 2009 at 11:54:23AM +0100, Jean-Marc Lasgouttes wrote: > >> Andre Poenitz writes: > >> > How much effort is it to syncronize two svn repos? > >> > >> I do not know whether rsync can do that, or if a svn repo is just a huge > >> file. Bo? > > > | An svn repo a lots of small files, rsync would be fine if it were > | available... > > Not if both repos are going to be live (one read-only) > > -- > Lgb How about Unison? Then both could be live. And commitable. - Martin
Re: An idea
On Wed, 18 Feb 2009 13:22:32 -0500 Manoj Rajagopalan wrote: > Hi Darlington, > >Equation cross-referencing is basic to LyX but there is a procedure > to going about this. > > 1. Use Insert->Math->Numbered Formula or Ctrl+Alt+N to create a numbered > formula. This should start an equation on a new line and should show a > (#) sign. You don't even have to do that... just insert a (display-style) formula. The 'Insert->Label' menu option will show when the cursor is inside such a formula. > 2. Position the cursor within the equation environment and click > Insert->Label and type in some name that helps you remember this > equation. It is customary though not mandatory to start equation labels > with 'eq:'. > 3. Position the cursor at the point you want to reference this equation > and then click Insert->Cross Reference. Then select the equation from > the list of labels you have previously created. > 3a. The options in the Format combo box allow you to select the style > for that reference, i.e., (eqn#) or eqn# or the page # for that eqn. etc. > >Does this answer your question? The LyX User Guide explains all this. > -- Manoj > > > Hove, Darlington (Mr) (s208093670) wrote: > > To whom it may concern > > > > I have recently started using Lyx and I must say it is a good word > > processing package. It has made my work easier than the traditional Latex > > version. However I feel there is one area that should be changed without > > delay. > > > > As a mathematician, I tend to come across many equations and more often > > than not, I have to refer and cross refer between equations. Now, from my > > experience with lyx, I am not able to reference an equation save for a > > section or a page. Now this to me needs correction and if you could look > > into this matter, it would help many potential lyx users out there. > > > > I would be very happy if my contribution receives feedback otherwise I am > > looking forward to hearing from you. > > > > Regards, > > > > > > Darlington Hove > > > > NOTICE: Please note that this eMail, and the contents thereof, is subject > > to the standard NMMU eMail disclaimer which may be found at: > > http://www.nmmu.ac.za/disclaimer/email.htm > > > > > > > >
Re: Add math autocorrect to RC file
On Wed, 14 Jan 2009 14:37:47 +0100
Jean-Marc Lasgouttes wrote:
> Martin Vermeer writes:
> > + // leave autocorrect mode if necessary
> > + if (autocorrectEnabled(cur) && c == ' ' && cur.autocorrect()) {
>
> Two questions (probably related)
> - why do you pass cur to autocorrectEnabled, whereas it does not rely on
> the cursor?
Hrmf.
> - why not put the cur.autocorrect() test into autocorrectEnabled, sicne
> they are always used together? Or maybe move the lyxrc check into
> Cursor::autocorrect.
>
> JMarc
Eh, how do you handle this:
if (autocorrectEnabled()) {
if (!cur.autocorrect())
cur.message(_("Autocorrect Off ('!' to enter)"));
else
cur.message(_("Autocorrect On ( to exit)"));
}
- Martin
Index: LyXRC.h
===
--- LyXRC.h (revision 28149)
+++ LyXRC.h (working copy)
@@ -38,6 +38,7 @@
enum LyXRCTags {
RC_ACCEPT_COMPOUND = 1,
RC_ALT_LANG,
+ RC_AUTOCORRECTION_MATH,
RC_PLAINTEXT_LINELEN,
RC_PLAINTEXT_ROFF_COMMAND,
RC_AUTOREGIONDELETE,
@@ -438,6 +439,8 @@
///
int completion_inline_dots;
///
+ bool autocorrection_math;
+ ///
double completion_popup_delay;
///
bool completion_popup_math;
Index: mathed/InsetMathNest.cpp
===
--- mathed/InsetMathNest.cpp (revision 28149)
+++ mathed/InsetMathNest.cpp (working copy)
@@ -10,8 +10,6 @@
#include
-//#define AUTOCORRECT
-
#include "InsetMathNest.h"
#include "InsetMathArray.h"
@@ -27,9 +25,7 @@
#include "InsetMathSpace.h"
#include "InsetMathSymbol.h"
#include "InsetMathUnknown.h"
-#ifdef AUTOCORRECT
#include "MathAutoCorrect.h"
-#endif
#include "MathCompletionList.h"
#include "MathData.h"
#include "MathFactory.h"
@@ -1519,22 +1515,18 @@
return true;
}
- // This is annoying as one has to press far too often.
- // Disable it.
-#ifdef AUTOCORRECT
- // leave autocorrect mode if necessary
- if (c == ' ' && cur.autocorrect()) {
- cur.autocorrect() = false;
- cur.message(_("Autocorrect Off ('!' to enter)"));
- return true;
- }
- if (c == '!' && !cur.autocorrect()) {
- cur.autocorrect() = true;
- cur.message(_("Autocorrect On ( to exit)"));
- return true;
- }
-#endif
+ // leave autocorrect mode if necessary
+ if (autocorrectEnabled() && c == ' ' && cur.autocorrect()) {
+ cur.autocorrect() = false;
+ cur.message(_("Autocorrect Off ('!' to enter)"));
+ return true;
+ }
+ if (autocorrectEnabled() && c == '!' && !cur.autocorrect()) {
+ cur.autocorrect() = true;
+ cur.message(_("Autocorrect On ( to exit)"));
+ return true;
+ }
// just clear selection on pressing the space bar
if (cur.selection() && c == ' ') {
@@ -1631,20 +1623,18 @@
}
-#ifdef AUTOCORRECT
// try auto-correction
- if (cur.autocorrect() && cur.pos() != 0 && math_autocorrect(cur.prevAtom(), c))
+ if (autocorrectEnabled() && cur.autocorrect() && cur.pos() != 0 && math_autocorrect(cur.prevAtom(), c))
return true;
-#endif
// no special circumstances, so insert the character without any fuss
cur.insert(c);
-#ifdef AUTOCORRECT
- if (!cur.autocorrect())
- cur.message(_("Autocorrect Off ('!' to enter)"));
- else
- cur.message(_("Autocorrect On ( to exit)"));
-#endif
+ if (autocorrectEnabled()) {
+ if (!cur.autocorrect())
+ cur.message(_("Autocorrect Off ('!' to enter)"));
+ else
+ cur.message(_("Autocorrect On ( to exit)"));
+ }
return true;
}
@@ -1732,6 +1722,12 @@
}
+bool InsetMathNest::autocorrectEnabled() const
+{
+ return lyxrc.autocorrection_math;
+}
+
+
bool InsetMathNest::completionSupported(Cursor const & cur) const
{
return cur.inMacroMode();
Index: mathed/InsetMathNest.h
===
--- mathed/InsetMathNest.h (revision 28149)
+++ mathed/InsetMathNest.h (working copy)
@@ -112,6 +112,8 @@
bool mouseHovered() const { return mouse_hover_; }
///
+ bool autocorrectEnabled() const;
+ ///
bool completionSupported(Cursor const &) const;
///
bool inlineCompletionSupported(Cursor const & cur) const;
Index: LyXRC.cpp
===
--- LyXRC.cpp (revision 28149)
+++ LyXRC.cpp (working copy)
@@ -58,6 +58,7 @@
{ "\\auto_number", LyXRC::RC_AUTO_NUMBER },
{ "\\auto_region_delete", LyXRC::RC_AUTOREGIONDELETE },
{ "\\auto_reset_options", LyXRC::RC_AUTORESET_OPTIONS
Re: Add math autocorrect to RC file
On Wed, 14 Jan 2009 13:22:54 +0100 Pavel Sanda wrote: > Martin Vermeer wrote: > > As in the attached. This makes it possible to enable autocorrection in the > > preferences file. > > would it be possible to add some list of autocorrected things into some of > our manual? Hmmm, yes. > it may be worth to add checkbox into preferences gui. That was the next step in my world domination plan ;-) Only, I'm rather lost with this qt stuff. > pavel - Martin
Add math autocorrect to RC file
As in the attached. This makes it possible to enable autocorrection in the
preferences file.
- Martin
Index: LyXRC.h
===
--- LyXRC.h (revision 28149)
+++ LyXRC.h (working copy)
@@ -38,6 +38,7 @@
enum LyXRCTags {
RC_ACCEPT_COMPOUND = 1,
RC_ALT_LANG,
+ RC_AUTOCORRECTION_MATH,
RC_PLAINTEXT_LINELEN,
RC_PLAINTEXT_ROFF_COMMAND,
RC_AUTOREGIONDELETE,
@@ -438,6 +439,8 @@
///
int completion_inline_dots;
///
+ bool autocorrection_math;
+ ///
double completion_popup_delay;
///
bool completion_popup_math;
Index: mathed/InsetMathNest.cpp
===
--- mathed/InsetMathNest.cpp (revision 28149)
+++ mathed/InsetMathNest.cpp (working copy)
@@ -10,8 +10,6 @@
#include
-//#define AUTOCORRECT
-
#include "InsetMathNest.h"
#include "InsetMathArray.h"
@@ -27,9 +25,7 @@
#include "InsetMathSpace.h"
#include "InsetMathSymbol.h"
#include "InsetMathUnknown.h"
-#ifdef AUTOCORRECT
#include "MathAutoCorrect.h"
-#endif
#include "MathCompletionList.h"
#include "MathData.h"
#include "MathFactory.h"
@@ -1519,22 +1515,18 @@
return true;
}
- // This is annoying as one has to press far too often.
- // Disable it.
-#ifdef AUTOCORRECT
- // leave autocorrect mode if necessary
- if (c == ' ' && cur.autocorrect()) {
- cur.autocorrect() = false;
- cur.message(_("Autocorrect Off ('!' to enter)"));
- return true;
- }
- if (c == '!' && !cur.autocorrect()) {
- cur.autocorrect() = true;
- cur.message(_("Autocorrect On ( to exit)"));
- return true;
- }
-#endif
+ // leave autocorrect mode if necessary
+ if (autocorrectEnabled(cur) && c == ' ' && cur.autocorrect()) {
+ cur.autocorrect() = false;
+ cur.message(_("Autocorrect Off ('!' to enter)"));
+ return true;
+ }
+ if (autocorrectEnabled(cur) && c == '!' && !cur.autocorrect()) {
+ cur.autocorrect() = true;
+ cur.message(_("Autocorrect On ( to exit)"));
+ return true;
+ }
// just clear selection on pressing the space bar
if (cur.selection() && c == ' ') {
@@ -1631,20 +1623,18 @@
}
-#ifdef AUTOCORRECT
// try auto-correction
- if (cur.autocorrect() && cur.pos() != 0 && math_autocorrect(cur.prevAtom(), c))
+ if (autocorrectEnabled(cur) && cur.autocorrect() && cur.pos() != 0 && math_autocorrect(cur.prevAtom(), c))
return true;
-#endif
// no special circumstances, so insert the character without any fuss
cur.insert(c);
-#ifdef AUTOCORRECT
- if (!cur.autocorrect())
- cur.message(_("Autocorrect Off ('!' to enter)"));
- else
- cur.message(_("Autocorrect On ( to exit)"));
-#endif
+ if (autocorrectEnabled(cur)) {
+ if (!cur.autocorrect())
+ cur.message(_("Autocorrect Off ('!' to enter)"));
+ else
+ cur.message(_("Autocorrect On ( to exit)"));
+ }
return true;
}
@@ -1732,6 +1722,12 @@
}
+bool InsetMathNest::autocorrectEnabled(Cursor const & cur) const
+{
+ return lyxrc.autocorrection_math;
+}
+
+
bool InsetMathNest::completionSupported(Cursor const & cur) const
{
return cur.inMacroMode();
Index: mathed/InsetMathNest.h
===
--- mathed/InsetMathNest.h (revision 28149)
+++ mathed/InsetMathNest.h (working copy)
@@ -112,6 +112,8 @@
bool mouseHovered() const { return mouse_hover_; }
///
+ bool autocorrectEnabled(Cursor const & cur) const;
+ ///
bool completionSupported(Cursor const &) const;
///
bool inlineCompletionSupported(Cursor const & cur) const;
Index: LyXRC.cpp
===
--- LyXRC.cpp (revision 28149)
+++ LyXRC.cpp (working copy)
@@ -58,6 +58,7 @@
{ "\\auto_number", LyXRC::RC_AUTO_NUMBER },
{ "\\auto_region_delete", LyXRC::RC_AUTOREGIONDELETE },
{ "\\auto_reset_options", LyXRC::RC_AUTORESET_OPTIONS },
+ { "\\autocorrection_math", LyXRC::RC_AUTOCORRECTION_MATH },
{ "\\autosave", LyXRC::RC_AUTOSAVE },
{ "\\backupdir_path", LyXRC::RC_BACKUPDIR_PATH },
{ "\\bibtex_command", LyXRC::RC_BIBTEX_COMMAND },
@@ -314,6 +315,7 @@
completion_popup_text = false;
completion_popup_delay = 2.0;
completion_popup_after_complete = true;
+ autocorrection_math = false;
completion_inline_math = true;
completion_inline_text = false;
completion_inline_dots = -1;
@@ -711,6 +713,10 @@
lexrc >> completion_inline_dots;
break;
+ case RC_AUTOCORRECTION_MATH:
+ lexrc >> autocorrection_math;
+ break;
+
case RC_COMPLETION_POPUP_DELAY:
lexrc >> completion_popup_delay;
break;
@@ -1968,6 +1974,14 @@
}
if (tag != RC_LAST)
break;
+ case RC_AUTOCORRECTION_MATH:
+ if (ignore_system_lyxrc ||
+ autocorrection_math != system_lyxrc.autocorrection_math) {
+ os << "\\autocorrection_math "
+<< convert(autocorrection_math) << '\n';
+ }
+ if (tag != RC_LAST)
+ break;
case RC_COMPLETION_POPUP_DELAY:
if (ignore_system_lyxrc ||
completion_popup_delay != system_lyxrc.completion_popup_delay) {
@@ -2652,6 +2
Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs
On Mon, 12 Jan 2009 08:55:22 +0200
Guy Rutenberg wrote:
> Hi,
>
> When writing a paragraph with an RTL language (I checked with Hebrew, but it
> should also happen with Arabic), and adding numbered list, the symbols are
> shown in the wrong order. I mean by that, that the dot comes before the
> numbering symbol instead of after it.
>
> The patch checks whether we are in a RTL paragraph and if so reverses it.
>
> I've attached the patch and a LyX document that shows the problem.
>
> The patch is against the trunk, but if it's needed for the fix to enter the
> 1.6 development, I'll be glad to provide one against this branch.
>
>
> Regards,
>
> Guy
>
>
>
> http://www.guyrutenberg.com
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 28095)
+++ src/Buffer.cpp (working copy)
@@ -2908,16 +2908,18 @@
switch (par.itemdepth) {
case 0:
- format = N_("\\arabic{enumi}.");
+ // the RTL check is needed so the . will be on
the
+ // right side of the numbering symbol.
+ format = par.isRTL(bp) ?
N_(".\\arabic{enumi}") : N_("\\arabic{enumi}."); break;
case 1:
format = N_("(\\alph{enumii})");
break;
case 2:
- format = N_("\\roman{enumiii}.");
+ format = par.isRTL(bp) ?
N_(".\\roman{enumiii}") : N_("\\roman{enumiii}."); break;
case 3:
- format = N_("\\Alph{enumiv}.");
+ format = par.isRTL(bp) ?
N_(".\\Alph{enumiv}") : N_("\\Alph{enumiv}."); break;
default:
// not a valid enumdepth...
Is this the right place to do it in? I'm honestly asking. Isn't this
something that can be done by localization in he.po and should not be
in the C++ code base? What is the reason for doing it like this?
- Martin
Re: Where in the Code List Numbering Happens?
On Sat, Jan 10, 2009 at 04:47:06PM +, Guy Rutenberg wrote:
> Hi,
>
> I've decided to tackle an old bidi bug where list numbering in RTL text are
> reversed (e.g. the dot appears before the number instead of after it).
>
> I've tried going through the code and find where the list numberings are
> printed
> to screen, but I couldn't find it.
>
> I've understood there is an instance of the Layout class that represents the
> Enumerate environment, but I didn't find where it's created and where its
> content is printed to the screen.
>
> I would really appreciate is someone could help out.
>
>
> Thanks,
>
> Guy Rutenberg
>
>
> ---
> http://www.guyrutenberg.com
Seems I was one of those responsible for this mess ;-)
Look in Buffer.cpp for static void setLabel(). Around line 2900 is the enum
handling. Note that strings like "\\arabic{enumi}." (with the dot!) are given
inside _( ), so they are meant to be localized. This is the current mechanism.
Most of the logic is in Counters.{cpp,h}.
HTH Martin
Re: Environment arguments
On Fri, Jan 02, 2009 at 02:36:42PM +0100, Jean-Marc Lasgouttes wrote: > Guenter Milde writes: > >> There was a discussion on the proper name for this, but I don't > >> remember anyone coming up with anything better. "Optional argument" is > >> correct but very LaTeX centric and not clear to the uninitiated. > > > > "LaTeX argument" seems the best choice to me. > > IMO the name should be coded in the layout file. > > Here is how it could work: > > 1/ when using getStatus(), the lfun validator uses FuncStatus::message to > set a special string that could be > - the name of the optional argument for the current layout > - the name of the current inset > - anything else that could be useful > > 2/ when the menu item string contains %s, the menu code replaces this %s > with the message returned by above. > > With this, we have a way to have menu entry names that depend on > context. > > Would that make sense? > > JMarc Definitely. Any implementation ideas? - Martin
Re: Environment arguments (was Re: Developers Roadmap for 2.0)
On Mon, Dec 29, 2008 at 11:20:23PM +, Guenter Milde wrote: > On 2008-12-12, rgheck wrote in gmane.editors.lyx.devel: > > Jean-Marc Lasgouttes wrote: > >> rgheck writes: > > >>> Yes, of course. But there are problems even there. Support for > >>> optional arguments in list environments is weird. If you put one in > >>> for the first item, it becomes the optional argument to the > >>> environment, not to the item, and optional arguments to later items > >>> are silently ignored. > > >> This is by design, I think. > > I agree that this is a strange design (btw, this holds also for the > label-width phantom text in a LyX-List). > > > Really? It seems as if it'd be more useful to have the optional argument > > to \item. At least, it'd be more useful for me. > > Really? You can use ERT to give an (optional or mandatory) arg to an > \item but you need the (misnamed) Insert>Short-Title menu item to give an > optional argument to the list environment. There was a discussion on the proper name for this, but I don't remember anyone coming up with anything better. "Optional argument" is correct but very LaTeX centric and not clear to the uninitiated. > > I need the latter for the configurable lists with the enumitem.module. > > Günter - Martin
Autocorrect
The attached patch optionally enables autocorrect in math, and fixes it so it
works again once you define AUTOCORRECT.
I propose to check this in, and I'll think about the usability issue reported
by André.
- Martin
Index: mathed/InsetMathNest.cpp
===
--- mathed/InsetMathNest.cpp (revision 27916)
+++ mathed/InsetMathNest.cpp (working copy)
@@ -10,6 +10,8 @@
#include
+//#define AUTOCORRECT
+
#include "InsetMathNest.h"
#include "InsetMathArray.h"
@@ -25,6 +27,9 @@
#include "InsetMathSpace.h"
#include "InsetMathSymbol.h"
#include "InsetMathUnknown.h"
+#ifdef AUTOCORRECT
+#include "MathAutoCorrect.h"
+#endif
#include "MathCompletionList.h"
#include "MathData.h"
#include "MathFactory.h"
@@ -1513,10 +1518,10 @@
// This is annoying as one has to press far too often.
// Disable it.
-#if 0
+#ifdef AUTOCORRECT
// leave autocorrect mode if necessary
- if (autocorrect() && c == ' ') {
- autocorrect() = false;
+ if (cur.autocorrect() && c == ' ') {
+ cur.autocorrect() = false;
return true;
}
#endif
@@ -1616,9 +1621,11 @@
}
+#ifdef AUTOCORRECT
// try auto-correction
- //if (autocorrect() && hasPrevAtom() && math_autocorrect(prevAtom(), c))
- // return true;
+ if (cur.autocorrect() && cur.pos() != 0 && math_autocorrect(cur.prevAtom(), c))
+ return true;
+#endif
// no special circumstances, so insert the character without any fuss
cur.insert(c);
Re: Notes in output
On Mon, 08 Dec 2008 09:32:24 +0100 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Guenter Milde <[EMAIL PROTECTED]> writes: > > But it might be a good idea to have a "visibility" toggle for all kind > > of notes (and a matching "high visibility" style for LyX notes in the > > output). > > Yes, but a 'all is possible' interface (up to "[X] show all footnotes > except those that contain a math expression" ? :) is risky in terms of > usability. > Yes... kitchen sink syndrome. You _can_ have a note inside a branch inset BTW. > Also there is the semantics part. There is a real need for having LyX > 'skip' some part of text as being 'not there'. For example, notes are > not part of ToC right now. > > JMarc - Martin
Re: Notes in output
On Sun, 07 Dec 2008 20:36:41 + (UTC) Guenter Milde <[EMAIL PROTECTED]> wrote: > On 2008-12-07, Uwe Stöhr wrote: > > > I really think we should implement something allowing that users can > > > influence the way Notes look in the output. > > Why not implement the Notes as a pre-defined branch that is off by default? > > Or unify the Notes>... and Branches>... insets so that it is > possible to convert a note to a branch and vice versa. > > Günter In that case it is better to unify Notes with Marginal and Footnotes, allowing conversion to/from them also. The common element is annotation. Branches is meant for other kinds of uses. - Martin
Re: problem with fig2pdftex in newest Ubuntu
On Wed, 03 Dec 2008 17:37:56 +0200 Martin Vermeer <[EMAIL PROTECTED]> wrote: > On Wed, 03 Dec 2008 16:25:24 +0100 > Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > > > Martin Vermeer wrote: > > > On Wed, 03 Dec 2008 13:49:44 +0100 > > > Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > > > > > > > > >> Martin Vermeer wrote: > > >> > > >>> Hi, > > >>> > > >>> I just was involuntarily forced to test Ubuntu 8.10 (my power supply > > >>> burned out and probably something else too, because we couldn't get > > >>> the box back to life again with a new power supply), and having > > >>> problems with XFig figures in LyX. > > >>> > > >>> They come out 90 degs rotated and with the wrong bounding box (?) > > >>> i.e., cut off. If I export to LaTeX manually and re-generate the > > >>> pdftex_t and pdf files from XFig manually, things work fine. > > >>> > > >>> I though the problem was with Angus' heuristics in fig2pdftex.py and > > >>> fig2pstex.py in lib/scripts. However, from the cammand line these > > >>> work OK too. > > >>> > > >>> Could somebody please have a look into this? Version is the official > > >>> one, 1.5.6. XFig is 3.2 patch level 5, > > >>> > > >> Hi Martin, > > >> > > >> I remember fixing in bug in the 1.6 version of the script in order to > > >> cleanup the external inset support. This was windows related AFAIR but > > >> you should have a look in there. I don't think this particular script > > >> has changed much anyway. > > >> > > >> Abdel. > > >> > > > > > > Abdel, > > > > > > it turns out that the "wrong" PDF is produced by ImageMagick, it says at > > > the start > > > > > > /Producer (ImageMagick 6.3.7 08/21/08 Q16 http://www.imagemagick.org) > > > > > > The "right" PDF has nothing like that. > > > > > > Does that ring a bell? > > > > > Not really, sorry. > > > > Abdel. > > Well the good news is that in SVN the bug is not present. > > BTW SVN prints in the minibuffer the python commands executed, like > fig2pdftex. 1.5.6 doesn't do that. I suppose somehow it doesn't find > the correct script and falls back to convertDefault.py, which uses > Imagemagick. > > But as to why it doesn't find the correct script? > > - Martin Another interesting detail: if you edit the figure and change it from Landscape to Portrait, it comes out correctly -- at least for External Material. This may be a workaround for now, and should be documented somewhere. Still having trouble with Graphics. Who's going to move subfigure over to External material so we don't need Graphics anymore? - Martin
Re: problem with fig2pdftex in newest Ubuntu
On Wed, 03 Dec 2008 16:25:24 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Martin Vermeer wrote: > > On Wed, 03 Dec 2008 13:49:44 +0100 > > Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > > > > > >> Martin Vermeer wrote: > >> > >>> Hi, > >>> > >>> I just was involuntarily forced to test Ubuntu 8.10 (my power supply > >>> burned out and probably something else too, because we couldn't get > >>> the box back to life again with a new power supply), and having > >>> problems with XFig figures in LyX. > >>> > >>> They come out 90 degs rotated and with the wrong bounding box (?) > >>> i.e., cut off. If I export to LaTeX manually and re-generate the > >>> pdftex_t and pdf files from XFig manually, things work fine. > >>> > >>> I though the problem was with Angus' heuristics in fig2pdftex.py and > >>> fig2pstex.py in lib/scripts. However, from the cammand line these > >>> work OK too. > >>> > >>> Could somebody please have a look into this? Version is the official > >>> one, 1.5.6. XFig is 3.2 patch level 5, > >>> > >> Hi Martin, > >> > >> I remember fixing in bug in the 1.6 version of the script in order to > >> cleanup the external inset support. This was windows related AFAIR but > >> you should have a look in there. I don't think this particular script > >> has changed much anyway. > >> > >> Abdel. > >> > > > > Abdel, > > > > it turns out that the "wrong" PDF is produced by ImageMagick, it says at > > the start > > > > /Producer (ImageMagick 6.3.7 08/21/08 Q16 http://www.imagemagick.org) > > > > The "right" PDF has nothing like that. > > > > Does that ring a bell? > > > Not really, sorry. > > Abdel. Well the good news is that in SVN the bug is not present. BTW SVN prints in the minibuffer the python commands executed, like fig2pdftex. 1.5.6 doesn't do that. I suppose somehow it doesn't find the correct script and falls back to convertDefault.py, which uses Imagemagick. But as to why it doesn't find the correct script? - Martin
Re: problem with fig2pdftex in newest Ubuntu
On Wed, 03 Dec 2008 13:49:44 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > > > Martin Vermeer wrote: > > Hi, > > > > I just was involuntarily forced to test Ubuntu 8.10 (my power supply > > burned out and probably something else too, because we couldn't get > > the box back to life again with a new power supply), and having > > problems with XFig figures in LyX. > > > > They come out 90 degs rotated and with the wrong bounding box (?) > > i.e., cut off. If I export to LaTeX manually and re-generate the > > pdftex_t and pdf files from XFig manually, things work fine. > > > > I though the problem was with Angus' heuristics in fig2pdftex.py and > > fig2pstex.py in lib/scripts. However, from the cammand line these > > work OK too. > > > > Could somebody please have a look into this? Version is the official > > one, 1.5.6. XFig is 3.2 patch level 5, > > Hi Martin, > > I remember fixing in bug in the 1.6 version of the script in order to > cleanup the external inset support. This was windows related AFAIR but > you should have a look in there. I don't think this particular script > has changed much anyway. > > Abdel. Abdel, it turns out that the "wrong" PDF is produced by ImageMagick, it says at the start /Producer (ImageMagick 6.3.7 08/21/08 Q16 http://www.imagemagick.org) The "right" PDF has nothing like that. Does that ring a bell? - Martin
Re: regression introduced by r27719
On Sat, Nov 29, 2008 at 10:47:50PM +0100, Jean-Marc Lasgouttes wrote:
> >> ...and reverting is rather a blunt instrument when you could have fixed
> >>
> >> bool producesOutput() const { return false; }
> >>
> >> in InsetNote.h -- in the sense that yes, in some cases a Note _does_
> >> produce
> >> LaTeX output ;-)
> >>
> >> I suppose this is Richard's turf.
> >>
> >>
> > No, this isn't anything I know about. The producesOutput() routine was
> > JMarc's, I believe.
>
> We probably need to introduce something finer than produces output. Two
> notions
>
> - this stuff is not really part of the document
>
> qnd
>
> - this stuff does not produce any latex output
>
> Currently producesOutput means the first one.
>
> JMarc
Doesn't my proposed fix nevertheless do the right thing in this case? I.e.,
move it from .h to .cpp and make it return false for comment and greyedout.
- Martin
Re: regression introduced by r27719
On Sat, Nov 29, 2008 at 03:17:23PM +0100, Uwe Stöhr wrote:
> > Fair enough, although discussion about the scope of the problem would be
> easier if you avoided
> > broad generalizations like "breaks _every_ document that...".
> >
> > I can understand that _some_ greyed out notes are broken, but why are
> comments broken?
>
> But _every_ is correct. Every document that contains greyed-out cannot be
> compiled because your change omitted the needed preamble code. For an
> unknown reason I then get also error messages that the comment environment
> is undefined although this needs no preamble code.
>
> regards Uwe
comment _does_ require preamble code: features.require("verbatim"); it
generates a \begin{comment} ... \end[comment} pair.
...and reverting is rather a blunt instrument when you could have fixed
bool producesOutput() const { return false; }
in InsetNote.h -- in the sense that yes, in some cases a Note _does_ produce
LaTeX output ;-)
I suppose this is Richard's turf.
- Martin
Re: lyx2lyx fails
On Thu, 27 Nov 2008 15:03:49 +0100 Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > José Matos wrote: > > > Please do, without looking too deep in the code I can only guess what is > > wrong with it. :-) > > > > I will report later in the list what are my findings on the issue. > > Meanwhile, I found the problem: nothing to do with LyX. I did a > search/replace on multiple files some time ago, and I obviously set the > wrong encoding in kfilereplace, so the LyX file contained one mis-encoded > glyph. > > Jürgen Still, failure to import seems like too harsh a punishment... lyx2lyx should handle this gracefully. Is that feasible? - Martin
Re: [PATCH] Layout Setting Issue
On Sat, Oct 25, 2008 at 10:47:14PM -0400, Richard heck wrote:
> rgheck wrote:
>>
>> There's a bug in the code that sets the layout for the first paragraph of
>> an InsetCollapsable. If you start LyX from a terminal and create a branch,
>> you'll see some error messages about PlainLayout not being found. This is
>> because the first paragraph is being set to PlainLayout in the
>> InsetCollapsable constructor, whereas InsetBranch takes Standard.
>>
>> [snip]
>>
>> The right place to do this would be the InsetText constructor. Is there a
>> better way around the "Can't call virtual functions in a constructor"
>> problem?
>>
>>
> The attached patch implements the solution to this problem that is
> suggested in _Effective C++_, namely, to pass the necessary information up
> the line from subclass to superclass.
>
> It could be simplified by making the useplain parameter optional, but it's
> easiest, at first, not to do it that way, to make sure everything is right.
> If this seems OK, I'll commit a simplifying patch next.
>
> Comments? OK to commit?
>
> rh
Would it be better to use an enum rather than a boolean? More
human-readable.
- Martin
> Index: src/insets/InsetOptArg.cpp
> ===
> --- src/insets/InsetOptArg.cpp(revision 27131)
> +++ src/insets/InsetOptArg.cpp(working copy)
> @@ -22,7 +22,7 @@
>
>
> InsetOptArg::InsetOptArg(Buffer const & buf)
> - : InsetCollapsable(buf)
> + : InsetCollapsable(buf, true)
> {}
>
>
> Index: src/insets/InsetCaption.cpp
> ===
> --- src/insets/InsetCaption.cpp (revision 27131)
> +++ src/insets/InsetCaption.cpp (working copy)
> @@ -48,13 +48,11 @@
>
>
> InsetCaption::InsetCaption(Buffer const & buf)
> - : InsetText(buf)
> + : InsetText(buf, true) // use plain layout
> {
> setAutoBreakRows(true);
> setDrawFrame(true);
> setFrameColor(Color_captionframe);
> - // There will always be only one
> -
> paragraphs().back().setLayout(buf.params().documentClass().plainLayout());
> }
>
>
> Index: src/insets/InsetFlex.cpp
> ===
> --- src/insets/InsetFlex.cpp (revision 27131)
> +++ src/insets/InsetFlex.cpp (working copy)
> @@ -34,7 +34,7 @@
>
>
> InsetFlex::InsetFlex(Buffer const & buf, string const & layoutName)
> - : InsetCollapsable(buf), name_(layoutName)
> + : InsetCollapsable(buf, true), name_(layoutName)
> {
> // again, because now the name is initialized
> setLayout(buf.params().documentClassPtr());
> Index: src/insets/InsetTabular.cpp
> ===
> --- src/insets/InsetTabular.cpp (revision 27131)
> +++ src/insets/InsetTabular.cpp (working copy)
> @@ -487,7 +487,6 @@
> inset(new InsetTableCell(buf))
> {
> inset->setBuffer(const_cast(buf));
> -
> inset->paragraphs().back().setLayout(buf.params().documentClass().plainLayout());
> }
>
>
> @@ -2787,7 +2786,7 @@
> /
>
> InsetTableCell::InsetTableCell(Buffer & buf)
> - : InsetText(buf), isFixedWidth(false),
> + : InsetText(buf, true), isFixedWidth(false),
> contentAlign(LYX_ALIGN_CENTER)
> {}
>
> Index: src/insets/InsetBranch.cpp
> ===
> --- src/insets/InsetBranch.cpp(revision 27131)
> +++ src/insets/InsetBranch.cpp(working copy)
> @@ -40,7 +40,7 @@
> namespace lyx {
>
> InsetBranch::InsetBranch(Buffer const & buf, InsetBranchParams const &
> params)
> - : InsetCollapsable(buf), params_(params)
> + : InsetCollapsable(buf, false), params_(params)
> {}
>
>
> Index: src/insets/InsetNote.cpp
> ===
> --- src/insets/InsetNote.cpp (revision 27131)
> +++ src/insets/InsetNote.cpp (working copy)
> @@ -116,7 +116,7 @@
> /
>
> InsetNote::InsetNote(Buffer const & buf, string const & label)
> - : InsetCollapsable(buf)
> + : InsetCollapsable(buf, true)
> {
> params_.type = notetranslator().find(label);
> }
> Index: src/insets/InsetBox.cpp
> ===
> --- src/insets/InsetBox.cpp (revision 27131)
> +++ src/insets/InsetBox.cpp (working copy)
> @@ -96,7 +96,8 @@
> /
>
> InsetBox::InsetBox(Buffer const & buffer, string const & label)
> - : InsetCollapsable(buffer), params_(label)
> + : InsetCollapsable(buffer, false), // this will be reset shortly
> + params_(label)
> {
> if (forcePlainLayout())
>
> paragraphs().back().setLayout(buffer.par
Re: lyx-1.6.0svn and layouts names
On Sat, Oct 25, 2008 at 10:06:54AM -0400, rgheck wrote:
> Philippe Charpentier wrote:
>> For example, the following CharStyle
>>
>> CharStyle Semi-Bold
>> LatexType Command
>> LatexName textsb
>> Font
>> Family Roman
>> Series Bold
>> EndFont
>> LabelFont
>> Family Roman
>> Size tiny
>> Color blue
>> EndFont
>> Preamble
>> \usepackage{sbdefault}
>> EndPreamble
>> End
>>
>> which is working in lyx-1.5 does not work in lyx-1.6 :
>> It appears in the list of CharStyles (in the menu "Edit"),
>> the command \usepackage{sbdefault} is put in the preamble
>> but the command \textsb{} is not written in the latex source
>>
>>
> The problem is that it had to be "command", lower case. I've fixed this.
>
> rh
Yes, this is the way to do it. Thanks!
- Martin
Re: lyx-1.6.0svn and layouts names
On Sat, Oct 25, 2008 at 01:58:59PM +0200, Uwe Stöhr wrote: > > > I have a lot of CharStyle written for lyx-1.5.x. They don't work with > > lyx-1.6. How I have to modify them to use > > in lyx-1.6? > > They should work. Please report this bug at http://bugzilla.lyx.org. REport > the crash you get in a separate bug. > > thanks and regards > Uwe Actually layout2layout handles this, under format == 4, lines 246 etc. Shouldn't LyX do this transparently? Please post a test CharStyle that fails. - Martin
Re: A reset text style function/button (?)
On Fri, Oct 03, 2008 at 12:09:25AM +0200, Nikos Alexandris wrote: > Often I need to revert to default text-style words or whole sentences > which I have changed in previous editing sessions of my document. > Wouldn't it make sense to have a reset text style function and not to > have to go through the "Text style" window? > > Best regards, > -- > Nikos Alexandris There is a button for applying the last used style. It can also be used for resetting, after doing the first one manually. - Martin
Re: Display of index in the Outline window--sorted alphabetically
On Thu, Sep 25, 2008 at 03:50:02PM +0200, Abdelrazak Younes wrote: > On 25/09/2008 15:34, leuven edwin wrote: >> also: could you reverse the sort order in the combobox in the toc panel? >> the toc is used most often so it would be nice to have it on top... >> > > Why not simply rename that to "Document Structure"? Or maybe just > "Sections"? > > Abdel. "Outline"? - Martin
Re: Cursor::anchor()
On Thu, Sep 25, 2008 at 01:20:39PM +0200, Vincent van Ravesteijn - TNW wrote: > > > How can I modify the anchor position of a selection ? > > > >Why do you need to do that, actually? > > > >Jmarc > > Well, if you select multiple lines and you hit tab then a tab will be > inserted at the beginning of each line. > > As a consequence, the selection needs to be updated to shift one pos to > the right.. > > Vincent Are you sure? Doesn't sound right if you're also indenting the line the anchor is on... the insert location is outside the selection. - Martin
Re: autocorrection
On Sat, Sep 20, 2008 at 02:23:51PM +0200, Andre Poenitz wrote: > On Sat, Sep 20, 2008 at 03:27:23PM +0300, Martin Vermeer wrote: > > On Sat, Sep 20, 2008 at 12:24:40PM +0200, Andre Poenitz wrote: > > > On Sat, Sep 20, 2008 at 02:34:14AM +0300, Martin Vermeer wrote: > > > > I see that there is an autocorrection thingy in mathed, but disabled. > > > > Why is that? Does it work? Could we give the user the option of > > > > enabling it? > > > > > > It was something like TeXMacs automatic substitution of, say, > > > '<' followed by '=' with \leq. > > > > > > It sort of worked, but it was not reallyh predictable so I left it > > > disabled. I guess merging it with the autocompletion would be the > > > way to go... > > > > > > Andre' > > > > But autocorrection is for macros only. How would you do this merging? > > Basically but waiting for Stefan to do it ;-) > > Andre' Yes, that's a good plan. ... Stefan! - Martin
Re: autocorrection
On Sat, Sep 20, 2008 at 12:24:40PM +0200, Andre Poenitz wrote: > On Sat, Sep 20, 2008 at 02:34:14AM +0300, Martin Vermeer wrote: > > I see that there is an autocorrection thingy in mathed, but disabled. > > Why is that? Does it work? Could we give the user the option of > > enabling it? > > It was something like TeXMacs automatic substitution of, say, > '<' followed by '=' with \leq. > > It sort of worked, but it was not reallyh predictable so I left it > disabled. I guess merging it with the autocompletion would be the > way to go... > > Andre' But autocorrection is for macros only. How would you do this merging? - Martin
Re: autocorrection
On Sat, Sep 20, 2008 at 06:12:41AM +0200, Stefan Schimanski wrote: > Never seen that. What does it do? \farc -> \frac and similar things? > > Stefan No... the name is a bit wrong. It replaces things like => on the fly by \Rightarrow (and a long list of similar things) to speed up math typing. - Martin > Am 20.09.2008 um 01:34 schrieb Martin Vermeer: > >> I see that there is an autocorrection thingy in mathed, but disabled. Why >> is that? Does it work? Could we give the user the option of enabling it? >> >> I know some users that would be very happy with this :-) >> >> - Martin >>
autocorrection
I see that there is an autocorrection thingy in mathed, but disabled. Why is that? Does it work? Could we give the user the option of enabling it? I know some users that would be very happy with this :-) - Martin
Re: LyX is Nominated for th e "Lutèce d'Or 2008"
On Thu, Sep 18, 2008 at 11:30:43PM +0200, Abdelrazak Younes wrote: > Bob Lounsbury wrote: >> 2008/9/18 Abdelrazak Younes<[EMAIL PROTECTED]>: >> >>> Dear all, LyX enthusiasts, users and developers, >>> >>> I have the pleasure to announce you all that LyX is Nominated for the >>> "Lutèce d'Or 2008"! >>> >> >> >> Could you give a quick translation (for us not up to snuff Americans) >> of what "Lutèce d'Or 2008" means? >> > > FYI Lutèce is the old pre-roman name for Paris. Literally this means > "Golden Lutèce 2008" prices. These prices are distributed each year at the > occasion of this open source manifestation. Ah! Lutetia, in Asterix :-) - Martin
Re: The Three Box Model
On Thu, Sep 11, 2008 at 09:11:49AM +0200, Abdelrazak Younes wrote: > Richard Heck wrote: > > Andre Poenitz wrote: > > > >> I admit we haven't discussed it for a few years, mainly because last > >> time we reached consensus that it would be Real Kool(tm) to have but > >> nobody implemented it. > >> > > Did anyone try? > > I played a bit with the drawing side once. Should not be terribly difficult. > > > Were there problems? > > I think the main problem is that people are not prepared to switch to a new > mental model WRT text selection. We also need proper support for inset > merging and splitting. > > Some people want to be able to select part of that inset, and part of that > subsequent inset without having to think in terms of insets entity. I > understand this POV but I disagree with it. For example, a change is a > change, I don't want to half select it together with the next change, this > use case is I think pretty rare; but if I want to undo part of a deletion > for example, that should be possible. This last use case involves inset > splitting which we don't support yet. > Could you believe that we were discussing this very thing in front of a beer > with JMarc and Edwin yesterday? What number LyX meeting was that? I remember using fractional numbers for this kind of happening to be in the same town at the same time. > > This would be particularly good with character styles > > Yes. > > Abdel. Martin
Re: [Cvslog] r26303 - in /lyx-devel/trunk/src/insets: InsetCollapsable...
On Mon, 08 Sep 2008 10:23:52 +0200 [EMAIL PROTECTED] wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > >> > BTW, I do not understand why this stuff is done in InsetCollapsable > >> > instead of InsetText. > >> Me either. Probably goes back to who knows when. > > Try move it and you'll find out what the reason is if any... > > Very wise advice :) > > Any chance to see you in Berlin, BTW? > > JMarc Probably not... lecture season and very busy in real life :-( - Martin
Re: [Cvslog] r26303 - in /lyx-devel/trunk/src/insets: InsetCollapsable...
On Fri, Sep 05, 2008 at 11:05:32AM -0400, Richard Heck wrote: > Jean-Marc Lasgouttes wrote: > > [EMAIL PROTECTED] writes: > > > >> + // FIXME At present, these are being enabled and disabled according to > >> + // whether PASSTHRU has been set in the InsetLayout. This makes some > >> + // sense, but there are other checks that should really be done. E.g., > >> + // one should not be able to inset IndexPrint inside an optional > >> argument!! > >> > > > > You can specify that in the insetAllowed method of IndexOptArg. > > > > > OK. > > > BTW, I do not understand why this stuff is done in InsetCollapsable > > instead of InsetText. > > > > > Me either. Probably goes back to who knows when. > > rh Try move it and you'll find out what the reason is if any... - Martin
Re: Multi-author track changes
On Sat, Sep 06, 2008 at 04:01:47PM +0200, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > > "Vincent van Ravesteijn - TNW"<[EMAIL PROTECTED]> writes: > > > > > >> Hi all, > >> > >> After complaints from a colleague that he couldn't see which changes in a > >> document were his and which were from his supervisor, I implemented a > >> slightly different way of showing the changes (see png). > >> > >> In the attached (preliminary) patch I defined 5 colors for a possible 5 > >> authors. I couldn't think of another way at the moment. > >> > > > > This is so,ething I had in ,ind too. Good work. Things could be sipler > > though by introducing a new Change::color() method instead of > > duplicating your ugly formula :) > > > > > >> PS. Would it be best to open an enhancement bug for these kinds of things > >> ? > >> > > > > Yes, if it turns out that it is not accepted right away. > > > > I think this patch should be accepted as it implement a badly missing > feature for change-tracking and is very straight forward. And Vincent fixed > more bugs than any of us recently :-) > > By the way Vincent, I much say that I am impressed with how quick you > learned your way inside LyX source code. Good work! > > Abdel. As a fellow old TU Delfter, I can only proudly agree ;-) - Martin
Re: [patch] fix bug 5138
On Thu, Aug 07, 2008 at 11:35:18PM +0200, Uwe Stöhr wrote: > See http://bugzilla.lyx.org/show_bug.cgi?id=5138 > > regards Uwe small patch... Martin
Re: RFC for a proper sub/superscript handling
On Tue, Jul 01, 2008 at 05:26:09PM +0200, Uwe Stöhr wrote: > Martin Vermeer schrieb: > > >> \textsuper/subscript is exactly designed for cases of "H2O", "SO_4^2-", > >> "2nd", and the like. > > No Uwe, you are IMHO mixing up two conceptually different classes of > > sub/superscript. > > What else is \textsubscript for? Are there any typographic rules or > conventions that say "Do not use subscripted text font for chemical > indices."? It is for use in text, like "2nd", "Mme", etc. (Well that's superscript) > > The chemistry stuff is not math, > > I know, I therefore want to use \textsubscript and not a math font as we > currently do. There are special LaTeX-packages for chemistry, but this is > overkill for simple cases like "H2O". > I don't understand why you are against using \textsuper- subscript . I am not against it... as long as we remember that it isn't "the right way". I am also not against writing "E = mc^2" using text... only math is already available in LyX so this hack isn't needed. I, from my side, rhetorically don't understand why you are against using math _ ^ for chemistry... a hack is a hack is a hack ;-) But I agree that \textsuper/sub is useful and should be implemented. - Martin
Re: RFC for a proper sub/superscript handling
On Sat, Jun 28, 2008 at 11:46:06AM +0200, Jürgen Spitzmüller wrote: > Martin Vermeer wrote: > > No Uwe, you are IMHO mixing up two conceptually different classes of > > sub/superscript. The chemistry stuff is not math, but similar to math, > > let's say "formula-like", a visual mini-language. It would deserve its own > > machinery, that gets the roman right, knows the periodic table and allows > > for isotope weights top left. It should probably support some chemistry > > package for LaTeX (which I am not familiar with). > > Right. Something like the bpchem package should be used to provide proper > markup for chemical formulae. > > Actually, it should not be too hard to set up some basic chemical.module. But that would again be flexinset = text based, right? The existing math infra is so much more suited for this. > Jürgen - Martin
Re: RFC for a proper sub/superscript handling
On Fri, Jun 27, 2008 at 12:57:55AM +0200, Uwe Stöhr wrote:
> Martin Vermeer schrieb:
>
> > I think the inset should be based on a frameless textinset,
> > but collapsable would be overkill.
>
> +1
>
> > The "text sub/superscript" is meant for things like 2nd, 3rd,
> > or in French 2ieme, Nro, Mme, Mlle, ... where math is obviously
> > inappropriate. Uwe what I get about your olleagues, are they
> > using this for chemistry (CO2, H2O, ...)?
>
> Yes, and I use this too. I also need sub/ and superscripts for various
> indices for variables, names, and conventions.
>
> > If so, that deserves
> > its own implementation, and there, math would be a more
> > logical starting point than text.
>
> Why? "H2O" is correctly H\textsubscript{2}O
>
> Math is incorrect here. Note that we currently use \text in math to undo the
> italics of math and this is an ugly hack.
What you should use there is \mathrm which has the correct size behaviour.
> \textsuper/subscript is exactly
> designed for cases of "H2O", "SO_4^2-", "2nd", and the like.
No Uwe, you are IMHO mixing up two conceptually different classes of
sub/superscript. The chemistry stuff is not math, but similar to math, let's
say "formula-like", a visual mini-language. It would deserve its own machinery,
that gets the roman right, knows the periodic table and allows for isotope
weights top left. It should probably support some chemistry package for LaTeX
(which I am not familiar with).
That would be the proper way to do it. A separate running-text
sub/super facility is needed, but using it for chemistry is un-LaTeX-like and
as much a hack as using math for it.
> regards Uwe
Regards Martin
Re: RFC for a proper sub/superscript handling
On Wed, Jun 25, 2008 at 11:42:40AM +0200, Abdelrazak Younes wrote: > Uwe Stöhr wrote: > > Martin Vermeer schrieb: > > > > > Did you know that ellipses (...), quotes etc. are insets? > > > > No. But these things are singe characters. The idea is to set the text > > attribute via the text style dialog as the users expect it (at least the > > colloegues I recently explained LyX), and as it is in OOo, Word, Abiword, > > The output can be formatted text or an inset. > We can do much much better than having to go through the very cumbersome > text style dialog. I for one hates when I have to guess by looking at the > little dot space where is the superscript style starts and ends with > OO/Word. I much prefer the way I do it now using a math inset. So, if we are > to implement this feature in text only I'd much prefer a similar look&feel > as in mathed. > > As for the ui, context menu and shortcuts will do. > > Abdel. I agree, though it should be on the menu tree as well. I think the inset should be based on a frameless textinset, but collapsable would be overkill. I don't think size or vertical position should be configurable, seeing how awful that usually looks in Word. The "text sub/superscript" is meant for things like 2nd, 3rd, or in French 2ieme, Nro, Mme, Mlle, ... where math is obviously inappropriate. Uwe what I get about your olleagues, are they using this for chemistry (CO2, H2O, ...)? If so, that deserves its own implementation, and there, math would be a more logical starting point than text. How does this sound? - Martin
Re: RFC for a proper sub/superscript handling
On Tue, Jun 24, 2008 at 07:38:08PM +0200, Uwe Stöhr wrote: > Abdelrazak Younes schrieb: > > > This is the old inset versus character attribute debate. I personally think > > you should implement that as an inset. > > my collegues convinced me not to use an inset: They have to write a lot of > chemical symbols like H2, NO2, etc. With an inset it looks really ugly on > screen and is more time consuming. I therefore had a look at various editors > and the way OOo and Word handle this, is really the best. > > >> So what do you think about my proposal? Is anybody thinking this can > >> be implemented easily? > > Yes, see above. But if going the text style way, you'll need to extend the > > Font class for this attribute. Either by adding yet another character > > attribute or by extending the FontSize enum in FontEnums.h with > > FONT_SIZE_SUB and FONT_SIZE_SUPER. This last solution is a bit of a hack > > but easy to implement. > > Hmm, then I'll try to go the easy way first. > > thanks and regards > Uwe I think you're making an error Uwe. Insets can be whatever you make them look like. Did you know that ellipses (...), quotes etc. are insets? Not a big error... I just expect you'll find it less clean and elegant in the end. We shouldn't aim to be as good as OOo. We should aim to be "better", by our own standards. Cheers Martin
Re: prevent backslash Escaping backslashes in CharStyles
On Fri, 16 May 2008 08:56:57 +0200
"Heidemeier Dr, Joachim" <[EMAIL PROTECTED]> wrote:
> Hi Martin,
> unfortunately it doesn't work. Both on Windows (1.5.3) and on Linux (1.5.5)
> the following layout failed.
>
> Format 4
> CharStyle ChemFormula
> LatexType Command
> LatexName BPChem
> PassThru1
> LabelFont
> Family Roman
> Color Red
> EndFont
>
> Preamble
>\usepackage{BPChem}
> EndPreamble
> End
>
> ---
> Error Message in both cases were:
> Setting debug level to 1024
> Debugging `tclass' (Textclass files reading)
> LyXSetStyle: parsing configuration...
> Reading textclasses from `C:/Dokumente und
> Einstellungen/heidemei/Anwendungsdaten/lyx15/textclass.lst'
> Starting parsing of textclass.lst
> line by line
>
> Reading input file [layouts/chem.inc]
> LyX: Unknown ClassOption tag `PassThru' [around line 4 of file
> [layouts/chem.inc]]
> LyX: Unknown ClassOption tag `0' [around line 5 of file [layouts/chem.inc]]
> Finished reading input file [layouts/chem.inc]
>
> End of parsing of textclass.lst
> LyXSetStyle: configuration parsed.
> lyx: Disabling LyX socket.
> Is there a restricted attribute set for CharStyles in 1.5.x ?
> BTW the 1.5 distribution does not contain a stdinsets.inc layout file.
> TNX and greetings
> --
> Dr. Joachim Heidemeier
> c/o Umweltbundesamt FG II 2.2
> Tel.: +49340 2103-2780
> eMail: [EMAIL PROTECTED]
Ah yes, this is a 1.6 feature. Sorry.
- Martin
> > -Original Message-
> > From: Martin Vermeer [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, May 14, 2008 4:31 PM
> > To: Heidemeier Dr, Joachim
> > Cc: lyx-devel@lists.lyx.org
> > Subject: Re: prevent backslash Escaping backslashes in CharStyles
> >
> > On Wed, 14 May 2008 15:48:01 +0200
> > "Heidemeier Dr, Joachim" <[EMAIL PROTECTED]> wrote:
> >
> > > Triggered by a recent question in lyx-users I fiddled a
> > little bit with the usage of the BPChem style from lyx. As
> > BPChem is a single latex command I tried the definition of a
> > Char Style:
> > >
> > > CharStyle ChemFormula
> > > LatexType Command
> > > LatexName BPChem
> > > LabelFont
> > > Family Roman
> > > Color blue
> > > EndFont
> > > Preamble
> > >\usepackage{BPChem}
> > > EndPreamble
> > > End
> > >
> > > I ran into the following problem:
> > >
> > > the argument to the \BPChem command might contain special
> > characters (tex control words) like \_ or \^ for sub- or
> > superscripts. When Lyx generates latex those backslashes will
> > be escaped so that they became characters to be typesetted.
> > Is there another possibility besides ERT to prevent those
> > backslashes from beeing escaped during Latex generation?
> > >
> > > Thanks
> > >
> > > --
> > > Dr. Joachim Heidemeier
> > > c/o Umweltbundesamt FG II 2.2
> > > Tel.: +49340 2103-2780
> > > eMail: [EMAIL PROTECTED]
> >
> >
> > Have a look at stdinsets.inc in the layouts directory. I
> > think what you need is the PassThru keyword.
> >
> > - Martin
> >
Re: prevent backslash Escaping backslashes in CharStyles
On Wed, 14 May 2008 15:48:01 +0200
"Heidemeier Dr, Joachim" <[EMAIL PROTECTED]> wrote:
> Triggered by a recent question in lyx-users I fiddled a little bit with the
> usage of the BPChem style from lyx. As BPChem is a single latex command I
> tried the definition of a Char Style:
>
> CharStyle ChemFormula
> LatexType Command
> LatexName BPChem
> LabelFont
> Family Roman
> Color blue
> EndFont
> Preamble
>\usepackage{BPChem}
> EndPreamble
> End
>
> I ran into the following problem:
>
> the argument to the \BPChem command might contain special characters (tex
> control words) like \_ or \^ for sub- or superscripts. When Lyx generates
> latex those backslashes will be escaped so that they became characters to be
> typesetted. Is there another possibility besides ERT to prevent those
> backslashes from beeing escaped during Latex generation?
>
> Thanks
>
> --
> Dr. Joachim Heidemeier
> c/o Umweltbundesamt FG II 2.2
> Tel.: +49340 2103-2780
> eMail: [EMAIL PROTECTED]
Have a look at stdinsets.inc in the layouts directory. I think what you need is
the PassThru keyword.
- Martin
Re: A base64-based embedding design without bundle/unbundle.
On Thu, 08 May 2008 20:45:33 +0200 Andre Poenitz <[EMAIL PROTECTED]> wrote: > On Thu, May 08, 2008 at 01:08:21PM -0500, Bo Peng wrote: > > > > 1. A libb64 library is copied to src/support/base64. (this is a > > > > sourceforge project with a do-whatever-you-want license). Functions > > > > are provided to encode/decode a file to/from base64 strings. > > > > > > QByteArray::fromBase64(). It's even ok to use in support/*... > > > > This is great. I did not know QT has to/fromBase64 functions. > > For some reason Qt's abilities are judged according to what it did in > 1993 whereas boost seems to be judged at the 2009 level... > > Andre' > > PS: As a bold but reasonably educated guess: We could get rid of 90% of > the code in support/* _and_ reduce compile and link times by a third (on > top of that what we gained lately _and_ get a decent socket _and_ get > a decent concurrency framework if that mindset would undergo a reality > check... Seems like a decent operating system, at least as good as emacs ;-) - Martin
Re: Branch panel: (De)activate
On Tue, 06 May 2008 18:49:54 +0300 Martin Vermeer <[EMAIL PROTECTED]> wrote: > > The attached moves the (De)activate button away from (especially) the > Remove button. For me this is the most often used button switching > between branches, and it's too easy to accidentally hit Remove. > (Although you can of course hit Cancel if you do.) > > Is this the right way to do it? > > - Martin Committed. - Martin
Branch panel: (De)activate
The attached moves the (De)activate button away from (especially) the Remove button. For me this is the most often used button switching between branches, and it's too easy to accidentally hit Remove. (Although you can of course hit Cancel if you do.) Is this the right way to do it? - Martin Index: BranchesUi.ui === --- BranchesUi.ui (revision 24412) +++ BranchesUi.ui (working copy) @@ -84,7 +84,7 @@ - + Toggle the selected branch @@ -94,7 +94,7 @@ - + Define or change background color
Re: [PATCH] caption dialog with initial support for contcaption
On Fri, Apr 25, 2008 at 05:08:51PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Enrico Forestieri wrote:
>> > Such that in step 4) above the choices would now be: "Standard",
>> > "ContCaption", and "CaptionAbove". Got it? You don't have to
>> > hardcode anything, the caption inset should simply be customizable
>> > through layout files.
>> >
>> Well what you describe is exactly what I understood for captionabove,
>> captionbelow, etc. And I of course agree that this is the way to go
>> for them. But I still don't understand why you want another specific
>> layout for contcaption. For one, you won't get the correct numbering
>> on screen as what my patch does. And second I naively thought that
>> continued caption could be applicable to all kind of caption layouts
>> (standard, above, etc) and that it was consequently a caption
>> property rather than a layout. Without any consideration to latex, I
>> think that's exactly what I would expect as a user, that contcaption
>> is just about numbering.
>
> Of course we could also have a tag 'numbering' that indicates how numbering
> is done. Taking your example, that would become:
>
> # Caption style re-definition
> InsetLayout Caption:Standard
> NextNoIndent 1
> Align Center
> AlignPossible Block, Center
> Font
>Sizesmall
> EndFont
> LabelFont
>Series Medium
>Shape Italic
> EndFont
> Numbering increment
> End
>
> # Continued Caption definition
> InsetLayout Caption:ContCaption
> CopyInsetStyleCaption:Standard
> LatexName contcaption
> Preamble
> \usepackage{caption}
> \captionsetup{font=footnotesize,labelfont=it}
> \newcommand{\contcaption}[1]{\ContinuedFloat\caption{#1}}
> \DeclareCaptionLabelFormat{continued}{#1~#2 (continued)}
> \captionsetup[ContinuedFloat]{labelformat=continued}
> EndPreamble
> Numbering stall
> End
>
> Martin, Richard, as you are the original authors of InsetFlex, do you think
> something like that can be easily implemented? I think this could be a nice
> improvment to InsetFlex.
Yes... I have seen you do much, much harder things ;-)
Making InsetCaption layout-configurable is an all-round
good thing.
- Martin
> Still, even if technically possible that would mean that we would need to
> also define other layouts such for contcaptionabove, etc, wouldn't we?
>
>
> Abdel.
>
>
>
>
Re: changeset/24395
On Mon, 21 Apr 2008 13:42:17 +0100 José Matos <[EMAIL PROTECTED]> wrote: > On Monday 21 April 2008 13:31:17 Pavel Sanda wrote: > > which is the key question. in case embedding is going to be part of 1.6 > > then my estimate is + 3 month of release delay. > > IMHO it depends on what is going on. > Take Enrico's script as an example, if it goes in I don't expect a delay of > 3 months. :-) > > Rephrasing, I would like to have feedback on this issue. Does any one would > like to push this in some/any form? > > > pavel I think it would be good to start from Enrico's script, as it doesn't add complexity to the core. - Martin
Re: Approaching LyX 1.5.5 (status update #1)
On Mon, 21 Apr 2008 00:58:44 +0200 Uwe Stöhr <[EMAIL PROTECTED]> wrote: > > any plain text editor (eg notepad) should be capable to open and save it. > > pavel > > That's not the problem. Editing a file which structure I don't know without > an editor with syntax > highlighting is very hard. I downloaded groff for Windows but don't > understand this program. > > regards Uwe Didn't LyX edit man pages at some point? - Martin
Re: compiling LyX
On Sat, 19 Apr 2008 21:01:44 +0200 Andre Poenitz <[EMAIL PROTECTED]> wrote: ... > > (I.e., how does it look as total lines vs. unique lines)? > > I don't understand the question. Our ~500 lines .cpp files typically > yield a ~5 lines compilation unit after the preprocessor expanded > all #includes. The resulting lines are more or less unique, but of > course most of the 49500 lines overhead will also be part of the next > compilation unit produced from the next .cpp file. Is that answering the > question? > > Andre' Depressively, yes. So bigger compilation units are better, right? Any tricks around this? - Martin
Re: compiling LyX
On Sat, Apr 19, 2008 at 09:27:31AM +0200, Andre Poenitz wrote: > > Just as a side note: For the first time we have a ratio of less then > 100 when comparing "total compiled lines of code" vs "our code": > > Total: compiled: 16378361 real: 164656 ratio: 99 > > We had about 24630737 lines half a year ago > > Andre' Where are those lines? Boost? Qt? And where does the reduction come from? Did we repeatedly compile the same lines? (I.e., how does it look as total lines vs. unique lines)? - Martin
Re: [Cvslog] r24293 - in /www-user/trunk: favicon.ico index.php
On Wed, 16 Apr 2008 21:51:02 +0200 Joost Verburg <[EMAIL PROTECTED]> wrote: > Jean-Marc Lasgouttes wrote: > > Or more exactly a password only known to developers. Something written > > at some place of aussie would be enough. > > The new password can be found here: > > /home/lyx/www/pmwiki/passwords.txt > > Joost Only, this is owned by group wiki to which I don't belong. - Martin
Re: [patch] support for beamerarticle
On Wed, 16 Apr 2008 14:35:12 +0200 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > José Matos wrote: > > On Wednesday 16 April 2008 08:41:27 Juergen Spitzmueller wrote: > >> Objections to this? > > > > Au contraire. :-) > > How many of you guys speak French by the way? > > Uwe? Edwin? I seem to remember you saying so. > Jose too then? I am impressed... > > Abdel. Moi aussi... - Martin
Re: [Cvslog] r24137 - /lyx-devel/trunk/src/LyXAction.cpp
On Sun, Apr 06, 2008 at 11:19:43AM +, [EMAIL PROTECTED] wrote: > Author: sanda > Date: Sun Apr 6 13:19:42 2008 > New Revision: 24137 > > URL: http://www.lyx.org/trac/changeset/24137 > Log: > * Doxy. > > Modified: > lyx-devel/trunk/src/LyXAction.cpp > > Modified: lyx-devel/trunk/src/LyXAction.cpp > URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/LyXAction.cpp?rev=24137 > == > --- lyx-devel/trunk/src/LyXAction.cpp (original) > +++ lyx-devel/trunk/src/LyXAction.cpp Sun Apr 6 13:19:42 2008 > @@ -1071,6 +1071,10 @@ > * \var lyx::FuncCode lyx::LFUN_INSET_DISSOLVE > * \li Action: Dissolve the current inset into text. > * \li Syntax: inset-dissolve [] > + * \li Params: : this can be used to make sure the right kind of inset > +is dissolved. For example "dissolve" entry in the > charstyles > +sub-menu should only dissolve the charstyle inset, > even if the > +cursor is inside several nested insets of different > type. Correct. You could add that the parameter corresponds to the "lyxtype". > * \li Author: JSpitz, 7 Aug 2006 > * \endvar > */ > > > ___ > Cvslog mailing list > [EMAIL PROTECTED] > http://www.lyx.org/mailman/listinfo/cvslog >
Re: dissolve-inset
On Sun, Apr 06, 2008 at 04:26:23AM +0200, Pavel Sanda wrote: > > I think this is to make sure we're dissolving the right kind of inset > > (e.g., a charstyle), but I'm not absolutely positive. > > yes and my questions are > - why is this needed - this lfun can be called without any argument. > - why it is limited to FLEX_CODE. > > pavel It's a long time ago, but as I remember it has to do with the "dissolve" entry in the charstyles sub-menu. You want this menu item to only dissolve the charstyle inset, even if the cursor is inside several nested insets of different type. So Richard is right. (Perhaps this was not the proper place to ensure this. Anyway a comment could be added) I am not convinced that the FLEX_CODE test is even needed. - Martin
Re: [Cvslog] r23913 - in /lyx-devel/trunk: development/FORMAT lib/lyx2...
On Mon, Mar 24, 2008 at 12:58:04PM -0400, rgheck wrote: > Martin Vermeer wrote: > > On Mon, Mar 24, 2008 at 12:31:15PM +, [EMAIL PROTECTED] wrote: > > > >> Author: rgheck > >> Date: Mon Mar 24 13:31:07 2008 > >> New Revision: 23913 > >> > >> URL: http://www.lyx.org/trac/changeset/23913 > >> Log: > >> Add support for document-local layout information. GUI is to follow. > >> > > > > That's a tall order to do generally and safely. > > > > > Well, I think it's OK. It's essentially equivalent to writing a module into > the document header. So any problems we find here we'd have found elsewhere, > too, I believe. > > > For charstyles, I suggest a mechanism whereby the cursor points > > to an existing lyxtext position with a set of character > > attributes, and say "put these into a local layout". I had such a thing > > working at one point. > > > > > That would be welcome, to be sure. > > This is very much an "advanced feature", and I'm thinking to leave it > GUI-less for a while, as I play around with it. I've already got a static > TextClass::validate() routine going, though, so we can at least make sure > that people add valid layout information. Of course, if you add something, That's good. Let's then make absolutely sure (icon: shotgun aimed at foot?) that this is in the same category as ERT and preamble. > use it, and then remove it, you'll have a (minor) problem, but that's > possible other ways already. > > If you've got other thoughts, I'd love to hear them. > > Richard > - Martin
Re: Primary colours of LyX? Was: Website re-design ideas
On Mon, Mar 24, 2008 at 07:29:44PM +0100, [EMAIL PROTECTED] wrote: > On Mon, 24 Mar 2008, Joost Verburg wrote: > > > Rich Shepard wrote: > >>Regardless of what layout you choose and how you go about building > >> it (I, too, support xhtml and css), there is one universal design > >> criterion I urge you to follow: high contrast between text and > >> background. > > > > I fully agree. The main text should be black-on-white instead of > > white-on-green. > > Do "LyX" have some sort of "primary" colours? Or some kind of colour theme? > My company spent money on letting a designer come up with a colour set, > where we should try and use a certain combo of colours... Do we have > something like that? > > /Christian You could consider choosing for "white" the default background of the LyX text window. That is kind of distinctive. - Martin
Re: [Cvslog] r23913 - in /lyx-devel/trunk: development/FORMAT lib/lyx2...
On Mon, Mar 24, 2008 at 12:31:15PM +, [EMAIL PROTECTED] wrote:
> Author: rgheck
> Date: Mon Mar 24 13:31:07 2008
> New Revision: 23913
>
> URL: http://www.lyx.org/trac/changeset/23913
> Log:
> Add support for document-local layout information. GUI is to follow.
That's a tall order to do generally and safely.
For charstyles, I suggest a mechanism whereby the cursor points
to an existing lyxtext position with a set of character
attributes, and say "put these into a local layout". I had such
a thing working at one point.
- Martin
> Modified:
> lyx-devel/trunk/development/FORMAT
> lyx-devel/trunk/lib/lyx2lyx/LyX.py
> lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py
> lyx-devel/trunk/src/Buffer.cpp
> lyx-devel/trunk/src/BufferParams.cpp
> lyx-devel/trunk/src/BufferParams.h
> lyx-devel/trunk/src/TextClass.cpp
> lyx-devel/trunk/src/TextClass.h
> lyx-devel/trunk/src/frontends/qt4/GuiDocument.cpp
>
> Modified: lyx-devel/trunk/development/FORMAT
> URL: http://www.lyx.org/trac/file/lyx-devel/trunk/development/FORMAT?rev=23913
> ==
> --- lyx-devel/trunk/development/FORMAT (original)
> +++ lyx-devel/trunk/development/FORMAT Mon Mar 24 13:31:07 2008
> @@ -1,5 +1,8 @@
> LyX file-format changes
> ---
> +
> +2008-03-24 Richard Heck <[EMAIL PROTECTED]>
> + * Format incremented to 322: local layout
>
> 2008-03-18 Edwin Leuven <[EMAIL PROTECTED]>
> * Format incremented to 321: drop row/col lines and ensure
>
> Modified: lyx-devel/trunk/lib/lyx2lyx/LyX.py
> URL: http://www.lyx.org/trac/file/lyx-devel/trunk/lib/lyx2lyx/LyX.py?rev=23913
> ==
> --- lyx-devel/trunk/lib/lyx2lyx/LyX.py (original)
> +++ lyx-devel/trunk/lib/lyx2lyx/LyX.py Mon Mar 24 13:31:07 2008
> @@ -80,7 +80,7 @@
> ("1_3", [221], minor_versions("1.3" , 7)),
> ("1_4", range(222,246), minor_versions("1.4" , 5)),
> ("1_5", range(246,277), minor_versions("1.5" , 2)),
> - ("1_6", range(277,322), minor_versions("1.6" , 0))]
> + ("1_6", range(277,323), minor_versions("1.6" , 0))] #
> rgh: local layout
>
>
> def formats_list():
>
> Modified: lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py
> URL:
> http://www.lyx.org/trac/file/lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py?rev=23913
> ==
> --- lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py (original)
> +++ lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py Mon Mar 24 13:31:07 2008
> @@ -1631,6 +1631,21 @@
> 'hspace*{\n\\backslash\nfill}\n\\end_layout\n\n\\end_inset\n\n')
>
>
> +def revert_local_layout(document):
> +' Revert local layout headers.'
> +i = 0
> +while True:
> +i = find_token(document.header, "\\begin_local_layout", i)
> +if i == -1:
> +return
> +j = find_end_of(document.header, i, "\\begin_local_layout",
> "\\end_local_layout")
> +if j == -1:
> +# this should not happen
> +break
> +document.header[i : j + 1] = []
> +
> +
> +
> ##
> # Conversion hub
> #
> @@ -1680,10 +1695,12 @@
> [318, []],
> [319, [convert_spaceinset, convert_hfill]],
> [320, []],
> - [321, [convert_tablines]]
> + [321, [convert_tablines]],
> + [322, []]
>]
>
> -revert = [[320, [revert_tablines]],
> +revert = [[321, [revert_local_layout]],
> + [320, [revert_tablines]],
> [319, [revert_protected_hfill]],
> [318, [revert_spaceinset, revert_hfills, revert_hspace]],
> [317, [remove_extra_embedded_files]],
>
> Modified: lyx-devel/trunk/src/Buffer.cpp
> URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Buffer.cpp?rev=23913
> ==
> --- lyx-devel/trunk/src/Buffer.cpp (original)
> +++ lyx-devel/trunk/src/Buffer.cpp Mon Mar 24 13:31:07 2008
> @@ -116,7 +116,7 @@
>
> namespace {
>
> -int const LYX_FORMAT = 321;
> +int const LYX_FORMAT = 322; // rgh: local layout
>
> typedef map DepClean;
> typedef map >
> RefCache;
>
> Modified: lyx-devel/trunk/src/BufferParams.cpp
> URL:
> http://www.lyx.org/trac/file/lyx-devel/trunk/src/BufferParams.cpp?rev=23913
> ==
> --- lyx-devel/trunk/src/BufferParams.cpp (original)
> +++ lyx-devel/trunk/src/BufferParams.cpp Mon Mar 24 13:31:07 2008
> @@ -506,6 +506,8 @@
>
> } else if (token == "\\begin_preamble") {
> readPreamble(lex);
> + } else if (token == "\\begin_local_layout") {
> + readLocalLayout(lex);
> } else if (token == "\\begin_modules") {
> readModules(lex);
> } else if (token == "
Re: Step back for char-style inset
On Fri, Mar 21, 2008 at 02:51:29PM -0400, rgheck wrote: > Martin Vermeer wrote: > > On Tue, Mar 18, 2008 at 09:54:28AM -0400, rgheck wrote: > > > >> Martin Vermeer wrote: > >> > >>> On Mon, 17 Mar 2008 23:30:46 -0400 > >>> rgheck <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> Dominik Böhm wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> I just saw that some of the latest svn commits changed the rendering > >>>>> behavior of char-style insets. I liked the way they were rendered > >>>>> before (without the handle and possibility to collapse) much more. > >>>>> Now my text looks like a mess, as I am using char-styles > >>>>> intensively. Why did you change the way char-styles work? > >>>>> > >>>>> Further I think the feature to collapse char-style insets doesn't > >>>>> make much sense. For example, if you have a char-style "term" that > >>>>> you use in definitions, the definition using a collapsed char-style > >>>>> inset would look like: > >>>>> "A term is a...", though you would have expected "A XXX is a...". > >>>>> And I think, "A term XXX is a..." also looks really ugly. The old > >>>>> way was simply better. > >>>>> > >>>>> > >>>> I'm going to play around with this a bit and see if I can't improve > >>>> things. I agree with you that, for some styles, the "inline" mode > >>>> makes a lot more sense. > >>>> > >>> I would go as far as to call this a bug. > >>> > >>> > >> Do we need a new decoration here, or is it just a matter of changing > >> which one is used? > >> > >> rh > >> > > > > Should this be put in bugzilla so it's not forgotten? > > > > > I think I've fixed this. The problem was that decoration_ was defaulting to > Classic rather than to Default. > > rh Okay thanks! You mean... instead of to Conglomerate? - Martin
Re: Step back for char-style inset
On Tue, Mar 18, 2008 at 09:54:28AM -0400, rgheck wrote: > Martin Vermeer wrote: > > On Mon, 17 Mar 2008 23:30:46 -0400 > > rgheck <[EMAIL PROTECTED]> wrote: > > > > > >> Dominik Böhm wrote: > >> > >>> Hello, > >>> > >>> I just saw that some of the latest svn commits changed the rendering > >>> behavior of char-style insets. I liked the way they were rendered > >>> before (without the handle and possibility to collapse) much more. > >>> Now my text looks like a mess, as I am using char-styles > >>> intensively. Why did you change the way char-styles work? > >>> > >>> Further I think the feature to collapse char-style insets doesn't > >>> make much sense. For example, if you have a char-style "term" that > >>> you use in definitions, the definition using a collapsed char-style > >>> inset would look like: > >>> "A term is a...", though you would have expected "A XXX is a...". > >>> And I think, "A term XXX is a..." also looks really ugly. The old > >>> way was simply better. > >>> > >>> > >> I'm going to play around with this a bit and see if I can't improve > >> things. I agree with you that, for some styles, the "inline" mode > >> makes a lot more sense. > >> > > > > I would go as far as to call this a bug. > > > > > Do we need a new decoration here, or is it just a matter of changing which > one is used? > > rh Should this be put in bugzilla so it's not forgotten? - Martin
Re: [patch] document dialog cosmetics
On Tue, 18 Mar 2008 15:38:45 +0100 Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > Pavel Sanda wrote: > > > "article (Int. Soc. for Photogrammetry etc)" which comes out here as: > > > "Nicht verfügbar: article (Int. Soc. for Photogrammetry etc)" > > > > if you are playing with it, then this should be shortened too. > > Yes, indeed. How about "article (ISPRS)"? People who need this probably know > the acronym anyway. Yes they do :-) - Martin
Re: Step back for char-style inset
On Tue, 18 Mar 2008 09:54:28 -0400 rgheck <[EMAIL PROTECTED]> wrote: > Martin Vermeer wrote: > > On Mon, 17 Mar 2008 23:30:46 -0400 > > rgheck <[EMAIL PROTECTED]> wrote: > > > > > >> Dominik Böhm wrote: > >> > >>> Hello, > >>> > >>> I just saw that some of the latest svn commits changed the rendering > >>> behavior of char-style insets. I liked the way they were rendered > >>> before (without the handle and possibility to collapse) much more. > >>> Now my text looks like a mess, as I am using char-styles > >>> intensively. Why did you change the way char-styles work? > >>> > >>> Further I think the feature to collapse char-style insets doesn't > >>> make much sense. For example, if you have a char-style "term" that > >>> you use in definitions, the definition using a collapsed char-style > >>> inset would look like: > >>> "A term is a...", though you would have expected "A XXX is a...". > >>> And I think, "A term XXX is a..." also looks really ugly. The old > >>> way was simply better. > >>> > >>> > >>> > >> I'm going to play around with this a bit and see if I can't improve > >> things. I agree with you that, for some styles, the "inline" mode > >> makes a lot more sense. > >> > > > > I would go as far as to call this a bug. > > > > > Do we need a new decoration here, or is it just a matter of changing > which one is used? > > rh From Dominik's description it appears that charstyle insets come out in "classic" decoration style. They used to be "conglomerate". I think flexinsets (in fact, charstyles, elements but not custom) should default to conglomerate. Looking at the code, but I don't quite understand it anymore. svn blame blames you and Abdel (around InsetCollapsable.cpp:800, if that's the right spot). - Martin
Re: Step back for char-style inset
On Mon, 17 Mar 2008 23:30:46 -0400 rgheck <[EMAIL PROTECTED]> wrote: > Dominik Böhm wrote: > > Hello, > > > > I just saw that some of the latest svn commits changed the rendering > > behavior of char-style insets. I liked the way they were rendered > > before (without the handle and possibility to collapse) much more. > > Now my text looks like a mess, as I am using char-styles > > intensively. Why did you change the way char-styles work? > > > > Further I think the feature to collapse char-style insets doesn't > > make much sense. For example, if you have a char-style "term" that > > you use in definitions, the definition using a collapsed char-style > > inset would look like: > > "A term is a...", though you would have expected "A XXX is a...". > > And I think, "A term XXX is a..." also looks really ugly. The old > > way was simply better. > > > > > I'm going to play around with this a bit and see if I can't improve > things. I agree with you that, for some styles, the "inline" mode > makes a lot more sense. > > rh I would go as far as to call this a bug. - Martin
Re: ERT inset
On Mon, 10 Mar 2008 08:17:04 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Abdelrazak Younes wrote: > > Pavel Sanda wrote: > >>> This has benn discussed on the list. This is the minimalitic style. > >>> To collapse an ERT, right-click on it, to uncollapse, click on it. > > > > We cannot keep this feature as this is in violation of the simple model > > "right-click == context menu". > > > >> > >> yes, right click is now context menu. > > > > Right, we need a context menu for minimalistic inset. We just need to > > modify the already existing InsetCollapsable::contextMenu(). This means > > that two mouse click instead of one will be needed... no big deal. > > That being said, we can also bind mouse 2 (middle-mouse) to this if we > really want single mouse clicking. Nah... how often does one use this? Actually I would more often paint stuff into the inset using the middle mouse. Put it on the context menu, stick to conventions. - Martin
Re: Fehler
On Sun, 09 Mar 2008 21:36:12 +0100 Matthias Schilde <[EMAIL PROTECTED]> wrote: > Sehr geehrte Damen und Herren, > > ich habe mir gestern Ihr aktuellstes Lyx-Version 1.5 auf meinem Rechner mit > WindowsXP installiert, um damit meiner Diplomarbeit ein besseres Aussehen als > mit Word zu verschaffen. Dabei konnte ich gestern abend noch dvi-, pdf- und > PS- Datein anschauen bzw. erstellen (z.B. für die Vorschau auf mein > Dokument). Seit heute abend kommt aber ein Fehler sobald ich die dvi, pdf > oder ps Datein erstellen möchte: > > "Error: /limitcheck in -file- > Operand stack: >39158274 55380987 1000 600 600 > Execution stack: >%interp_exit .runexec2 --nostringval-- --nostringval-- > --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- > --nostringval-- false 1 %stopped_push 1893 1 3 %oparray_pop > 1892 1 3 %oparray_pop 1876 1 3 %oparray_pop 1755 1 3 > %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- > --nostringval-- --nostringval-- 2 %stopped_push > Dictionary stack: >--dict:1155/1684(ro)(G)-- --dict:0/20(G)-- --dict:73/200(L)-- > --dict:91/300(L)-- > Current allocation mode is local > Last OS error: No such file or directory > MiKTeX GPL Ghostscript 8.60: Unrecoverable error, exit code 1 > " > > Dieser Fehler kommt auch bei den vorhandenen Dokumenten Tutorium, > Benutzerhandbuch usw. > > > Es kommt außerdem in LyX direkt die Fehlermeldung: > "Bei der Ausführung von python -tt "C:/Programe/Latex_Lyx/Lyx15/Recources ist > ein Fehler aufgetreten > [OK]" > > Woran liegt das und wie kann ich diese Fehler beheben? > > > Mit freundlichen Grüßen, > Matthias Schilde Try nested dissection. Comment out (with the Note inset) about half of your document, and see if the error disappears. Then the other half. Then, half of the "guilty" half. And so on... Let us know which statement is causing the crash. HTH Martin
Re: A few questions
On Thu, Mar 06, 2008 at 02:39:28PM -0500, Raymond Martin wrote: > Qt Linguist are really for software localization). Just so you know, > OmegaT+ can translate documents in HTML/XHTML, ODF, OOo, OOXML, > PO, Java properties, JavaHelp, DocBook, plaintext, XLIFF, INI. And gettext po? That's interesting... that's what we are using. But is it better than emacs gettext mode? - Martin
Re: A few questions
On Thu, 06 Mar 2008 05:30:23 -0500 Raymond Martin <[EMAIL PROTECTED]> wrote: > Hi, > > I'm currently in the re-design phase of an application I am working on and > I really am wondering how I can either use LyX as its base code or add the > functionality from the type of application I have into LyX. > > The application I am redesigning is mainly for translators (I call it a > translation > processor) and it uses translation memory and TMX (translation memory > exchange) > in its operation. This functionality could also be useful to all kinds of > writers in general > (something I have come to term as Writing Memory, as opposed to another term > Authoring Memory). > > Some of the main problems with moving forward: > > - original application is in Java >- need to port code to/from Java/C++ (Swing/Qt4) >- there is the option of QtJambi (but native library support is an issue) > - user workflow/paradigm is almost completely different >-original application only provides text editor view of content > - no real formatting/layout, etc. > - LyX code base is significantly larger > ... > > A few questions: > > Does this Writing Memory type feature seems interesting to anyone for use in > LyX? > > Would a Java port of LyX ever be a consideration? > > Is there any way to use a plugin type feature with LyX currently (sorry if > this > is already answered in documentation somewhere)? > > Please let me know what you think. > > Raymond Martin (OmegaT+ project manager) > > OmegaT+ - http://omegatplus.sourceforge.net Actually this sounds very interesting. I installed Omega-T some time ago and played around with it. My wife is an interpreter/translator and at the time was interested too. I just installed it again... looks good. The problem we saw at the time was that translation is done a segment at a time, and a segment is at least the size of a sentence. Has that changed? Can it be made smaller? I tried to look but didn't see it. There are several approaches to this. It would probably be possible to make OmegaT understand the LyX format, which is simple tagged text. But if you want to be able to work inside the LyX GUI, it gets trickier. One approach would be the one we use for symbolic algebra systems and the like. I believe it is pipe based. You write a formula and LyX sends it, e.g., to maxima or octave for evaluation. In the same way LyX could interact with OmegaT. (Is it possible to start it up without a GUI?). Then you could send a selected segment to OmegaT, and receive the translation back, to be put into a "translated" branch, while the untranslated original is encapsulated into an "original language" branch. This leverages the ability to have multilingual docs in LyX. - Martin
Re: [patch BRANCH] insertInset
On Thu, 06 Mar 2008 10:46:29 + José Matos <[EMAIL PROTECTED]> wrote: > On Thursday 06 March 2008 10:21:42 Juergen Spitzmueller wrote: > > OK? > > +1 > > > Jürgen Yes, what took so long to backport it? Ah... that would have been my job :-( - Martin
Re: Summer of code
On Tue, 04 Mar 2008 12:09:57 +0100 Stefan Schimanski <[EMAIL PROTECTED]> wrote: > Anything planed this year? > > http://code.google.com/soc/2008/ > > Stefan No... I tried last year but with a poor, and poorly written, application. Material should still be on the Wiki. - Martin
Re: Assertion in rgbFromHexName()
On Thu, Feb 28, 2008 at 06:18:37PM +0100, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
>> On Thu, 28 Feb 2008 16:06:39 +0100
>> Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
>>> rgheck wrote:
>>>> Abdelrazak Younes wrote:
>>>>> The code is very weird:
>>>>>
>>>>> if (isRequired("framed") && mustProvide("color")) {
>>>>> RGBColor c = rgbFromHexName(lcolor.getX11Name(Color_shadedbg));
>>>>>
>>>> This is the same problem discussed a while back concerning color
>>>> handing:
>>>>http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg135771.html
>>>> though no-one has yet done anything about it.
>>>>
>>>>> getX11Name() returns a named color (egg "red") and rgbFromHexName()
>>>>> requires an Hexadecimal color beginning with '#'. I can't believe this
>>>>> code is old...
>>>>>
>>>> [EMAIL PROTECTED] src]$ svn blame LaTeXFeatures.cpp | grep Hex
>>>> 21395poenitz RGBColor c =
>>>> rgbFromHexName(lcolor.getX11Name(Color_shadedbg));
>>> OK, this is clearly bogus. In GUI mode We could and should use
>>> Application::getRgbColor(). Problem is for non GUI mode (command-line
>>> export). I guess getRgbColor() needs to be put out of Application and
>>> become support method (using QtCore).
>>>
>>> Abdel.
>> But isn't this colour only used in the GUI?
>
> I am not sure I understand the question. getRgbColor() will just
> "transform" the given color into its RGB representation, this is GUI
> independent.
> Or do you mean Color_shadedbg?
>
> Abdel.
That's what I mean.
- Martin
Re: Assertion in rgbFromHexName()
On Thu, 28 Feb 2008 16:06:39 +0100
Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
> rgheck wrote:
> > Abdelrazak Younes wrote:
> >> The code is very weird:
> >>
> >> if (isRequired("framed") && mustProvide("color")) {
> >> RGBColor c = rgbFromHexName(lcolor.getX11Name(Color_shadedbg));
> >>
> > This is the same problem discussed a while back concerning color handing:
> >
> > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg135771.html
> >
> > though no-one has yet done anything about it.
> >
> >> getX11Name() returns a named color (egg "red") and rgbFromHexName()
> >> requires an Hexadecimal color beginning with '#'. I can't believe this
> >> code is old...
> >>
> > [EMAIL PROTECTED] src]$ svn blame LaTeXFeatures.cpp | grep Hex
> > 21395poenitz RGBColor c =
> > rgbFromHexName(lcolor.getX11Name(Color_shadedbg));
>
> OK, this is clearly bogus. In GUI mode We could and should use
> Application::getRgbColor(). Problem is for non GUI mode (command-line
> export). I guess getRgbColor() needs to be put out of Application and
> become support method (using QtCore).
>
> Abdel.
But isn't this colour only used in the GUI?
- Martin
Re: Google trend on LyX
On Mon, 25 Feb 2008 09:40:10 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Mildly interesting: > > http://www.google.com/trends?q=LyX&ctab=0&geo=all&date=all&sort=0 > > Abdel. and mildly false: "lyx" is "luxury" in Swedish :-) - Martin
Re: Another assert
On Fri, 22 Feb 2008 10:04:33 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Jean-Marc Lasgouttes wrote: > > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > >>> or we > >>> need ColorSet::ColorSet() to include the hex values directly. Or else we > >>> need to hardcode the hex values where they're wanted. > >> Rather not. The ColorSet list should be able to contain official X11 names > >> at that position. > > > > I am not sure that using official X11 color names still make sense now > > that LyX is not a unix/x11 thing only anymore and that we have a color > > picker (and no way to see the names in the interface anyway). > > Qt understand X11 color names but we should probably go toward a cross > platform definition indeed. Qt docs recommend the SVG color names: > > http://www.w3.org/TR/SVG/types.html#ColorKeywords > > void QColor::setNamedColor ( const QString & name ) > Sets the RGB value of this QColor to name, which may be in one of these > formats: > #RGB (each of R, G, and B is a single hex digit) > #RRGGBB > #RRRGGGBBB > # > A name from the list of colors defined in the list of SVG color keyword > names provided by the World Wide Web Consortium; for example, > "steelblue" or "gainsboro". These color names work on all platforms. > transparent - representing the absence of a color. > X11 only: If allowX11ColorNames() returns true, any valid X11 color > name. See the documentation for XParseColor() for information about > valid X11 color names. > > Abdel. Sounds like a plan. And it seems that these SVG colours actually include the X colours. - Martin
Re: Another assert
On Thu, 21 Feb 2008 14:49:12 -0500
rgheck <[EMAIL PROTECTED]> wrote:
> Abdelrazak Younes wrote:
> > Richard Heck wrote:
> >> Richard Heck wrote:
> >>> José Matos wrote:
> After Richard fix I get an assertion.
>
>
> >>> The problem is that lcolor.getX11Name(Color_shadedbg), on
> >>> LaTeXFeatures line 636, is returning "red". I'll look to see why
> >>> this is, but maybe someone else knows?
> >>>
> >> This just looks like bad code:
> >>LaTeXFeatures.cpp: 636: RGBColor c =
> >> rgbFromHexName(lcolor.getX11Name(Color_shadedbg))
> >> but code that wasn't previously triggered, when it should have been.
> >> getX11name() will often (even usually) return something that isn't
> >> suitable input for rgbFromHexName(). In this case:
> >>Color.cpp:113: { Color_shadedbg, N_("shaded box"), "shaded",
> >> "red", "shaded" },
> >> so it returns "red".
> >>
> >> I'm guessing this code wasn't previously triggered because of
> >> something to do with missing InsetLayouts.
> >>
> >> I don't know enough about the color stuff to fix this quickly, but
> >> someone else does, I hope. Yes?
> > Maybe Juergen or Uwe?
>
> Or JMarc or Andre?
>
> For what it's worth, it looks as if we need either (a) some routine that
> will take these "named" colors and spit out their hex equivalents,
The X system should have a routine for doing that... I am surprised at
all these calls to rgbFromHexName that obviously require a hex argument,
yet the getX11Name routine obviously was intended to return an official
X11 name if one exists; see the system file /usr/lib/X11/rgb.txt. I
have a recollection that at one time (when Angus was around) a system
conversion routine X -> rgb was being called for this based on this file.
> or we
> need ColorSet::ColorSet() to include the hex values directly. Or else we
> need to hardcode the hex values where they're wanted.
Rather not. The ColorSet list should be able to contain official X11 names
at that position.
> rh
- Martin
Re: Mathed completion popup
On Tue, 19 Feb 2008 21:38:24 +0100 Stefan Schimanski <[EMAIL PROTECTED]> wrote: > Hi! > > A small progress report of the patch: I made it very generic now and > am on the way to implement completion for the text mode as well. You > can see a tiny screencast here: > >http://www.youtube.com/watch?v=vf3zSa9x2F4 > > Stefan Looks pretty fantastic. - Martin > Am 06.02.2008 um 00:49 schrieb Stefan Schimanski: > > > Hi! > > > > I was wondering today how complicated it would be to add a > > completion popup to mathed. Well, it took me three hours and here it > > is. Of course here and there, there are some rough edges and it has > > to be cleaned up, but it's easier than I expected. > > > > > > > > > > Stefan > > > > >
Re: [Cvslog] r23029 - in /lyx-devel/trunk: lib/layouts/stdinsets.inc s...
On Sat, Feb 16, 2008 at 05:29:49PM +0100, Uwe Stöhr wrote: > > @@ -182,7 +182,7 @@ > > LatexName index > > Decorationclassic > > Font > > - Color Green > > + Color latex > > Hmmm, is this concepually correct? The content of an index inset is nowadays > a > pretty general (single-line) lyxtext, not raw LaTeX. > > It is still LaTeX code you have to enter there (\see, @, !, and the like), > se my explanation in this thread: > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg135690.html > > regards Uwe In my understanding it's more complicated than that... I expect the LaTeX colour will not diminish confusion, and add some new of its own. Ideally \see etc should be their own insets, only appearing om the menu inside index insets... an index mini-language. Short of that, there is no real solution. - Martin
Re: the color scheme for insets in LyX 1.6
On Sat, Feb 16, 2008 at 12:59:49AM +0100, Uwe Stöhr wrote: > The discussion in the thread > "[Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc" > lead us to: > > - we should use colored labels in LyX 1.6 for certain insets > - the colors should be customizable > - to distinguish the labels, different inset types should not have the same > label color > > I implemented this now this way: > > > - we should use colored labels in LyX 1.6 for certain insets > > LyX's 1.6 colored inset labels are kept colored. But I changed the text > color for index entries to "latex", to indicate that the users have to > insert there LaTeX code. (Although this is described in the User's Guide > this topic appears from time to time on the lyx-users list.) Is the User's Guide up to date in this respect? I recall that LyX formatting etc. is supported here, and then there are some indexing-special things like "see" and @. - Martin > > - the colors should be customizable > > All label colors and the URL inset text color are now customizable in the > preferences. > > > - to distinguish the labels, different inset types should not have the > same label color > > - Footnote labels are now lightblue and no longer green like the index > label. > - Note labels are now yellow like in LyX 1.2 - 1.4 and no longer blue like > the URL label. > - Branch labels are lightbrown and not red, since red should be used for > alerts and really important things as you will always first look at red > text. > - Margin note labels are dark purple and not red. > > (sorry Martin, no label color is orange, because this looks not very well in > the grey label box) > > Attached is a file to see the colors. Of course the colors I set are > subjective, so please post what color you like to change. > > regards Uwe
Re: [Cvslog] r23029 - in /lyx-devel/trunk: lib/layouts/stdinsets.inc s...
On Fri, Feb 15, 2008 at 11:38:18PM +, [EMAIL PROTECTED] wrote: > Author: uwestoehr > Date: Sat Feb 16 00:38:16 2008 > New Revision: 23029 > > URL: http://www.lyx.org/trac/changeset/23029 > Log: > Color.cpp, ColorCode.h: define new colors for inset labels and insets text > stdinsets: use the new colors to allow the users to customize them Great! > Modified: > lyx-devel/trunk/lib/layouts/stdinsets.inc > lyx-devel/trunk/src/Color.cpp > lyx-devel/trunk/src/ColorCode.h > > Modified: lyx-devel/trunk/lib/layouts/stdinsets.inc > URL: > http://www.lyx.org/trac/file/lyx-devel/trunk/lib/layouts/stdinsets.inc?rev=23029 > == > --- lyx-devel/trunk/lib/layouts/stdinsets.inc (original) > +++ lyx-devel/trunk/lib/layouts/stdinsets.inc Sat Feb 16 00:38:16 2008 > @@ -66,7 +66,7 @@ > MiscNo_Bar > EndFont > LabelFont > - Color Red > + Color marginlabel > SizeSmall > EndFont > MultiPar true > @@ -87,7 +87,7 @@ > MiscNo_Bar > EndFont > LabelFont > - Color Green > + Color footlabel > SizeSmall > EndFont > MultiPar true > @@ -170,7 +170,7 @@ > InsetLayout Branch > Decorationclassic > LabelFont > - Color Red > + Color branchlabel > SizeSmall > EndFont > MultiPar true > @@ -182,7 +182,7 @@ > LatexName index > Decorationclassic > Font > - Color Green > + Color latex Hmmm, is this concepually correct? The content of an index inset is nowadays a pretty general (single-line) lyxtext, not raw LaTeX. > SizeSmall > Family Roman > Shape Up > @@ -192,7 +192,7 @@ > MiscNo_Bar > EndFont > LabelFont > - Color Green > + Color indexlabel > SizeSmall > EndFont > MultiPar false > @@ -253,11 +253,11 @@ > ForceLTR true > Font > Family Typewriter > - Color Blue > + Color urltext OK. > EndFont > LabelFont > Family Typewriter > - Color Blue > + Color urllabel > SizeSmall > EndFont > Requires url - Martin
Re: Fwd: Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc
On Fri, 15 Feb 2008 12:01:34 +0100 Uwe Stöhr <[EMAIL PROTECTED]> wrote: > Martin Vermeer schrieb: > > > Please don't revert the blue text / fixed pitch in URL. That _was_ by > design. > > I won't change anything, but the footnote label text, as I described. > > >> Now, from my point of view only the label color of footnote insets should > >> be > >> changed to orange or > >> so. > > > > Orange, why not. (Makes my old Dutch heart beat a little faster) > > It's so easy to please you ;-) > > I tried this, but this would mean to define a new color in colors.h. As old > Dutch, do you want to do > this? (It seems that I won't have access to my SVN tree the next days.) > > regards Uwe Me not easily, no, not over the weekend. Putting the colour in color.h makes it user configurable (doesn't it?). Good thing. - Martin
Re: Fwd: Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc
On Fri, 15 Feb 2008 10:29:25 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > I guess Uwe forgot to put the list in copy. > > - Forwarded message from Uwe Stöhr <[EMAIL PROTECTED]> - > Date: Fri, 15 Feb 2008 00:02:59 +0100 > From: Uwe Stöhr <[EMAIL PROTECTED]> > Reply-To: Uwe Stöhr <[EMAIL PROTECTED]> > Subject: Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc > To: [EMAIL PROTECTED] > > > IMO, the fact that 1.5 didn't make use of color to distinguish between > insets > does not mean that > > we shouldn't in 1.6. > > Also my opinion. I had now again a look at all insets and restored the > minimalistic style for listings. > > Now, from my point of view only the label color of footnote insets should be > changed to orange or > so. Orange, why not. (Makes my old Dutch heart beat a little faster) > This assures that no inset has the same label color (currently Index and > Footnote are green and > I would like to keep the green for the Index as it is inconspicuous). > And of course bug 4400 needs to be fixed. > > regards Uwe > > - End forwarded message - - Martin
Re: Character-Styles in LyX-svn
On Thu, 14 Feb 2008 17:15:09 +0100 Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > Martin Vermeer wrote: > > > Have you changed the way how to insert charstyles or is that a bug? > > > > Try flex-insert instead :-) > > Please document this in the RELEASE-NOTES. > > Jürgen So done, r23019, thanks for the reminder. - Martin
Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc
On Thu, 14 Feb 2008 18:58:41 +0100 Uwe Stöhr <[EMAIL PROTECTED]> wrote: > rgheck schrieb: > > > I didn't have anything to do with that. I'm guessing it just sort of > > happened. > > OK, when there was no intention and reason, I'll restore the colors to what > we have in Lyx 1.5. > > regards Uwe Please don't revert the blue text / fixed pitch in URL. That _was_ by design. - Martin
Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc
On Thu, 14 Feb 2008 00:11:59 +0100 Uwe Stöhr <[EMAIL PROTECTED]> wrote: > Martin Vermeer schrieb: > > > Does the attached look OK? > > Yes. > > regards Uwe Committed, r23003. Uwe, feel free to change colours etc. in the default. - Martin
Re: Character-Styles in LyX-svn
On Wed, Feb 13, 2008 at 11:33:04PM +0100, Pavel Sanda wrote: > > > Have you changed the way how to insert charstyles or is that a bug? > > > > Try flex-insert instead :-) > > i just put in some doxy for it; looked in the code and found there is > some reference to "standard" argument - i don't understand its function. > > Martin, can you polish that doxy (r22985)? > > thanks > pavel Done (r22992). - Martin
Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc
On Wed, Feb 13, 2008 at 12:31:14AM +0100, Uwe Stöhr wrote:
> Martin Vermeer schrieb:
>
>>> I don't think we should change such basic UI stuff like insets. The way
>>> we handle them is well accepted by the users and in my opinion an
>>> important part of the success of the UI concept of LyX. So please leave
>>> it as it is, according to my arguments above.
>> A document with lots of index entries occupies way too much real
>> estate. We discussed this in extenso: this is the reason to lose the
>> button.
>
> I missed this discussion, but anyway, we should listen to the users. I'm
> following the lyx-users list and introduced LyX to many people and never
> heard that anybody complained about labels. When an experienced user really
> prefers not to have a label for certain insets, then he can change it for
> his installation as he can change the toolbars and their buttons.
> For ERT I agree to Richard that the minimal style is useful as you alwayss
> need to know for ERT the content.
>
> Concerning the Index label, it is only 3 characters wide, so not problem
> with space. And normally you have index entries in a collapsed inset since
> you don't really want to see code like:
> Currency Symbols!\see|[EMAIL PROTECTED]
> Having a collapsed inset behind a word or a symbol is clear that this word
> is in 99.9% of the cases the word that is in the index. This was the output
> of an discussion where I requested to pop up the index dialog when
> inserting an index entry. So before we change anything here, our indexing
> experts like Jürgen should state their opinions.
>
>> Same (depending on your writing style, even more) for branches.
>
> Especially for branches I don't agree. Having the name of the branch in a
> label is very important, at least when I work with branches, as I had the
> case with 6 branches and I need to see at the first look what is what and
> not be forced to use the mouse to hover over insets to get their meaning.
>
> So to repeat myself, please reflect yourself and imagine you are an average
> LyX user not knowing all the tricks and expert stuff we developers know.
> (Last week I gave a LyX introduction and again noticed that newbies
> interact with LyX different to how I do. It's good to be reset from time to
> time to an average LyX niveau.)
>
> regards Uwe
Does the attached look OK?
- Martin
Index: minimalistic.module
===
--- minimalistic.module (revision 0)
+++ minimalistic.module (revision 0)
@@ -0,0 +1,54 @@
+#\DeclareLyXModule{Minimalistic}
+#DescriptionBegin
+# Redefines several insets as being Minimalistic, for use by old-timers.
+#DescriptionEnd
+
+Format 6
+
+InsetLayout Index
+ Decoration minimalistic
+ LabelString Idx
+ LatexType command
+ LatexName index
+ Font
+ Color Green
+ SizeSmall
+ EndFont
+ LabelFont
+ Color Green
+ SizeSmall
+ EndFont
+ MultiPar false
+ NeedProtect true
+End
+
+InsetLayout Branch
+ Decorationminimalistic
+ LabelFont
+Color Red
+SizeSmall
+ EndFont
+ MultiPar true
+End
+
+InsetLayout URL
+LyXType standard
+LatexName url
+LatexType command
+Decorationminimalistic
+LabelString URL
+PassThru true
+ForceLTR true
+Font
+ Family Typewriter
+ Color Blue
+EndFont
+LabelFont
+ Family Typewriter
+ Color Blue
+ SizeSmall
+EndFont
+Requires url
+End
+
+
Re: Notes, Foot notes and Marginal notes...
On Wed, Feb 13, 2008 at 06:26:56PM +0100, Abdelrazak Younes wrote: > Is there any particular reason why InsetNote and InsetMarginal are not > merged in InsetNote? > > Abdel. Historical, I assume... - Martin
Re: [Cvslog] r22923 - /lyx-devel/trunk/lib/layouts/stdinsets.inc
On Tue, 12 Feb 2008 09:39:03 +0100 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > Shall I put this in? > > I'd say yes. > > JMarc Done. Now is perhaps the time to reconsider some of the button decisions. - Martin
