LyX-List and KOMA Labeling

2009-01-12 Thread Guenter Milde
In the documentation list, there came a question about documenting the Lyx-List, while the actual Style is called Labeling (the Guide uses KOMA script). In my view, instead of documenting that a LyX-List is called Labeling in some document classes, ... >> "The right thing"™ would be to use one co

Re: Small problem with BlanketPermission on the new site.

2009-01-12 Thread John Weiss
On Sat, Jan 10, 2009 at 07:06:41PM +0100, Pavel Sanda wrote: > Angus Leeming wrote: > > We had one curmudgeonly gentleman, John Weiss, who point blank refused to > > licence his contribution to LyX under the GPL version 2 or later. The old > > flavour of this page has him down as licencing his co

Re: LFUN for user-cusotmizable vc-commands #2

2009-01-12 Thread Pavel Sanda
Richard Heck wrote: >> +LYXERR(Debug::LYXVC, "Directory: " << path); >> +FileName pp(path); >> +support::PathChanger p(pp); >> >> > Is some kind of error checking needed here? i dont see easy way. attached the new patch. pavel diff --

Re: Finding maths with AdvancedSearch

2009-01-12 Thread Tommaso Cucinotta
Hi, please, find attached a preliminary replace functionality (just try the "ReplaceNext button"), made while traveling, as usual :-). Like with find, there are some stability issues if you search (and replace) backwards, but hopefully I'll find the time to fix that as well. Bye, T. Index:

Re: LFUN for user-cusotmizable vc-commands

2009-01-12 Thread Pavel Sanda
Richard Heck wrote: >> + * \li Syntax: vc-command >> + * \li Params: : Flags for the command can be combined together.\n >> +U - dUmmy - no flags \n >> +D - Doc - need document loaded to proceed \n >> +I - dIrty - mark document dirty \

Re: LFUN for user-cusotmizable vc-commands

2009-01-12 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote: > What is related to VC in there? mainly the intention :) >It looks like a generic command interface. i can rename the lfun if it looks better. > Frankly, I do not think it is more useful than actually implementing the > different vc backends... the reason here was

Re: LFUN for user-cusotmizable vc-commands

2009-01-12 Thread Jean-Marc Lasgouttes
Le 12 janv. 09 à 22:20, Pavel Sanda a écrit : hi, i'm not the only who would welcome lfun for customization of vc commands. comments? What is related to VC in there? It looks like a generic command interface. Frankly, I do not think it is more useful than actually implementing the dif

Re: Strange behaviour of PathChanger

2009-01-12 Thread Andre Poenitz
On Mon, Jan 12, 2009 at 10:31:43PM +0100, Pavel Sanda wrote: > Andre Poenitz wrote: > > It's nasty when optimizers 'improve' ;-} > > iirc from the POV of C++ Standard such optimizations are not permitted > unless you guarantee that I/O remain the same, right? The compiler is free to elide calls t

Re: LFUN for user-cusotmizable vc-commands

2009-01-12 Thread rgheck
diff --git a/src/FuncCode.h b/src/FuncCode.h index b9c88c8..ebab4cc 100644 --- a/src/FuncCode.h +++ b/src/FuncCode.h @@ -413,6 +413,8 @@ enum FuncCode LFUN_WORD_FINDADV, // Tommaso, 20081003 LFUN_REGEXP_MODE,// Tommaso, 20081003 LFUN_COPY_LAB

Re: Strange behaviour of PathChanger

2009-01-12 Thread Pavel Sanda
Andre Poenitz wrote: > It's nasty when optimizers 'improve' ;-} iirc from the POV of C++ Standard such optimizations are not permitted unless you guarantee that I/O remain the same, right? > Could you try to add a 'volatile' in front of the 'support::PathChanger p(pp)' > and see whether it makes

LFUN for user-cusotmizable vc-commands

