date:20070621


Andre Poenitz wrote:
Pretty trivial patch attached. 


Ok?


can you add a comment?

[Patch] Allow insertion of spaces using the minibuffer

2007-06-21 Thread Andre Poenitz


Pretty trivial patch attached. 

Ok?

Andre'


Index: Text3.cpp
===
--- Text3.cpp   (revision 18813)
+++ Text3.cpp   (working copy)
@@ -973,7 +973,7 @@
docstring hexstring = cmd.argument();
if (lyx::support::isHex(hexstring)) {
char_type c = lyx::support::hexToInt(hexstring);
-   if (c > 32 && c < 0x10) {
+   if (c >= 32 && c < 0x10) {
lyxerr << "Inserting c: " << c << endl;
docstring s = docstring(1, c);
lyx::dispatch(FuncRequest(LFUN_SELF_INSERT, s));

Re: src/lyx on Mac Doesn't Display Math Symbols



Am 22.06.2007 um 02:22 schrieb Roger Mc Murtrie:

In testing lyx1.5.0rc1 math block problems on a Mac under OSX 10.4,  
I have found that starting lyx using src/lyx results in math blocks  
not displaying symbols, instead, for example Greek letters display  
as English letters with the Greek character mu displaying as  
English m. However, if I make install and start the resultant  
LyX,app, this problem does not occur.
I wondered if this should be considered a "bug" or is it expected  
and acceptable behavior?


Put a link to the lib/fonts folder where you binary is. Then it  
works. Not sure if it's a bug.


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable

Dov Feldstern schrieb:

and one of them has been supported for
a long time, so suddenly switching to the other and breaking
compatibility with the traditionally supported one doesn't seem right.

As I said we never supported arabTeX directly. So we don't switch to something.
Mostafa, what is your opinion here?

But anyway, to your patch:

- better use arabic_arabtex and arabic_arabi. If this is a fileformat change,
fine by me.
- your patch is incomplete, you miss the fontencoding issue. What font encoding
is required by
arabTeX? I can add this to your patch when we made a decision what to support.

We never supported this since the user has to some manual adjustments
before it works. When LyX would automatically load arabTeX when the
user uses Arabic as document language then you can say we support it.

I don't understand that approach. By that measure, we don't support
Hebrew, either, because I still have to setup the keymap myself;

Why that? We support now unicode so you should be able to type directly without
using a keymap.

because there's a whole Wiki page dedicated to how to get Hebrew working in LyX,
which proves that it doesn't exactly work out of the box

Hmm, you can drop the binding file issue there and when you have a Hebrew keyboard also the keyboard
map section.
For me it only took 5 minutes to set up Hebrew: Installing the culsmus.exe that brings the Hebrew
fonts to LaTeX and that's it. (Btw. it was me who created this wiki page originally.)

Of course you have for every language first set up LaTeX by installing packages, but with support I
mean that you don't have to use preamble hacks or fiddling with the preferences to make things work
when you change the document language.

With your recipe in
http://permalink.gmane.org/gmane.editors.lyx.devel/88100
I cannot write an Arabic and immediately later an English document. Docments with mixed languages
are also not really possible. arabTeX simply don't work correctly for me. I tested this out hardly
half a year ago and gave up, but now with arabi, everything concernig the infrastructure works:

- no special other package to install to get the input encoding
- I can mix languages as much as I want without editing the preamble or ERT
- I can type Arabic and Englich documents without modifying the preferences
when I switch
- when you have an Arabic keyboard, you don't need a keyboard map file
- babel support: no need to translate the names manually in the preamble for
every document

All this is also possible with Hebrew, so this is what I call support. But all this is not possible
with arabTeX. Sure also arabi has it's drawbacks but as the infrastructure is ready with it, we can
build in small workarounds like the ones for Farsi in my patch.

---

Besides this I would commit at least the Farsi related stuff of my patch as this improves
typesetting Farsi enormously.

regards Uwe

src/lyx on Mac Doesn't Display Math Symbols

2007-06-21 Thread Roger Mc Murtrie

In testing lyx1.5.0rc1 math block problems on a Mac under OSX 10.4, I  
have found that starting lyx using src/lyx results in math blocks not  
displaying symbols, instead, for example Greek letters display as  
English letters with the Greek character mu displaying as English m.  
However, if I make install and start the resultant LyX,app, this  
problem does not occur.
I wondered if this should be considered a "bug" or is it expected and  
acceptable behavior?


Roger

Re: [patch] fix bug 1942

2007-06-21 Thread Roger Mc Murtrie

I don't think that  bug 3902 should stop you committing your valuable  
solution to bug 1942 as, in the Mac case, it provides a considerable  
improvement.
I'm not sure that the  bug 1942 solution has "introduced" the problem  
of  bug 3902 but, rather, has provided visibility to bug 1942.
The improvement provided by the  bug 1942 solution far outweighs any  
disadvantage due to  bug 3902.


Roger

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Uwe Stöhr wrote:

Dov Feldstern schrieb:

To repeat myself: ArabTeX without arabi can't be used due to the 
missing babel interface and


ArabTeX is not babel-based, and therefore doesn't require a babel 
interface.


But LyX currenly uses babel to handle the different languages. Therefore 
arabi will be used when LyX inserts \selectlanguage{arabic}.


I don't understand why you don't want to have ONE package for Arabic AND 
Farsi. This fixes many problems and keeps it maintainable. Having 
support for two packages side by side requires much more maintaining 
work and expect it will introduce new problems we are currently not 
aware of.


I would like to have one. But right now we have two packages for Arabic, 
neither one of which is perfect; and one of them has been supported for 
a long time, so suddenly switching to the other and breaking 
compatibility with the traditionally supported one doesn't seem right.


Certainly I see advantages to using Arabi. For example, I don't think it 
will be possible to mix Hebrew and Arabic using ArabTeX, I think it 
*will* be possible with Arabi. But until Arabi is the clear winner --- 
and currently it's not, it still has many problems --- I don't think we 
should drop ArabTeX.




, more important, due to the missing input encodings. 


ArabTeX can use many different encodings, including a 
transliteration-type encoding which uses plain ASCII, I think. It does 
not include cp1256 by default, AFAICT. However, (a) it does include 
other encodings (iso-8859-8, for example), which LyX did support until 
recently, I'm not sure if it still does;


Yes but not cp1256 which is required on Windows.

(b) as you have pointed out, one can use ArabTeX with the cp1256 
encoding provided by arabi.


Yes, but then you use automatically arabi not arabTeX, see my 
explanation above.


arabi is not yet perfect; the fonts for ArabTeX are nicer; because 
that's the way it used to be done.


Every pacakge has its disadvantages. I mean we can discuss this again 
and again without changing this. But we have to decide what package to 
use arabTeX OR arabi - both is not an option.


Both *is* an only an option, I think it's a *must*.

I have sent a patch which does that, I resent it about three times 
already, but it doesn't seem to be getting through...




The point is, we used to support it, and we shouldn't just drop that 
support if it's not absolutely necessary.


We never supported this since the user has to some manual adjustments 
before it works. When LyX would automatically load arabTeX when the user 
uses Arabic as document language then you can say we support it.


I don't understand that approach. By that measure, we don't support 
Hebrew, either, because I still have to setup the keymap myself; because 
there's a whole Wiki page dedicated to how to get Hebrew working in LyX, 
which proves that it doesn't exactly work out of the box --- and that's 
only the Windows instructions, for linux it a bit more complicated; 
because until about a month ago, RTL was turned off by default, so the 
user had to turn it on manually. But the fact is that I've been using 
LyX to write complex Hebrew documents for the past five years, and I 
would be very upset if suddenly all that was broken "because we didn't 
really support it up until now".




regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Dov Feldstern schrieb:

To repeat myself: ArabTeX without arabi can't be used due to the 
missing babel interface and


ArabTeX is not babel-based, and therefore doesn't require a babel 
interface.


But LyX currenly uses babel to handle the different languages. Therefore arabi will be used when LyX 
inserts \selectlanguage{arabic}.


I don't understand why you don't want to have ONE package for Arabic AND Farsi. This fixes many 
problems and keeps it maintainable. Having support for two packages side by side requires much more 
maintaining work and expect it will introduce new problems we are currently not aware of.


, more important, due to the missing input encodings. 


ArabTeX can use many different encodings, including a 
transliteration-type encoding which uses plain ASCII, I think. It does 
not include cp1256 by default, AFAICT. However, (a) it does include 
other encodings (iso-8859-8, for example), which LyX did support until 
recently, I'm not sure if it still does;


Yes but not cp1256 which is required on Windows.

(b) as you have pointed out, 
one can use ArabTeX with the cp1256 encoding provided by arabi.


Yes, but then you use automatically arabi not arabTeX, see my explanation above.

arabi is not yet perfect; the fonts for 
ArabTeX are nicer; because that's the way it used to be done.


Every pacakge has its disadvantages. I mean we can discuss this again and again without changing 
this. But we have to decide what package to use arabTeX OR arabi - both is not an option.


The point is, we used to support it, and we shouldn't just drop that support if 
it's not absolutely necessary.


We never supported this since the user has to some manual adjustments before it works. When LyX 
would automatically load arabTeX when the user uses Arabic as document language then you can say we 
support it.


regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Uwe Stöhr wrote:

Dov Feldstern schrieb:


So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.


see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you 
follow the instructions there, ArabTeX works perfectly alright in LyX.


You procedure requires a lot of manual changes, and it also proves that 
arabTeX is currently not used directly by LyX.


Yes, that is correct. For many many years this was how LyX supported 
Hebrew as well as Arabic. AFAIK, they still don't work "out of the box", 
and there's a certain amount of setup required by the user. This does 
*not* prove that there aren't Arabic users out there using ArabTeX in 
LyX. And those users, if they exist, will not be happy if we break it.




The goal is that the uses only has to set the document language to 
Arabic in LyX's document settings menu and can start. With my patch and 
arabi this is possible.


I applaud that goal, but not at the expense of breaking backwards 
compatibility.




regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable

I'm resending this message, as only about half my emails seem to be 
getting through tonight. My apologies if you're receiving it twice...


Uwe Stöhr wrote:

Dov Feldstern schrieb:

I will test this now. But even if it all works, this is *not* OK as it 
is --- it breaks ArabTeX Arabic.


I don't understand. Currently ArabTeX is never loaded by LyX for Arabic 
documents so it is also not used. My patch requires arabi for both 
languages.


In the email I sent a few days ago, I explained exactly how to get LyX
working in Arabic, with either ArabTeX or Arabi. As explained there, it
is possible to perform a small one-time setup of LyX, and then use
ArabTeX for Arabic in LyX. So LyX has been supporting Arabic to a
certain extent for quite a while, using ArabTeX. The changes you are
proposing now break that support.


To repeat myself: ArabTeX without arabi can't be used due to the missing 
babel interface and


ArabTeX is not babel-based, and therefore doesn't require a babel interface.

, more important, due to the missing input encodings. 


ArabTeX can use many different encodings, including a
transliteration-type encoding which uses plain ASCII, I think. It does
not include cp1256 by default, AFAICT. However, (a) it does include
other encodings (iso-8859-8, for example), which LyX did support until
recently, I'm not sure if it still does; (b) as you have pointed out,
one can use ArabTeX with the cp1256 encoding provided by arabi. Why
would someone want to? Because arabi is not yet perfect; the fonts for
ArabTeX are nicer; because that's the way it used to be done. The point
is, we used to support it, and we shouldn't just drop that support if
it's not absolutely necessary.

The latter was bug 2927 which is now fixed for a while but since then 
the arabi-package is required for Arabic.
But once arabi is installed on your system, it will be used 
automatically, so ArabTeX is already not an option. Even if you load it 
in the preamble it will only be used for Arabic-only documents. As soon 
you have another language in your document arabi will be used again due 
to its babel interface.
So why not using my solution? Note that I created it by the requests of 
Mostafa.


Because it breaks ArabTeX, that's all. The patch I sent in earlier
tonight (see below) separates between ArabTeX and Arabi, so that on top
of it, it should be possible to implement your patch without breaking
ArabTeX. Then your solution can be used.

Please see the email I sent earlier tonight for a patch which 
separates between arabi and arabtex. This patch should be implemented 
over the arabic_arabi language.


I haven't received an email from you yet.



Yes, there seems to be a problem with email to the newsgroup --- look at
the times of the emails I (and others) sent to the newsgroup tonight,
vs. their arrival times. If it doesn't arrive by tomorrow, I'll resend it...


regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Dov Feldstern schrieb:


So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.


see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you 
follow the instructions there, ArabTeX works perfectly alright in LyX.


You procedure requires a lot of manual changes, and it also proves that arabTeX is currently not 
used directly by LyX.


The goal is that the uses only has to set the document language to Arabic in LyX's document settings 
menu and can start. With my patch and arabi this is possible.


regards Uwe

Re: farsi keyboard "farsi.kmap"


> I have attached the Farsi keyboard based on Linux Farsi keymap which can be
> added to directory "LYX_DEVEL/lib/kbd/". The only problem I have is the last
> line in which I tried to assign a letter to the double quote, i.e. \", and it
> did not work.

" couldn't be mapped because it's reserved for quotation

So when you remove the last line or replace it by another, this can go in.

regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Uwe Stöhr wrote:

Uwe Stöhr schrieb:

I don't understand. Currently ArabTeX is never loaded by LyX for 
Arabic documents so it is also not used.


Bug 2928 is the prove for my statement. Bug 2928 occurs because the \R 
command is not defined. But when ArabTeX was loaded \R would have been 
defined. When you load ArabTeX with the line

\usepackage{arabtex}
in the document preamble, bug 2928 doesn't occur.

So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.


see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you 
follow the instructions there, ArabTeX works perfectly alright in LyX.




regards Uwe


Dov

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Uwe Stöhr schrieb:

I don't understand. Currently ArabTeX is never loaded by LyX for Arabic 
documents so it is also not used.


Bug 2928 is the prove for my statement. Bug 2928 occurs because the \R command is not defined. But 
when ArabTeX was loaded \R would have been defined. When you load ArabTeX with the line

\usepackage{arabtex}
in the document preamble, bug 2928 doesn't occur.

So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.

regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable




Uwe Stöhr wrote:

Dov Feldstern schrieb:

I will test this now. But even if it all works, this is *not* OK as it 
is --- it breaks ArabTeX Arabic.


I don't understand. Currently ArabTeX is never loaded by LyX for Arabic 
documents so it is also not used. My patch requires arabi for both 
languages.


In the email I sent a few days ago, I explained exactly how to get LyX 
working in Arabic, with either ArabTeX or Arabi. As explained there, it 
is possible to perform a small one-time setup of LyX, and then use 
ArabTeX for Arabic in LyX. So LyX has been supporting Arabic to a 
certain extent for quite a while, using ArabTeX. The changes you are 
proposing now break that support.


To repeat myself: ArabTeX without arabi can't be used due to the missing 
babel interface and


ArabTeX is not babel-based, and therefore doesn't require a babel interface.

, more important, due to the missing input encodings. 


ArabTeX can use many different encodings, including a 
transliteration-type encoding which uses plain ASCII, I think. It does 
not include cp1256 by default, AFAICT. However, (a) it does include 
other encodings (iso-8859-8, for example), which LyX did support until 
recently, I'm not sure if it still does; (b) as you have pointed out, 
one can use ArabTeX with the cp1256 encoding provided by arabi. Why 
would someone want to? Because arabi is not yet perfect; the fonts for 
ArabTeX are nicer; because that's the way it used to be done. The point 
is, we used to support it, and we shouldn't just drop that support if 
it's not absolutely necessary.


The latter was bug 2927 which is now fixed for a while but since then 
the arabi-package is required for Arabic.
But once arabi is installed on your system, it will be used 
automatically, so ArabTeX is already not an option. Even if you load it 
in the preamble it will only be used for Arabic-only documents. As soon 
you have another language in your document arabi will be used again due 
to its babel interface.
So why not using my solution? Note that I created it by the requests of 
Mostafa.


Because it breaks ArabTeX, that's all. The patch I sent in earlier 
tonight (see below) separates between ArabTeX and Arabi, so that on top 
of it, it should be possible to implement your patch without breaking 
ArabTeX. Then your solution can be used.


Please see the email I sent earlier tonight for a patch which 
separates between arabi and arabtex. This patch should be implemented 
over the arabic_arabi language.


I haven't received an email from you yet.



Yes, there seems to be a problem with email to the newsgroup --- look at 
the times of the emails I (and others) sent to the newsgroup tonight, 
vs. their arrival times. If it doesn't arrive by tomorrow, I'll resend it...



regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Dov Feldstern schrieb:

I will test this now. But even if it all works, this is *not* OK as it 
is --- it breaks ArabTeX Arabic.


I don't understand. Currently ArabTeX is never loaded by LyX for Arabic documents so it is also not 
used. My patch requires arabi for both languages.


To repeat myself: ArabTeX without arabi can't be used due to the missing babel interface and, more 
important, due to the missing input encodings. The latter was bug 2927 which is now fixed for a 
while but since then the arabi-package is required for Arabic.
But once arabi is installed on your system, it will be used automatically, so ArabTeX is already not 
an option. Even if you load it in the preamble it will only be used for Arabic-only documents. As 
soon you have another language in your document arabi will be used again due to its babel interface.

So why not using my solution? Note that I created it by the requests of Mostafa.

Please see the email I sent earlier 
tonight for a patch which separates between arabi and arabtex. This 
patch should be implemented over the arabic_arabi language.


I haven't received an email from you yet.

regards Uwe

[patch] fix bug 1942


Attached is a patch from Georg that fixes the regression bug 1942:
   Inconsistent look of integral symbols.

I tested it thoroughly will all combinations of the packages esint, wasysym, 
and amsmath.

A Mac user has reported a perhaps related problem that I and Georg couldn't reproduce as consequence 
of bug 1942. So before this can go in, I need an OK from a Mac user that this patch does only fix 
the bug and not introduces the problem reported in

http://bugzilla.lyx.org/show_bug.cgi?id=3902

Stefan, JMarc, could you please test this the following way:

Before you apply the patch: Check if bug 3902 is not already there.

With the patch applied:
- create a document with only \iint in a formula.
- check via the View Source window that the package esint is loaded by LyX in 
the preamble
- now disable the option "use esint automatically" in the document -> math 
settings
- in the View Source window you can that amsmath is loaded instead of the 
package esint

When this is the case and the patch doesn't change anything regarding bug 3902 the patch is OK and 
can go in.


thanks in advance and regards
Uwe
Index: src/mathed/MathFactory.cpp
===
--- src/mathed/MathFactory.cpp	(Revision 18837)
+++ src/mathed/MathFactory.cpp	(Arbeitskopie)
@@ -175,11 +175,12 @@ void initSymbols()
 			// create fallbacks if necessary
 
 			// store requirements as long as we can
-			if (tmp.requires.empty() &&
-			(tmp.inset == "msa" || tmp.inset == "msb"))
-tmp.requires = from_ascii("amssymb");
-			else if (tmp.inset == "wasy")
-tmp.requires = from_ascii("wasysym");
+			if (tmp.requires.empty()) {
+if (tmp.inset == "msa" || tmp.inset == "msb")
+	tmp.requires = from_ascii("amssymb");
+else if (tmp.inset == "wasy")
+	tmp.requires = from_ascii("wasysym");
+			}
 
 			// symbol font is not available sometimes
 			docstring symbol_font = from_ascii("lyxsymbol");
Index: src/LaTeXFeatures.cpp
===
--- src/LaTeXFeatures.cpp	(Revision 18837)
+++ src/LaTeXFeatures.cpp	(Arbeitskopie)
@@ -445,8 +445,11 @@ string const LaTeXFeatures::getPackages(
 	// than those above.
 	//
 
-	if (mustProvide("amsmath")
-	&& params_.use_amsmath != BufferParams::package_off) {
+	// esint is preferred for esintoramsmath
+	if ((mustProvide("amsmath") &&
+	 params_.use_amsmath != BufferParams::package_off) ||
+	(mustProvide("esintoramsmath") &&
+	 params_.use_esint == BufferParams::package_off)) {
 		packages << "\\usepackage{amsmath}\n";
 	}
 
@@ -539,8 +542,8 @@ string const LaTeXFeatures::getPackages(
 
 	// esint must be after amsmath and wasysym, since it will redeclare
 	// inconsistent integral symbols
-	if (mustProvide("esint")
-	&& params_.use_esint != BufferParams::package_off)
+	if ((mustProvide("esint") || mustProvide("esintoramsmath")) &&
+	params_.use_esint != BufferParams::package_off)
 		packages << "\\usepackage{esint}\n";
 
 	// url.sty
Index: lib/symbols
===
--- lib/symbols	(Revision 18837)
+++ lib/symbols	(Arbeitskopie)
@@ -761,14 +761,20 @@ varointwasy 1170
 # It is important that they have the same requirements in both cases,
 # otherwise the LaTeX output would depend on the availability of the esint10
 # font in the GUI
+# Note that we do _not_ require the wasysym package for any integral besides
+# \varint and \varoint. The reason is that the integrals of the wasysym
+# package do not match the standard \int and \intop. See
+# http://bugzilla.lyx.org/show_bug.cgi?id=1942 for details.
+# If the wasysym integrals are really wanted then one has to load the package
+# manually and disable automatic loading of amsmath and esint.
 iffont esint
 intesint0010  mathop  ∫  esint
 intop  esint0010  mathop  ∫  esint
-iint   esint0030  mathop  x  esint
+iint   esint0030  mathop  x  esintoramsmath
 iintop esint0030  mathop  x  esint
-iiint  esint0050  mathop  x  esint
+iiint  esint0050  mathop  x  esintoramsmath
 iiintopesint0050  mathop  x  esint
-nt esint0070  mathop  x  esint
+nt esint0070  mathop  x  esintoramsmath
 ntop   esint0070  mathop  x  esint
 dotsintesint0090  mathop  x  esint
 dotsintop  esint0090  mathop  x  esint
@@ -787,11 +793,11 @@ ointclockwiseopesint0250
 else
 intcmex  82  242  mathop  ∫  esint
 intop  cmex  82  242  mathop  ∫  esint
-iint   wasy 1150  mathop  x  esint
+iint   wasy 1150  mathop  x

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable

I will test this now. But even if it all works, this is *not* OK as it 
is --- it breaks ArabTeX Arabic. Please see the email I sent earlier 
tonight for a patch which separates between arabi and arabtex. This 
patch should be implemented over the arabic_arabi language.


I'll get back to you regarding how this works.

Dov

Uwe Stöhr wrote:

Attached is a better patch where everything is implemented:

- correct encoding for the fontenc package. Mostafa tested this and gave 
his OK for this issue.


- special quotation mark definitions for Farsi. Mostafa tested this and 
gave his OK for this issue.


- fix for bug 2929 - use \textAR and not \R. Improved version of Dov's 
patch. Mostafa also tested

  this successfully.

- use the document language also for the TOC. This is a special 
arabi-package thing. Please test.


- To make the TOC settings work and also for other issues, arabic must 
be loaded to babel too when

  farsi is the document language. Please test.

Mostafa, when you give your OK I'll commit it. When there are possible 
problems with the two new things, I'll only commit the uncritical and 
tested issues from above.
(With this patch now also your example_lyxified.lyx you sent two days 
ago to be added to LyX's examples compiles for me.)


Dov, OK by you?

I think we have now a clean setup for boths languages based on the arabi 
package.


José, can this go in? I think it's worth because without this patch 
Arabic is not usable and for Farsi only with preamble hacks.


regards Uwe

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


Dov Feldstern schrieb:

I haven't read this entire thread thoroughly yet, but you might want to 
see if this specific issue is related to 
http://bugzilla.lyx.org/show_bug.cgi?id=3555 (only relevant in mixed 
language documents, I think, but I'm not sure...)


We don't have this problem here because the arabi-package requires the explicit setting of the 
language for the TOC. So the \TOCLanguage command assures that the correct encoding is used inside 
the TOC.


regards Uwe

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


Mostafa Vahedi schrieb:


But if you put the command "\TOCLanguage{farsi}" then
if you do not put "\selectlanguage{farsi}" as the first
command after the "\begin{document}" or in other words
as an ERT at the first line of the document then you
will receive several complains from LyX about some
undefined characters.


Wit my latest patch I just sent I can really see no difference with or without a first ERT 
\selectlanguage command. Could you please check this again with my latest patch. If you still see a 
difference, please tell me exactly what it is.


regards Uwe

Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable


Attached is a better patch where everything is implemented:

- correct encoding for the fontenc package. Mostafa tested this and gave his OK 
for this issue.

- special quotation mark definitions for Farsi. Mostafa tested this and gave 
his OK for this issue.

- fix for bug 2929 - use \textAR and not \R. Improved version of Dov's patch. 
Mostafa also tested
  this successfully.

- use the document language also for the TOC. This is a special arabi-package 
thing. Please test.

- To make the TOC settings work and also for other issues, arabic must be 
loaded to babel too when
  farsi is the document language. Please test.

Mostafa, when you give your OK I'll commit it. When there are possible problems with the two new 
things, I'll only commit the uncritical and tested issues from above.
(With this patch now also your example_lyxified.lyx you sent two days ago to be added to LyX's 
examples compiles for me.)


Dov, OK by you?

I think we have now a clean setup for boths languages based on the arabi 
package.

José, can this go in? I think it's worth because without this patch Arabic is not usable and for 
Farsi only with preamble hacks.


regards Uwe
Index: lib/languages
===
--- lib/languages	(revision 18849)
+++ lib/languages	(working copy)
@@ -25,7 +25,8 @@
 # Esperanto has no country code
 esperanto   esperanto	"Esperanto"	false  iso8859-3  eo	 ""
 estonianestonian	"Estonian"	false  iso8859-15 et_EE	 ""
-farsi   farsi	"Farsi"		true   utf8   fa_IR	 ""
+# the definitions are only used due to bugs in the arabi-package - remove them if they become unnecessary!
+farsi   farsi	"Farsi"		true   utf8   fa_IR	 "[EMAIL PROTECTED]@R{#1}}}\DeclareTextSymbol{\guillemotright}{LFE}{62}\DeclareTextSymbol{\guillemotleft}{LFE}{60}"
 finnish finnish	"Finnish"	false  iso8859-15 fi_FI	 ""
 # We redefine \og and \fg (guillemets) for older french language definitions
 french  french 	"French"	false  iso8859-15 fr_FR	 "\addto\extrasfrench{\providecommand{\og}{\leavevmode\flqq~}\providecommand{\fg}{\ifdim\lastskip>[EMAIL PROTECTED]"
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp	(revision 18849)
+++ src/BufferParams.cpp	(working copy)
@@ -855,6 +855,13 @@
 	bool const use_babel = features.useBabel();
 	if (use_babel) {
 		language_options << features.getLanguages();
+		// arabic must also be loaded when farsi is the document language
+		// this is hopefully not needed with future versions of the arabi-package
+		if (language->lang() == "farsi") {
+			if (!features.getLanguages().empty())
+language_options << ',';
+			language_options << "arabic";
+		}
 		if (!language->babel().empty()) {
 			if (!language_options.str().empty())
 language_options << ',';
@@ -892,9 +899,17 @@
 	if (fontsDefaultFamily != "default")
 		os << "\\renewcommand{\\familydefault}{\\"
 		   << from_ascii(fontsDefaultFamily) << "}\n";
+
+	// set font encoding
 	// this one is not per buffer
-	if (lyxrc.fontenc != "default") {
+	// for Arabic and Farsi we also need to load the LAE and LFE encoding
+	if ((lyxrc.fontenc != "default" && language->lang() == "arabic") ||
+		(lyxrc.fontenc != "default" && language->lang() == "farsi")) {
 		os << "\\usepackage[" << from_ascii(lyxrc.fontenc)
+		   << ",LFE,LAE]{fontenc}\n";
+		texrow.newline();
+	} else {
+		os << "\\usepackage[" << from_ascii(lyxrc.fontenc)
 		   << "]{fontenc}\n";
 		texrow.newline();
 	}
@@ -1144,8 +1159,16 @@
 		lyxpreamble += from_utf8(features.getBabelOptions());
 	}
 
-	lyxpreamble += "\\makeatother\n";
+	// these definitions are needed by the arabi-package
+	// when the document language is Arabic or Farsi, the language is set
+	// as the language for the TOC
+	if (language->babel() == "arabic")
+		lyxpreamble += "\\TOCLanguage{arabic}\n";
+	if (language->babel() == "farsi")
+		lyxpreamble += "\\TOCLanguage{farsi}\n";
 
+	lyxpreamble += "\\makeatother\n\n";
+
 	int const nlines =
 		int(lyx::count(lyxpreamble.begin(), lyxpreamble.end(), '\n'));
 	for (int j = 0; j != nlines; ++j) {
Index: src/Font.cpp
===
--- src/Font.cpp	(revision 18849)
+++ src/Font.cpp	(working copy)
@@ -756,6 +756,13 @@
 			base.language()->lang() == "farsi") {
 			os << "\\textLR{";
 			count += 8;
+		} else if (language()->lang() == "arabic") {
+			os << "\\textAR{";
+			count += 8;
+		} else if (!isRightToLeft() &&
+			base.language()->lang() == "arabic") {
+			os << "\\textLR{";
+			count += 8;
 		} else if (isRightToLeft() != prev.isRightToLeft()) {
 			if (isRightToLeft()) {
 os << "\\R{";
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp	(revision 18849)
+++ src/insets/InsetTabular.cpp	(working copy)
@@ -2286,6 +2286,8 @@
 			if (par.getParLanguage(buf.params())->lang() ==
 			"farsi")

Re: Bromarv

2007-06-21 Thread Jean-Marc Lasgouttes

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

Andre> Have you checked less direct flights? There still seems to be
Andre> Helsinki-Berlin for available ~100 EUR on Tuesday.

Jean-Marc> I may not understand their site, but they do not tell me on
^^you take air berlin, right?
Jean-Marc> which day they do paris-dusseldorf-helsinki after June 29.

JMarc

Re: Bromarv

2007-06-21 Thread Jean-Marc Lasgouttes

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

>>  Looking at the timetables, only Finnair gives me an arrival date
>> of 11h40 on Thursday (which is OK to catch the bus),

Andre> I'll be there at 11:55.

OK.

>> but the return would have to be on monday (12h15) or wednesday.
>> 
>> Last week there were many other flights, and with more interesting
>> rates :(

Andre> Have you checked less direct flights? There still seems to be
Andre> Helsinki-Berlin for available ~100 EUR on Tuesday.

I may not understand their site, but they do not tell me on which day
they do paris-dusseldorf-helsinki after June 29.

JMarc

Re: No paragraph alignment options

Edwin Leuven wrote:

> Alfredo Braunstein wrote:
>> Edwin Leuven wrote:
>> 
>>> case 2 is in my opinion not so relevant because i don't see why (in the
>>> current solution) one would have default unchecked and then choose the
>>> explicit alignment that matches default behavior
>> 
>> One such cases: I'm in Standard Layout and I want my par centered so I
>> set it explicitly. Then I change layout to one with centered default
>> [then realize it's not what I though] and change back. I've lost my
>> explicit centering.
> 
> this is not case 2, but case 1:
> 
>   x is set and we change the default to x

It's both ;-)

After changing the default to x, the situation is such that (with the
current code) the default is not checked but x == default. So changing back
falls in case 2.

> 
> ...
> 
> could you give a meaningful example with specific layouts between which
> you would be switching (out of curiosity) which would give rise to the
> above?

Specially with new document classes I normally don't know what the layouts
really are so I switch back and forth several times...

The point is that we will be changing an explicit user setting on the user's
back. I think it's wrong.

A/

Re: character pairs such as parenthesis in Farsi (a patch)

Mostafa Vahedi wrote:
Currently (only) Unicode is used for Farsi as the input encoding. Moreover in Unicode the openning parenthesis is always the left one (independent of the language) I have modified the code to reverse the direction of the character-pairs when it wants to display the characters whenever the language is Arabic or Farsi. Maybe the direction should be changed only when the language is Farsi (not Arabic), but only one parameter, i.e. bool Arabic, is sent to the function).

Mostafa

Hi Mostafa!

This patch looks good, but I'm not sure that it should be applied for
Arabic. Currently (before applying your patch, but with what you
previously put in already in place) I'm getting backwards parentheses in
Arabic. As I see it, there are two ways to go about solving this:

1) If the parentheses really do need to be reversed when using Unicode
input (I'm not set up for Unicode input, I don't think, so I can't test
this), then the patch *should* be applied also for arabic. Then,
however, when using the keymap, parentheses are backwards --- but we can
just fix that in the keymap itself, by adding

\kmap ( )
\kmap ) (

2) If for Arabic Unicode the patch should not be applied, then it should
be applied only for farsi.

Either way, it probably wouldn't be a bad idea to add a separate bool
variable for farsi --- there's no real reason why farsi and arabic
should share the variable...

(I haven't tried your patch, because I'm having trouble with the spacing
copying it from the email. Could you attach it --- or one modified
according to the above suggestions -- as an attachment next time, then
I'll test it.)

Dov

Re: No paragraph alignment options


Alfredo Braunstein wrote:

Edwin Leuven wrote:


case 2 is in my opinion not so relevant because i don't see why (in the
current solution) one would have default unchecked and then choose the
explicit alignment that matches default behavior


One such cases: I'm in Standard Layout and I want my par centered so I set
it explicitly. Then I change layout to one with centered default [then
realize it's not what I though] and change back. I've lost my explicit
centering.


this is not case 2, but case 1:

 x is set and we change the default to x

...

could you give a meaningful example with specific layouts between which 
you would be switching (out of curiosity) which would give rise to the 
above?

Re: Arabi / ArabTeX for Arabic


Uwe Stöhr wrote:


Actually, Mostafa has fixed the last *two* issues for Farsi, but not 
for Arabic, so as not to interfere with ArabTex. But at least the 
know-how is already in the sources. We only need to figure out how to 
allow the option of either Arabi or ArabTeX, so that one doesn't break 
the other. I think Mostafa had an interesting idea for this, of 
defining two Arabic languages.


This doesn't work. One version has to call ArabTeX in the preamble but 
arabi wil be used when it is installed due to its babel support except 
of the \R command. This leads to inconsistent output. And ArabTeX 
doesn't come with an input encoding for Windows.
So why not use arabi for baoth, Farsi and Arabic. When there are isues 
with the arabi package in terms of resulting font, ligatures, etc. we 
should report it to the arabi people and I'm sure they will fix it for 
their next release.


I'm not sure I follow you. I'm talking about only Arabic, for the 
moment. One of the problems that we have is that there are two separate 
packages which can be used for Arabic: ArabTeX (which is what LyX 
traditionally uses for Arabic), and Arabi, which LyX now uses for Farsi, 
and which is babel-based (?).


The problem is, some thing need to be done one way for ArabTeX, and a 
different way for Arabi. For example, do we use \R or \textAR to switch 
to RTL? Deciding on one of these ways will mean that one of the above 
packages can't be used in LyX.


So perhaps there could be two languages: "Arabic (Arabi)" and "Arabic 
(ArabTeX)". We would treat them as two totally separate languages, for 
one we would do everything the Arabi way, and for the other the ArabTeX 
way. That way, we could start using Arabi for Arabic, and still provide 
backwards compatibility by allowing ArabTeX.


Does this make sense, and is it possible?

Dov

Re: No paragraph alignment options

Edwin Leuven wrote:

> case 2 is in my opinion not so relevant because i don't see why (in the
> current solution) one would have default unchecked and then choose the
> explicit alignment that matches default behavior

One such cases: I'm in Standard Layout and I want my par centered so I set
it explicitly. Then I change layout to one with centered default [then
realize it's not what I though] and change back. I've lost my explicit
centering.

A/

Re: Is there an easy way to tell if an inset is modified?


:-) You patch seems to work but I do not really understand what is
going on. Could you explain a bit?


Sure, the standalone notifyCursorLeaves calls  
Inset::notifyCursorLeaves of
all insets in the cursor stack; so this catches the parent  
MathHullInset.

I was about to write such a function, only that I found it already
implemented ;-)


Did that for the cursor up/down logic in the last patch some days  
ago. I also wanted to use that in the other places, don't know why I  
didn't ... maybe wasn't brave enough :)


Haven't tested it, but for me it looks safe and the right thing to do.

Stefan


PGP.sig
Description: Signierter Teil der Nachricht

issues with change tracking

if i creat a selection that spans more than one line and then type 
something (so that the selection gets replace with my new text), the 
selection before the line where cursor is isn't crossed out. there is a 
missing screen update here.



second thing is when i delete a collapsed footnote. the collapse 
footnote gets crossed out in lyx but not the text inside. in the dvi the 
footnote isn't crossed out.

Re: [PATCH] Paragraph Setting UI Bugs


Richard Heck wrote:

This patch addresses the usability bugs discussed in this thread:
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have 
good ideas on these things.) The main change is that the "Default" 
button is now a radio button like the rest, so you don't have to uncheck 
Default to be allowed to check something else.


much better indeed

The layout that happens 
to be the default isn't treated specially except insofar as it is 
italicized, so as to indicate which one it is.


i don't like this fiddling with fonts to suggest to the user what is 
going on.


why not be explicit?

o Default (Justified)

o Justified
o Left
o Center
o Right

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable

Uwe Stöhr wrote:

Mostafa Vahedi schrieb:

 > See the attached patch. I implemented this but disabled it because
 > \TOCLanguage gives me the error
 > "unknown command". Therefore your example-lyxified doesn't compile.

The command "\TOCLanguage{}" is defined after the call to BABEL in 
Latex Preamble.

This was the first I tested, but it doesn't work for me, no matter where 
I call \TOCLanguage.

I haven't read this entire thread thoroughly yet, but you might want to 
see if this specific issue is related to 
http://bugzilla.lyx.org/show_bug.cgi?id=3555 (only relevant in mixed 
language documents, I think, but I'm not sure...)

Dov

Re: No paragraph alignment options


Alfredo Braunstein wrote:

This is bad. What if the user changes layout (or worse document class) and
the new layout has different default alignment? You are losing information
here.


ah, i see the problem now.

there seem to be 2 problem cases:

1 x is set and we change the default to x:
2 x (default) is set and the default changes:

(x being one of justified/left/center/right)

case 2 is in my opinion not so relevant because i don't see why (in the 
current solution) one would have default unchecked and then choose the 
explicit alignment that matches default behavior


which leaves case 1 and the question if we would like to keep the 
explicit formatting here.


i would be fine with having the default take precedence in both cases 
and have this in the interface:


o Justified (default)
o Left
o Center
o Right

but i can understand that others might think otherwise...

Re: Is there an easy way to tell if an inset is modified?

Bo Peng wrote:

>> I don't know Bo, I think that latex_code() is a reasonably efficient way
>> of having a signature of the math inset (to check if it has changed). I
>> would be surprised if this had a real performance impact (typically O(1)
>> operations per user interaction, we do much worse elsewhere in the code)
> 
> OK. Do you have any doubt in replacing notifyCursorLeaves with the
> standalone version? If not, I will submit Alfredo's patch. It looks
> safe enough to me.

It seems safe also to me. But there's no real hurry, we can wait for another
OK. I can commit tomorrow (I have now svn access).

A/

Re: Bromarv

2007-06-21 Thread Andre Poenitz

On Tue, Jun 19, 2007 at 06:15:24PM +0200, Jean-Marc Lasgouttes wrote:
> > "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:
> 
> christian> On Mon, 18 Jun 2007, Andre Poenitz wrote:
> >> Now that I was too stupid to get my booking right the first time, I
> >> again have a choice of dates.
> >> 
> >> Originally I was thinking about Thursday-Monday "as usual" but
> >> given the timetables that'd mean absolutely no work on Thursday and
> >> Monday, which is a bit below "business as usual". So I think about
> >> taking the return flight on Tuesday - which, otoh, would not be
> >> _that_ nice if I were the only one hanging around in the waters of
> >> Finland ;-}
> >> 
> >> So: When do other people come?
> 
> christian> I'm flexible and I'd enjoy doing something on Tuesday. I
> christian> might stay around another day as well for that matter. So
> christian> far I haven't decided if I'll fly there, or go by ferry and
> christian> motorcycle/car.
> 
> Looking at the timetables, only Finnair gives me an arrival date of
> 11h40 on Thursday (which is OK to catch the bus),

I'll be there at 11:55.

> but the return would have to be on monday (12h15) or wednesday.
> 
> Last week there were many other flights, and with more interesting
> rates :(

Have you checked less direct flights? There still seems to be
Helsinki-Berlin for available ~100 EUR on Tuesday.

Andre'

Re: Is there an easy way to tell if an inset is modified?


I don't know Bo, I think that latex_code() is a reasonably efficient way of
having a signature of the math inset (to check if it has changed). I would
be surprised if this had a real performance impact (typically O(1)
operations per user interaction, we do much worse elsewhere in the code)


OK. Do you have any doubt in replacing notifyCursorLeaves with the
standalone version? If not, I will submit Alfredo's patch. It looks
safe enough to me.

Cheers,
Bo

Re: [PATCH] Paragraph Setting UI Bugs


That's a great usability improvement!


+1

Bo

Re: Is there an easy way to tell if an inset is modified?

Bo Peng wrote:

>> You patch seems to work but I do not really understand what is
>> going on. Could you explain a bit?
> 
> I found this notifyCursorLeaves(old, new) function and see what is
> going on. If Abdel does not see any side effect of calling too many
> notifyCursorLeaves, your patch has my OK.
> 
> I, starting from the very beginning, dislike the fact that
> latex_code() is called every time a cursor leave a mathed. But again,
> your patch is simpler and fixes the problem. I may revert yours and
> the whole notifyCursorLeaves stuff, and replace them with
> inset::markDirty() after 1.5.0.

I don't know Bo, I think that latex_code() is a reasonably efficient way of
having a signature of the math inset (to check if it has changed). I would
be surprised if this had a real performance impact (typically O(1)
operations per user interaction, we do much worse elsewhere in the code)

A/

Re: [PATCH] Paragraph Setting UI Bugs

2007-06-21 Thread Joost Verburg


Richard Heck wrote:

This patch addresses the usability bugs discussed in this thread:
   
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html 

and largely implements Helge's suggestions. (Helge often seems to have 
good ideas on these things.) The main change is that the "Default" 
button is now a radio button like the rest, so you don't have to uncheck 
Default to be allowed to check something else. The layout that happens 
to be the default isn't treated specially except insofar as it is 
italicized, so as to indicate which one it is.


That's a great usability improvement! I switched from LyX 1.4 to 1.5 a 
few days ago and this was one of the most annoying things in the user 
interface.


The other two UI bugs that I think should be fixed before 1.5 are the 
position/status of the outline panel that are not remebered and the math 
panels that do not work in text mode.


Joost

Re: Is there an easy way to tell if an inset is modified?


> Have you fixed 1486 yet. Jose has Oked it so you can commit now,
> please remember to close the bug as well.

I don't have commit rights yet. Could you do that for me?


I will do that.


Sure, the standalone notifyCursorLeaves calls Inset::notifyCursorLeaves of
all insets in the cursor stack; so this catches the parent MathHullInset.
I was about to write such a function, only that I found it already
implemented ;-)


I will wait for another OK.

Cheers,
Bo

Re: Is there an easy way to tell if an inset is modified?


You patch seems to work but I do not really understand what is
going on. Could you explain a bit?


I found this notifyCursorLeaves(old, new) function and see what is
going on. If Abdel does not see any side effect of calling too many
notifyCursorLeaves, your patch has my OK.

I, starting from the very beginning, dislike the fact that
latex_code() is called every time a cursor leave a mathed. But again,
your patch is simpler and fixes the problem. I may revert yours and
the whole notifyCursorLeaves stuff, and replace them with
inset::markDirty() after 1.5.0.

Cheers,
Bo

Re: Is there an easy way to tell if an inset is modified?

Bo Peng wrote:

>> The following fix (based on your nice explanation) seems to cure the
>> problem without major rearrangements, but I didn't tested it well.
> 
> Have you fixed 1486 yet. Jose has Oked it so you can commit now,
> please remember to close the bug as well.

I don't have commit rights yet. Could you do that for me?

> It is amazing that you can always find better fixes for my patches.

Just luck ;-) It's easier the problem is already well described and
identified.

> :-) You patch seems to work but I do not really understand what is
> going on. Could you explain a bit?

Sure, the standalone notifyCursorLeaves calls Inset::notifyCursorLeaves of
all insets in the cursor stack; so this catches the parent MathHullInset.
I was about to write such a function, only that I found it already
implemented ;-)

