Re: Towards rc1 (status update #4, trunk frozen)

[Pavel Sanda]

Stephan Witt wrote:
 But I tried to verify it on Linux - it is there too. No platform dependency!
 You have to disable the Open documents in tabs check box in preferences and
 follow the recipe Anders gave exactly.
 
 Interestingly the existing document is marked as changed after saving the 
 preamble
 of the new document!

Anders, can you file a new bug report? pavel

Setting use_system_colors to true?

[Jean-Marc Lasgouttes]

Hello,

Since we might get more system-like icons, could we set system colors to 
'true' by default? Remember that the background color is not affected, 
for you linen lovers :)


JMarc

Re: Setting use_system_colors to true?

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 Since we might get more system-like icons, could we set system colors to 
 'true' by default? Remember that the background color is not affected, 
 for you linen lovers :)

Can you remember me which colors are affected?

Jürgen

Re: Setting use_system_colors to true?

[Stephan Witt]

Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes:

 Hello,
 
 Since we might get more system-like icons, could we set system colors to 
 'true' by default? Remember that the background color is not affected, for 
 you linen lovers :)

I'd happily distribute it like that for mac os.
This patch I did not commit because I didn't know if it is controversial.

Stephan

Re: Setting use_system_colors to true?

[Jean-Marc Lasgouttes]

Le 08/03/2011 12:05, Stephan Witt a écrit :

Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes:


Hello,

Since we might get more system-like icons, could we set system colors to 'true' 
by default? Remember that the background color is not affected, for you linen 
lovers :)


I'd happily distribute it like that for mac os.
This patch I did not commit because I didn't know if it is controversial.


I'd say that next rc would be a good time to know whether it is 
controversial.


JMarc

Setting GUI to english

[Jean-Marc Lasgouttes]

A stupid question: is it suppoed to be possible in preferences to set 
the GUI to 'no translation' aka english? I cannot do that at least on my 
build.


JMarc

Re: Setting GUI to english

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 A stupid question: is it suppoed to be possible in preferences to set 
 the GUI to 'no translation' aka english? I cannot do that at least on my 
 build.

I have English and this seems to work.

Jürgen

Re: Setting use_system_colors to true?

[Stephan Witt]

Am 08.03.2011 um 12:08 schrieb Jean-Marc Lasgouttes:

 Le 08/03/2011 12:05, Stephan Witt a écrit :
 Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes:
 
 Hello,
 
 Since we might get more system-like icons, could we set system colors to 
 'true' by default? Remember that the background color is not affected, for 
 you linen lovers :)
 
 I'd happily distribute it like that for mac os.
 This patch I did not commit because I didn't know if it is controversial.
 
 I'd say that next rc would be a good time to know whether it is controversial.

I did it :)

Stephan

Re: Setting GUI to english

[Vincent van Ravesteijn]

On Tue, Mar 8, 2011 at 12:10 PM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 A stupid question: is it suppoed to be possible in preferences to set the
 GUI to 'no translation' aka english? I cannot do that at least on my build.

 JMarc

Aussi ici, pas de problème.

Vincent

Re: Setting use_system_colors to true?

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 Jean-Marc Lasgouttes wrote:
  Since we might get more system-like icons, could we set system colors to 
  'true' by default? Remember that the background color is not affected, 
  for you linen lovers :)
 
 Can you remember me which colors are affected?

wasn't some flame war around this ? i mean why it didn't happen at that time
if its good idea... :) (can't rememember details)

pavel

Re: Setting use_system_colors to true?

[Jürgen Spitzmüller]

Pavel Sanda wrote:
  Can you remember me which colors are affected?
 
 wasn't some flame war around this ? i mean why it didn't happen at that
 time if its good idea... :) (can't rememember details)

The only flames I remember in this context were fueled by the background color 
of the work area. As far as I am concerned, I am probably fine with the 
proposed change (as long as the background area is preserved ;-)

Jürgen

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Richard Heck]

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
formated ref for a cross reference, the package prettyref is loaded in
the LaTeX preamble but the reference is traduced by \ref{...} instead of
\prettyref{...}.

I've just tried this with latest trunk, and I do not see this problem. 
Is the label itself in the form prefix:label? If not, then, we do just 
output \ref, so the thing will compile.


Richard

Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Hello,

I started using LyX 2.0RC1, and by now, there is only one thing that
bothers  me:
While I'm typing a document in one language, and then, when the cursor is
right after the last word (with no space), I'm typing language hebrew  in
the minibuffer (or: using predefined shortcuts that commits the same). The
language do changes, but the last word is also marked and it's language
switched.

For example, If I write one two^, and when the cursor is where the ^ is,
changes the language, it will convert into one [owt],  when the two is
reversed, as it thinks it's in Hebrew, and the [ - ] part is marked.

This is new behavior - it was not there in some previous versions of 2.0,
but it's there in beta 4.

Thanks,
Ronen.

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Stephan Witt]

Am 08.03.2011 um 16:51 schrieb Ronen Abravanel:

 Hello,
 
 I started using LyX 2.0RC1, and by now, there is only one thing that bothers  
 me: 
 While I'm typing a document in one language, and then, when the cursor is 
 right after the last word (with no space), I'm typing language hebrew  in 
 the minibuffer (or: using predefined shortcuts that commits the same). The 
 language do changes, but the last word is also marked and it's language 
 switched.
 
 For example, If I write one two^, and when the cursor is where the ^ is, 
 changes the language, it will convert into one [owt],  when the two is 
 reversed, as it thinks it's in Hebrew, and the [ - ] part is marked. 
 
 This is new behavior - it was not there in some previous versions of 2.0, but 
 it's there in beta 4.

Yes, this is new - but it's meant as a feature.
If you change the language without any selection LyX changes the language of 
the word under the cursor.

Do you want to change the language for the delimiter following the word? Sorry, 
I don't know anything about hebrew.

Stephan

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

My most common situation in which this is a problem is the following

Hebrew text (English translation) more hebrew..

For most language, you wouldn't mind if the  ( ) will be in English or in
other language, but Hebrew is written from right to left, which means the
Parentheses  are written in reverse. Meaning, if the closing parentheses
will be in English, it will apear as:

Hebrew text ((English Hebrew

(Or something like that)

there fore, the following parentheses or comma must be at the same language
as the paragraph language, and not as the last-word language.

My override now is

hebrew (english ) hebrew, or hebrew english , hebrew [note the space before
the comma or the closing parentheses], and that's both ugly and wrong.

An Hebrew example:
כותב בעברית (english) עברית -- In this way its typed when the closing
parentheses is hebrew
כותב בעברית ((english  עברית. -- here the closing parentheses is english

Thanks,
Ronen.


On Tue, Mar 8, 2011 at 6:18 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 08.03.2011 um 16:51 schrieb Ronen Abravanel:

  Hello,
 
  I started using LyX 2.0RC1, and by now, there is only one thing that
 bothers  me:
  While I'm typing a document in one language, and then, when the cursor is
 right after the last word (with no space), I'm typing language hebrew  in
 the minibuffer (or: using predefined shortcuts that commits the same). The
 language do changes, but the last word is also marked and it's language
 switched.
 
  For example, If I write one two^, and when the cursor is where the ^
 is, changes the language, it will convert into one [owt],  when the two
 is reversed, as it thinks it's in Hebrew, and the [ - ] part is marked.
 
  This is new behavior - it was not there in some previous versions of 2.0,
 but it's there in beta 4.

 Yes, this is new - but it's meant as a feature.
 If you change the language without any selection LyX changes the language
 of the word under the cursor.

 Do you want to change the language for the delimiter following the word?
 Sorry, I don't know anything about hebrew.

 Stephan

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Charpentier Philippe]

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
formated ref for a cross reference, the package prettyref is loaded in
the LaTeX preamble but the reference is traduced by \ref{...} instead of
\prettyref{...}.

I've just tried this with latest trunk, and I do not see this problem. Is the 
label itself in the form prefix:label? If not, then, we do just output \ref, 
so the thing will compile.


Richard

No: with the french language and babel loaded, the form prefix:label will not 
compile on my system. As I said in a very old discussion, the only way to 
compile on all systems, is to modify prettyref.sty (replacing : by |) and to 
use prefix|label. This was possible with all previous versions of lyx and that 
is what I did in my french documents. Thus they will not compile correctly with 
lyx-2.0 if nothing is changed.

PhC

compile 2.0rc1 on mac

[William Bray]

I have been testing the beta versions of Lyx 2.0 for some time on my Mac 
running OS 10.6.6.

With the latest svn version I get the following error in the build stage 
regarding Hunspell:


  CXXHunspellChecker.o
HunspellChecker.cpp:31:33: error: hunspell/hunspell.hxx: No such file or 
directory
HunspellChecker.cpp:45: error: ‘Hunspell’ was not declared in this scope
HunspellChecker.cpp:45: error: template argument 2 is invalid
HunspellChecker.cpp:45: error: template argument 4 is invalid
HunspellChecker.cpp:45: error: invalid type in declaration before ‘;’ token
HunspellChecker.cpp:62: error: ISO C++ forbids declaration of ‘Hunspell’ with 
no type
HunspellChecker.cpp:62: error: expected ‘;’ before ‘*’ token
HunspellChecker.cpp:63: error: ISO C++ forbids declaration of ‘Hunspell’ with 
no type
HunspellChecker.cpp:63: error: expected ‘;’ before ‘*’ token
HunspellChecker.cpp:64: error: ISO C++ forbids declaration of ‘Hunspell’ with 
no type
HunspellChecker.cpp:64: error: expected ‘;’ before ‘*’ token
HunspellChecker.cpp: In destructor ‘lyx::HunspellChecker::Private::~Private()’:
HunspellChecker.cpp:97: error: expected initializer before ‘it’
HunspellChecker.cpp:98: error: expected initializer before ‘end’
HunspellChecker.cpp:100: error: ‘it’ was not declared in this scope
HunspellChecker.cpp:100: error: ‘end’ was not declared in this scope
HunspellChecker.cpp: At global scope:
HunspellChecker.cpp:178: error: expected constructor, destructor, or type 
conversion before ‘*’ token
HunspellChecker.cpp:188: error: expected constructor, destructor, or type 
conversion before ‘*’ token
HunspellChecker.cpp:382: error: expected `}' at end of input
make[4]: *** [HunspellChecker.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
**

I have not seen this listed as a bug?

My config line is
./configure --with-version-suffix=-2.0 --with-libiconv-prefix=/usr --with-x=no 
--disable-stdlib-debug --prefix=/Applications/Lyx-2.app 
--with-qt4-dir=/usr/local/qt4 --enable-build-type=release

As a work around, if I add the option --with-hunspell=no to the config line, 
then the prerelease builds fine.

best regards,

bill

PS I did not encounter this problem until very recently, i.e., earlier beta 
versions built fine.

[RFC] what is a word (boundary)?

[Jürgen Spitzmüller]

IIRC somebody already brought up this issue some time back.

Hunspell can check both complex composites constructed with (hard) hyphens (as 
in fifty-year-old chap) and, more interestingly, elliptical or fractal 
composites who use a hard hyphen in order to refer to a shared morpheme in a 
paired word form (as in two- and threefold or German Betriebsklima und 
-sicherheit).

At least in German, both types of these beasts are pretty frequent, so we 
should pass hard hyphens to the speller if hunspell is used, instead of just 
trimming them off the word (as we do now). The results, at least here, are way 
better. Currently, for instance, Hunspell would mark -sicherheit as 
misspelled (since we pass sicherheit) and suggest Sicherheit and, nota 
bene, -sicherheit.

The attached patch is an attempt in this direction. It passes hard hyphens 
(and nonbreakdashes) to the speller if this speller is hunspell.

However, since the isWordSeparator function is not only used by the 
spellchecker, this change affects other things as well. For instance, 
currently, if you set the cursor left of the word socio-linguistics and hit 
Insert  Index entry, only socio is copied inside the index inset. With my 
patch, socio-linguistics as a whole is copied inside. This seems more 
correct to me, at least wrt English and German, however, it is of course not 
suitable that the index entry generation differs wrt to the speller which is 
used.

So my question is, should we

* limit the change to the hunspell checker only, which means that we set up an 
extra isWordSeparator function (or an option) for the spellchecker?

* treat hard hyphens not as word separators in general, i.e. ditch the 
canHandleSplitMorphemes() part of the patch?

To me, the second option makes more sense, but of course this the more 
intrusive change.

Jürgen
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp	(Revision 37883)
+++ src/Paragraph.cpp	(Arbeitskopie)
@@ -2843,11 +2843,31 @@
 
 bool Paragraph::isWordSeparator(pos_type pos) const
 {
-	if (Inset const * inset = getInset(pos))
+	bool const preserve_dash = theSpellChecker()
+		 theSpellChecker()-canHandleSplitMorphemes();
+
+	if (Inset const * inset = getInset(pos)) {
+		// if the speller can handle splitted morphemes
+		// we must pass nobreakdashes to the spell checker
+		InsetSpecialChar const * isc =
+			dynamic_castconst InsetSpecialChar*(inset);
+		if (preserve_dash  isc != 0
+		 (isc-kind() == InsetSpecialChar::NOBREAKDASH))
+			return false;
 		return !inset-isLetter();
+	}
 	if (pos == size())
 		return true;
 	char_type const c = d-text_[pos];
+	// if the speller can handle splitted morphemes
+	// and we have a hard hyphen (no en- or emdash),
+	// we pass this to the spell checker
+	if (c == '-'  preserve_dash) {
+		int j = pos + 1;
+		if ((j == size() || d-text_[j] != '-')
+		 (pos == 0 || d-text_[pos - 1] != '-'))
+			return false;
+	}
 	// We want to pass the ' and escape chars to the spellchecker
 	static docstring const quote = from_utf8(lyxrc.spellchecker_esc_chars + '\'');
 	return (!isLetterChar(c)  !isDigitASCII(c)  !contains(quote, c));
Index: src/SpellChecker.h
===
--- src/SpellChecker.h	(Revision 37883)
+++ src/SpellChecker.h	(Arbeitskopie)
@@ -75,6 +75,9 @@
 	/// if speller can spell check whole paragraph return true
 	virtual bool canCheckParagraph() const { return false; }
 
+	/// if speller can handle splitted morphemes (as in two- and threefold) 
+	virtual bool canHandleSplitMorphemes() const { return false; }
+
 	/// count of misspelled words
 	virtual int numMisspelledWords() const { return 0; }
 
Index: src/HunspellChecker.h
===
--- src/HunspellChecker.h	(Revision 37883)
+++ src/HunspellChecker.h	(Arbeitskopie)
@@ -31,6 +31,7 @@
 	void remove(WordLangTuple const );
 	void accept(WordLangTuple const );
 	bool hasDictionary(Language const * lang) const;
+	bool canHandleSplitMorphemes() const { return true; }
 	docstring const error();
 	void advanceChangeNumber();
 	///@}

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Richard Heck]

On 03/08/2011 11:47 AM, Charpentier Philippe wrote:

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
formated ref for a cross reference, the package prettyref is 
loaded in
the LaTeX preamble but the reference is traduced by \ref{...} 
instead of

\prettyref{...}.

I've just tried this with latest trunk, and I do not see this 
problem. Is the label itself in the form prefix:label? If not, 
then, we do just output \ref, so the thing will compile.


Richard

No: with the french language and babel loaded, the form prefix:label 
will not compile on my system. As I said in a very old discussion, the 
only way to compile on all systems, is to modify prettyref.sty 
(replacing : by |) and to use prefix|label. This was possible 
with all previous versions of lyx and that is what I did in my french 
documents. Thus they will not compile correctly with lyx-2.0 if 
nothing is changed.


Ahh, OK, then I guess we should check for the | separator, too. I'll do 
that shortly.


That said, wasn't the introduction of refstyle supposed to be the solution?

Richard


PhC

Re: compile 2.0rc1 on mac

[Stephan Witt]

Am 08.03.2011 um 18:29 schrieb William Bray:

 I have been testing the beta versions of Lyx 2.0 for some time on my Mac 
 running OS 10.6.6.
 
 With the latest svn version I get the following error in the build stage 
 regarding Hunspell:
 
 
  CXXHunspellChecker.o
 HunspellChecker.cpp:31:33: error: hunspell/hunspell.hxx: No such file or 
 directory
 ...
 make[4]: *** [HunspellChecker.o] Error 1
 make[3]: *** [all-recursive] Error 1
 make[2]: *** [all] Error 2
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2
 **
 
 I have not seen this listed as a bug?

You are the first one without hunspell header but with hunspell library... :)

 My config line is
 ./configure --with-version-suffix=-2.0 --with-libiconv-prefix=/usr 
 --with-x=no --disable-stdlib-debug --prefix=/Applications/Lyx-2.app 
 --with-qt4-dir=/usr/local/qt4 --enable-build-type=release
 
 As a work around, if I add the option --with-hunspell=no to the config line, 
 then the prerelease builds fine.

The attached patch fixes this. JMarc, is this the right thing?

Stephan

Index: config/spell.m4
===
--- config/spell.m4 (Revision 37877)
+++ config/spell.m4 (Arbeitskopie)
@@ -55,9 +55,11 @@
[lyx_use_hunspell=true; break;],
[lyx_use_hunspell=false])
 
-   AC_CHECK_LIB(hunspell, main, LIBS=-lhunspell $LIBS, 
lyx_use_hunspell=false)
-   if test x$lyx_use_hunspell = xfalse ; then
-   AC_CHECK_LIB(hunspell-1.2, main, [LIBS=-lhunspell-1.2 $LIBS 
lyx_use_hunspell=true], lyx_use_hunspell=false)
+   if test x$lyx_use_hunspell = xtrue ; then
+   AC_CHECK_LIB(hunspell, main, LIBS=-lhunspell $LIBS, 
lyx_use_hunspell=false)
+   if test x$lyx_use_hunspell = xfalse ; then
+AC_CHECK_LIB(hunspell-1.2, main, [LIBS=-lhunspell-1.2 
$LIBS lyx_use_hunspell=true], lyx_use_hunspell=false)
+   fi
fi
AC_MSG_CHECKING([whether to use hunspell])
if $lyx_use_hunspell ; then

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Stephan Witt]

Am 08.03.2011 um 17:36 schrieb Ronen Abravanel:

 My most common situation in which this is a problem is the following
 
 Hebrew text (English translation) more hebrew..
 
 For most language, you wouldn't mind if the  ( ) will be in English or in 
 other language, but Hebrew is written from right to left, which means the 
 Parentheses  are written in reverse. Meaning, if the closing parentheses will 
 be in English, it will apear as:
 
 Hebrew text ((English Hebrew
 
 (Or something like that)
 
 there fore, the following parentheses or comma must be at the same language 
 as the paragraph language, and not as the last-word language.

I believe you.

The attached patch changes this to restore the old behavior when cursor is at 
the word end.
Ok to apply?

Stephan

/Users/Shared/LyX ~/cvs/lyx /Users/Shared/LyX/lyx-build/LyX-2.0.0svn.build
Index: src/Text3.cpp
===
--- src/Text3.cpp   (Revision 37877)
+++ src/Text3.cpp   (Arbeitskopie)
@@ -1890,7 +1890,8 @@
Language const * lang = 
languages.getLanguage(to_utf8(cmd.argument()));
if (!lang)
break;
-   selectWordWhenUnderCursor(cur, WHOLE_WORD);
+   if (!cur.paragraph().isWordSeparator(cur.pos()))
+   selectWordWhenUnderCursor(cur, WHOLE_WORD);
Font font(ignore_font, lang);
toggleAndShow(cur, this, font);
break;

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Works grate for me...


On Tue, Mar 8, 2011 at 10:54 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 08.03.2011 um 17:36 schrieb Ronen Abravanel:

  My most common situation in which this is a problem is the following
 
  Hebrew text (English translation) more hebrew..
 
  For most language, you wouldn't mind if the  ( ) will be in English or
 in other language, but Hebrew is written from right to left, which means the
 Parentheses  are written in reverse. Meaning, if the closing parentheses
 will be in English, it will apear as:
 
  Hebrew text ((English Hebrew
 
  (Or something like that)
 
  there fore, the following parentheses or comma must be at the same
 language as the paragraph language, and not as the last-word language.

 I believe you.

 The attached patch changes this to restore the old behavior when cursor is
 at the word end.
 Ok to apply?

 Stephan

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Pavel Sanda]

Stephan Witt wrote:
 The attached patch changes this to restore the old behavior when cursor is at 
 the word end.
 Ok to apply?

maybe add comment into code for the next generations?
pavel

Re: compile 2.0rc1 on mac

[Jean-Marc Lasgouttes]

Le 08/03/2011 21:30, Stephan Witt a écrit :

The attached patch fixes this. JMarc, is this the right thing?


I think it was correct, but here is nevertheless a more idiomatic 
version (that subsumes José's patch too).


Please and commit if it works also for you.
José, if you have time, please test it too !

JMarc

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Jean-Marc Lasgouttes]

Le 08/03/2011 21:54, Stephan Witt a écrit :

The attached patch changes this to restore the old behavior when cursor is at 
the word end.
Ok to apply?


You can simply use WHOLE_WORD_STRICT instead of WHOLE_WORD to get this 
effect.


JMarc

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Stephan Witt]

Am 08.03.2011 um 23:09 schrieb Jean-Marc Lasgouttes:

 Le 08/03/2011 21:54, Stephan Witt a écrit :
 The attached patch changes this to restore the old behavior when cursor is 
 at the word end.
 Ok to apply?
 
 You can simply use WHOLE_WORD_STRICT instead of WHOLE_WORD to get this effect.

Ah, ok - I didn't thought of that. But it's not exactly the same.
When in front of a word the selection is not done too. That raises the
question if it's better or not to use WHOLE_WORD_STRICT...
When entering hebrew text is the word end at from() or at the to() pos?

Stephan

PS. Ronen, if you want to try it - the patch is attached.

/Users/Shared/LyX ~/cvs/lyx /Users/Shared/LyX/lyx-build/LyX-2.0.0svn.build
Index: src/Text3.cpp
===
--- src/Text3.cpp   (Revision 37885)
+++ src/Text3.cpp   (Arbeitskopie)
@@ -1890,7 +1890,7 @@
Language const * lang = 
languages.getLanguage(to_utf8(cmd.argument()));
if (!lang)
break;
-   selectWordWhenUnderCursor(cur, WHOLE_WORD);
+   selectWordWhenUnderCursor(cur, WHOLE_WORD_STRICT);
Font font(ignore_font, lang);
toggleAndShow(cur, this, font);
break;

Re: compile 2.0rc1 on mac

[Stephan Witt]

Am 08.03.2011 um 23:06 schrieb Jean-Marc Lasgouttes:

 Le 08/03/2011 21:30, Stephan Witt a écrit :
 The attached patch fixes this. JMarc, is this the right thing?
 
 I think it was correct, but here is nevertheless a more idiomatic version 
 (that subsumes José's patch too).

The problem was: the result of header presence detection - aka missing header 
is respected by the first test for the library but not by the second test.

 Please and commit if it works also for you.

I've tested it and it works on my system. I could reproduce the problem - 
somehow hunspell-1.2 was found by the linker - and it is fixed now.

 José, if you have time, please test it too!

Yes, please. I'm almost sure, but to double check is better.

Stephan

Re: [RFC] what is a word (boundary)?

[Stephan Witt]

Am 08.03.2011 um 18:56 schrieb Jürgen Spitzmüller:

 IIRC somebody already brought up this issue some time back.

JMarcs mail from 2011-02-02 with subject Spell checking and breaking words.

Yes, we should do something about this.

 Hunspell can check both complex composites constructed with (hard) hyphens 
 (as 
 in fifty-year-old chap) and, more interestingly, elliptical or fractal 
 composites who use a hard hyphen in order to refer to a shared morpheme in 
 a 
 paired word form (as in two- and threefold or German Betriebsklima und 
 -sicherheit).
 
 At least in German, both types of these beasts are pretty frequent, so we 
 should pass hard hyphens to the speller if hunspell is used, instead of just 
 trimming them off the word (as we do now). The results, at least here, are 
 way 
 better. Currently, for instance, Hunspell would mark -sicherheit as 
 misspelled (since we pass sicherheit) and suggest Sicherheit and, nota 
 bene, -sicherheit.
 
 The attached patch is an attempt in this direction. It passes hard hyphens 
 (and nonbreakdashes) to the speller if this speller is hunspell.
 
 However, since the isWordSeparator function is not only used by the 
 spellchecker, this change affects other things as well. For instance, 
 currently, if you set the cursor left of the word socio-linguistics and hit 
 Insert  Index entry, only socio is copied inside the index inset. With my 
 patch, socio-linguistics as a whole is copied inside. This seems more 
 correct to me, at least wrt English and German, however, it is of course not 
 suitable that the index entry generation differs wrt to the speller which is 
 used.
 
 So my question is, should we
 
 * limit the change to the hunspell checker only, which means that we set up 
 an 
 extra isWordSeparator function (or an option) for the spellchecker?
 
 * treat hard hyphens not as word separators in general, i.e. ditch the 
 canHandleSplitMorphemes() part of the patch?

* make it a property of the language? Add a list of characters to include in 
words?
 We have to add this anyway to drop the escape chars field from spell checker 
settings.
 Give the spell checker backend some control over this list - aspell e. g. can 
remove
 the dash from it, hunspell would keep it.

 To me, the second option makes more sense, but of course this the more 
 intrusive change.

Stephan

Re: Towards rc1 (status update #4, trunk frozen)

[Pavel Sanda]

Stephan Witt wrote:
> But I tried to verify it on Linux - it is there too. No platform dependency!
> You have to disable the "Open documents in tabs" check box in preferences and
> follow the recipe Anders gave exactly.
> 
> Interestingly the existing document is marked as changed after saving the 
> preamble
> of the new document!

Anders, can you file a new bug report? pavel

Setting use_system_colors to true?

[Jean-Marc Lasgouttes]

Hello,

Since we might get more system-like icons, could we set system colors to 
'true' by default? Remember that the background color is not affected, 
for you linen lovers :)


JMarc

Re: Setting use_system_colors to true?

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> Since we might get more system-like icons, could we set system colors to 
> 'true' by default? Remember that the background color is not affected, 
> for you linen lovers :)

Can you remember me which colors are affected?

Jürgen

Re: Setting use_system_colors to true?

[Stephan Witt]

Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes:

> Hello,
> 
> Since we might get more system-like icons, could we set system colors to 
> 'true' by default? Remember that the background color is not affected, for 
> you linen lovers :)

I'd happily distribute it like that for mac os.
This patch I did not commit because I didn't know if it is controversial.

Stephan

Re: Setting use_system_colors to true?

[Jean-Marc Lasgouttes]

Le 08/03/2011 12:05, Stephan Witt a écrit :

Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes:


Hello,

Since we might get more system-like icons, could we set system colors to 'true' 
by default? Remember that the background color is not affected, for you linen 
lovers :)


I'd happily distribute it like that for mac os.
This patch I did not commit because I didn't know if it is controversial.


I'd say that next rc would be a good time to know whether it is 
controversial.


JMarc

Setting GUI to english

[Jean-Marc Lasgouttes]

A stupid question: is it suppoed to be possible in preferences to set 
the GUI to 'no translation' aka english? I cannot do that at least on my 
build.


JMarc

Re: Setting GUI to english

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> A stupid question: is it suppoed to be possible in preferences to set 
> the GUI to 'no translation' aka english? I cannot do that at least on my 
> build.

I have "English" and this seems to work.

Jürgen

Re: Setting use_system_colors to true?

[Stephan Witt]

Am 08.03.2011 um 12:08 schrieb Jean-Marc Lasgouttes:

> Le 08/03/2011 12:05, Stephan Witt a écrit :
>> Am 08.03.2011 um 11:51 schrieb Jean-Marc Lasgouttes:
>> 
>>> Hello,
>>> 
>>> Since we might get more system-like icons, could we set system colors to 
>>> 'true' by default? Remember that the background color is not affected, for 
>>> you linen lovers :)
>> 
>> I'd happily distribute it like that for mac os.
>> This patch I did not commit because I didn't know if it is controversial.
> 
> I'd say that next rc would be a good time to know whether it is controversial.

I did it :)

Stephan

Re: Setting GUI to english

[Vincent van Ravesteijn]

On Tue, Mar 8, 2011 at 12:10 PM, Jean-Marc Lasgouttes
 wrote:
> A stupid question: is it suppoed to be possible in preferences to set the
> GUI to 'no translation' aka english? I cannot do that at least on my build.
>
> JMarc

Aussi ici, pas de problème.

Vincent

Re: Setting use_system_colors to true?

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
> > Since we might get more system-like icons, could we set system colors to 
> > 'true' by default? Remember that the background color is not affected, 
> > for you linen lovers :)
> 
> Can you remember me which colors are affected?

wasn't some flame war around this ? i mean why it didn't happen at that time
if its good idea... :) (can't rememember details)

pavel

Re: Setting use_system_colors to true?

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> > Can you remember me which colors are affected?
> 
> wasn't some flame war around this ? i mean why it didn't happen at that
> time if its good idea... :) (can't rememember details)

The only flames I remember in this context were fueled by the background color 
of the work area. As far as I am concerned, I am probably fine with the 
proposed change (as long as the background area is preserved ;-)

Jürgen

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Richard Heck]

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
"formated ref" for a cross reference, the package prettyref is loaded in
the LaTeX preamble but the reference is traduced by \ref{...} instead of
\prettyref{...}.

I've just tried this with latest trunk, and I do not see this problem. 
Is the label itself in the form "prefix:label"? If not, then, we do just 
output \ref, so the thing will compile.


Richard

Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Hello,

I started using LyX 2.0RC1, and by now, there is only one thing that
bothers  me:
While I'm typing a document in one language, and then, when the cursor is
right after the last word (with no space), I'm typing "language hebrew"  in
the minibuffer (or: using predefined shortcuts that commits the same). The
language do changes, but the last word is also marked and it's language
switched.

For example, If I write "one two^", and when the cursor is where the ^ is,
changes the language, it will convert into "one [owt]",  when the "two" is
reversed, as it "thinks" it's in Hebrew, and the [ - ] part is marked.

This is new behavior - it was not there in some previous versions of 2.0,
but it's there in beta 4.

Thanks,
Ronen.

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Stephan Witt]

Am 08.03.2011 um 16:51 schrieb Ronen Abravanel:

> Hello,
> 
> I started using LyX 2.0RC1, and by now, there is only one thing that bothers  
> me: 
> While I'm typing a document in one language, and then, when the cursor is 
> right after the last word (with no space), I'm typing "language hebrew"  in 
> the minibuffer (or: using predefined shortcuts that commits the same). The 
> language do changes, but the last word is also marked and it's language 
> switched.
> 
> For example, If I write "one two^", and when the cursor is where the ^ is, 
> changes the language, it will convert into "one [owt]",  when the "two" is 
> reversed, as it "thinks" it's in Hebrew, and the [ - ] part is marked. 
> 
> This is new behavior - it was not there in some previous versions of 2.0, but 
> it's there in beta 4.

Yes, this is new - but it's meant as a feature.
If you change the language without any selection LyX changes the language of 
the word under the cursor.

Do you want to change the language for the delimiter following the word? Sorry, 
I don't know anything about hebrew.

Stephan

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

My most common situation in which this is a problem is the following

Hebrew text (English translation) more hebrew..

For most language, you wouldn't mind if the " ( )" will be in English or in
other language, but Hebrew is written from right to left, which means the
Parentheses  are written in reverse. Meaning, if the closing parentheses
will be in English, it will apear as:

Hebrew text ((English Hebrew

(Or something like that)

there fore, the following parentheses or comma must be at the same language
as the paragraph language, and not as the last-word language.

My override now is

hebrew (english ) hebrew, or hebrew english , hebrew [note the space before
the comma or the closing parentheses], and that's both ugly and wrong.

An Hebrew example:
כותב בעברית (english) עברית -- In this way its typed when the closing
parentheses is hebrew
כותב בעברית ((english  עברית. -- here the closing parentheses is english

Thanks,
Ronen.


On Tue, Mar 8, 2011 at 6:18 PM, Stephan Witt  wrote:

> Am 08.03.2011 um 16:51 schrieb Ronen Abravanel:
>
> > Hello,
> >
> > I started using LyX 2.0RC1, and by now, there is only one thing that
> bothers  me:
> > While I'm typing a document in one language, and then, when the cursor is
> right after the last word (with no space), I'm typing "language hebrew"  in
> the minibuffer (or: using predefined shortcuts that commits the same). The
> language do changes, but the last word is also marked and it's language
> switched.
> >
> > For example, If I write "one two^", and when the cursor is where the ^
> is, changes the language, it will convert into "one [owt]",  when the "two"
> is reversed, as it "thinks" it's in Hebrew, and the [ - ] part is marked.
> >
> > This is new behavior - it was not there in some previous versions of 2.0,
> but it's there in beta 4.
>
> Yes, this is new - but it's meant as a feature.
> If you change the language without any selection LyX changes the language
> of the word under the cursor.
>
> Do you want to change the language for the delimiter following the word?
> Sorry, I don't know anything about hebrew.
>
> Stephan

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Charpentier Philippe]

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
"formated ref" for a cross reference, the package prettyref is loaded in
the LaTeX preamble but the reference is traduced by \ref{...} instead of
\prettyref{...}.

I've just tried this with latest trunk, and I do not see this problem. Is the 
label itself in the form "prefix:label"? If not, then, we do just output \ref, 
so the thing will compile.


Richard

No: with the french language and babel loaded, the form "prefix:label" will not 
compile on my system. As I said in a very old discussion, the only way to 
compile on all systems, is to modify prettyref.sty (replacing ":" by "|") and to 
use "prefix|label". This was possible with all previous versions of lyx and that 
is what I did in my french documents. Thus they will not compile correctly with 
lyx-2.0 if nothing is changed.

PhC

compile 2.0rc1 on mac

[William Bray]

I have been testing the beta versions of Lyx 2.0 for some time on my Mac 
running OS 10.6.6.

With the latest svn version I get the following error in the build stage 
regarding Hunspell:


  CXXHunspellChecker.o
HunspellChecker.cpp:31:33: error: hunspell/hunspell.hxx: No such file or 
directory
HunspellChecker.cpp:45: error: ‘Hunspell’ was not declared in this scope
HunspellChecker.cpp:45: error: template argument 2 is invalid
HunspellChecker.cpp:45: error: template argument 4 is invalid
HunspellChecker.cpp:45: error: invalid type in declaration before ‘;’ token
HunspellChecker.cpp:62: error: ISO C++ forbids declaration of ‘Hunspell’ with 
no type
HunspellChecker.cpp:62: error: expected ‘;’ before ‘*’ token
HunspellChecker.cpp:63: error: ISO C++ forbids declaration of ‘Hunspell’ with 
no type
HunspellChecker.cpp:63: error: expected ‘;’ before ‘*’ token
HunspellChecker.cpp:64: error: ISO C++ forbids declaration of ‘Hunspell’ with 
no type
HunspellChecker.cpp:64: error: expected ‘;’ before ‘*’ token
HunspellChecker.cpp: In destructor ‘lyx::HunspellChecker::Private::~Private()’:
HunspellChecker.cpp:97: error: expected initializer before ‘it’
HunspellChecker.cpp:98: error: expected initializer before ‘end’
HunspellChecker.cpp:100: error: ‘it’ was not declared in this scope
HunspellChecker.cpp:100: error: ‘end’ was not declared in this scope
HunspellChecker.cpp: At global scope:
HunspellChecker.cpp:178: error: expected constructor, destructor, or type 
conversion before ‘*’ token
HunspellChecker.cpp:188: error: expected constructor, destructor, or type 
conversion before ‘*’ token
HunspellChecker.cpp:382: error: expected `}' at end of input
make[4]: *** [HunspellChecker.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
**

I have not seen this listed as a bug?

My config line is
./configure --with-version-suffix=-2.0 --with-libiconv-prefix=/usr --with-x=no 
--disable-stdlib-debug --prefix=/Applications/Lyx-2.app 
--with-qt4-dir=/usr/local/qt4 --enable-build-type=release

As a work around, if I add the option --with-hunspell=no to the config line, 
then the prerelease builds fine.

best regards,

bill

PS I did not encounter this problem until very recently, i.e., earlier beta 
versions built fine.

[RFC] what is a word (boundary)?

[Jürgen Spitzmüller]

IIRC somebody already brought up this issue some time back.

Hunspell can check both complex composites constructed with (hard) hyphens (as 
in "fifty-year-old chap") and, more interestingly, "elliptical" or "fractal" 
composites who use a hard hyphen in order to refer to a "shared" morpheme in a 
paired word form (as in "two- and threefold" or German "Betriebsklima und 
-sicherheit").

At least in German, both types of these beasts are pretty frequent, so we 
should pass hard hyphens to the speller if hunspell is used, instead of just 
trimming them off the word (as we do now). The results, at least here, are way 
better. Currently, for instance, Hunspell would mark "-sicherheit" as 
misspelled (since we pass "sicherheit") and suggest "Sicherheit" and, nota 
bene, "-sicherheit".

The attached patch is an attempt in this direction. It passes hard hyphens 
(and nonbreakdashes) to the speller if this speller is hunspell.

However, since the isWordSeparator function is not only used by the 
spellchecker, this change affects other things as well. For instance, 
currently, if you set the cursor left of the word "socio-linguistics" and hit 
Insert > Index entry, only "socio" is copied inside the index inset. With my 
patch, "socio-linguistics" as a whole is copied inside. This seems more 
correct to me, at least wrt English and German, however, it is of course not 
suitable that the index entry generation differs wrt to the speller which is 
used.

So my question is, should we

* limit the change to the hunspell checker only, which means that we set up an 
extra isWordSeparator function (or an option) for the spellchecker?

* treat hard hyphens not as word separators in general, i.e. ditch the 
canHandleSplitMorphemes() part of the patch?

To me, the second option makes more sense, but of course this the more 
intrusive change.

Jürgen
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp	(Revision 37883)
+++ src/Paragraph.cpp	(Arbeitskopie)
@@ -2843,11 +2843,31 @@
 
 bool Paragraph::isWordSeparator(pos_type pos) const
 {
-	if (Inset const * inset = getInset(pos))
+	bool const preserve_dash = theSpellChecker()
+		&& theSpellChecker()->canHandleSplitMorphemes();
+
+	if (Inset const * inset = getInset(pos)) {
+		// if the speller can handle splitted morphemes
+		// we must pass nobreakdashes to the spell checker
+		InsetSpecialChar const * isc =
+			dynamic_cast(inset);
+		if (preserve_dash && isc != 0
+		&& (isc->kind() == InsetSpecialChar::NOBREAKDASH))
+			return false;
 		return !inset->isLetter();
+	}
 	if (pos == size())
 		return true;
 	char_type const c = d->text_[pos];
+	// if the speller can handle splitted morphemes
+	// and we have a hard hyphen (no en- or emdash),
+	// we pass this to the spell checker
+	if (c == '-' && preserve_dash) {
+		int j = pos + 1;
+		if ((j == size() || d->text_[j] != '-')
+		&& (pos == 0 || d->text_[pos - 1] != '-'))
+			return false;
+	}
 	// We want to pass the ' and escape chars to the spellchecker
 	static docstring const quote = from_utf8(lyxrc.spellchecker_esc_chars + '\'');
 	return (!isLetterChar(c) && !isDigitASCII(c) && !contains(quote, c));
Index: src/SpellChecker.h
===
--- src/SpellChecker.h	(Revision 37883)
+++ src/SpellChecker.h	(Arbeitskopie)
@@ -75,6 +75,9 @@
 	/// if speller can spell check whole paragraph return true
 	virtual bool canCheckParagraph() const { return false; }
 
+	/// if speller can handle splitted morphemes (as in "two- and threefold") 
+	virtual bool canHandleSplitMorphemes() const { return false; }
+
 	/// count of misspelled words
 	virtual int numMisspelledWords() const { return 0; }
 
Index: src/HunspellChecker.h
===
--- src/HunspellChecker.h	(Revision 37883)
+++ src/HunspellChecker.h	(Arbeitskopie)
@@ -31,6 +31,7 @@
 	void remove(WordLangTuple const &);
 	void accept(WordLangTuple const &);
 	bool hasDictionary(Language const * lang) const;
+	bool canHandleSplitMorphemes() const { return true; }
 	docstring const error();
 	void advanceChangeNumber();
 	///@}

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Richard Heck]

On 03/08/2011 11:47 AM, Charpentier Philippe wrote:

Le 08.03.2011 14:56, Richard Heck a écrit :

On 03/08/2011 02:34 AM, Philippe Charpentier wrote:

Hi
the following bug is present in the revision 37872: if I choose
"formated ref" for a cross reference, the package prettyref is 
loaded in
the LaTeX preamble but the reference is traduced by \ref{...} 
instead of

\prettyref{...}.

I've just tried this with latest trunk, and I do not see this 
problem. Is the label itself in the form "prefix:label"? If not, 
then, we do just output \ref, so the thing will compile.


Richard

No: with the french language and babel loaded, the form "prefix:label" 
will not compile on my system. As I said in a very old discussion, the 
only way to compile on all systems, is to modify prettyref.sty 
(replacing ":" by "|") and to use "prefix|label". This was possible 
with all previous versions of lyx and that is what I did in my french 
documents. Thus they will not compile correctly with lyx-2.0 if 
nothing is changed.


Ahh, OK, then I guess we should check for the | separator, too. I'll do 
that shortly.


That said, wasn't the introduction of refstyle supposed to be the solution?

Richard


PhC

Re: compile 2.0rc1 on mac

[Stephan Witt]

Am 08.03.2011 um 18:29 schrieb William Bray:

> I have been testing the beta versions of Lyx 2.0 for some time on my Mac 
> running OS 10.6.6.
> 
> With the latest svn version I get the following error in the build stage 
> regarding Hunspell:
> 
> 
>  CXXHunspellChecker.o
> HunspellChecker.cpp:31:33: error: hunspell/hunspell.hxx: No such file or 
> directory
> ...
> make[4]: *** [HunspellChecker.o] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> **
> 
> I have not seen this listed as a bug?

You are the first one without hunspell header but with hunspell library... :)

> My config line is
> ./configure --with-version-suffix=-2.0 --with-libiconv-prefix=/usr 
> --with-x=no --disable-stdlib-debug --prefix=/Applications/Lyx-2.app 
> --with-qt4-dir=/usr/local/qt4 --enable-build-type=release
> 
> As a work around, if I add the option --with-hunspell=no to the config line, 
> then the prerelease builds fine.

The attached patch fixes this. JMarc, is this the right thing?

Stephan

Index: config/spell.m4
===
--- config/spell.m4 (Revision 37877)
+++ config/spell.m4 (Arbeitskopie)
@@ -55,9 +55,11 @@
[lyx_use_hunspell=true; break;],
[lyx_use_hunspell=false])
 
-   AC_CHECK_LIB(hunspell, main, LIBS="-lhunspell $LIBS", 
lyx_use_hunspell=false)
-   if test x$lyx_use_hunspell = xfalse ; then
-   AC_CHECK_LIB(hunspell-1.2, main, [LIBS="-lhunspell-1.2 $LIBS" 
lyx_use_hunspell=true], lyx_use_hunspell=false)
+   if test x$lyx_use_hunspell = xtrue ; then
+   AC_CHECK_LIB(hunspell, main, LIBS="-lhunspell $LIBS", 
lyx_use_hunspell=false)
+   if test x$lyx_use_hunspell = xfalse ; then
+AC_CHECK_LIB(hunspell-1.2, main, [LIBS="-lhunspell-1.2 
$LIBS" lyx_use_hunspell=true], lyx_use_hunspell=false)
+   fi
fi
AC_MSG_CHECKING([whether to use hunspell])
if $lyx_use_hunspell ; then

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Stephan Witt]

Am 08.03.2011 um 17:36 schrieb Ronen Abravanel:

> My most common situation in which this is a problem is the following
> 
> Hebrew text (English translation) more hebrew..
> 
> For most language, you wouldn't mind if the " ( )" will be in English or in 
> other language, but Hebrew is written from right to left, which means the 
> Parentheses  are written in reverse. Meaning, if the closing parentheses will 
> be in English, it will apear as:
> 
> Hebrew text ((English Hebrew
> 
> (Or something like that)
> 
> there fore, the following parentheses or comma must be at the same language 
> as the paragraph language, and not as the last-word language.

I believe you.

The attached patch changes this to restore the old behavior when cursor is at 
the word end.
Ok to apply?

Stephan

/Users/Shared/LyX ~/cvs/lyx /Users/Shared/LyX/lyx-build/LyX-2.0.0svn.build
Index: src/Text3.cpp
===
--- src/Text3.cpp   (Revision 37877)
+++ src/Text3.cpp   (Arbeitskopie)
@@ -1890,7 +1890,8 @@
Language const * lang = 
languages.getLanguage(to_utf8(cmd.argument()));
if (!lang)
break;
-   selectWordWhenUnderCursor(cur, WHOLE_WORD);
+   if (!cur.paragraph().isWordSeparator(cur.pos()))
+   selectWordWhenUnderCursor(cur, WHOLE_WORD);
Font font(ignore_font, lang);
toggleAndShow(cur, this, font);
break;

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Works grate for me...


On Tue, Mar 8, 2011 at 10:54 PM, Stephan Witt  wrote:

> Am 08.03.2011 um 17:36 schrieb Ronen Abravanel:
>
> > My most common situation in which this is a problem is the following
> >
> > Hebrew text (English translation) more hebrew..
> >
> > For most language, you wouldn't mind if the " ( )" will be in English or
> in other language, but Hebrew is written from right to left, which means the
> Parentheses  are written in reverse. Meaning, if the closing parentheses
> will be in English, it will apear as:
> >
> > Hebrew text ((English Hebrew
> >
> > (Or something like that)
> >
> > there fore, the following parentheses or comma must be at the same
> language as the paragraph language, and not as the last-word language.
>
> I believe you.
>
> The attached patch changes this to restore the old behavior when cursor is
> at the word end.
> Ok to apply?
>
> Stephan
>
>

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Pavel Sanda]

Stephan Witt wrote:
> The attached patch changes this to restore the old behavior when cursor is at 
> the word end.
> Ok to apply?

maybe add comment into code for the next generations?
pavel

Re: compile 2.0rc1 on mac

[Jean-Marc Lasgouttes]

Le 08/03/2011 21:30, Stephan Witt a écrit :

The attached patch fixes this. JMarc, is this the right thing?


I think it was correct, but here is nevertheless a more idiomatic 
version (that subsumes José's patch too).


Please and commit if it works also for you.
José, if you have time, please test it too !

JMarc

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Jean-Marc Lasgouttes]

Le 08/03/2011 21:54, Stephan Witt a écrit :

The attached patch changes this to restore the old behavior when cursor is at 
the word end.
Ok to apply?


You can simply use WHOLE_WORD_STRICT instead of WHOLE_WORD to get this 
effect.


JMarc

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Stephan Witt]

Am 08.03.2011 um 23:09 schrieb Jean-Marc Lasgouttes:

> Le 08/03/2011 21:54, Stephan Witt a écrit :
>> The attached patch changes this to restore the old behavior when cursor is 
>> at the word end.
>> Ok to apply?
> 
> You can simply use WHOLE_WORD_STRICT instead of WHOLE_WORD to get this effect.

Ah, ok - I didn't thought of that. But it's not exactly the same.
When in front of a word the selection is not done too. That raises the
question if it's better or not to use WHOLE_WORD_STRICT...
When entering hebrew text is the word end at from() or at the to() pos?

Stephan

PS. Ronen, if you want to try it - the patch is attached.

/Users/Shared/LyX ~/cvs/lyx /Users/Shared/LyX/lyx-build/LyX-2.0.0svn.build
Index: src/Text3.cpp
===
--- src/Text3.cpp   (Revision 37885)
+++ src/Text3.cpp   (Arbeitskopie)
@@ -1890,7 +1890,7 @@
Language const * lang = 
languages.getLanguage(to_utf8(cmd.argument()));
if (!lang)
break;
-   selectWordWhenUnderCursor(cur, WHOLE_WORD);
+   selectWordWhenUnderCursor(cur, WHOLE_WORD_STRICT);
Font font(ignore_font, lang);
toggleAndShow(cur, this, font);
break;

Re: compile 2.0rc1 on mac

[Stephan Witt]

Am 08.03.2011 um 23:06 schrieb Jean-Marc Lasgouttes:

> Le 08/03/2011 21:30, Stephan Witt a écrit :
>> The attached patch fixes this. JMarc, is this the right thing?
> 
> I think it was correct, but here is nevertheless a more idiomatic version 
> (that subsumes José's patch too).

The problem was: the result of header presence detection - aka missing header 
is respected by the first test for the library but not by the second test.

> Please and commit if it works also for you.

I've tested it and it works on my system. I could reproduce the problem - 
somehow hunspell-1.2 was found by the linker - and it is fixed now.

> José, if you have time, please test it too!

Yes, please. I'm almost sure, but to double check is better.

Stephan

Re: [RFC] what is a word (boundary)?

[Stephan Witt]

Am 08.03.2011 um 18:56 schrieb Jürgen Spitzmüller:

> IIRC somebody already brought up this issue some time back.

JMarcs mail from 2011-02-02 with subject "Spell checking and breaking words".

Yes, we should do something about this.

> Hunspell can check both complex composites constructed with (hard) hyphens 
> (as 
> in "fifty-year-old chap") and, more interestingly, "elliptical" or "fractal" 
> composites who use a hard hyphen in order to refer to a "shared" morpheme in 
> a 
> paired word form (as in "two- and threefold" or German "Betriebsklima und 
> -sicherheit").
> 
> At least in German, both types of these beasts are pretty frequent, so we 
> should pass hard hyphens to the speller if hunspell is used, instead of just 
> trimming them off the word (as we do now). The results, at least here, are 
> way 
> better. Currently, for instance, Hunspell would mark "-sicherheit" as 
> misspelled (since we pass "sicherheit") and suggest "Sicherheit" and, nota 
> bene, "-sicherheit".
> 
> The attached patch is an attempt in this direction. It passes hard hyphens 
> (and nonbreakdashes) to the speller if this speller is hunspell.
> 
> However, since the isWordSeparator function is not only used by the 
> spellchecker, this change affects other things as well. For instance, 
> currently, if you set the cursor left of the word "socio-linguistics" and hit 
> Insert > Index entry, only "socio" is copied inside the index inset. With my 
> patch, "socio-linguistics" as a whole is copied inside. This seems more 
> correct to me, at least wrt English and German, however, it is of course not 
> suitable that the index entry generation differs wrt to the speller which is 
> used.
> 
> So my question is, should we
> 
> * limit the change to the hunspell checker only, which means that we set up 
> an 
> extra isWordSeparator function (or an option) for the spellchecker?
> 
> * treat hard hyphens not as word separators in general, i.e. ditch the 
> canHandleSplitMorphemes() part of the patch?

* make it a property of the language? Add a list of characters to include in 
words?
 We have to add this anyway to drop the escape chars field from spell checker 
settings.
 Give the spell checker backend some control over this list - aspell e. g. can 
remove
 the dash from it, hunspell would keep it.

> To me, the second option makes more sense, but of course this the more 
> intrusive change.

Stephan