2009-01-12 Thread Pavel Sanda
hi, i'm not the only who would welcome lfun for customization of vc commands. comments? pavel diff --git a/src/FuncCode.h b/src/FuncCode.h index b9c88c8..ebab4cc 100644 --- a/src/FuncCode.h +++ b/src/FuncCode.h @@ -413,6 +413,8 @@ enum FuncCode LFUN_WORD_FINDADV, // Tommaso,

Re: layout question

2009-01-12 Thread Jean-Marc Lasgouttes
rgheck writes: > Some alternative to the current ~ would be nice. Using ~ means, of > course, that LaTeX has all kinds of problems with linebreaks if you > try to use FreeSpacing in lines of any width. OTOH, some people are used to LyX-Code breaking lines and would not unhappy to see their file o

Re: Strange behaviour of PathChanger

2009-01-12 Thread Andre Poenitz
On Mon, Jan 12, 2009 at 09:27:42PM +0100, Pavel Sanda wrote: > Pavel Sanda wrote: > > hi, > > > > i have the following codes: > > > > #1: > > case LFUN_VC_COMMAND: { > > string path = cmd.getArg(1); > > support::PathChanger p(FileName(path)); > > > > > > #2: > > case LFUN_VC_COMMAND: {

Re: Strange behaviour of PathChanger

2009-01-12 Thread Pavel Sanda
Pavel Sanda wrote: > hi, > > i have the following codes: > > #1: > case LFUN_VC_COMMAND: { > string path = cmd.getArg(1); > support::PathChanger p(FileName(path)); > > > #2: > case LFUN_VC_COMMAND: { > string path = cmd.getArg(1); > support::PathChanger p(FileName(cmd.ge

Strange behaviour of PathChanger

2009-01-12 Thread Pavel Sanda
hi, i have the following codes: #1: case LFUN_VC_COMMAND: { string path = cmd.getArg(1); support::PathChanger p(FileName(path)); #2: case LFUN_VC_COMMAND: { string path = cmd.getArg(1); support::PathChanger p(FileName(cmd.getArg(1)); in the first case path is n

Re: layout question

2009-01-12 Thread rgheck
Jean-Marc Lasgouttes wrote: rgheck writes: At the moment, I'm not sure we can do that in a normal environment (i.e., not in an inset). But there's no reason we couldn't. Currently, listings reuses ERT (?) to handle spaces. We could of course decide to have a new parameter to alloz mul

Re: layout question

2009-01-12 Thread Jean-Marc Lasgouttes
rgheck writes: > At the moment, I'm not sure we can do that in a normal environment > (i.e., not in an inset). But there's no reason we couldn't. Currently, listings reuses ERT (?) to handle spaces. We could of course decide to have a new parameter to alloz multiple normal space. Even better, we

Re: layout question

2009-01-12 Thread rgheck
leuven edwin wrote: richard wrote: ~ is the only way to preserve multiple spaces in LaTeX. i don't think so, it depends on the environment. listings for example preserves multiple spaces. I see. what i am after is listings type behavior, but using Style instead of InsetLayout

Re: [Cvslog] r28105 - /lyx-devel/trunk/src/insets/InsetBibtex.cpp

2009-01-12 Thread rgheck
Jürgen Spitzmüller wrote: rgheck wrote: Here. Looks good AFAICS. And well documented. Thanks! BTW this begins to get competition to Angus Leeming's idea of using BibTeX itself as a BibTeX parser :-) Interesting idea, though it would make LyX dependent upon TeX for its basi

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Jean-Marc Lasgouttes
Abdelrazak Younes writes: > Or even three if this is a bidi document (eg: Hebrew/English with a > French UI). In general for stuff like this LyX uses the language of > current paragraph... I hope this is also true for numbering. I thought it was rather the language of the document... JMarc

Re: [Cvslog] r28105 - /lyx-devel/trunk/src/insets/InsetBibtex.cpp