A/

Re: Is there an easy way to tell if an inset is modified?


The following fix (based on your nice explanation) seems to cure the problem
without major rearrangements, but I didn't tested it well.


Have you fixed 1486 yet. Jose has Oked it so you can commit now,
please remember to close the bug as well.

It is amazing that you can always find better fixes for my patches.
:-) You patch seems to work but I do not really understand what is
going on. Could you explain a bit?

Bo

math panels

i think frac can go (as in attached) since there are only 2 entries 
which are already on the main math toolbar


gonna commit unless someone objects

...

something else entirely:

the panels can be easily added to the toolbar list by putting the 
following in default.ui:



"latex_deco" "math,bottom"
"latex_dots" "math,bottom"
"latex_arrow" "math,bottom"
"latex_bop" "math,bottom"
"latex_brel" "math,bottom"
"latex_greek" "math,bottom"
"latex_misc" "math,bottom"
"latex_varsz" "math,bottom"
"latex_ams_misc" "math,bottom"
"latex_ams_arrows" "math,bottom"
"latex_ams_rel" "math,bottom"
"latex_ams_nrel" "math,bottom"
"latex_ams_ops" "math,bottom"

do we want to do something with this?
Index: lib/ui/stdtoolbars.inc
===
--- lib/ui/stdtoolbars.inc	(revision 18841)
+++ lib/ui/stdtoolbars.inc	(working copy)
@@ -194,7 +194,6 @@
 
 	Toolbar "math_panels" "Math Panels"
 		PopupMenu "space" "Math Spacings"
-		PopupMenu "sqrt-square" "Roots"
 		PopupMenu "style" "Styles"
 		PopupMenu "frac-square" "Fractions"
 		PopupMenu "font" "Fonts"

Re: No paragraph alignment options

2007-06-21 Thread Anders Ekberg


On Jun 21, 2007, at 17:28 , Richard Heck wrote:

Anders Ekberg wrote:

On 21 jun 2007, at 13.12, Helge Hafting wrote:

Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's  
not an option in the way that the others are.

Sorry, but I consider that a bad argument. Sure, "default" is a bit
different. That does NOT imply it can't be a radio button like  
the rest.


To me, "default" means "whatever is default for this paragraph type"
while the other choices are explicit. (I.e. if you really want a
right-adjusted heading, and so on.)

The problem is not so much that the interface is hard to understand.
(It _is_, but people always learn such stuff after a while. Even  
non-latexers

keep a few useful latex commands around. . .)
It is also clunky to use, which is the big killer here.
If I want "centered", I want to click "centered" and be done with  
it!

I do not want to have to uncheck "default" first.
And I believe most other writers see it the same way.

Agree.
It is also consistent with the text settings where "Reset" (read  
Default) is an option like all others in the pop-up menus. In fact  
to use a pop-up menu with

No change
Justified
Left
Center
Right
Reset
would increase the consistency. Would this be a possibility?
I agree with Helge's analysis, too, and have prepared a patch which  
I'll send separately. I propose to stick with "default", though,  
again for Helge's reasons: It means "whatever the default is for  
this paragraph" and corresponds to LYX_ALIGN_LAYOUT. So it  
basically means "No special alignment". There's no need to "No  
change", so far as I can see. If you want that, you just don't do  
anything, since the button will always be set to whatever it was  
before.