2009-01-12 Thread Jürgen Spitzmüller
rgheck wrote: > Here. Looks good AFAICS. And well documented. BTW this begins to get competition to Angus Leeming's idea of using BibTeX itself as a BibTeX parser :-) Jürgen

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Abdelrazak Younes
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Would be nice to do the same for Arabic and Farsi. Drop a note to our Arabic translator (or just do it). Done. Abdel.

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Jürgen Spitzmüller
Abdelrazak Younes wrote: > Would be nice to do the same for Arabic and Farsi. Drop a note to our Arabic translator (or just do it). For Farsi, we have no localization. Jürgen

RE: layout question

2009-01-12 Thread leuven edwin
richard wrote: > ~ is the only way to preserve multiple spaces in LaTeX. i don't think so, it depends on the environment. listings for example preserves multiple spaces. what i am after is listings type behavior, but using Style instead of InsetLayout and for that i don't want the ~ nor the ex

Re: [Cvslog] r28105 - /lyx-devel/trunk/src/insets/InsetBibtex.cpp

2009-01-12 Thread rgheck
Jürgen Spitzmüller wrote: rgheck wrote: Jurgen, I'd like to do this, r27975, r27987, and r27989 for branch. Together, these improve the presentation of citation strings, using unicode where appropriate and parsing the "family name" better than we now do. Could you post a patch? Her

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Abdelrazak Younes
Jürgen Spitzmüller wrote: Guy Rutenberg wrote: I've altered the he.po file and it worked. I've attached a patch of the changes. It's in (branch and trunk). Would be nice to do the same for Arabic and Farsi. Abdel.

Re: layout question

2009-01-12 Thread rgheck
leuven edwin wrote: i am fiddling with a layout i'm trying to put together i want to define an environment that contains plain text. i have the following Style Stata-Log LatexType Environment LatexName stlog FreeSpacing true Kee

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Jürgen Spitzmüller
Guy Rutenberg wrote: > I've altered the he.po file and it worked. I've attached a patch of the > changes. It's in (branch and trunk). Jürgen

layout question

2009-01-12 Thread leuven edwin
i am fiddling with a layout i'm trying to put together i want to define an environment that contains plain text. i have the following Style Stata-Log LatexType Environment LatexName stlog FreeSpacing true KeepEmpty tru

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Abdelrazak Younes
Guy Rutenberg wrote: Hi, On Mon, Jan 12, 2009 at 12:16 PM, Abdelrazak Younes > wrote: Jean-Marc Lasgouttes wrote: For stuff like this, LyX uses the language of the document, not of the interface. Actually, LyX uses (at least) two localizatio

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Guy Rutenberg
Hi, On Mon, Jan 12, 2009 at 12:16 PM, Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: > >> >> For stuff like this, LyX uses the language of the document, not of the >> interface. Actually, LyX uses (at least) two localizations in parallel. >> >> > > Or even three if this is a bidi documen

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Abdelrazak Younes
Jean-Marc Lasgouttes wrote: "Guy Rutenberg" writes: There are two reasons that I think are worth putting it in the C++ code: 1. Many users who write documents in Hebrew are using the English interface of LyX, so that changes in he.po will not affect them. For stuff like this, LyX use

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Jean-Marc Lasgouttes
"Guy Rutenberg" writes: > There are two reasons that I think are worth putting it in the C++ code: > > 1. Many users who write documents in Hebrew are using the English interface > of LyX, so that changes in he.po will not affect them. For stuff like this, LyX uses the language of the document, n

Re: [patch] fix bug 5682

2009-01-12 Thread Christian Ridderström
On Sun, 11 Jan 2009, Andre Poenitz wrote: Fair enough. Just submit then. "to trunk" that means. Andre', usually not talking about "branch". André, usually not talking about André in 3rd person :-) Sorry, I'm bored... :-) /Christian -- Christian Ridderström, +46-8-768 39 44http

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Guy Rutenberg
Hi Martin, On Mon, Jan 12, 2009 at 10:37 AM, Martin Vermeer wrote: > > 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? > There are two r

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

2009-01-12 Thread Martin Vermeer
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 >