Of course, "No change" is for the pop-up menu case where you need a  
possibility to select "nothing" (since you can't use Cancel if you  
wish to apply other changes in the dialogue).

/A

Re: Is there an easy way to tell if an inset is modified?

Bo Peng wrote:

> The problem with bug 3903
> (http://bugzilla.lyx.org/show_bug.cgi?id=3903) is clear, there is no
> notifyCursorLeave when you are not in an InsetMathHull (the outer
> level of the inset). Therefore, after you edit in, for example, super
> or subscript, math preview is not updated.

The following fix (based on your nice explanation) seems to cure the problem
without major rearrangements, but I didn't tested it well.

A/

Index: BufferView.cpp
===
--- BufferView.cpp	(revision 18842)
+++ BufferView.cpp	(working copy)
@@ -1351,7 +1351,7 @@
 	bool badcursor = false;
 	bool leftinset = (&cursor_.inset() != &cur.inset());
 	if (leftinset)
-		badcursor = cursor_.inset().notifyCursorLeaves(cursor_);
+		badcursor = notifyCursorLeaves(cursor_, cur);
 
 	// do the dEPM magic if needed
 	// FIXME: (1) move this to InsetText::notifyCursorLeaves?

Re: Is there an easy way to tell if an inset is modified?

2007-06-21 Thread Abdelrazak Younes


Bo Peng wrote:


 This is the unfinished part. Numerous LFUNC can contaminate an
inset, what is the best way to know if an inset is modified? I am
thinking of doing an markDiry after each recordUndo, but there are too
many recordUndo's. Is there any way to know if recordUndo() is called?


Why don't you call Inset::markDirty() for all inset inside recordUndo() ?

Abdel.

Re: No paragraph alignment options

Bennett Helm wrote:

> On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
> 
>> and this one doesn't make sense:
>>
>> if we could tell beforehand what the default was because then we
>> could show something like:
>>
>> o Justified (default)
>> o Left
>> o Center
>> o Right
>>
>>
>> ?
>>
> 
> Of the options I've seen, I agree that this is the best.

This is bad. What if the user changes layout (or worse document class) and
the new layout has different default alignment? You are losing information
here.

A/

[PATCH] Paragraph Setting UI Bugs



This patch addresses the usability bugs discussed in this thread:
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have 
good ideas on these things.) The main change is that the "Default" 
button is now a radio button like the rest, so you don't have to uncheck 
Default to be allowed to check something else. The layout that happens 
to be the default isn't treated specially except insofar as it is 
italicized, so as to indicate which one it is.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Index: src/frontends/qt4/QParagraph.cpp
===
--- src/frontends/qt4/QParagraph.cpp	(revision 18842)
+++ src/frontends/qt4/QParagraph.cpp	(working copy)
@@ -50,7 +50,7 @@
 	connect(applyPB, SIGNAL(clicked()), form_, SLOT(slotApply()));
 	connect(closePB, SIGNAL(clicked()), form_, SLOT(slotClose()));
 	connect(restorePB, SIGNAL(clicked()), form_, SLOT(slotRestore()));
-	connect(alignDefaultCB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
+	connect(alignDefaultRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
 	connect(alignJustRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
 	connect(alignLeftRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
 	connect(alignRightRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
@@ -77,9 +77,10 @@
 		" items is used."
 	));
 
-	radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
-	radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
-	radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
+	radioMap[LYX_ALIGN_LAYOUT] = alignDefaultRB;
+	radioMap[LYX_ALIGN_BLOCK]  = alignJustRB;
+	radioMap[LYX_ALIGN_LEFT]   = alignLeftRB;
+	radioMap[LYX_ALIGN_RIGHT]  = alignRightRB;
 	radioMap[LYX_ALIGN_CENTER] = alignCenterRB;
 }
 
@@ -105,35 +106,36 @@
 
 
 void QParagraphDialog::checkAlignmentRadioButtons() {
-	if (alignDefaultCB->isChecked()) {
-		QPRadioMap::const_iterator it = radioMap.begin();
-		for (; it != radioMap.end(); ++it)
-			it->second->setDisabled(true);
-	} else {
-		LyXAlignment alignPossible = form_->controller().alignPossible();
-		QPRadioMap::const_iterator it = radioMap.begin();
-		for (; it != radioMap.end(); ++it)
-			it->second->setEnabled(it->first & alignPossible);
+	LyXAlignment const alignPossible = form_->controller().alignPossible();
+	LyXAlignment const defaultAlignment = form_->controller().alignDefault();
+	QPRadioMap::iterator it = radioMap.begin();
+	for (; it != radioMap.end(); ++it) {
+		it->second->setEnabled((it->first & alignPossible) ||
+		   (it->first == LYX_ALIGN_LAYOUT));
+		QFont newFont = it->second->font();
+		newFont.setItalic((it->first == defaultAlignment) || 
+		  (it->first == LYX_ALIGN_LAYOUT));
+		it->second->setFont(newFont);
 	}
 }
 
 
-void QParagraphDialog::on_alignDefaultCB_toggled(bool)
-{
-	checkAlignmentRadioButtons();
-	alignmentToRadioButtons();
-}
-
-
 void QParagraphDialog::alignmentToRadioButtons(LyXAlignment align)
 {
-	if (align == LYX_ALIGN_LAYOUT)
-		align = form_->controller().alignDefault();
+	LyXAlignment const defaultAlignment = form_->controller().alignDefault();
+	if (align == LYX_ALIGN_LAYOUT || align == defaultAlignment) {
+		alignDefaultRB->blockSignals(true);
+		alignDefaultRB->setChecked(true);
+		alignDefaultRB->blockSignals(false);
+		return;
+	}
 
 	QPRadioMap::const_iterator it = radioMap.begin();
 	for (;it != radioMap.end(); ++it) {
 		if (align == it->first) {
+			it->second->blockSignals(true);
 			it->second->setChecked(true);
+			it->second->blockSignals(false);
 			return;
 		}
 	}
@@ -145,8 +147,6 @@
 
 LyXAlignment QParagraphDialog::getAlignmentFromDialog()
 {
-	if (alignDefaultCB->isChecked())
-		return LYX_ALIGN_LAYOUT;
 	LyXAlignment alignment = LYX_ALIGN_NONE;
 	QPRadioMap::const_iterator it = radioMap.begin();
 	for (; it != radioMap.end(); ++it) {
@@ -155,8 +155,6 @@
 			break;
 		}
 	}
-	if (alignment == form_->controller().alignDefault())
-		return LYX_ALIGN_LAYOUT;
 	return alignment;
 }
 
@@ -243,15 +241,8 @@
 	}
 
 	// alignment
-	LyXAlignment newAlignment = params.align();
-	LyXAlignment defaultAlignment = controller().alignDefault();
-	bool alignmentIsDefault =
-		newAlignment == LYX_ALIGN_LAYOUT || newAlignment == defaultAlignment;
-	dialog_->alignDefaultCB->blockSignals(true);
-	dialog_->alignDefaultCB->setChecked(alignmentIsDefault);
-	dialog_->alignDefaultCB->blockSignals(false);
 	dialog_->checkAlignmentRadioButtons();
-	dialog_->alignmentToRadioButtons(newAlignment);
+	dialog_->alignmentToRadioButtons(params.align());
 
 	//indentation
 	bool const c

Re: No paragraph alignment options


Bennett Helm wrote:

On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:

and this one doesn't make sense:

if we could tell beforehand what the default was because then we 
could show something like:

o Justified (default)
o Left
o Center
o Right
?

Of the options I've seen, I agree that this is the best.
In principle, I think default ought to be separate: Saying "default" 
means "don't do anything special", whereas saying "Justified" ought to 
mean, "Make it justified, no matter what". (Imagine you have a child 
doc, and it might be included in different master docs with different 
defaults.) In fact, that's not how LyX handles things at present. If you 
check "Justified" and that happens to be the default, then it's the same 
as checking "Default". But this is a different bug, I think, viz:


void Text::setParagraph(Cursor & cur,
   Spacing const & spacing, LyXAlignment align,
   docstring const & labelwidthstring, bool noindent)
{
BOOST_ASSERT(cur.text());
// make sure that the depth behind the selection are restored, too
pit_type undopit = undoSpan(cur.selEnd().pit());
recUndo(cur, cur.selBegin().pit(), undopit - 1);

for (pit_type pit = cur.selBegin().pit(), end = cur.selEnd().pit();
 pit <= end; ++pit) {
Paragraph & par = pars_[pit];
ParagraphParameters & params = par.params();
params.spacing(spacing);

// does the layout allow the new alignment?
Layout_ptr const & layout = par.layout();

if (align == LYX_ALIGN_LAYOUT)
align = layout->align;
if (align & layout->alignpossible) {
/// NOTE: It's right here that the bug mentioned above lies. It would be trivial
/// to change this if people thought it necessary. Just delete the next three 
lines
/// and fix the whitespace.
if (align == layout->align)
params.align(LYX_ALIGN_LAYOUT);
else
params.align(align);
}
par.setLabelWidthString(labelwidthstring);
params.noindent(noindent);
}
}

Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Is there an easy way to tell if an inset is modified?


The problem with bug 3903
(http://bugzilla.lyx.org/show_bug.cgi?id=3903) is clear, there is no
notifyCursorLeave when you are not in an InsetMathHull (the outer
level of the inset). Therefore, after you edit in, for example, super
or subscript, math preview is not updated.

There is another problem with the current approach: preview snippet is
always regenerated with notifyCursorLeave. That is to say, output to
latex will happen every time when you enter and leave a mathed. This
is, presumably, inefficient.

My solution is to find a way to know if an inset is modified. If so,
clear snippet_, and when a redraw is *needed*, snippet_ is
regenerated.

The attached pre-patch has already fixed the bug, just that too many
events mark an inset dirty so preview is regenerated way too many
times. Help is needed here.

Index: src/insets/RenderPreview.h
===
--- src/insets/RenderPreview.h  (revision 18842)
+++ src/insets/RenderPreview.h  (working copy)
@@ -84,6 +84,12 @@
/// equivalent to dynamic_cast
virtual RenderPreview * asPreview() { return this; }

+   /// clear preview
+   void clear() { snippet_.clear(); }
+
+   /// is this preview empty?
+   bool empty() { snippet_.empty(); }
+

BO: clear snippet_.

Index: src/insets/Inset.h
===
--- src/insets/Inset.h  (revision 18842)
+++ src/insets/Inset.h  (working copy)
@@ -433,6 +433,9 @@
/// Add an entry to the TocList
/// pit is the ParConstIterator of the paragraph containing the inset
virtual void addToToc(TocList &, Buffer const &, ParConstIterator &) 
const {}
+   /// mark this inset as dirty, inset can, for example, regenerate
+   /// preview in this function
+   virtual void markDirty() {}

BO: Another virtual function of inset This is to mark inset as
dirty so appropriate action can be taken. I add it here because it can
be used to, for example, re-generate TOC.


@@ -276,6 +284,12 @@
 bool InsetMathHull::previewState(BufferView * bv) const
{
if (!editing(bv) && RenderPreview::status() == LyXRC::PREVIEW_ON) {
+   if (preview_->empty()) {
+   docstring const snippet = latex_string(*this);
+   lyxerr << "add preview" << to_utf8(snippet) << 
std::endl;
+   preview_->addPreview(snippet, *bv->buffer());
+   preview_->startLoading(*bv->buffer());
+   }
graphics::PreviewImage const * pimage =
preview_->getPreviewImage(*bv->buffer());
return pimage && pimage->image();
@@ -395,19 +409,6 @@
}

BO: if preview_ is empty, regenerate it.


-bool InsetMathHull::notifyCursorLeaves(Cursor & cur)
-{
-   if (RenderPreview::status() == LyXRC::PREVIEW_ON) {
-   Buffer const & buffer = cur.buffer();
-   docstring const snippet = latex_string(*this);
-   preview_->addPreview(snippet, buffer);
-   preview_->startLoading(buffer);
-   cur.updateFlags(Update::Force);
-   }
-   return false;
-}

BO: Remove notifyCursorLeave.

+void InsetMathHull::markDirty()
+{
+   preview_->clear();
+ }

BO: if the inset is dirty, clear preview.


Index: src/mathed/InsetMathNest.cpp
===
--- src/mathed/InsetMathNest.cpp(revision 18842)
+++ src/mathed/InsetMathNest.cpp(working copy)
@@ -1001,6 +1001,9 @@
InsetMath::doDispatch(cur, cmd);
break;
}
+   // FIXME: Need an efficient way of knowing if the inset has been 
modified.
+   if (cur.result().dispatched())
+   markDirty();
}

 This is the unfinished part. Numerous LFUNC can contaminate an
inset, what is the best way to know if an inset is modified? I am
thinking of doing an markDiry after each recordUndo, but there are too
many recordUndo's. Is there any way to know if recordUndo() is called?

Cheers,
Bo
Index: src/insets/RenderPreview.h
===
--- src/insets/RenderPreview.h	(revision 18842)
+++ src/insets/RenderPreview.h	(working copy)
@@ -84,6 +84,12 @@
 	/// equivalent to dynamic_cast
 	virtual RenderPreview * asPreview() { return this; }
 
+	/// clear preview
+	void clear() { snippet_.clear(); }
+
+	/// is this preview empty?
+	bool empty() { snippet_.empty(); }
+
 private:
 	/// Not implemented.
 	RenderPreview & operator=(RenderPreview const &);
Index: src/insets/Inset.h
===
--- src/insets/Inset.h	(revision 18842)
+++ src/insets/Inset.h	(working copy)
@@ -433,6 +433,9 @@
 	/// Add an entry to the TocList
 	/// pit is the ParConstIterator of the paragraph containing the inset
 	virtual void addToToc(TocList &, Buffer const &, ParConstIterator &) const {}

Re: No paragraph alignment options

2007-06-21 Thread Bennett Helm


On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:


and this one doesn't make sense:

if we could tell beforehand what the default was because then we  
could show something like:


o Justified (default)
o Left
o Center
o Right


?



Of the options I've seen, I agree that this is the best.

Bennett

Re: No paragraph alignment options


and this one doesn't make sense:

if we could tell beforehand what the default was because then we could 
show something like:


o Justified (default)
o Left
o Center
o Right


?

Re: Update of previews too lazy


> When editing a nested element in an math inset and clicking outside
> the complete formula the preview never (not slowly, never) gets
> updated. But this is so far the only case where I can really
> reproduce it.


This is now bug 3903.

Bo

Re: No paragraph alignment options


Anders Ekberg wrote:

On 21 jun 2007, at 13.12, Helge Hafting wrote:

Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not 
an option in the way that the others are.

Sorry, but I consider that a bad argument. Sure, "default" is a bit
different. That does NOT imply it can't be a radio button like the rest.

To me, "default" means "whatever is default for this paragraph type"
while the other choices are explicit. (I.e. if you really want a
right-adjusted heading, and so on.)

The problem is not so much that the interface is hard to understand.
(It _is_, but people always learn such stuff after a while. Even 
non-latexers

keep a few useful latex commands around. . .)
It is also clunky to use, which is the big killer here.
If I want "centered", I want to click "centered" and be done with it!
I do not want to have to uncheck "default" first.
And I believe most other writers see it the same way.

Agree.
It is also consistent with the text settings where "Reset" (read 
Default) is an option like all others in the pop-up menus. In fact to 
use a pop-up menu with

No change
Justified
Left
Center
Right
Reset
would increase the consistency. Would this be a possibility?
I agree with Helge's analysis, too, and have prepared a patch which I'll 
send separately. I propose to stick with "default", though, again for 
Helge's reasons: It means "whatever the default is for this paragraph" 
and corresponds to LYX_ALIGN_LAYOUT. So it basically means "No special 
alignment". There's no need to "No change", so far as I can see. If you 
want that, you just don't do anything, since the button will always be 
set to whatever it was before.


Richard



/Anders



--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: No paragraph alignment options

2007-06-21 Thread Anders Ekberg


On 21 jun 2007, at 13.12, Helge Hafting wrote:

Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's  
not an option in the way that the others are.

Sorry, but I consider that a  bad argument. Sure, "default" is a bit
different.  That does NOT imply it can't be a radio button like the  
rest.


To me, "default" means "whatever is default for this paragraph type"
while the other choices are explicit. (I.e. if you really want a
right-adjusted heading, and so on.)

The problem is not so much that the interface is hard to understand.
(It _is_, but people always learn such stuff after a while. Even  
non-latexers

keep a few useful latex commands around. . .)
It is also clunky to use, which is the big killer here.
If I want "centered", I want to click "centered" and be done with it!
I do not want to have to uncheck "default" first.
And I believe most other writers see it the same way.


Agree.
It is also consistent with the text settings where "Reset" (read  
Default) is an option like all others in the pop-up menus. In fact to  
use a pop-up menu with

  No change
  Justified
  Left
  Center
  Right
  Reset
would increase the consistency. Would this be a possibility?

/Anders

Re: Close button takes half of the tabbar?


> Maybe I am lacking an icon?

There should be an icon. And then Qt renders it small AFAIK. Have you
updated your resource folder?


I have added closetab.xmp to scons_manifest.py.

Cheers,
Bo

Re: Ehancement request: paragraph-params-noalign LFUN


Bob Alvarez wrote:

I hope this is the right place to send this.
You can post such things at bugzilla.lyx.org, but I've added a note to 
2714 about it, so no need now.


I usually do not want to start a new paragraph after a display 
equation, so I have been setting the next paragraph to \noindent using 
ERT.


This is quite tedious so I created a keyboard shortcut to do the job 
(with the help of Richard Heck).
\bind "C-y" "command-sequence ert-insert; self-insert \noindent a; 
delete-backward; next-inset-toggle"


I think this is a common problem and you should consider building it 
into LyX.

Will do.

rh

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: Close button takes half of the tabbar?



Am 21.06.2007 um 16:16 schrieb Bo Peng:


New doc1 | New doc2 |   | Close |

My close button is huge here, please correct it. This is qt422, linux.

Maybe I am lacking an icon?

Cheers,
Bo


There should be an icon. And then Qt renders it small AFAIK. Have you  
updated your resource folder?


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Close button takes half of the tabbar?


New doc1 | New doc2 |   | Close |

My close button is huge here, please correct it. This is qt422, linux.

Maybe I am lacking an icon?

Cheers,
Bo

Re: [PATCH] BUG 1486 copied formula is not previewed.

2007-06-21 Thread José Matos

On Thursday 21 June 2007 14:36:33 Bo Peng wrote:
> Anyway, your patch fixes this specific problem with less code, so it can go
> in.
>
> Cheers,
> Bo

OK.

-- 
José Abílio

Re: Is the glossary in 1.5svn supposed to work?

2007-06-21 Thread Juergen Spitzmueller

Helge Hafting wrote:

> The problem is solved. I had a custom makeindex script in order to
> support index styles and still use indexes from within lyx-1.3
> This script did not work with glossaries though.  Removing it
> fixed everything.

You know that you can customize the makeindex call now in preferences (in
order to support styles)?

Jürgen

Re: [PATCH] BUG 1486 copied formula is not previewed.


I wonder if there is any side-effect of using something like the attached
instead.


Your patch is better, so you have my OK.

My original thought was to remove outside addPreview so that all
MathHull (and other previewable insets) get their preview in this way
(if preview empty, add snippet). I mean, buffer or bufferview should
not have to worry about adding preview for insets. If some nested
mathed is changed, it can simply remove this snippet so that it will
be re-generated

Anyway, your patch fixes this specific problem with less code, so it can go in.

Cheers,
Bo

Re: Update of previews too lazy


Same problem here:

When editing a nested element in an math inset and clicking outside
the complete formula the preview never (not slowly, never) gets
updated. But this is so far the only case where I can really
reproduce it.


Please file a bugzilla report about it since Jose dictated that every
patch must has a bug number. :-)

I am looking at preview-related bugs.

Bo

Re: Bug 3561: crash on encoding changes, the real reason

2007-06-21 Thread Juergen Spitzmueller

Stefan Schimanski wrote:

> This is a critical bug for quite some time in bugzilla without a
> clear explanation what the problem is. I added this now as a comment.
> It has not much to do with the source view, but with encoding changes
> in general, also during TeX export. You basically cannot export
> documents with paragraphs starting in encoding A and finishing in
> encoding B. I think we should really fix that before RC2 (I hope it's
> not too late).

It's good that you are on the issue, and I agree this should be fixed ASAP.
I'm afraid I cannot be of much help. I already tried to debug this one, and
I do not really understand what's going on.

Jürgen

Re: Update of previews too lazy

2007-06-21 Thread Andreas Neustifter



On 20.06.2007, at 23:30, Bernhard Roider wrote:

Bo Peng schrieb:

On 6/20/07, Neal Becker <[EMAIL PROTECTED]> wrote:

1.50rc1

When I edit math, previews don't update until I fiddle around a bit.

1. Edit math
2. Click outside math - no update
3. Click inside math again
4. Click outside math again.  Maybe update this time.

This is because it takes time for latex to compile your math, I guess
there is nothing we can do here, unless you are willing to let lyx
freeze until the preview is generated.



No, there is really a problem. It often happens that the previewed  
image does not reflect the current version of the formula. then you  
have to click inside ans outside and sometimes that helps to  
generate a new prview image. What allways helps: leave the formula  
with the cursor. And what i think i can say (but i could not verify  
exactly) is that if you click inside a nested element in the  
formula (like the numerator of a fraction) and then outide it does  
_not_ generate a new image.


Same problem here:

When editing a nested element in an math inset and clicking outside  
the complete formula the preview never (not slowly, never) gets  
updated. But this is so far the only case where I can really  
reproduce it.


(LyX rev. 18837, Qt 4.3.0 source, Mac OS X)

Andi

Re: Bug: Need to remove the .aux file when changing document language?


Helge Hafting wrote:

I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)

The glossary problem is now solved (bad local makeindex)
but the .aux problem remains.



The rater annoying error is that I get latex compile errors whenever
I change the document language!

I.e. view->dvi once, change document language, now you
can't view->dvi again because the previous language is
"undefined".  Of course it is - it is not in use!

Looking at exported .tex, there was no mention of the
previous language at all. The string did not exist in the file.
But it did exist in the .aux file, and LyX seems to think it
is ok to re-use this file? Removing the .aux file
fixed everything, I could then view->dvi with a different language.

Perhaps LyX should take care do do this then, when a
document language change is applied?

Helge Hafting

Re: Is the glossary in 1.5svn supposed to work?


Georg Baum wrote:

Helge Hafting wrote:

  

I noticed the glossary stuff while translating.
Inserting a few entries as well as a glossary don't
do anything though.  No errors - and no glossary.



This should not happen. Glossaries are supposed to work.

  

I exported the file to tex, and ran latex
myself.  The logfile tell me that there
is no "testfile.nls" - documentation
suggests that makeindex was supposed to make
that one for me.



This is because you did not run makeindex with special arguments that are
required for glossaries.

  

Indexes work fine, so I don't think my makeindex is broken.

Is there anything else I ought to do or install? Should
lyx check that the installation supports glossaries?



This is done: LyX loads the nomencl package with a minimum required version.
This should result in an error if it is not available.

I suspect that the log file parsing is broken so that it does not recognize
that a .nls file is needed, and therefore does not create one. Maybe this
is related to http://bugzilla.lyx.org/show_bug.cgi?id=3132.
  

The problem is solved. I had a custom makeindex script in order to
support index styles and still use indexes from within lyx-1.3
This script did not work with glossaries though.  Removing it
fixed everything.

Helge Hafting

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


Mostafa Vahedi schrieb:


OK. So which way are we going to follow? The manual one or
the other one?


The automatic one if possible.

 I tested, but it doesn't work for me, 

no matter where I call \TOCLanguage.


We should load the babel package this way: 
"\usepackage[farsi,arabic,english]{babel}", 
before using the command "\TOCLanguage{farsi}".

This command is defined in the arabic-babel files.


I did this and it doesn't work. I'll check this again later today.


I am using the windows version packaged for MiKTeX 2.5
on the date 2nd Jan 2007.


I use the same one but with MiKTeX 2.6.

regards Uwe

Bug: Need to remove the .aux file when changing document language?


I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)

The rater annoying error is that I get latex compile errors whenever
I change the document language!

I.e. view->dvi once, change document language, now you
can't view->dvi again because the previous language is
"undefined".  Of course it is - it is not in use!

Looking at exported .tex, there was no mention of the
previous language at all. The string did not exist in the file.
But it did exist in the .aux file, and LyX seems to think it
is ok to re-use this file? Removing the .aux file
fixed everything, I could then view->dvi with a different language.

Perhaps LyX should take care do do this then, when a
document language change is applied?

Helge Hafting

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


 6)(One other bug!). We should add the command
 "\selectlanguage{farsi}" as an ERT as the first 
 line of the
 document.

>>> I can see no difference. With and without the 
>>> ERT command, the result is identical.

>> I checked this issue after applying the patches. 
>> Still I have problem if I don't put the mentioned 
>> ERT. Something is wrong!!

> What is wrong?
> What is the version number of the arabi-package 
> you are using? Mine is version 1.1, December 16, 2006


I found out the problem. 

First note that when you don't put the command 
"\TOCLanguage{farsi}" everything is OK except 
that you will see the page numbers in English. 
Don't you? Moreover in this case putting the 
ERT does not make any difference!

But if you put the command "\TOCLanguage{farsi}" then
if you do not put "\selectlanguage{farsi}" as the first
command after the "\begin{document}" or in other words
as an ERT at the first line of the document then you
will receive several complains from LyX about some
undefined characters.


 
-
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.

Re: No paragraph alignment options


Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not an 
option in the way that the others are. 

Sorry, but I consider that a  bad argument. Sure, "default" is a bit
different.  That does NOT imply it can't be a radio button like the rest.

To me, "default" means "whatever is default for this paragraph type"
while the other choices are explicit. (I.e. if you really want a
right-adjusted heading, and so on.)

The problem is not so much that the interface is hard to understand.
(It _is_, but people always learn such stuff after a while. Even 
non-latexers

keep a few useful latex commands around. . .)
It is also clunky to use, which is the big killer here.
If I want "centered", I want to click "centered" and be done with it!
I do not want to have to uncheck "default" first.
And I believe most other writers see it the same way.

"Conceptual" differences really isn't that interesting.  So please -
make "default" a radio button the same way as left/rigth/center.

If you feel a need to mark the conceptual difference - feel free
to set the "default" radio button a little apart from the other
radio buttons, as you suggested.  That is fine!  But it should
definitely _work_ like "just another radio button" in this case.
The user can then change alignment with a _single_
click or hotkey. It is easy to understand too. :-)

Some ideas. Separator line:

o Default
 -
o Justified
o Right
o Center
o Left

or indentation:

o Default
o Justified
o Right
o Center
o Left

The user can now see that "default" is a special state, but
still change it with a _single_ operation. Ease of use, and easily learned.

(Which alignment is the default varies depending on the environment, 
but the default will be one of left, right, centered, or justified.) 
It's for this reason that I haven't been able to think of anything 
better than how it is now, and once you see the logic of it, it does 
seem reasonable. The only trouble is that the logic isn't obvious.


So, to answer Richard: I don't have any good idea how to improve it. I 
wouldn't put in a line to separate them; that does the opposite of 
what you want: to indicate a link between them. Boldface doesn't seem 
the right sort of thing: what's wanted is a visual image that 
indicates that the default checkbox has a kind of priority or control 
over the status of the radio buttons. Perhaps, then, the radio buttons 
should be indented a bit underneath the checkbox?


X Default
  o Justified
  o Left
  o Center
  o Right

(Notice that I've switched the order of the radio buttons, putting 
center in the middle rather than at the end.) 

Center in the center - nice idea!

Helge Hafting

Re: center table - confusing interface for text alignment


Neal Becker wrote:

Actually, it's not table.  If I put the cursor anywhere in the document, I
have the same result.  All the options for alignment are greyed out, and
default is checked.
  

Uncheck default then.
Default sets the alignment to whatever is preferred for
the paragraph type in question.
("standard" is block aligned, headings are left aligned, . . .)

When "standard" is unchecked, the explicit choices becomes
possible instead. I can see that this is confusing,
it would probably be better to have "standard" being
just another radio button along with the others.

Helge Hafting

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


>> Mostafa Vahedi schrieb:

>> I can not give any guarantee about the fix. The author 
>> is extermely busy sometimes. I prefer the manual one for 
>> the time being. Then if it stays more we can do something 
>> about it. I have submitted many bug fixes to the author 
>> and I am waiting for his reply.

> OK, but this requires a bit more work. I suggest you 
> open a new bug report in bugzilla so that we can keep 
> the overview.

OK. So which way are we going to follow? The manual one or
the other one?

>>> See the attached patch. I implemented this but disabled 
>>> it because \TOCLanguage gives me the error "unknown 
>>> command". Therefore your example-lyxified doesn't 
>>> compile.

>> The command "\TOCLanguage{}" is defined after the 
>> call to BABEL in Latex Preamble.

> This was the first I tested, but it doesn't work for me, 
> no matter where I call \TOCLanguage.

We should load the babel package this way: 
"\usepackage[farsi,arabic,english]{babel}", 
before using the command "\TOCLanguage{farsi}".
This command is defined in the arabic-babel files.

>> The Arabic peopel may use other quotation marks. 
>> I will check it!

> Please inform me when you found it out.

Sure.

> 6) (One other bug!). We should add the command
> "\selectlanguage{farsi}" as an ERT as the first 
> line of the
> document.

>>> I can see no difference. With and without the ERT 
>>> command, the result is identical.
  
>> I checked this issue after applying the patches. 
>> Still I have problem if I don't put the mentioned 
>> ERT. Something is wrong!!

> What is wrong?
> What is the version number of the arabi-package you are using? Mine is 
> version
> Version 1.1, December 16, 2006

I am using the windows version packaged for MiKTeX 2.5
on the date 2nd Jan 2007.

> Does the fontenc part of my patch work for you?

Yes. Thanks.

Mostafa


 
-
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


Mostafa Vahedi schrieb:

I can not give any guarantee about the fix. The author is extermely busy 
sometimes. I prefer the manual one for the time being. Then if it stays 
more we can do something about it. I have submitted many bug fixes to 
the author and I am waiting for his reply.


OK, but this requires a bit more work. I suggest you open a new bug report in bugzilla so that we 
can keep the overview.



 > See the attached patch. I implemented this but disabled it because
 > \TOCLanguage gives me the error
 > "unknown command". Therefore your example-lyxified doesn't compile.
 
The command "\TOCLanguage{}" is defined after the call to BABEL in Latex 
Preamble.


This was the first I tested, but it doesn't work for me, no matter where I call 
\TOCLanguage.


The Arabic peopel may use other quoatation marks. I will check it!


Please inform me when you found it out.


  6) (One other bug!). We should add the command
  "\selectlanguage{farsi}" as an ERT as the first line of the
  document.
 > I can see no difference. With and without the ERT command, the result
 > is identical.
 
I checked this issue after applying the patches. Still I 
have problem if I don't put the mentioned ERT. Something is wrong!!


What is wrong?
What is the version number of the arabi-package you are using? Mine is version
Version 1.1, December 16, 2006

---

Does the fontenc part of my patch work for you?

regards Uwe

RE: Re: Empty Math Panel Popups

2007-06-21 Thread Leuven, E.

Alfredo wrote:
>> Edwin Leuven wrote:
>> unless someone shouts out i am gonna put this in by noon tomorrow (thu 21)
>
> (shouting) You have my ok :-)

enjoy:

http://www.lyx.org/trac/changeset/18842

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable


 6) (One other bug!). We should add the command 
 "\selectlanguage{farsi}" as an ERT as the first line of the 
 document.

>>> No need for this. When the document language is Farsi, no switch is 
>>> needed. For later switches, this 
>>> is currently correctly done by LyX.

>> Again as I said this bug is due to ARABI package. In the previous 
>> email I have attached the example_lyxified.lyx. Try to compile it as it 
>> is and then try to compile it without the first line containing the 
>> ERT. You will see that LyX will complain about some undefined characters. 
>> Again since this is a bug of LyX we should not change the source again 
>> as I said before!

> I can see no difference. With and without the ERT command, the result 
> is identical.

I checked this issue after applying the patches. Still I 
have problem if I don't put the mentioned ERT. Something 
is wrong!!


   
-
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, 
when.

Bug 3561: crash on encoding changes, the real reason


May I point you to http://bugzilla.lyx.org/show_bug.cgi?id=3561 again?

This is a critical bug for quite some time in bugzilla without a  
clear explanation what the problem is. I added this now as a comment.  
It has not much to do with the source view, but with encoding changes  
in general, also during TeX export. You basically cannot export  
documents with paragraphs starting in encoding A and finishing in  
encoding B. I think we should really fix that before RC2 (I hope it's  
not too late).


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: [PATCH] BUG 1486 copied formula is not previewed.

Bo Peng wrote:

>> Waiting for two OKs.
> 
> Please use this version.

I wonder if there is any side-effect of using something like the attached
instead.

A/

Index: InsetMathHull.cpp
===
--- InsetMathHull.cpp	(revision 18837)
+++ InsetMathHull.cpp	(working copy)
@@ -182,7 +182,7 @@
 InsetMathHull::InsetMathHull(InsetMathHull const & other)
 	: InsetMathGrid(other),
 	  type_(other.type_), nonum_(other.nonum_), label_(other.label_),
-	  preview_(new RenderPreview(this))
+	  preview_(new RenderPreview(*other.preview_, this))
 {}

Re: No paragraph alignment options


Bennett Helm wrote:

X Default
  o Justified
  o Left
  o Center
  o Right


maybe giving the choice between "default" or "environment default" and 
"custom" or "force" makes it more explicit?


o Default
o Custom
  o Justified
  o Left
  o Center
  o Right

it would of course be nicer if we could tell beforehand what the default 
was because then we could show something like:


o Justified (default)
o Left
o Center
o Right

and not take any action when the default button is checked

...

Re: [patch] fix bug 2928: make Arabic and Farsi correctly usable