[no subject]

[Eckhard Höffner]

Maybe it is polyglossia. Look at the Tex file or do not use the preamble,
but the beginning of the document.
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: Use better subject lines, please? (Was: question)

[Steve Litt]

On Thu, 2022-09-22 at 09:20 -0400, Kevin Cole wrote:
> Hi,
> 
> Since most lists that I'm on seem to consist of messages that begin as a
> question, followed by replies attempting to answer the question or gather
> more information, a subject line consisting of nothing but the word
> "question" is pretty useless.
> 
> So, a gentle nudge to some: Try to come up with a concise subject line that
> summarizes the actual question, please. No need to include the word
> "question" (in most cases, I suspect, though there's always an exception to
> a rule somewhere).
> 
> Thanks!

Absolutely true!

For more on making email communication easier and more straightforward, 
everybody
who speaks English should read the following document:

http://www.catb.org/~esr/faqs/smart-questions.html

Also, the LyX list was the list I remember that introduced itself to the MWE, 
the
minimal example necessary to produce the symptom. Using an MWE makes the cause
obvious to those in the know, and if your life is like mine, by the time you've
created the MWE, the root cause is obvious to you so you needn't post the 
question
at all.

I can add some things:

* Don't top-post in a group discussion: It breaks relationships between 
questions
and answers.

* Instead, interleave post, where you answer each question directly below the
question. This way all know which question the answer is answering.

* If you simply must top post in a group discussion, instead of using pronouns,
reproduce exactly what you're talking about. Those who top-post "I agree, and
furthermore the foo should come earlier" leave the ambiguities: 1) With whom 
does he
agree and about what, and 2) The foo should come earlier than what?

* When you email a lot of questions, anticipate top posters, and number your
questions so the top poster can at least use those numbers to link the answer 
to the
question.

* Nothing I've said here implies you shouldn't follow the usual and customary
business email standard of top posting in order to preserve every assertion and
cover everybody's ass.

* Whether you top post or not, remove all context quotes not relevant to what 
you're
saying. This makes your meaning much clearer, and removes the task of reading
through hundreds or thousands of moot words. The #1 argument FOR top-posting in
mailinng lists is people don't want to go through hundreds or thousands of words
just to get to what you say. This is a valid argument, but if you remove 
unneeded
context quotes this argument ceases to be a problem.

* For free software centric mailing lists, for gosh sakes use plain text, not 
html.

* Make sure your email client does quoting in a way that different peoples'
contributions are identified by indents or color or whatever their email client
does. There's nothing like reading an email with same-level quoting, in which it
looks like the poster is arguing with himself and you can't tell who said what.

By the way, most of what I mention above applies to any group discussion: email,
forums, slack, stackoverflow, or others.

SteveT

-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Use better subject lines, please? (Was: question)

[Kevin Cole]

Hi,

Since most lists that I'm on seem to consist of messages that begin as a
question, followed by replies attempting to answer the question or gather
more information, a subject line consisting of nothing but the word
"question" is pretty useless.

So, a gentle nudge to some: Try to come up with a concise subject line that
summarizes the actual question, please. No need to include the word
"question" (in most cases, I suspect, though there's always an exception to
a rule somewhere).

Thanks!
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

[no subject]

[Nathan Blodgett]

Alright then, I will post to lyx-devel and with more info.
Basically Pacstall is package manager for Debian based systems and for more
info see pacstall.dev.
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

[no subject]

[Nathan Blodgett via lyx-users]

Hello, there is an ongoing pull request for your package at:
https://github.com/pacstall/pacstall-programs/pull/971. Just a couple of
questions, would you like to maintain it, and also it would be great to
have this installation method in wiki (users can install via: pacstall -I
lyx-deb once the PR is merged).
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Subject index with Makeindex

[Andreas Plihal]

The enclosed MWE shows a simple document with a series of key words with which I would like to fill a subject index. However, if I choose Makeindex as the index processor, the subject index is NOT displayed in the resulting PDF document. PLEASE, can someone tell me why? And how do I manage to create a subject index using Makeindex. Incidentally, no ind-file is created during compilation.

 

Greetings Andreas

MWE3.lyx
Description: application/lyx


MWE3.pdf
Description: Adobe PDF document
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Requirements for a subject index

[Andreas Plihal]

In the recent past I have made similar inquiries, but they received no response. After I was very nicely pointed out by your colleagues what I could improve on my questions to you - thank you very much! - I would like to make my request again. My request today completely replaces my older requests!

 

 

I have now made two MWEs by radically deleting the text in the LYX file and emptying the preamble as much as possible.

Both MWEs contain the same text and only differ in terms of the index processor.

There are sections A, B and a footnote (F) in the document. The three keywords should have the lowercase letter a, b or f after the page number in the subject index, depending on which of the three sections (A, B, F) they are placed in.

 


	MWE1 uses the index processor texindy. The associated PDF file shows that a German DUDEN order according to DIN5007-1 can be created in the subject register, just as I would like it to be. The three keywords appear, but without a page number. This is not surprising, since the macros in the preamble were also tailored for the index processor Makeindex (but not by me - I am not familiar with it).



	MWE2 uses the Makeindex index processor in the following way:

	
		Document > Settings > Index: Standard
		Preamble:
		\ usepackage [makeidx] 
		\ makeindex [-g] 
		
		The subject index is completely missing in the associated PDF file.
	
	


 

Now to my concern:


	The subject index should be classified according to DIN5007-1 and 
	some specially marked keywords should have a lower case letter after the page number.


As long as that is achieved, it doesn't matter which index processor I use.

 

 

Some data about my work environment:


	OS
	Edition: Windows 10 Home
	Version: 21H1
	Installed on: 11.‎03.‎2021
	OS build: 19043.1237
	Services: Windows Feature Experience Pack 120.2212.3530.0
	 
	LYX
	LyX 2.3.6.1 (2020-12-29)
	CMake Build
	
	System directory: C:\Program Files\LyX 2.3\Resources\
	User directory: ~\AppData\Roaming\LyX2.3\
	Qt-Version (Laufzeit): 5.15.2
	Qt-Version (bei Erstellung): 5.15.2


 

Greetings

Andreas

MWE1.lyx
Description: application/lyx


MWE1.pdf
Description: Adobe PDF document


MWE2.lyx
Description: application/lyx


MWE2.pdf
Description: Adobe PDF document
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: Introductory text to subject index

[Jürgen Spitzmüller]

Am Sonntag, dem 02.05.2021 um 18:46 +0200 schrieb Andreas Plihal:
> for a KOMA book I have created both a list of figures and a subject
> index. However, I would like to add an introductory text to the
> subject index, immediately after the heading.
> Where and how should I place this introductory text in the LYX file?

In ERT

\setindexpreamble{Introductory text...}

somewhere in the document (before the index).

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: Introductory text to subject index

[Ricardo Berlasso]

El dom, 2 may 2021 a las 18:46, Andreas Plihal () escribió:

> Hi,
>
> for a KOMA book I have created both a list of figures and a subject index. 
> However,
> I would like to add an introductory text to the subject index, immediately
> after the heading.
> Where and how should I place this introductory text in the LYX file?
>

If it's just a short paragraph, just bellow the point where you inserted
the index, introduce a TeX box (Ctrl-L) and type inside it something like

\addtocontents{toc}{The content you want to add\par}

The text will be added between the subject and the index content.

Regards,
Ricardo


>
> Best regards
> Andreas
> --
> lyx-users mailing list
> lyx-users@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-users
>
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Introductory text to subject index

[Andreas Plihal]

Hi, 

 

for a KOMA book I have created both a list of figures and a subject index. However, I would like to add an introductory text to the subject index, immediately after the heading. 

Where and how should I place this introductory text in the LYX file?

 

Best regards

Andreas
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

[no subject]

[Hussain KH]

Pls subscibr me lyx development.
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

[no subject]

[Dolan Krishna Bayen]

Dear sir, how to recover my damaged . lyx filekindly suggest me some
ideayour faithfully
Dolan
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: rename name index and subject index

[Guenter Milde]

On 2017-04-01, Wolfgang Engelmann wrote:

> [-- Type: text/plain, Encoding: 7bit --]

> I would like to rename my 'name index' and 'subject index' to the German 
> 'Namensverzeichnis' and 'Stichwortverzeichnis' with


> \renewcommand{\indexname}{Sachverzeichnis}

> in the preamble, but this does not give the desired output in the pdf 
> file. What would be the appropriate way of doing it?

Probably, this is overwritten by babel. You may try with ERT in the
document body or \AtBeginDocument. 

rename name index and subject index

[Wolfgang Engelmann]

I would like to rename my 'name index' and 'subject index' to the German 
'Namensverzeichnis' and 'Stichwortverzeichnis' with



\renewcommand{\indexname}{Sachverzeichnis}


in the preamble, but this does not give the desired output in the pdf 
file. What would be the appropriate way of doing it?


Wolfgang

subject index gives error, name index is alright

[Wolfgang Engelmann]

Hello List,

after having spent several hours to find out an error I would like to ask 
for your help.

I am translating a book (of about 200 pages) which I have written in German 
into English.
The pdf output of the German one is ok.
The output of the English version gives me an error (see ###1###)
and view complete log gives me (see ###2###)

If I comment out the subject index at the end of my document it works 
alright.
The name index works alright.

Has anybody run into such an error and could give me a hint what is going 
wrong?

I am using koma script book style and A5 size, if this is of concern.

Is there a way (eg in the tex file) to take off parts of the indexed entries, 
in order to localize the entry causing the error?

Wolfgang

###1###)
 \subitem field}
\selectlanguage{american}% , \hyperpage{45}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.

 ###2###)
]) (./AAAFlowerClock20130626A-idx.ind [201] [202

] [203
]
! Extra }, or forgotten \endgroup.

Re: subject index gives error, name index is alright

[Wolfgang Engelmann]

Am Monday, 24. June 2013, 11:23:43 schrieb Wolfgang Engelmann:

I have solved it by removing the .idx .ind and .aux file of a former latex 
run. 

The hint came from this:

http://tex.stackexchange.com/questions/82669/will-cruft-from-a-previous-
compile-ever-change-the-final-look-of-my-document

Wolfgang

 Hello List,
 
 after having spent several hours to find out an error I would like to
 ask for your help.
 
 I am translating a book (of about 200 pages) which I have written in
 German into English.
 The pdf output of the German one is ok.
 The output of the English version gives me an error (see ###1###)
 and view complete log gives me (see ###2###)
 
 If I comment out the subject index at the end of my document it works
 alright.
 The name index works alright.
 
 Has anybody run into such an error and could give me a hint what is
 going wrong?
 
 I am using koma script book style and A5 size, if this is of concern.
 
 Is there a way (eg in the tex file) to take off parts of the indexed
 entries, in order to localize the entry causing the error?
 
 Wolfgang
 
 ###1###)
  \subitem field}
 \selectlanguage{american}% , \hyperpage{45}
 I've deleted a group-closing symbol because it seems to be
 spurious, as in `$x}$'. But perhaps the } is legitimate and
 you forgot something else, as in `\hbox{$x}'. In such cases
 the way to recover is to insert both the forgotten and the
 deleted material, e.g., by typing `I$}'.
 
  ###2###)
 ]) (./AAAFlowerClock20130626A-idx.ind [201] [202
 
 ] [203
 ]
 ! Extra }, or forgotten \endgroup.


-- 
-
Wolfgang Engelmann
Schlossgartenstrasse 22
D-72070 Tübingen
Tel 07071 68325

subject index gives error, name index is alright

[Wolfgang Engelmann]

Hello List,

after having spent several hours to find out an error I would like to ask 
for your help.

I am translating a book (of about 200 pages) which I have written in German 
into English.
The pdf output of the German one is ok.
The output of the English version gives me an error (see ###1###)
and view complete log gives me (see ###2###)

If I comment out the subject index at the end of my document it works 
alright.
The name index works alright.

Has anybody run into such an error and could give me a hint what is going 
wrong?

I am using koma script book style and A5 size, if this is of concern.

Is there a way (eg in the tex file) to take off parts of the indexed entries, 
in order to localize the entry causing the error?

Wolfgang

###1###)
 \subitem field}
\selectlanguage{american}% , \hyperpage{45}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.

 ###2###)
]) (./AAAFlowerClock20130626A-idx.ind [201] [202

] [203
]
! Extra }, or forgotten \endgroup.

Re: subject index gives error, name index is alright

[Wolfgang Engelmann]

Am Monday, 24. June 2013, 11:23:43 schrieb Wolfgang Engelmann:

I have solved it by removing the .idx .ind and .aux file of a former latex 
run. 

The hint came from this:

http://tex.stackexchange.com/questions/82669/will-cruft-from-a-previous-
compile-ever-change-the-final-look-of-my-document

Wolfgang

 Hello List,
 
 after having spent several hours to find out an error I would like to
 ask for your help.
 
 I am translating a book (of about 200 pages) which I have written in
 German into English.
 The pdf output of the German one is ok.
 The output of the English version gives me an error (see ###1###)
 and view complete log gives me (see ###2###)
 
 If I comment out the subject index at the end of my document it works
 alright.
 The name index works alright.
 
 Has anybody run into such an error and could give me a hint what is
 going wrong?
 
 I am using koma script book style and A5 size, if this is of concern.
 
 Is there a way (eg in the tex file) to take off parts of the indexed
 entries, in order to localize the entry causing the error?
 
 Wolfgang
 
 ###1###)
  \subitem field}
 \selectlanguage{american}% , \hyperpage{45}
 I've deleted a group-closing symbol because it seems to be
 spurious, as in `$x}$'. But perhaps the } is legitimate and
 you forgot something else, as in `\hbox{$x}'. In such cases
 the way to recover is to insert both the forgotten and the
 deleted material, e.g., by typing `I$}'.
 
  ###2###)
 ]) (./AAAFlowerClock20130626A-idx.ind [201] [202
 
 ] [203
 ]
 ! Extra }, or forgotten \endgroup.


-- 
-
Wolfgang Engelmann
Schlossgartenstrasse 22
D-72070 Tübingen
Tel 07071 68325

subject index gives error, name index is alright

[Wolfgang Engelmann]

Hello List,

after having spent several hours to find out an error I would like to ask 
for your help.

I am translating a book (of about 200 pages) which I have written in German 
into English.
The pdf output of the German one is ok.
The output of the English version gives me an error (see ###1###)
and view complete log gives me (see ###2###)

If I comment out the subject index at the end of my document it works 
alright.
The name index works alright.

Has anybody run into such an error and could give me a hint what is going 
wrong?

I am using koma script book style and A5 size, if this is of concern.

Is there a way (eg in the tex file) to take off parts of the indexed entries, 
in order to localize the entry causing the error?

Wolfgang

###1###)
 \subitem field}
\selectlanguage{american}% , \hyperpage{45}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.

 ###2###)
]) (./AAAFlowerClock20130626A-idx.ind [201] [202

] [203
]
! Extra }, or forgotten \endgroup.

Re: subject index gives error, name index is alright

[Wolfgang Engelmann]

Am Monday, 24. June 2013, 11:23:43 schrieb Wolfgang Engelmann:

I have solved it by removing the .idx .ind and .aux file of a former latex 
run. 

The hint came from this:

http://tex.stackexchange.com/questions/82669/will-cruft-from-a-previous-
compile-ever-change-the-final-look-of-my-document

Wolfgang

> Hello List,
> 
> after having spent several hours to find out an error I would like to
> ask for your help.
> 
> I am translating a book (of about 200 pages) which I have written in
> German into English.
> The pdf output of the German one is ok.
> The output of the English version gives me an error (see ###1###)
> and view complete log gives me (see ###2###)
> 
> If I comment out the subject index at the end of my document it works
> alright.
> The name index works alright.
> 
> Has anybody run into such an error and could give me a hint what is
> going wrong?
> 
> I am using koma script book style and A5 size, if this is of concern.
> 
> Is there a way (eg in the tex file) to take off parts of the indexed
> entries, in order to localize the entry causing the error?
> 
> Wolfgang
> 
> ###1###)
>  \subitem field}
> \selectlanguage{american}% , \hyperpage{45}
> I've deleted a group-closing symbol because it seems to be
> spurious, as in `$x}$'. But perhaps the } is legitimate and
> you forgot something else, as in `\hbox{$x}'. In such cases
> the way to recover is to insert both the forgotten and the
> deleted material, e.g., by typing `I$}'.
> 
>  ###2###)
> ]) (./AAAFlowerClock20130626A-idx.ind [201] [202
> 
> ] [203
> ]
> ! Extra }, or forgotten \endgroup.


-- 
-
Wolfgang Engelmann
Schlossgartenstrasse 22
D-72070 Tübingen
Tel 07071 68325

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

 Ok, AFAIU this refers to the XeLaTeX engine and not to LyX.
 Of course, if someone wants to develop a solid algorithm for language
 guessing and can convince the LyX developer community of it and has the
 resources to implement and test it - it may happen. Another option
 would be to have a spell checker backend including this feature.

OK. Sadly I am not that person, but I am very glad that this
discussion has occurred and at least the potential for improvements
identified.

 But alas, the user is still utterly laboured with tedious repetition
 of language specification (also text style selection, with the hack i
 use), and will remain so until LyX UI changes.

 Do you have an example for such a document?

I will email you immediately with a copy.

 But it can be tricky to make it right. It heavily depends on the spell 
 checker -
 aspell e. g. accepts completely different alternative language settings as
 hunspell or apples spell checker do. And it depends on the 
 runtime-environment -
 what dictionaries are available for the user on the current machine.
 And we have the feature to switch between the spell checker back ends at 
 runtime.

 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction 
 layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

 I'll cite my own investigation about similarity between spell checking APIs.
 The focus was the management of personal word lists.

 We have support for different spell checker backends.
 All of them are able to check words, of course.
 But the capabilities with personal word lists differs horrible.
 The following table presents the results of my investigation.

 Feature     | aspell | native (mac) | enchant | hunspell
 
 check       | +      | +            | +       | +
 suggest     | +      | +            | +       | +
 accept      | +      | +            | +       | +
 insert      | +      | +            | o (2)   | o (3)
 ispersonal? | o (1)  | +            | -       | -
 remove      | -      | +            | + (4)   | -

 Legend:
 + feature is supported
 - feature is not supported
 o there are limitations:
 1) aspell has the interface to enumerate the personal word list.
   So it's possible to implement, I have a patch for LyX at hand.
 2) The versions below 1.6.0 are truncating the personal word list
   on open - effectively no personal word list available after restart.
 3) There is no persistent state for personal word lists.
 (4) Enchant manages it's own personal word lists.

Thanks for this very interesting review.

Points (2) and (3), plus the lack of a remove feature for some
engines, seem to be the sorts of things that comments upstream
could fix.  In addition, (3) could be worked around by LyX pretty
easily (though such code is always best avoided), and both (2)
and missing remove functionality seem not critical (just annoying).

Could you please clarify what the purpose of 'ispersonal?' is at the
LyX UI level?  I'm guessing it's a feature to test whether a word
came from a standard dictionary or from a personal dictionary,
but I am unsure of whether this distinction is useful at all for LyX?

 There is some rumor on the net already to consolidate the spelling
 for the whole desktop.
 https://wiki.ubuntu.com/ConsolidateSpellingLibs
 I don't know how long it would last to get some result.

This seems to be a move for pushing Ubuntu towards hunspell
and enchant.  hunspell is claimed to be the most modern
implementation of a multilingual spell checking backend.

However, its language support is not complete, so users of
some languages still require support for other, specialised
engines (Voikko for Finnish, Zemberek for Turkish, Uspell for
Yiddish, Hebrew, and Eastern European languages, Hspell
for Hebrew) which enchant can provide.

Contrary to your prior email, it seems that enchant does
work on OSX, since support for AppleSpell (Mac OSX) is
claimed @ http://www.abisource.com/projects/enchant/

(Note: Ubuntu cites problems preventing the dropping of
older implementations due to the lack of upstream hunspell
or enchant support in some major software packages, such
as PHP. GTKSpell and KDE use enchant already).

 3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really 
 solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to 
 link
   the manual language markup made in conjunction with a font-linked 
 solution
   to the manual language 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

 Ok, AFAIU this refers to the XeLaTeX engine and not to LyX.
 Of course, if someone wants to develop a solid algorithm for language
 guessing and can convince the LyX developer community of it and has the
 resources to implement and test it - it may happen. Another option
 would be to have a spell checker backend including this feature.

OK. Sadly I am not that person, but I am very glad that this
discussion has occurred and at least the potential for improvements
identified.

 But alas, the user is still utterly laboured with tedious repetition
 of language specification (also text style selection, with the hack i
 use), and will remain so until LyX UI changes.

 Do you have an example for such a document?

I will email you immediately with a copy.

 But it can be tricky to make it right. It heavily depends on the spell 
 checker -
 aspell e. g. accepts completely different alternative language settings as
 hunspell or apples spell checker do. And it depends on the 
 runtime-environment -
 what dictionaries are available for the user on the current machine.
 And we have the feature to switch between the spell checker back ends at 
 runtime.

 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction 
 layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

 I'll cite my own investigation about similarity between spell checking APIs.
 The focus was the management of personal word lists.

 We have support for different spell checker backends.
 All of them are able to check words, of course.
 But the capabilities with personal word lists differs horrible.
 The following table presents the results of my investigation.

 Feature     | aspell | native (mac) | enchant | hunspell
 
 check       | +      | +            | +       | +
 suggest     | +      | +            | +       | +
 accept      | +      | +            | +       | +
 insert      | +      | +            | o (2)   | o (3)
 ispersonal? | o (1)  | +            | -       | -
 remove      | -      | +            | + (4)   | -

 Legend:
 + feature is supported
 - feature is not supported
 o there are limitations:
 1) aspell has the interface to enumerate the personal word list.
   So it's possible to implement, I have a patch for LyX at hand.
 2) The versions below 1.6.0 are truncating the personal word list
   on open - effectively no personal word list available after restart.
 3) There is no persistent state for personal word lists.
 (4) Enchant manages it's own personal word lists.

Thanks for this very interesting review.

Points (2) and (3), plus the lack of a remove feature for some
engines, seem to be the sorts of things that comments upstream
could fix.  In addition, (3) could be worked around by LyX pretty
easily (though such code is always best avoided), and both (2)
and missing remove functionality seem not critical (just annoying).

Could you please clarify what the purpose of 'ispersonal?' is at the
LyX UI level?  I'm guessing it's a feature to test whether a word
came from a standard dictionary or from a personal dictionary,
but I am unsure of whether this distinction is useful at all for LyX?

 There is some rumor on the net already to consolidate the spelling
 for the whole desktop.
 https://wiki.ubuntu.com/ConsolidateSpellingLibs
 I don't know how long it would last to get some result.

This seems to be a move for pushing Ubuntu towards hunspell
and enchant.  hunspell is claimed to be the most modern
implementation of a multilingual spell checking backend.

However, its language support is not complete, so users of
some languages still require support for other, specialised
engines (Voikko for Finnish, Zemberek for Turkish, Uspell for
Yiddish, Hebrew, and Eastern European languages, Hspell
for Hebrew) which enchant can provide.

Contrary to your prior email, it seems that enchant does
work on OSX, since support for AppleSpell (Mac OSX) is
claimed @ http://www.abisource.com/projects/enchant/

(Note: Ubuntu cites problems preventing the dropping of
older implementations due to the lack of upstream hunspell
or enchant support in some major software packages, such
as PHP. GTKSpell and KDE use enchant already).

 3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really 
 solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to 
 link
   the manual language markup made in conjunction with a font-linked 
 solution
   to the manual language 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

>> http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html
>
> Ok, AFAIU this refers to the XeLaTeX engine and not to LyX.
> Of course, if someone wants to develop a solid algorithm for language
> guessing and can convince the LyX developer community of it and has the
> resources to implement and test it - it may happen. Another option
> would be to have a spell checker backend including this feature.

OK. Sadly I am not that person, but I am very glad that this
discussion has occurred and at least the potential for improvements
identified.

>> But alas, the user is still utterly laboured with tedious repetition
>> of language specification (also text style selection, with the hack i
>> use), and will remain so until LyX UI changes.
>
> Do you have an example for such a document?

I will email you immediately with a copy.

>>> But it can be tricky to make it right. It heavily depends on the spell 
>>> checker -
>>> aspell e. g. accepts completely different "alternative" language settings as
>>> hunspell or apples spell checker do. And it depends on the 
>>> runtime-environment -
>>> what dictionaries are available for the user on the current machine.
>>> And we have the feature to switch between the spell checker back ends at 
>>> runtime.
>>
>> This sounds ugly.  Is there any similarity between spell checking APIs?  Is
>> there a cross platform, spell checking library unification / abstraction 
>> layer
>> available? Would it be worth developing one? How difficult is it to detect
>> known dictionaries and spell checkers on a cross-platform basis?
>
> I'll cite my own investigation about similarity between spell checking APIs.
> The focus was the management of personal word lists.
>
>> We have support for different spell checker backends.
>> All of them are able to check words, of course.
>> But the capabilities with personal word lists differs horrible.
>> The following table presents the results of my investigation.
>>
>> Feature     | aspell | native (mac) | enchant | hunspell
>> 
>> check       | +      | +            | +       | +
>> suggest     | +      | +            | +       | +
>> accept      | +      | +            | +       | +
>> insert      | +      | +            | o (2)   | o (3)
>> ispersonal? | o (1)  | +            | -       | -
>> remove      | -      | +            | + (4)   | -
>>
>> Legend:
>> + feature is supported
>> - feature is not supported
>> o there are limitations:
>> 1) aspell has the interface to enumerate the personal word list.
>>   So it's possible to implement, I have a patch for LyX at hand.
>> 2) The versions below 1.6.0 are truncating the personal word list
>>   on open - effectively no personal word list available after restart.
>> 3) There is no persistent state for personal word lists.
> (4) Enchant manages it's own personal word lists.

Thanks for this very interesting review.

Points (2) and (3), plus the lack of a remove feature for some
engines, seem to be the sorts of things that comments upstream
could fix.  In addition, (3) could be worked around by LyX pretty
easily (though such code is always best avoided), and both (2)
and missing remove functionality seem not critical (just annoying).

Could you please clarify what the purpose of 'ispersonal?' is at the
LyX UI level?  I'm guessing it's a feature to test whether a word
came from a "standard" dictionary or from a "personal" dictionary,
but I am unsure of whether this distinction is useful at all for LyX?

>> There is some rumor on the net already to consolidate the spelling
>> for the whole desktop.
>> https://wiki.ubuntu.com/ConsolidateSpellingLibs
>> I don't know how long it would last to get some result.

This seems to be a move for pushing Ubuntu towards hunspell
and enchant.  hunspell is claimed to be the most modern
implementation of a multilingual spell checking backend.

However, its language support is not complete, so users of
some languages still require support for other, specialised
engines (Voikko for Finnish, Zemberek for Turkish, Uspell for
Yiddish, Hebrew, and Eastern European languages, Hspell
for Hebrew) which enchant can provide.

Contrary to your prior email, it seems that enchant does
work on OSX, since support for AppleSpell (Mac OSX) is
claimed @ http://www.abisource.com/projects/enchant/

(Note: Ubuntu cites problems preventing the dropping of
older implementations due to the lack of upstream hunspell
or enchant support in some major software packages, such
as PHP. GTKSpell and KDE use enchant already).

 3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   "solutions" in use.  In terms of LyX, none of these are really 
 "solutions"
   as even with LyX 2.0beta1 it appears 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 26.01.2011 um 15:00 schrieb Walter:

I'll try to answer this - although I surely don't have so much time you had to 
write this.

 Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
 a spell check for the first time.
 
 The interface is good and no doubt an improvement on previous eras, however
 the following struck me as possible to improve.
 
 Those items marked with [*] I consider a bug in LyX. Those items marked
 with [X] I consider a bug elsewhere.
 
 
 1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

The following refers to the field Alternative language I'd guess.

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:
 
It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or underscore.
 
   I tried this (en_AU), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

Ok, with this use case - mixed language documents - you are requested to
mark the text appropriately. Here LyX does no guessing and there are no
plans to change that.

   The method to do this (eg: separate multiple values with a space or comma),
   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.
 
   Whilst the ideal route would be to add (relatively) complex integration
   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight or
   perhaps ever.

Alternative language is a - as I would rate it - cul-de-sac and shouldn't be 
there.
If any LyX should have a mapping of available languages to alternate languages.

As it is now the single value here is used for all text having the documents 
language
as a replacement to pass on to the spell checker.

So if you want to use English (UK) you don't need to change it here -
simply set your document language to English (UK).

The alternate language is used for all (!) languages regardless of making 
any sense. If you edit a french LyX-document and the alternate language
is set to en_GB e. g. you'll have no fun.

This is what I would rate as a bug. 

So this field is of very limited use and should be replaced by something else.
Of course something else may have an more user friendly interface too...

But it can be tricky to make it right. It heavily depends on the spell checker -
aspell e. g. accepts completely different alternative language settings as
hunspell or apples spell checker do. And it depends on the runtime-environment -
what dictionaries are available for the user on the current machine.
And we have the feature to switch between the spell checker back ends at 
runtime.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

Until the field gets replaced or removed a tooltip may help.

 2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

You propose to auto extend the selection to word boundaries when setting
the language at a given position and no selection exists. That sounds
sensible...

 3. 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

 I'll try to answer this - although I surely don't have so much time you had 
 to write this.

Relativity...

 Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
 a spell check for the first time.

 The interface is good and no doubt an improvement on previous eras, however
 the following struck me as possible to improve.

 Those items marked with [*] I consider a bug in LyX. Those items marked
 with [X] I consider a bug elsewhere.


 1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

 The following refers to the field Alternative language I'd guess.

Correct!

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:

    It follows the same format of the  LANG  environmental variable on
     most systems. It consists of the two letter ISO 639 language code and
     an optional two letter ISO 3166 country code after a dash or underscore.

   I tried this (en_AU), and it did work.  However, there are two problems:
    - Even the first step would be a challenge for some users
    - I would like to add multiple values to the field, since otherwise even
      at this early stage of my document still hundreds of words and place
      names in French, German, Greek (+romanised Greek), Chinese (+romanised
      Chinese), etc. trip up the spell checker. (Use of these languages
      is frequent and scattered right throughout the document.)

 Ok, with this use case - mixed language documents - you are requested to
 mark the text appropriately. Here LyX does no guessing and there are no
 plans to change that.

On the contrary, dear fellow: the opposite has already come to pass!
Demand hath begat a plan!  One man, I understand, begat that plan: a
module fan, Michiel Kamermans!
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

http://www.ctan.org/tex-archive/macros/xetex/latex/fontwrap/
 So that fonts are *autoselected* based on UNICODE range unless
otherwise overridden.

But alas, the user is still utterly laboured with tedious repetition
of language specification (also text style selection, with the hack i
use), and will remain so until LyX UI changes.

 But it can be tricky to make it right. It heavily depends on the spell 
 checker -
 aspell e. g. accepts completely different alternative language settings as
 hunspell or apples spell checker do. And it depends on the 
 runtime-environment -
 what dictionaries are available for the user on the current machine.
 And we have the feature to switch between the spell checker back ends at 
 runtime.

This sounds ugly.  Is there any similarity between spell checking APIs?  Is
there a cross platform, spell checking library unification / abstraction layer
available? Would it be worth developing one? How difficult is it to detect
known dictionaries and spell checkers on a cross-platform basis?

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

 Until the field gets replaced or removed a tooltip may help.

Great!

 2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

 You propose to auto extend the selection to word boundaries when setting
 the language at a given position and no selection exists. That sounds
 sensible...

Hurrah!

 3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to link
   

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Liviu Andronic]

Hello
This is a long document indeed and, unfortunately, I couldn't find the  
will to go through it all. But I should have a couple of interesting  
references regarding multilingual documents.


This has been discussed previously on the list, in the context of XeTeX  
support in LyX 2.0 SVN:

http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html
http://comments.gmane.org/gmane.editors.lyx.general/66485

Especially Daron's comments:
http://permalink.gmane.org/gmane.editors.lyx.general/66547

Hope this is of help
Liviu



On Wed, 26 Jan 2011 15:00:56 +0100, Walter walter.stan...@gmail.com  
wrote:


(Note: Mostly this email dates from pre-Christmas December - took me  
awhile

   to post!)

(This is a bit more verbose than it should be, as I am presently stuck in
an historic colonial hill station of Tunisia, by the Algerian border, and
being winter the weather is bitter and I am therefore locked in my hotel
room with time, but no internet connection!)

Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
a spell check for the first time.

The interface is good and no doubt an improvement on previous eras,  
however

the following struck me as possible to improve.

Those items marked with [*] I consider a bug in LyX. Those items marked
with [X] I consider a bug elsewhere.


1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt  
right

   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though  
that's

   probably my fault.)

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell'  
would
   clear it up, indeed some text was located that made the expected  
format

   for the entry of a single language value probable:

It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code  
and
 an optional two letter ISO 3166 country code after a dash or  
underscore.


   I tried this (en_AU), and it did work.  However, there are two  
problems:

- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise  
even
  at this early stage of my document still hundreds of words and  
place
  names in French, German, Greek (+romanised Greek), Chinese  
(+romanised

  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

   The method to do this (eg: separate multiple values with a space or  
comma),

   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.

   Whilst the ideal route would be to add (relatively) complex  
integration

   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight  
or

   perhaps ever.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

2. Right click to set spellchecker language on a highlighted word fails  
[*]

   
   It appears that when 'Tools|Preferences|Language  
Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1  
was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are  
right

   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use  
'Edit|

   Language|Whatever language' to actually perform the change - pointless
   tedium.

3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of  
multilingual

   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really  
solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to  
link
   the manual language markup made in conjunction with a font-linked  
solution

   to the manual language markup required for spellchecking purposes.

   The TeX-world's colourful background to all this is understandable,  
and of
   course I would not suggest to fly in the face of either  
configurability
   nor tradition nor the 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

Possible answer: http://www.abisource.com/projects/enchant/

- Walter

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Liviu Andronic]

On Thu, Jan 27, 2011 at 3:16 PM, Walter walter.stan...@gmail.com wrote:
 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction 
 layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

 Possible answer: http://www.abisource.com/projects/enchant/

LyX supports enchant. [1] [2]
Liviu

[1] http://wiki.lyx.org/LyX/NewInLyX20#toc28
[2] http://www.mail-archive.com/lyx-announce@lists.lyx.org/msg00124.html


 - Walter




-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 27.01.2011 um 15:16 schrieb Walter:

 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction 
 layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?
 
 Possible answer: http://www.abisource.com/projects/enchant/

Unfortunately enchant has big drawbacks:
* missing language variety support
* not available for LyX on mac

And in fact it is only a wrapper around existing spell checkers -
just as LyX is :-)

Stephan

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 27.01.2011 um 14:05 schrieb Walter:

 Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
 a spell check for the first time.
 
 The interface is good and no doubt an improvement on previous eras, however
 the following struck me as possible to improve.
 
 Those items marked with [*] I consider a bug in LyX. Those items marked
 with [X] I consider a bug elsewhere.
 
 
 1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)
 
 The following refers to the field Alternative language I'd guess.
 
 Correct!
 
   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:
 
It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or 
 underscore.
 
   I tried this (en_AU), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)
 
 Ok, with this use case - mixed language documents - you are requested to
 mark the text appropriately. Here LyX does no guessing and there are no
 plans to change that.
 
 On the contrary, dear fellow: the opposite has already come to pass!
 Demand hath begat a plan!  One man, I understand, begat that plan: a
 module fan, Michiel Kamermans!
 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

Ok, AFAIU this refers to the XeLaTeX engine and not to LyX.
Of course, if someone wants to develop a solid algorithm for language
guessing and can convince the LyX developer community of it and has the
resources to implement and test it - it may happen. Another option
would be to have a spell checker backend including this feature.

 http://www.ctan.org/tex-archive/macros/xetex/latex/fontwrap/
 So that fonts are *autoselected* based on UNICODE range unless
 otherwise overridden.
 
 But alas, the user is still utterly laboured with tedious repetition
 of language specification (also text style selection, with the hack i
 use), and will remain so until LyX UI changes.

Do you have an example for such a document?

 
 But it can be tricky to make it right. It heavily depends on the spell 
 checker -
 aspell e. g. accepts completely different alternative language settings as
 hunspell or apples spell checker do. And it depends on the 
 runtime-environment -
 what dictionaries are available for the user on the current machine.
 And we have the feature to switch between the spell checker back ends at 
 runtime.
 
 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

I'll cite my own investigation about similarity between spell checking APIs.
The focus was the management of personal word lists.

 We have support for different spell checker backends.
 All of them are able to check words, of course.
 But the capabilities with personal word lists differs horrible.
 The following table presents the results of my investigation.
 
 Feature | aspell | native (mac) | enchant | hunspell
 
 check   | +  | +| +   | +
 suggest | +  | +| +   | +
 accept  | +  | +| +   | +
 insert  | +  | +| o (2)   | o (3)
 ispersonal? | o (1)  | +| -   | -
 remove  | -  | +| + (4)   | -
 
 Legend:
 + feature is supported
 - feature is not supported
 o there are limitations:
 1) aspell has the interface to enumerate the personal word list.
   So it's possible to implement, I have a patch for LyX at hand.
 2) The versions below 1.6.0 are truncating the personal word list
   on open - effectively no personal word list available after restart.
 3) There is no persistent state 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Jürgen Spitzmüller]

Stephan Witt wrote:
 Of course, if someone wants to develop a solid algorithm for language
 guessing and can convince the LyX developer community of it and has the
 resources to implement and test it - it may happen. Another option
 would be to have a spell checker backend including this feature.

Note that language settings are not only needed for the spellchecker, but 
ultimately also for LaTeX (babel). If you do not mark the language properly, 
you will get wrong hyphenation, which is much more crucial than the 
spellchecker. 

Jürgen

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 26.01.2011 um 15:00 schrieb Walter:

I'll try to answer this - although I surely don't have so much time you had to 
write this.

 Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
 a spell check for the first time.
 
 The interface is good and no doubt an improvement on previous eras, however
 the following struck me as possible to improve.
 
 Those items marked with [*] I consider a bug in LyX. Those items marked
 with [X] I consider a bug elsewhere.
 
 
 1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

The following refers to the field Alternative language I'd guess.

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:
 
It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or underscore.
 
   I tried this (en_AU), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

Ok, with this use case - mixed language documents - you are requested to
mark the text appropriately. Here LyX does no guessing and there are no
plans to change that.

   The method to do this (eg: separate multiple values with a space or comma),
   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.
 
   Whilst the ideal route would be to add (relatively) complex integration
   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight or
   perhaps ever.

Alternative language is a - as I would rate it - cul-de-sac and shouldn't be 
there.
If any LyX should have a mapping of available languages to alternate languages.

As it is now the single value here is used for all text having the documents 
language
as a replacement to pass on to the spell checker.

So if you want to use English (UK) you don't need to change it here -
simply set your document language to English (UK).

The alternate language is used for all (!) languages regardless of making 
any sense. If you edit a french LyX-document and the alternate language
is set to en_GB e. g. you'll have no fun.

This is what I would rate as a bug. 

So this field is of very limited use and should be replaced by something else.
Of course something else may have an more user friendly interface too...

But it can be tricky to make it right. It heavily depends on the spell checker -
aspell e. g. accepts completely different alternative language settings as
hunspell or apples spell checker do. And it depends on the runtime-environment -
what dictionaries are available for the user on the current machine.
And we have the feature to switch between the spell checker back ends at 
runtime.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

Until the field gets replaced or removed a tooltip may help.

 2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

You propose to auto extend the selection to word boundaries when setting
the language at a given position and no selection exists. That sounds
sensible...

 3. 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

 I'll try to answer this - although I surely don't have so much time you had 
 to write this.

Relativity...

 Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
 a spell check for the first time.

 The interface is good and no doubt an improvement on previous eras, however
 the following struck me as possible to improve.

 Those items marked with [*] I consider a bug in LyX. Those items marked
 with [X] I consider a bug elsewhere.


 1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

 The following refers to the field Alternative language I'd guess.

Correct!

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:

    It follows the same format of the  LANG  environmental variable on
     most systems. It consists of the two letter ISO 639 language code and
     an optional two letter ISO 3166 country code after a dash or underscore.

   I tried this (en_AU), and it did work.  However, there are two problems:
    - Even the first step would be a challenge for some users
    - I would like to add multiple values to the field, since otherwise even
      at this early stage of my document still hundreds of words and place
      names in French, German, Greek (+romanised Greek), Chinese (+romanised
      Chinese), etc. trip up the spell checker. (Use of these languages
      is frequent and scattered right throughout the document.)

 Ok, with this use case - mixed language documents - you are requested to
 mark the text appropriately. Here LyX does no guessing and there are no
 plans to change that.

On the contrary, dear fellow: the opposite has already come to pass!
Demand hath begat a plan!  One man, I understand, begat that plan: a
module fan, Michiel Kamermans!
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

http://www.ctan.org/tex-archive/macros/xetex/latex/fontwrap/
 So that fonts are *autoselected* based on UNICODE range unless
otherwise overridden.

But alas, the user is still utterly laboured with tedious repetition
of language specification (also text style selection, with the hack i
use), and will remain so until LyX UI changes.

 But it can be tricky to make it right. It heavily depends on the spell 
 checker -
 aspell e. g. accepts completely different alternative language settings as
 hunspell or apples spell checker do. And it depends on the 
 runtime-environment -
 what dictionaries are available for the user on the current machine.
 And we have the feature to switch between the spell checker back ends at 
 runtime.

This sounds ugly.  Is there any similarity between spell checking APIs?  Is
there a cross platform, spell checking library unification / abstraction layer
available? Would it be worth developing one? How difficult is it to detect
known dictionaries and spell checkers on a cross-platform basis?

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

 Until the field gets replaced or removed a tooltip may help.

Great!

 2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

 You propose to auto extend the selection to word boundaries when setting
 the language at a given position and no selection exists. That sounds
 sensible...

Hurrah!

 3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to link
   

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Liviu Andronic]

Hello
This is a long document indeed and, unfortunately, I couldn't find the  
will to go through it all. But I should have a couple of interesting  
references regarding multilingual documents.


This has been discussed previously on the list, in the context of XeTeX  
support in LyX 2.0 SVN:

http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html
http://comments.gmane.org/gmane.editors.lyx.general/66485

Especially Daron's comments:
http://permalink.gmane.org/gmane.editors.lyx.general/66547

Hope this is of help
Liviu



On Wed, 26 Jan 2011 15:00:56 +0100, Walter walter.stan...@gmail.com  
wrote:


(Note: Mostly this email dates from pre-Christmas December - took me  
awhile

   to post!)

(This is a bit more verbose than it should be, as I am presently stuck in
an historic colonial hill station of Tunisia, by the Algerian border, and
being winter the weather is bitter and I am therefore locked in my hotel
room with time, but no internet connection!)

Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
a spell check for the first time.

The interface is good and no doubt an improvement on previous eras,  
however

the following struck me as possible to improve.

Those items marked with [*] I consider a bug in LyX. Those items marked
with [X] I consider a bug elsewhere.


1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt  
right

   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though  
that's

   probably my fault.)

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell'  
would
   clear it up, indeed some text was located that made the expected  
format

   for the entry of a single language value probable:

It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code  
and
 an optional two letter ISO 3166 country code after a dash or  
underscore.


   I tried this (en_AU), and it did work.  However, there are two  
problems:

- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise  
even
  at this early stage of my document still hundreds of words and  
place
  names in French, German, Greek (+romanised Greek), Chinese  
(+romanised

  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

   The method to do this (eg: separate multiple values with a space or  
comma),

   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.

   Whilst the ideal route would be to add (relatively) complex  
integration

   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight  
or

   perhaps ever.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

2. Right click to set spellchecker language on a highlighted word fails  
[*]

   
   It appears that when 'Tools|Preferences|Language  
Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1  
was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are  
right

   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use  
'Edit|

   Language|Whatever language' to actually perform the change - pointless
   tedium.

3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of  
multilingual

   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really  
solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to  
link
   the manual language markup made in conjunction with a font-linked  
solution

   to the manual language markup required for spellchecking purposes.

   The TeX-world's colourful background to all this is understandable,  
and of
   course I would not suggest to fly in the face of either  
configurability
   nor tradition nor the 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

Possible answer: http://www.abisource.com/projects/enchant/

- Walter

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Liviu Andronic]

On Thu, Jan 27, 2011 at 3:16 PM, Walter walter.stan...@gmail.com wrote:
 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction 
 layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

 Possible answer: http://www.abisource.com/projects/enchant/

LyX supports enchant. [1] [2]
Liviu

[1] http://wiki.lyx.org/LyX/NewInLyX20#toc28
[2] http://www.mail-archive.com/lyx-announce@lists.lyx.org/msg00124.html


 - Walter




-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 27.01.2011 um 15:16 schrieb Walter:

 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction 
 layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?
 
 Possible answer: http://www.abisource.com/projects/enchant/

Unfortunately enchant has big drawbacks:
* missing language variety support
* not available for LyX on mac

And in fact it is only a wrapper around existing spell checkers -
just as LyX is :-)

Stephan

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 27.01.2011 um 14:05 schrieb Walter:

 Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
 a spell check for the first time.
 
 The interface is good and no doubt an improvement on previous eras, however
 the following struck me as possible to improve.
 
 Those items marked with [*] I consider a bug in LyX. Those items marked
 with [X] I consider a bug elsewhere.
 
 
 1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)
 
 The following refers to the field Alternative language I'd guess.
 
 Correct!
 
   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:
 
It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or 
 underscore.
 
   I tried this (en_AU), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)
 
 Ok, with this use case - mixed language documents - you are requested to
 mark the text appropriately. Here LyX does no guessing and there are no
 plans to change that.
 
 On the contrary, dear fellow: the opposite has already come to pass!
 Demand hath begat a plan!  One man, I understand, begat that plan: a
 module fan, Michiel Kamermans!
 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

Ok, AFAIU this refers to the XeLaTeX engine and not to LyX.
Of course, if someone wants to develop a solid algorithm for language
guessing and can convince the LyX developer community of it and has the
resources to implement and test it - it may happen. Another option
would be to have a spell checker backend including this feature.

 http://www.ctan.org/tex-archive/macros/xetex/latex/fontwrap/
 So that fonts are *autoselected* based on UNICODE range unless
 otherwise overridden.
 
 But alas, the user is still utterly laboured with tedious repetition
 of language specification (also text style selection, with the hack i
 use), and will remain so until LyX UI changes.

Do you have an example for such a document?

 
 But it can be tricky to make it right. It heavily depends on the spell 
 checker -
 aspell e. g. accepts completely different alternative language settings as
 hunspell or apples spell checker do. And it depends on the 
 runtime-environment -
 what dictionaries are available for the user on the current machine.
 And we have the feature to switch between the spell checker back ends at 
 runtime.
 
 This sounds ugly.  Is there any similarity between spell checking APIs?  Is
 there a cross platform, spell checking library unification / abstraction layer
 available? Would it be worth developing one? How difficult is it to detect
 known dictionaries and spell checkers on a cross-platform basis?

I'll cite my own investigation about similarity between spell checking APIs.
The focus was the management of personal word lists.

 We have support for different spell checker backends.
 All of them are able to check words, of course.
 But the capabilities with personal word lists differs horrible.
 The following table presents the results of my investigation.
 
 Feature | aspell | native (mac) | enchant | hunspell
 
 check   | +  | +| +   | +
 suggest | +  | +| +   | +
 accept  | +  | +| +   | +
 insert  | +  | +| o (2)   | o (3)
 ispersonal? | o (1)  | +| -   | -
 remove  | -  | +| + (4)   | -
 
 Legend:
 + feature is supported
 - feature is not supported
 o there are limitations:
 1) aspell has the interface to enumerate the personal word list.
   So it's possible to implement, I have a patch for LyX at hand.
 2) The versions below 1.6.0 are truncating the personal word list
   on open - effectively no personal word list available after restart.
 3) There is no persistent state 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Jürgen Spitzmüller]

Stephan Witt wrote:
 Of course, if someone wants to develop a solid algorithm for language
 guessing and can convince the LyX developer community of it and has the
 resources to implement and test it - it may happen. Another option
 would be to have a spell checker backend including this feature.

Note that language settings are not only needed for the spellchecker, but 
ultimately also for LaTeX (babel). If you do not mark the language properly, 
you will get wrong hyphenation, which is much more crucial than the 
spellchecker. 

Jürgen

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 26.01.2011 um 15:00 schrieb Walter:

I'll try to answer this - although I surely don't have so much time you had to 
write this.

> Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
> a spell check for the first time.
> 
> The interface is good and no doubt an improvement on previous eras, however
> the following struck me as possible to improve.
> 
> Those items marked with "[*]" I consider a bug in LyX. Those items marked
> with "[X]" I consider a bug elsewhere.
> 
> 
> 1. Preferences|Language Settings|Spellchecker [*]
>   --
>   Fields lack a description.  Faced with having used non-US spelling
>   in my document ("for shame!"), I do not want to manually set hundreds
>   of individual words to be 'English (UK)', which using the inbuilt right
>   sidebar interface appears to be the default way forward.  (For some
>   reason, 'English (AU)' is not even an option on my system, though that's
>   probably my fault.)

The following refers to the field "Alternative language" I'd guess.

>   Thus driven to the preferences dialog, I was unsure of which mystical
>   value to enter in to the great LyX machine.  Assuming 'man aspell' would
>   clear it up, indeed some text was located that made the expected format
>   for the entry of a single language value probable:
> 
>"It follows the same format of the  LANG  environmental variable on
> most systems. It consists of the two letter ISO 639 language code and
> an optional two letter ISO 3166 country code after a dash or underscore."
> 
>   I tried this ("en_AU"), and it did work.  However, there are two problems:
>- Even the first step would be a challenge for some users
>- I would like to add multiple values to the field, since otherwise even
>  at this early stage of my document still hundreds of words and place
>  names in French, German, Greek (+romanised Greek), Chinese (+romanised
>  Chinese), etc. trip up the spell checker. (Use of these languages
>  is frequent and scattered right throughout the document.)

Ok, with this use case - mixed language documents - you are requested to
mark the text appropriately. Here LyX does no guessing and there are no
plans to change that.

>   The method to do this (eg: separate multiple values with a space or comma),
>   or indeed whether entering multiple values in to this field is at all
>   possible remains unclear.
> 
>   Whilst the ideal route would be to add (relatively) complex integration
>   code that auto-detected available spellcheckers, their dictionaries,
>   and provided a sexy GUI for end user language selection instead of a
>   mystical text field, I realise this is not going to happen overnight or
>   perhaps ever.

Alternative language is a - as I would rate it - cul-de-sac and shouldn't be 
there.
If any LyX should have a mapping of available languages to alternate languages.

As it is now the single value here is used for all text having the documents 
language
as a replacement to pass on to the spell checker.

So if you want to use English (UK) you don't need to change it here -
simply set your document language to English (UK).

The alternate language is used for all (!) languages regardless of making 
any sense. If you edit a french LyX-document and the alternate language
is set to "en_GB" e. g. you'll have no fun.

This is what I would rate as a bug. 

So this field is of very limited "use" and should be replaced by something else.
Of course "something else" may have an more user friendly interface too...

But it can be tricky to make it right. It heavily depends on the spell checker -
aspell e. g. accepts completely different "alternative" language settings as
hunspell or apples spell checker do. And it depends on the runtime-environment -
what dictionaries are available for the user on the current machine.
And we have the feature to switch between the spell checker back ends at 
runtime.

>   Thus, as a relatively easy half-way fix, could we please have some
>   increased on-screen documentation?  Something like "eg: 'en_GB' for
>   aspell." may suffice for 95% of users.

Until the field gets replaced or removed a tooltip may help.

> 2. Right click to set spellchecker language on a highlighted word fails [*]
>   
>   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
>   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
>   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
>   clicked, there is an option to set their language for spellchecking
>   purposes.  However, this does not appear to actually do anything!
>   This makes it necessary for the user to select the word then use 'Edit|
>   Language|Whatever language' to actually perform the change - pointless
>   tedium.

You propose to auto extend the selection to word boundaries when setting
the 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

> I'll try to answer this - although I surely don't have so much time you had 
> to write this.

Relativity...

>> Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
>> a spell check for the first time.
>>
>> The interface is good and no doubt an improvement on previous eras, however
>> the following struck me as possible to improve.
>>
>> Those items marked with "[*]" I consider a bug in LyX. Those items marked
>> with "[X]" I consider a bug elsewhere.
>>
>>
>> 1. Preferences|Language Settings|Spellchecker [*]
>>   --
>>   Fields lack a description.  Faced with having used non-US spelling
>>   in my document ("for shame!"), I do not want to manually set hundreds
>>   of individual words to be 'English (UK)', which using the inbuilt right
>>   sidebar interface appears to be the default way forward.  (For some
>>   reason, 'English (AU)' is not even an option on my system, though that's
>>   probably my fault.)
>
> The following refers to the field "Alternative language" I'd guess.

Correct!

>>   Thus driven to the preferences dialog, I was unsure of which mystical
>>   value to enter in to the great LyX machine.  Assuming 'man aspell' would
>>   clear it up, indeed some text was located that made the expected format
>>   for the entry of a single language value probable:
>>
>>    "It follows the same format of the  LANG  environmental variable on
>>     most systems. It consists of the two letter ISO 639 language code and
>>     an optional two letter ISO 3166 country code after a dash or underscore."
>>
>>   I tried this ("en_AU"), and it did work.  However, there are two problems:
>>    - Even the first step would be a challenge for some users
>>    - I would like to add multiple values to the field, since otherwise even
>>      at this early stage of my document still hundreds of words and place
>>      names in French, German, Greek (+romanised Greek), Chinese (+romanised
>>      Chinese), etc. trip up the spell checker. (Use of these languages
>>      is frequent and scattered right throughout the document.)
>
> Ok, with this use case - mixed language documents - you are requested to
> mark the text appropriately. Here LyX does no guessing and there are no
> plans to change that.

On the contrary, dear fellow: the opposite has already come to pass!
Demand hath begat a plan!  One man, I understand, begat that plan: a
module fan, Michiel Kamermans!
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html


 "So that fonts are *autoselected* based on UNICODE range unless
otherwise overridden."

But alas, the user is still utterly laboured with tedious repetition
of language specification (also text style selection, with the hack i
use), and will remain so until LyX UI changes.

> But it can be tricky to make it right. It heavily depends on the spell 
> checker -
> aspell e. g. accepts completely different "alternative" language settings as
> hunspell or apples spell checker do. And it depends on the 
> runtime-environment -
> what dictionaries are available for the user on the current machine.
> And we have the feature to switch between the spell checker back ends at 
> runtime.

This sounds ugly.  Is there any similarity between spell checking APIs?  Is
there a cross platform, spell checking library unification / abstraction layer
available? Would it be worth developing one? How difficult is it to detect
known dictionaries and spell checkers on a cross-platform basis?

>>   Thus, as a relatively easy half-way fix, could we please have some
>>   increased on-screen documentation?  Something like "eg: 'en_GB' for
>>   aspell." may suffice for 95% of users.
>
> Until the field gets replaced or removed a tooltip may help.

Great!

>> 2. Right click to set spellchecker language on a highlighted word fails [*]
>>   
>>   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
>>   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
>>   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
>>   clicked, there is an option to set their language for spellchecking
>>   purposes.  However, this does not appear to actually do anything!
>>   This makes it necessary for the user to select the word then use 'Edit|
>>   Language|Whatever language' to actually perform the change - pointless
>>   tedium.
>
> You propose to auto extend the selection to word boundaries when setting
> the language at a given position and no selection exists. That sounds
> sensible...

Hurrah!

>> 3. Wider problem of spellchecking and multilingual support
>>   ---
>>   Regarding points 1 and 2, really there is a wider problem of multilingual
>>   support being a little 'all over the place', with a bunch of different
>>   

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Liviu Andronic]

Hello
This is a long document indeed and, unfortunately, I couldn't find the  
will to go through it all. But I should have a couple of interesting  
references regarding multilingual documents.


This has been discussed previously on the list, in the context of XeTeX  
support in LyX 2.0 SVN:

http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html
http://comments.gmane.org/gmane.editors.lyx.general/66485

Especially Daron's comments:
http://permalink.gmane.org/gmane.editors.lyx.general/66547

Hope this is of help
Liviu



On Wed, 26 Jan 2011 15:00:56 +0100, Walter   
wrote:


(Note: Mostly this email dates from pre-Christmas December - took me  
awhile

   to post!)

(This is a bit more verbose than it should be, as I am presently stuck in
an historic colonial hill station of Tunisia, by the Algerian border, and
being winter the weather is bitter and I am therefore locked in my hotel
room with time, but no internet connection!)

Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
a spell check for the first time.

The interface is good and no doubt an improvement on previous eras,  
however

the following struck me as possible to improve.

Those items marked with "[*]" I consider a bug in LyX. Those items marked
with "[X]" I consider a bug elsewhere.


1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document ("for shame!"), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt  
right

   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though  
that's

   probably my fault.)

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell'  
would
   clear it up, indeed some text was located that made the expected  
format

   for the entry of a single language value probable:

"It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code  
and
 an optional two letter ISO 3166 country code after a dash or  
underscore."


   I tried this ("en_AU"), and it did work.  However, there are two  
problems:

- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise  
even
  at this early stage of my document still hundreds of words and  
place
  names in French, German, Greek (+romanised Greek), Chinese  
(+romanised

  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

   The method to do this (eg: separate multiple values with a space or  
comma),

   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.

   Whilst the ideal route would be to add (relatively) complex  
integration

   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight  
or

   perhaps ever.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like "eg: 'en_GB' for
   aspell." may suffice for 95% of users.

2. Right click to set spellchecker language on a highlighted word fails  
[*]

   
   It appears that when 'Tools|Preferences|Language  
Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1  
was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are  
right

   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use  
'Edit|

   Language|Whatever language' to actually perform the change - pointless
   tedium.

3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of  
multilingual

   support being a little 'all over the place', with a bunch of different
   "solutions" in use.  In terms of LyX, none of these are really  
"solutions"
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to  
link
   the manual language markup made in conjunction with a font-linked  
solution

   to the manual language markup required for spellchecking purposes.

   The TeX-world's colourful background to all this is understandable,  
and of
   course I would not suggest to fly in the face of either  
configurability
   nor 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

> This sounds ugly.  Is there any similarity between spell checking APIs?  Is
> there a cross platform, spell checking library unification / abstraction layer
> available? Would it be worth developing one? How difficult is it to detect
> known dictionaries and spell checkers on a cross-platform basis?

Possible answer: http://www.abisource.com/projects/enchant/

- Walter

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Liviu Andronic]

On Thu, Jan 27, 2011 at 3:16 PM, Walter  wrote:
>> This sounds ugly.  Is there any similarity between spell checking APIs?  Is
>> there a cross platform, spell checking library unification / abstraction 
>> layer
>> available? Would it be worth developing one? How difficult is it to detect
>> known dictionaries and spell checkers on a cross-platform basis?
>
> Possible answer: http://www.abisource.com/projects/enchant/
>
LyX supports enchant. [1] [2]
Liviu

[1] http://wiki.lyx.org/LyX/NewInLyX20#toc28
[2] http://www.mail-archive.com/lyx-announce@lists.lyx.org/msg00124.html


> - Walter
>



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 27.01.2011 um 15:16 schrieb Walter:

>> This sounds ugly.  Is there any similarity between spell checking APIs?  Is
>> there a cross platform, spell checking library unification / abstraction 
>> layer
>> available? Would it be worth developing one? How difficult is it to detect
>> known dictionaries and spell checkers on a cross-platform basis?
> 
> Possible answer: http://www.abisource.com/projects/enchant/

Unfortunately enchant has big drawbacks:
* missing language variety support
* not available for LyX on mac

And in fact it is only a wrapper around existing spell checkers -
just as LyX is :-)

Stephan

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Stephan Witt]

Am 27.01.2011 um 14:05 schrieb Walter:

>>> Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
>>> a spell check for the first time.
>>> 
>>> The interface is good and no doubt an improvement on previous eras, however
>>> the following struck me as possible to improve.
>>> 
>>> Those items marked with "[*]" I consider a bug in LyX. Those items marked
>>> with "[X]" I consider a bug elsewhere.
>>> 
>>> 
>>> 1. Preferences|Language Settings|Spellchecker [*]
>>>   --
>>>   Fields lack a description.  Faced with having used non-US spelling
>>>   in my document ("for shame!"), I do not want to manually set hundreds
>>>   of individual words to be 'English (UK)', which using the inbuilt right
>>>   sidebar interface appears to be the default way forward.  (For some
>>>   reason, 'English (AU)' is not even an option on my system, though that's
>>>   probably my fault.)
>> 
>> The following refers to the field "Alternative language" I'd guess.
> 
> Correct!
> 
>>>   Thus driven to the preferences dialog, I was unsure of which mystical
>>>   value to enter in to the great LyX machine.  Assuming 'man aspell' would
>>>   clear it up, indeed some text was located that made the expected format
>>>   for the entry of a single language value probable:
>>> 
>>>"It follows the same format of the  LANG  environmental variable on
>>> most systems. It consists of the two letter ISO 639 language code and
>>> an optional two letter ISO 3166 country code after a dash or 
>>> underscore."
>>> 
>>>   I tried this ("en_AU"), and it did work.  However, there are two problems:
>>>- Even the first step would be a challenge for some users
>>>- I would like to add multiple values to the field, since otherwise even
>>>  at this early stage of my document still hundreds of words and place
>>>  names in French, German, Greek (+romanised Greek), Chinese (+romanised
>>>  Chinese), etc. trip up the spell checker. (Use of these languages
>>>  is frequent and scattered right throughout the document.)
>> 
>> Ok, with this use case - mixed language documents - you are requested to
>> mark the text appropriately. Here LyX does no guessing and there are no
>> plans to change that.
> 
> On the contrary, dear fellow: the opposite has already come to pass!
> Demand hath begat a plan!  One man, I understand, begat that plan: a
> module fan, Michiel Kamermans!
> http://www.mail-archive.com/lyx-users@lists.lyx.org/msg83713.html

Ok, AFAIU this refers to the XeLaTeX engine and not to LyX.
Of course, if someone wants to develop a solid algorithm for language
guessing and can convince the LyX developer community of it and has the
resources to implement and test it - it may happen. Another option
would be to have a spell checker backend including this feature.

> 
> "So that fonts are *autoselected* based on UNICODE range unless
> otherwise overridden."
> 
> But alas, the user is still utterly laboured with tedious repetition
> of language specification (also text style selection, with the hack i
> use), and will remain so until LyX UI changes.

Do you have an example for such a document?

> 
>> But it can be tricky to make it right. It heavily depends on the spell 
>> checker -
>> aspell e. g. accepts completely different "alternative" language settings as
>> hunspell or apples spell checker do. And it depends on the 
>> runtime-environment -
>> what dictionaries are available for the user on the current machine.
>> And we have the feature to switch between the spell checker back ends at 
>> runtime.
> 
> This sounds ugly.  Is there any similarity between spell checking APIs?  Is
> there a cross platform, spell checking library unification / abstraction layer
> available? Would it be worth developing one? How difficult is it to detect
> known dictionaries and spell checkers on a cross-platform basis?

I'll cite my own investigation about similarity between spell checking APIs.
The focus was the management of personal word lists.

> We have support for different spell checker backends.
> All of them are able to check words, of course.
> But the capabilities with personal word lists differs horrible.
> The following table presents the results of my investigation.
> 
> Feature | aspell | native (mac) | enchant | hunspell
> 
> check   | +  | +| +   | +
> suggest | +  | +| +   | +
> accept  | +  | +| +   | +
> insert  | +  | +| o (2)   | o (3)
> ispersonal? | o (1)  | +| -   | -
> remove  | -  | +| + (4)   | -
> 
> Legend:
> + feature is supported
> - feature is not supported
> o there are limitations:
> 1) aspell has the interface to enumerate the personal word list.
>   So it's possible to implement, I have a 

Re: Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Jürgen Spitzmüller]

Stephan Witt wrote:
> Of course, if someone wants to develop a solid algorithm for language
> guessing and can convince the LyX developer community of it and has the
> resources to implement and test it - it may happen. Another option
> would be to have a spell checker backend including this feature.

Note that language settings are not only needed for the spellchecker, but 
ultimately also for LaTeX (babel). If you do not mark the language properly, 
you will get wrong hyphenation, which is much more crucial than the 
spellchecker. 

Jürgen

Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

(Note: Mostly this email dates from pre-Christmas December - took me awhile
   to post!)

(This is a bit more verbose than it should be, as I am presently stuck in
an historic colonial hill station of Tunisia, by the Algerian border, and
being winter the weather is bitter and I am therefore locked in my hotel
room with time, but no internet connection!)

Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
a spell check for the first time.

The interface is good and no doubt an improvement on previous eras, however
the following struck me as possible to improve.

Those items marked with [*] I consider a bug in LyX. Those items marked
with [X] I consider a bug elsewhere.


1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:

It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or underscore.

   I tried this (en_AU), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

   The method to do this (eg: separate multiple values with a space or comma),
   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.

   Whilst the ideal route would be to add (relatively) complex integration
   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight or
   perhaps ever.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to link
   the manual language markup made in conjunction with a font-linked solution
   to the manual language markup required for spellchecking purposes.

   The TeX-world's colourful background to all this is understandable, and of
   course I would not suggest to fly in the face of either configurability
   nor tradition nor the existing user base's preferences, however to my mind
   it would be expedient for ease of use (especially for new users with
   little TeX background, who - let's face it - represent the largest
   possible and probable future user base) if LyX would 'encourage' people
   to an 'intelligent' default solution instead of leaving them high and dry
   with a there's 1000 ways to do it but we're not really going to hint at
   any of them situation, as we see at present.  Now, I see the adoption
   of XeTeX-specific checkboxes in LyX 2.0beta1 as a *great* step forward
   in this direction, but there's a ways to go yet.

   As per previous posts whereby I suggested revising the user interface 

Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

(Note: Mostly this email dates from pre-Christmas December - took me awhile
   to post!)

(This is a bit more verbose than it should be, as I am presently stuck in
an historic colonial hill station of Tunisia, by the Algerian border, and
being winter the weather is bitter and I am therefore locked in my hotel
room with time, but no internet connection!)

Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
a spell check for the first time.

The interface is good and no doubt an improvement on previous eras, however
the following struck me as possible to improve.

Those items marked with [*] I consider a bug in LyX. Those items marked
with [X] I consider a bug elsewhere.


1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document (for shame!), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:

It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or underscore.

   I tried this (en_AU), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

   The method to do this (eg: separate multiple values with a space or comma),
   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.

   Whilst the ideal route would be to add (relatively) complex integration
   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight or
   perhaps ever.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like eg: 'en_GB' for
   aspell. may suffice for 95% of users.

2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   solutions in use.  In terms of LyX, none of these are really solutions
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to link
   the manual language markup made in conjunction with a font-linked solution
   to the manual language markup required for spellchecking purposes.

   The TeX-world's colourful background to all this is understandable, and of
   course I would not suggest to fly in the face of either configurability
   nor tradition nor the existing user base's preferences, however to my mind
   it would be expedient for ease of use (especially for new users with
   little TeX background, who - let's face it - represent the largest
   possible and probable future user base) if LyX would 'encourage' people
   to an 'intelligent' default solution instead of leaving them high and dry
   with a there's 1000 ways to do it but we're not really going to hint at
   any of them situation, as we see at present.  Now, I see the adoption
   of XeTeX-specific checkboxes in LyX 2.0beta1 as a *great* step forward
   in this direction, but there's a ways to go yet.

   As per previous posts whereby I suggested revising the user interface 

Subject: LyX 2.0beta3: Spell Checking + Multilingualism

[Walter]

(Note: Mostly this email dates from pre-Christmas December - took me awhile
   to post!)

(This is a bit more verbose than it should be, as I am presently stuck in
an historic colonial hill station of Tunisia, by the Algerian border, and
being winter the weather is bitter and I am therefore locked in my hotel
room with time, but no internet connection!)

Whilst using LyX 2.0beta1 [since verified on LyX 2.0beta3] I recently ran
a spell check for the first time.

The interface is good and no doubt an improvement on previous eras, however
the following struck me as possible to improve.

Those items marked with "[*]" I consider a bug in LyX. Those items marked
with "[X]" I consider a bug elsewhere.


1. Preferences|Language Settings|Spellchecker [*]
   --
   Fields lack a description.  Faced with having used non-US spelling
   in my document ("for shame!"), I do not want to manually set hundreds
   of individual words to be 'English (UK)', which using the inbuilt right
   sidebar interface appears to be the default way forward.  (For some
   reason, 'English (AU)' is not even an option on my system, though that's
   probably my fault.)

   Thus driven to the preferences dialog, I was unsure of which mystical
   value to enter in to the great LyX machine.  Assuming 'man aspell' would
   clear it up, indeed some text was located that made the expected format
   for the entry of a single language value probable:

"It follows the same format of the  LANG  environmental variable on
 most systems. It consists of the two letter ISO 639 language code and
 an optional two letter ISO 3166 country code after a dash or underscore."

   I tried this ("en_AU"), and it did work.  However, there are two problems:
- Even the first step would be a challenge for some users
- I would like to add multiple values to the field, since otherwise even
  at this early stage of my document still hundreds of words and place
  names in French, German, Greek (+romanised Greek), Chinese (+romanised
  Chinese), etc. trip up the spell checker. (Use of these languages
  is frequent and scattered right throughout the document.)

   The method to do this (eg: separate multiple values with a space or comma),
   or indeed whether entering multiple values in to this field is at all
   possible remains unclear.

   Whilst the ideal route would be to add (relatively) complex integration
   code that auto-detected available spellcheckers, their dictionaries,
   and provided a sexy GUI for end user language selection instead of a
   mystical text field, I realise this is not going to happen overnight or
   perhaps ever.

   Thus, as a relatively easy half-way fix, could we please have some
   increased on-screen documentation?  Something like "eg: 'en_GB' for
   aspell." may suffice for 95% of users.

2. Right click to set spellchecker language on a highlighted word fails [*]
   
   It appears that when 'Tools|Preferences|Language Settings|Spellchecker|
   Spellcheck continuously' is set, and red-wavy (Note: LyX 2.0.0beta1 was
   wavy, LyX 2.0.0beta3 is straight and thicker) underlined words are right
   clicked, there is an option to set their language for spellchecking
   purposes.  However, this does not appear to actually do anything!
   This makes it necessary for the user to select the word then use 'Edit|
   Language|Whatever language' to actually perform the change - pointless
   tedium.

3. Wider problem of spellchecking and multilingual support
   ---
   Regarding points 1 and 2, really there is a wider problem of multilingual
   support being a little 'all over the place', with a bunch of different
   "solutions" in use.  In terms of LyX, none of these are really "solutions"
   as even with LyX 2.0beta1 it appears to be demonstrably impossible to link
   the manual language markup made in conjunction with a font-linked solution
   to the manual language markup required for spellchecking purposes.

   The TeX-world's colourful background to all this is understandable, and of
   course I would not suggest to fly in the face of either configurability
   nor tradition nor the existing user base's preferences, however to my mind
   it would be expedient for ease of use (especially for new users with
   little TeX background, who - let's face it - represent the largest
   possible and probable future user base) if LyX would 'encourage' people
   to an 'intelligent' default solution instead of leaving them high and dry
   with a "there's 1000 ways to do it but we're not really going to hint at
   any of them" situation, as we see at present.  Now, I see the adoption
   of XeTeX-specific checkboxes in LyX 2.0beta1 as a *great* step forward
   in this direction, but "there's a ways to go yet".

   As per previous posts whereby I suggested 

Re: change subject alignment in letter koma-script v.2

[Jean-Marie Pacquet]

Le 14/02/2010 22:49, Giovanni Bacci a écrit :

   domenica 14 febbraio 2010, 22:26, Jean-Marie Pacquet:

   

Default subject (i.e. beforeopening and untitled) is left justified.
Only the title (if selected) is centered. This can be seen on figure
6.1: Schematic of letter paper's pseudo lengths.
So I don't really understand your request: do you want the title to
be left justified?
 

   I've attached an example. As you can see, setting
subject=afteropening cause the object to be centered in the page. What
i'd like to have is a left-aligned subject line, exactly as it's with
subject=beforeopening
   
You are right and I don't know how to change that within Lyx. The Latex 
gurus may have a solution.

--
jmp

Re: change subject alignment in letter koma-script v.2

[Jean-Marie Pacquet]

Le 14/02/2010 22:49, Giovanni Bacci a écrit :

   domenica 14 febbraio 2010, 22:26, Jean-Marie Pacquet:

   

Default subject (i.e. beforeopening and untitled) is left justified.
Only the title (if selected) is centered. This can be seen on figure
6.1: Schematic of letter paper's pseudo lengths.
So I don't really understand your request: do you want the title to
be left justified?
 

   I've attached an example. As you can see, setting
subject=afteropening cause the object to be centered in the page. What
i'd like to have is a left-aligned subject line, exactly as it's with
subject=beforeopening
   
You are right and I don't know how to change that within Lyx. The Latex 
gurus may have a solution.

--
jmp

Re: change subject alignment in letter koma-script v.2

[Jean-Marie Pacquet]

Le 14/02/2010 22:49, Giovanni Bacci a écrit :

   domenica 14 febbraio 2010, 22:26, Jean-Marie Pacquet:

   

Default subject (i.e. beforeopening and untitled) is left justified.
Only the title (if selected) is centered. This can be seen on figure
6.1: Schematic of letter paper's pseudo lengths.
So I don't really understand your request: do you want the title to
be left justified?
 

   I've attached an example. As you can see, setting
subject=afteropening cause the object to be centered in the page. What
i'd like to have is a left-aligned subject line, exactly as it's with
subject=beforeopening
   
You are right and I don't know how to change that within Lyx. The Latex 
gurus may have a solution.

--
jmp

change subject alignment in letter koma-script v.2

[Giovanni Bacci]

  Hi list. I've a problem non strictly about lyx, but i hope to get an
answer, maybe useful for other lyxer too.
Anyway, I'd like to know if it's possible to change subject alignment
in a letter koma-script v.2 class. As an option i can only choose
{before,after}opening and titled/untitled. Both of them came with
a center aligned text. But what i'd like to obtain is a left justified
alignment. I've googled a bit, but without finding any clue.
  Any hints?

Thanks,
  Giovanni

Re: change subject alignment in letter koma-script v.2

[Jean-Marie Pacquet]

Giovanni Bacci a écrit :

[...]
Anyway, I'd like to know if it's possible to change subject alignment
in a letter koma-script v.2 class. As an option i can only choose
{before,after}opening and titled/untitled. Both of them came with
a center aligned text. But what i'd like to obtain is a left justified
alignment. I've googled a bit, but without finding any clue.
  Any hints?
  
Default subject (i.e. beforeopening and untitled) is left justified. 
Only the title (if selected) is centered. This can be seen on figure 
6.1: Schematic of letter paper's pseudo lengths.
So I don't really understand your request: do you want the title to be 
left justified?

--
jmp

Re: change subject alignment in letter koma-script v.2

[Giovanni Bacci]

  domenica 14 febbraio 2010, 22:26, Jean-Marie Pacquet:

 Default subject (i.e. beforeopening and untitled) is left justified. 
 Only the title (if selected) is centered. This can be seen on figure 
 6.1: Schematic of letter paper's pseudo lengths.
 So I don't really understand your request: do you want the title to
 be left justified?

  I've attached an example. As you can see, setting
subject=afteropening cause the object to be centered in the page. What
i'd like to have is a left-aligned subject line, exactly as it's with
subject=beforeopening

Thanks,
  Giovanni

newfile1.pdf
Description: Adobe PDF document

change subject alignment in letter koma-script v.2

[Giovanni Bacci]

  Hi list. I've a problem non strictly about lyx, but i hope to get an
answer, maybe useful for other lyxer too.
Anyway, I'd like to know if it's possible to change subject alignment
in a letter koma-script v.2 class. As an option i can only choose
{before,after}opening and titled/untitled. Both of them came with
a center aligned text. But what i'd like to obtain is a left justified
alignment. I've googled a bit, but without finding any clue.
  Any hints?

Thanks,
  Giovanni

Re: change subject alignment in letter koma-script v.2

[Jean-Marie Pacquet]

Giovanni Bacci a écrit :

[...]
Anyway, I'd like to know if it's possible to change subject alignment
in a letter koma-script v.2 class. As an option i can only choose
{before,after}opening and titled/untitled. Both of them came with
a center aligned text. But what i'd like to obtain is a left justified
alignment. I've googled a bit, but without finding any clue.
  Any hints?
  
Default subject (i.e. beforeopening and untitled) is left justified. 
Only the title (if selected) is centered. This can be seen on figure 
6.1: Schematic of letter paper's pseudo lengths.
So I don't really understand your request: do you want the title to be 
left justified?

--
jmp

Re: change subject alignment in letter koma-script v.2

[Giovanni Bacci]

  domenica 14 febbraio 2010, 22:26, Jean-Marie Pacquet:

 Default subject (i.e. beforeopening and untitled) is left justified. 
 Only the title (if selected) is centered. This can be seen on figure 
 6.1: Schematic of letter paper's pseudo lengths.
 So I don't really understand your request: do you want the title to
 be left justified?

  I've attached an example. As you can see, setting
subject=afteropening cause the object to be centered in the page. What
i'd like to have is a left-aligned subject line, exactly as it's with
subject=beforeopening

Thanks,
  Giovanni

newfile1.pdf
Description: Adobe PDF document

change subject alignment in letter koma-script v.2

[Giovanni Bacci]

  Hi list. I've a problem non strictly about lyx, but i hope to get an
answer, maybe useful for other lyxer too.
Anyway, I'd like to know if it's possible to change subject alignment
in a letter koma-script v.2 class. As an option i can only choose
{before,after}opening and titled/untitled. Both of them came with
a center aligned text. But what i'd like to obtain is a left justified
alignment. I've googled a bit, but without finding any clue.
  Any hints?

Thanks,
  Giovanni

Re: change subject alignment in letter koma-script v.2

[Jean-Marie Pacquet]

Giovanni Bacci a écrit :

[...]
Anyway, I'd like to know if it's possible to change subject alignment
in a letter koma-script v.2 class. As an option i can only choose
{before,after}opening and titled/untitled. Both of them came with
a center aligned text. But what i'd like to obtain is a left justified
alignment. I've googled a bit, but without finding any clue.
  Any hints?
  
Default subject (i.e. beforeopening and untitled) is left justified. 
Only the title (if selected) is centered. This can be seen on figure 
6.1: Schematic of letter paper's pseudo lengths.
So I don't really understand your request: do you want the title to be 
left justified?

--
jmp

Re: change subject alignment in letter koma-script v.2

[Giovanni Bacci]

  domenica 14 febbraio 2010, 22:26, Jean-Marie Pacquet:

> Default subject (i.e. beforeopening and untitled) is left justified. 
> Only the title (if selected) is centered. This can be seen on figure 
> 6.1: Schematic of letter paper's pseudo lengths.
> So I don't really understand your request: do you want the title to
> be left justified?

  I've attached an example. As you can see, setting
subject=afteropening cause the object to be centered in the page. What
i'd like to have is a left-aligned subject line, exactly as it's with
subject=beforeopening

Thanks,
  Giovanni

newfile1.pdf
Description: Adobe PDF document

Re: [Survey] Explicit subject tag on this list

[Manveru]

2009/9/17 Andre Poenitz andre.poen...@mathematik.tu-chemnitz.de

 [...]

 That's not really surprising for a page that needs creating an account.
 I am even surprised that 36 people voted...

 Andre'


I am surprised you said that. I've tested and voting was possible without
logging in. I've just enter the survey from a PC that had never been on
polldaddy.com and the survey is open. And nobody else complains about
logging in.

-- 
Manveru
jabber: manv...@manveru.pl
gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Trevor Jenkins]

On Fri, Sep 18, 2009 at 7:56 AM, Manveru manv...@manveru.pl wrote:

 2009/9/17 Andre Poenitz andre.poen...@mathematik.tu-chemnitz.de

  That's not really surprising for a page that needs creating an account.
  I am even surprised that 36 people voted...

 I am surprised you said that. I've tested and voting was possible without
 logging in. I've just enter the survey from a PC that had never been on
 polldaddy.com and the survey is open. And nobody else complains about
 logging in.


Don't how you tested but it asked me to login before I could do anything
else. ergo I ignored the survey.

Regards, Trevor.
 Re: deemed!

Re: [Survey] Explicit subject tag on this list

[Manveru]

2009/9/17 Andre Poenitz andre.poen...@mathematik.tu-chemnitz.de

 [...]

 That's not really surprising for a page that needs creating an account.
 I am even surprised that 36 people voted...

 Andre'


I am surprised you said that. I've tested and voting was possible without
logging in. I've just enter the survey from a PC that had never been on
polldaddy.com and the survey is open. And nobody else complains about
logging in.

-- 
Manveru
jabber: manv...@manveru.pl
gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Trevor Jenkins]

On Fri, Sep 18, 2009 at 7:56 AM, Manveru manv...@manveru.pl wrote:

 2009/9/17 Andre Poenitz andre.poen...@mathematik.tu-chemnitz.de

  That's not really surprising for a page that needs creating an account.
  I am even surprised that 36 people voted...

 I am surprised you said that. I've tested and voting was possible without
 logging in. I've just enter the survey from a PC that had never been on
 polldaddy.com and the survey is open. And nobody else complains about
 logging in.


Don't how you tested but it asked me to login before I could do anything
else. ergo I ignored the survey.

Regards, Trevor.
 Re: deemed!

Re: [Survey] Explicit subject tag on this list

[Manveru]

2009/9/17 Andre Poenitz 

> [...]
>
> That's not really surprising for a page that needs creating an account.
> I am even surprised that 36 people voted...
>
> Andre'
>

I am surprised you said that. I've tested and voting was possible without
logging in. I've just enter the survey from a PC that had never been on
polldaddy.com and the survey is open. And nobody else complains about
logging in.

-- 
Manveru
jabber: manv...@manveru.pl
gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Trevor Jenkins]

On Fri, Sep 18, 2009 at 7:56 AM, Manveru  wrote:

> 2009/9/17 Andre Poenitz 
>
> > That's not really surprising for a page that needs creating an account.
> > I am even surprised that 36 people voted...
>
> I am surprised you said that. I've tested and voting was possible without
> logging in. I've just enter the survey from a PC that had never been on
> polldaddy.com and the survey is open. And nobody else complains about
> logging in.


Don't how you tested but it asked me to login before I could do anything
else. ergo I ignored the survey.

Regards, Trevor.
<>< Re: deemed!

Re: [Survey] Explicit subject tag on this list

[Manveru]

2009/9/7 Manveru manv...@manveru.pl

 Hi LyXers,

 I created a survey about explicit subject tagging:
 http://surveys.polldaddy.com/s/F47471D51261D0F9/

 Feel welcome to fill the answers. Please do not reply to this message.

 --
 Manveru
 jabber: manv...@manveru.pl
 gg: 1624001
   http://www.manveru.pl


 Q.1 Do you want explicit mark in subject line?  [image: More Details]
http://polldaddy.com/surveys/report-multiple.php?f=174199q=550622qt=400

Answer Count

 No, I do not want explicit mark in subject line.   24 (67%)

 Yes, I want explicit mark in subject line.   10 (28%)

 I do not have opinion about this.   2 (6%)

 People who answered question:
  *36* (100%)
Not a lot of people answered this survey.

-- 
Manveru
jabber: manv...@manveru.pl
gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Julio Rojas]

Not a lot of people interested on the subject???
-
Julio Rojas
jcredbe...@gmail.com



On Thu, Sep 17, 2009 at 3:09 PM, Manveru manv...@manveru.pl wrote:
 2009/9/7 Manveru manv...@manveru.pl

 Hi LyXers,

 I created a survey about explicit subject tagging:
 http://surveys.polldaddy.com/s/F47471D51261D0F9/

 Feel welcome to fill the answers. Please do not reply to this message.

 --
 Manveru
 jabber: manv...@manveru.pl
     gg: 1624001
   http://www.manveru.pl


  Q.1 Do you want explicit mark in subject line?  [image: More Details]
 http://polldaddy.com/surveys/report-multiple.php?f=174199q=550622qt=400

 Answer Count

  No, I do not want explicit mark in subject line.   24 (67%)

  Yes, I want explicit mark in subject line.   10 (28%)

  I do not have opinion about this.   2 (6%)

  People who answered question:
  *36* (100%)
 Not a lot of people answered this survey.

 --
 Manveru
 jabber: manv...@manveru.pl
    gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Kenward Vaughan]

On Thu, 2009-09-17 at 17:52 +0200, Julio Rojas wrote:
 Not a lot of people interested on the subject???

I went ahead and took the survey (no opinion). 

I wanted to point out that filtering the list is easy without such a
catch. I have evolution check the recipients for lyx-users which snags
nearly everything.

I'm sorry if I'm simply repeating what others may have said.  I have not
followed the thread at all... :(


Kenward
-- 
Perhaps the most valuable result of all education is the ability to
make yourself do the thing you have to do, when it ought to be done,
whether you like it or not; it is the first lesson that ought to be
learned; and however early a man's training begins, it is probably the
last lesson that he learns thoroughly.

Thomas Henry Huxley

Re: [Survey] Explicit subject tag on this list

[Andre Poenitz]

On Thu, Sep 17, 2009 at 03:09:58PM +0200, Manveru wrote:
  I created a survey about explicit subject tagging:
  http://surveys.polldaddy.com/s/F47471D51261D0F9/
 
  Feel welcome to fill the answers. Please do not reply to this message.
 
  --
  Manveru
  jabber: manv...@manveru.pl
  gg: 1624001
http://www.manveru.pl
 
 
  Q.1 Do you want explicit mark in subject line?  [image: More Details]
 http://polldaddy.com/surveys/report-multiple.php?f=174199q=550622qt=400
 
 Answer Count
 
  No, I do not want explicit mark in subject line.   24 (67%)
 
  Yes, I want explicit mark in subject line.   10 (28%)
 
  I do not have opinion about this.   2 (6%)
 
  People who answered question:
   *36* (100%)
 Not a lot of people answered this survey.

That's not really surprising for a page that needs creating an account.
I am even surprised that 36 people voted...

Andre'

Re: [Survey] Explicit subject tag on this list

[Manveru]

2009/9/7 Manveru manv...@manveru.pl

 Hi LyXers,

 I created a survey about explicit subject tagging:
 http://surveys.polldaddy.com/s/F47471D51261D0F9/

 Feel welcome to fill the answers. Please do not reply to this message.

 --
 Manveru
 jabber: manv...@manveru.pl
 gg: 1624001
   http://www.manveru.pl


 Q.1 Do you want explicit mark in subject line?  [image: More Details]
http://polldaddy.com/surveys/report-multiple.php?f=174199q=550622qt=400

Answer Count

 No, I do not want explicit mark in subject line.   24 (67%)

 Yes, I want explicit mark in subject line.   10 (28%)

 I do not have opinion about this.   2 (6%)

 People who answered question:
  *36* (100%)
Not a lot of people answered this survey.

-- 
Manveru
jabber: manv...@manveru.pl
gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Julio Rojas]

Not a lot of people interested on the subject???
-
Julio Rojas
jcredbe...@gmail.com



On Thu, Sep 17, 2009 at 3:09 PM, Manveru manv...@manveru.pl wrote:
 2009/9/7 Manveru manv...@manveru.pl

 Hi LyXers,

 I created a survey about explicit subject tagging:
 http://surveys.polldaddy.com/s/F47471D51261D0F9/

 Feel welcome to fill the answers. Please do not reply to this message.

 --
 Manveru
 jabber: manv...@manveru.pl
     gg: 1624001
   http://www.manveru.pl


  Q.1 Do you want explicit mark in subject line?  [image: More Details]
 http://polldaddy.com/surveys/report-multiple.php?f=174199q=550622qt=400

 Answer Count

  No, I do not want explicit mark in subject line.   24 (67%)

  Yes, I want explicit mark in subject line.   10 (28%)

  I do not have opinion about this.   2 (6%)

  People who answered question:
  *36* (100%)
 Not a lot of people answered this survey.

 --
 Manveru
 jabber: manv...@manveru.pl
    gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Kenward Vaughan]

On Thu, 2009-09-17 at 17:52 +0200, Julio Rojas wrote:
 Not a lot of people interested on the subject???

I went ahead and took the survey (no opinion). 

I wanted to point out that filtering the list is easy without such a
catch. I have evolution check the recipients for lyx-users which snags
nearly everything.

I'm sorry if I'm simply repeating what others may have said.  I have not
followed the thread at all... :(


Kenward
-- 
Perhaps the most valuable result of all education is the ability to
make yourself do the thing you have to do, when it ought to be done,
whether you like it or not; it is the first lesson that ought to be
learned; and however early a man's training begins, it is probably the
last lesson that he learns thoroughly.

Thomas Henry Huxley

Re: [Survey] Explicit subject tag on this list

[Andre Poenitz]

On Thu, Sep 17, 2009 at 03:09:58PM +0200, Manveru wrote:
  I created a survey about explicit subject tagging:
  http://surveys.polldaddy.com/s/F47471D51261D0F9/
 
  Feel welcome to fill the answers. Please do not reply to this message.
 
  --
  Manveru
  jabber: manv...@manveru.pl
  gg: 1624001
http://www.manveru.pl
 
 
  Q.1 Do you want explicit mark in subject line?  [image: More Details]
 http://polldaddy.com/surveys/report-multiple.php?f=174199q=550622qt=400
 
 Answer Count
 
  No, I do not want explicit mark in subject line.   24 (67%)
 
  Yes, I want explicit mark in subject line.   10 (28%)
 
  I do not have opinion about this.   2 (6%)
 
  People who answered question:
   *36* (100%)
 Not a lot of people answered this survey.

That's not really surprising for a page that needs creating an account.
I am even surprised that 36 people voted...

Andre'

Re: [Survey] Explicit subject tag on this list

[Manveru]

2009/9/7 Manveru <manv...@manveru.pl>

> Hi LyXers,
>
> I created a survey about explicit subject tagging:
> http://surveys.polldaddy.com/s/F47471D51261D0F9/
>
> Feel welcome to fill the answers. Please do not reply to this message.
>
> --
> Manveru
> jabber: manv...@manveru.pl
> gg: 1624001
>   http://www.manveru.pl
>

 Q.1 Do you want explicit mark in subject line?  [image: More Details]
<http://polldaddy.com/surveys/report-multiple.php?f=174199=550622=400>

Answer Count

 No, I do not want explicit mark in subject line.   24 (67%)

 Yes, I want explicit mark in subject line.   10 (28%)

 I do not have opinion about this.   2 (6%)

 People who answered question:
  *36* (100%)
Not a lot of people answered this survey.

-- 
Manveru
jabber: manv...@manveru.pl
gg: 1624001
  http://www.manveru.pl

Re: [Survey] Explicit subject tag on this list

[Julio Rojas]

Not a lot of people interested on the subject???
-
Julio Rojas
jcredbe...@gmail.com



On Thu, Sep 17, 2009 at 3:09 PM, Manveru <manv...@manveru.pl> wrote:
> 2009/9/7 Manveru <manv...@manveru.pl>
>
>> Hi LyXers,
>>
>> I created a survey about explicit subject tagging:
>> http://surveys.polldaddy.com/s/F47471D51261D0F9/
>>
>> Feel welcome to fill the answers. Please do not reply to this message.
>>
>> --
>> Manveru
>> jabber: manv...@manveru.pl
>>     gg: 1624001
>>   http://www.manveru.pl
>>
>
>  Q.1 Do you want explicit mark in subject line?  [image: More Details]
> <http://polldaddy.com/surveys/report-multiple.php?f=174199=550622=400>
>
> Answer Count
>
>  No, I do not want explicit mark in subject line.   24 (67%)
>
>  Yes, I want explicit mark in subject line.   10 (28%)
>
>  I do not have opinion about this.   2 (6%)
>
>  People who answered question:
>  *36* (100%)
> Not a lot of people answered this survey.
>
> --
> Manveru
> jabber: manv...@manveru.pl
>    gg: 1624001
>  http://www.manveru.pl
>

Re: [Survey] Explicit subject tag on this list

[Kenward Vaughan]

On Thu, 2009-09-17 at 17:52 +0200, Julio Rojas wrote:
> Not a lot of people interested on the subject???

I went ahead and took the survey ("no opinion"). 

I wanted to point out that filtering the list is easy without such a
catch. I have evolution check the recipients for "lyx-users" which snags
nearly everything.

I'm sorry if I'm simply repeating what others may have said.  I have not
followed the thread at all... :(


Kenward
-- 
Perhaps the most valuable result of all education is the ability to
make yourself do the thing you have to do, when it ought to be done,
whether you like it or not; it is the first lesson that ought to be
learned; and however early a man's training begins, it is probably the
last lesson that he learns thoroughly.

Thomas Henry Huxley

Re: [Survey] Explicit subject tag on this list

[Andre Poenitz]

On Thu, Sep 17, 2009 at 03:09:58PM +0200, Manveru wrote:
> > I created a survey about explicit subject tagging:
> > http://surveys.polldaddy.com/s/F47471D51261D0F9/
> >
> > Feel welcome to fill the answers. Please do not reply to this message.
> >
> > --
> > Manveru
> > jabber: manv...@manveru.pl
> > gg: 1624001
> >   http://www.manveru.pl
> >
> 
>  Q.1 Do you want explicit mark in subject line?  [image: More Details]
> <http://polldaddy.com/surveys/report-multiple.php?f=174199=550622=400>
> 
> Answer Count
> 
>  No, I do not want explicit mark in subject line.   24 (67%)
> 
>  Yes, I want explicit mark in subject line.   10 (28%)
> 
>  I do not have opinion about this.   2 (6%)
> 
>  People who answered question:
>   *36* (100%)
> Not a lot of people answered this survey.

That's not really surprising for a page that needs creating an account.
I am even surprised that 36 people voted...

Andre'

nice digest reply Re: the [[Lyx] explicit mail subject] thread

[Todd Denniston]

Joe(theWordy)Philbrook wrote, On 12/23/-28158 02:59 PM:
 Note:	the quoted texts below are all liberally snipped... 
	for full context see the thread...

SNIP

Personally I don't think that's ever going to happen any more than I
think anybody will ever offer a list server with a smart digest option
that includes some kind of header like tag in each individual message
of the digest that can be used by a digest only subscriber to request a
personal resend of just those individual messages they wanted to reply
to. Which would provide a way for digest users to avoid messing with the
threaded message reply path.

Like I said, it ain't gonna happen... 


But wouldn't it be nice if I was wrong?


SNIP
At least on this bit I think there is a way to get the _effect_ you want, 
differently.

This happens to be a reply to the lyx-users digest...
the lyx-users digest is sent as a mime digest and with Thunderbird the user can simply double click 
on the message of interest (each message is listed as a mime attachment in the digest) which opens 
the message as a pretty much normal message and then hit reply.
For some reason I had to take an extra Re: off the subject line, and I felt that SNIPing the message 
was reasonable, but this was the extent of the editing I HAD to do.


for most mailman lists you can either select mime digests from the HTML interface or send `set 
digest mime` (with an authenticate line) to the list-request address

see section 8 of
http://wiki.list.org/display/DOC/Mailman+2.1+Members+Manual
for some more details.

Using this knowledge in another email client is an exorcise left to the reader and other list 
members. :)


Lyx on Linux, with out header munging. :0
Boy we have stepped off topic. :)
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

nice digest reply Re: the [[Lyx] explicit mail subject] thread

[Todd Denniston]

Joe(theWordy)Philbrook wrote, On 12/23/-28158 02:59 PM:
 Note:	the quoted texts below are all liberally snipped... 
	for full context see the thread...

SNIP

Personally I don't think that's ever going to happen any more than I
think anybody will ever offer a list server with a smart digest option
that includes some kind of header like tag in each individual message
of the digest that can be used by a digest only subscriber to request a
personal resend of just those individual messages they wanted to reply
to. Which would provide a way for digest users to avoid messing with the
threaded message reply path.

Like I said, it ain't gonna happen... 


But wouldn't it be nice if I was wrong?


SNIP
At least on this bit I think there is a way to get the _effect_ you want, 
differently.

This happens to be a reply to the lyx-users digest...
the lyx-users digest is sent as a mime digest and with Thunderbird the user can simply double click 
on the message of interest (each message is listed as a mime attachment in the digest) which opens 
the message as a pretty much normal message and then hit reply.
For some reason I had to take an extra Re: off the subject line, and I felt that SNIPing the message 
was reasonable, but this was the extent of the editing I HAD to do.


for most mailman lists you can either select mime digests from the HTML interface or send `set 
digest mime` (with an authenticate line) to the list-request address

see section 8 of
http://wiki.list.org/display/DOC/Mailman+2.1+Members+Manual
for some more details.

Using this knowledge in another email client is an exorcise left to the reader and other list 
members. :)


Lyx on Linux, with out header munging. :0
Boy we have stepped off topic. :)
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

nice digest reply Re: the [[Lyx] explicit mail subject] thread

[Todd Denniston]

Joe(theWordy)Philbrook wrote, On 12/23/-28158 02:59 PM:
 Note:	the quoted texts below are all liberally "snipped"... 
	for full context see the thread...



Personally I don't think that's ever going to happen any more than I
think anybody will ever offer a list server with a smart digest option
that includes some kind of "header like" tag in each individual message
of the digest that can be used by a digest only subscriber to request a
personal resend of just those individual messages they wanted to reply
to. Which would provide a way for digest users to avoid messing with the
threaded message reply path.

Like I said, it ain't gonna happen... 


But wouldn't it be nice if I was wrong?



At least on this bit I think there is a way to get the _effect_ you want, 
differently.

This happens to be a reply to the lyx-users digest...
the lyx-users digest is sent as a mime digest and with Thunderbird the user can simply double click 
on the message of interest (each message is listed as a mime attachment in the digest) which opens 
the message as a pretty much normal message and then hit reply.
For some reason I had to take an extra Re: off the subject line, and I felt that SNIPing the message 
was reasonable, but this was the extent of the editing I HAD to do.


for most mailman lists you can either select mime digests from the HTML interface or send `set 
digest mime` (with an authenticate line) to the list-request address

see section 8 of
http://wiki.list.org/display/DOC/Mailman+2.1+Members+Manual
for some more details.

Using this knowledge in another email client is an exorcise left to the reader and other list 
members. :)


Lyx on Linux, with out header munging. :0
Boy we have stepped off topic. :)
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

Re: How many use Linux: was[LyX] explicit mail subject

[Jonathan Ryshpan]

It would be interesting for the Lyx website to collect this info.

I assume the posting contains a typo, and should read:
They can record OS statistics, **unless** they are hidden by the user.

(When top posting starts, let top posting continue (8-).

jon

On Fri, 2009-09-11 at 21:06 +0200, Murat Yildizoglu wrote:
 Well, Lyx Website hit statistics could give a very rough idea maybe.
 They can record OS statistics, if they are hidden by the user.
 
 2009/9/11 Andrew Sullivan a...@shinkuro.com:
  On Fri, Sep 11, 2009 at 11:42:22AM -0400, Steve Litt wrote:
  assumption. Does anyone know the percentages of LyX users on:
 
  Given that it is free software and therefore nearly impossible to know
  what the user community size is, knowing the relative sizes of
  segments of the population seems to be a little ambitious.

Re: How many use Linux: was[LyX] explicit mail subject

[Jonathan Ryshpan]

It would be interesting for the Lyx website to collect this info.

I assume the posting contains a typo, and should read:
They can record OS statistics, **unless** they are hidden by the user.

(When top posting starts, let top posting continue (8-).

jon

On Fri, 2009-09-11 at 21:06 +0200, Murat Yildizoglu wrote:
 Well, Lyx Website hit statistics could give a very rough idea maybe.
 They can record OS statistics, if they are hidden by the user.
 
 2009/9/11 Andrew Sullivan a...@shinkuro.com:
  On Fri, Sep 11, 2009 at 11:42:22AM -0400, Steve Litt wrote:
  assumption. Does anyone know the percentages of LyX users on:
 
  Given that it is free software and therefore nearly impossible to know
  what the user community size is, knowing the relative sizes of
  segments of the population seems to be a little ambitious.

Re: How many use Linux: was[LyX] explicit mail subject

[Jonathan Ryshpan]

It would be interesting for the Lyx website to collect this info.

I assume the posting contains a typo, and should read:
They can record OS statistics, **unless** they are hidden by the user.

(When top posting starts, let top posting continue (8-).

jon

On Fri, 2009-09-11 at 21:06 +0200, Murat Yildizoglu wrote:
> Well, Lyx Website hit statistics could give a very rough idea maybe.
> They can record OS statistics, if they are hidden by the user.
> 
> 2009/9/11 Andrew Sullivan :
> > On Fri, Sep 11, 2009 at 11:42:22AM -0400, Steve Litt wrote:
> >> assumption. Does anyone know the percentages of LyX users on:
> >
> > Given that it is free software and therefore nearly impossible to know
> > what the user community size is, knowing the relative sizes of
> > segments of the population seems to be a little ambitious.

Re: the [[Lyx] explicit mail subject] thread

[Joe(theWordy)Philbrook]

 Note:  the quoted texts below are all liberally snipped... 
for full context see the thread...

It would appear that on Sep 2, Delta moins did innocently start this thread:

 there is no keyword in the mail subject that tell people
 this comes from the Lyx users list. It's very messing because
 you cannot filter the mails efficiently.

 I don't know if it should be done automaticaly by the list
 system or if people that send mail should add something like
 I've done for example manually.

It would appear that on Sep 2, Manveru did say:

 Just sort or filter your e-mails by From: field from header of your
 mails. All e-mail clients support this. At least all good e-mail
 clients.


It would appear that on Sep 2, Helge Hafting did say:

 Delta moins wrote:
  Ok I knew this solution and yeah it works. I will use it.
  If I'm the only for who an explicit mail subject lacks it's ok.
 
 There are more who wants this, but also quite a few who don't want it. The
 mail can be sorted by other headers than Subject.
 Once the lyx mailing list arrives in a folder of its own anyway, having [LyX]
 in every subject becomes somewhat irritating.

From my point of view that would becomes *_VERY_* irritating...
I subscribe to a list that does do this And I wish they didn't.

But like Helge: Who on Sep 9, also did say:

= This list was created without subject manipulation, please just respect that.
= I subscribe to some lists that do mangle the subject. I don't like it, but I
= don't request a change. It is the list maintainter's choice to make.

I don't ask them to change it... I just sigh a lot...


It would appear that on Sep 2, Murray Eisenberg did say:

 I agree with the O.P. on this. This is something that, surely, is easily fixed
 at the server end, so that each message going out from the server has, say,
 [LyX] prepended to the subject.
 
 Many other mailing lists do this. There should be no need for the subscribers
 to have to filter.

It would appear that on Sep 2, Christian Ridderström did say:

 On Wed, 2 Sep 2009, Manveru wrote:
  There is many voices in favour of such feature. But not a lot of
  people vote against. If may I suggest, maybe someone can create a
  poll/survey for LyX users list subscribers.
 
 I think the many voices that don't like it are tired of having this
 recurring discussion  ;-)

I suspect that just as many mailing lists differ on this as do on the
Reply-To: munging issue somebody mentioned... Because there is such
a thing as free choice on operating systems, mail servers, and
mail clients, neither choice {for either issue} can possibly be a
one 'size' pleases all solution. And like top vs bottom posting
or the infamous vi vs emacs debates, these are all holy wars that
simply can NOT be forever put to rest...

EXCEPT that, at least in the case of Subject: tagging (IE [LyX]) then 
there is the potential for it to become a non-issue. All it would take 
is for the list server(s) to evolve to include a configuration choice
for tagged, or non tagged Subject: headers, just as there is usually a
choice for digest or non-digest... 

Personally I don't think that's ever going to happen any more than I
think anybody will ever offer a list server with a smart digest option
that includes some kind of header like tag in each individual message
of the digest that can be used by a digest only subscriber to request a
personal resend of just those individual messages they wanted to reply
to. Which would provide a way for digest users to avoid messing with the
threaded message reply path.

Like I said, it ain't gonna happen... 

But wouldn't it be nice if I was wrong?

sigh


It would appear that on Sep 2, Rich Shepard did say:

   As long as I've subscribed to this mail list, all messages have the
 subject line prefixed with [Lyx]. Perhaps that's because all I've used is
 procmail and (al)pine as my MUA, but it's always been there.

Hmmmnnn I myself use procmail (with only a minimal understanding of it)
I would be very interested in seeing your ~/.procmail.rc recipe for the
lyx mailing list...

And if perchance, you happen to know how I could use procmail to
strip such tags from the messages I get from lists that do add them,
would you kindly explain it to me???

Because if I knew how to do that I'd no longer mind it when some list
manager decides to add Subject: tags to a list I'm reading...


-- 
|   ~^~   ~^~
|   *   *  Joe (theWordy) Philbrook
|   ^ J(tWdy)P
| \___/  jtw...@ttlc.net

Re: the [[Lyx] explicit mail subject] thread

[Joe(theWordy)Philbrook]

 Note:  the quoted texts below are all liberally snipped... 
for full context see the thread...

It would appear that on Sep 2, Delta moins did innocently start this thread:

 there is no keyword in the mail subject that tell people
 this comes from the Lyx users list. It's very messing because
 you cannot filter the mails efficiently.

 I don't know if it should be done automaticaly by the list
 system or if people that send mail should add something like
 I've done for example manually.

It would appear that on Sep 2, Manveru did say:

 Just sort or filter your e-mails by From: field from header of your
 mails. All e-mail clients support this. At least all good e-mail
 clients.


It would appear that on Sep 2, Helge Hafting did say:

 Delta moins wrote:
  Ok I knew this solution and yeah it works. I will use it.
  If I'm the only for who an explicit mail subject lacks it's ok.
 
 There are more who wants this, but also quite a few who don't want it. The
 mail can be sorted by other headers than Subject.
 Once the lyx mailing list arrives in a folder of its own anyway, having [LyX]
 in every subject becomes somewhat irritating.

From my point of view that would becomes *_VERY_* irritating...
I subscribe to a list that does do this And I wish they didn't.

But like Helge: Who on Sep 9, also did say:

= This list was created without subject manipulation, please just respect that.
= I subscribe to some lists that do mangle the subject. I don't like it, but I
= don't request a change. It is the list maintainter's choice to make.

I don't ask them to change it... I just sigh a lot...


It would appear that on Sep 2, Murray Eisenberg did say:

 I agree with the O.P. on this. This is something that, surely, is easily fixed
 at the server end, so that each message going out from the server has, say,
 [LyX] prepended to the subject.
 
 Many other mailing lists do this. There should be no need for the subscribers
 to have to filter.

It would appear that on Sep 2, Christian Ridderström did say:

 On Wed, 2 Sep 2009, Manveru wrote:
  There is many voices in favour of such feature. But not a lot of
  people vote against. If may I suggest, maybe someone can create a
  poll/survey for LyX users list subscribers.
 
 I think the many voices that don't like it are tired of having this
 recurring discussion  ;-)

I suspect that just as many mailing lists differ on this as do on the
Reply-To: munging issue somebody mentioned... Because there is such
a thing as free choice on operating systems, mail servers, and
mail clients, neither choice {for either issue} can possibly be a
one 'size' pleases all solution. And like top vs bottom posting
or the infamous vi vs emacs debates, these are all holy wars that
simply can NOT be forever put to rest...

EXCEPT that, at least in the case of Subject: tagging (IE [LyX]) then 
there is the potential for it to become a non-issue. All it would take 
is for the list server(s) to evolve to include a configuration choice
for tagged, or non tagged Subject: headers, just as there is usually a
choice for digest or non-digest... 

Personally I don't think that's ever going to happen any more than I
think anybody will ever offer a list server with a smart digest option
that includes some kind of header like tag in each individual message
of the digest that can be used by a digest only subscriber to request a
personal resend of just those individual messages they wanted to reply
to. Which would provide a way for digest users to avoid messing with the
threaded message reply path.

Like I said, it ain't gonna happen... 

But wouldn't it be nice if I was wrong?

sigh


It would appear that on Sep 2, Rich Shepard did say:

   As long as I've subscribed to this mail list, all messages have the
 subject line prefixed with [Lyx]. Perhaps that's because all I've used is
 procmail and (al)pine as my MUA, but it's always been there.

Hmmmnnn I myself use procmail (with only a minimal understanding of it)
I would be very interested in seeing your ~/.procmail.rc recipe for the
lyx mailing list...

And if perchance, you happen to know how I could use procmail to
strip such tags from the messages I get from lists that do add them,
would you kindly explain it to me???

Because if I knew how to do that I'd no longer mind it when some list
manager decides to add Subject: tags to a list I'm reading...


-- 
|   ~^~   ~^~
|   *   *  Joe (theWordy) Philbrook
|   ^ J(tWdy)P
| \___/  jtw...@ttlc.net

Re: the [[Lyx] explicit mail subject] thread

[Joe(theWordy)Philbrook]

 Note:  the quoted texts below are all liberally "snipped"... 
for full context see the thread...

It would appear that on Sep 2, Delta moins did innocently start this thread:

> there is no keyword in the mail subject that tell people
> "this comes from the Lyx users list". It's very messing because
> you cannot filter the mails efficiently.

> I don't know if it should be done automaticaly by the list
> system or if people that send mail should add something like
> I've done for example manually.

It would appear that on Sep 2, Manveru did say:

> Just sort or filter your e-mails by From: field from header of your
> mails. All e-mail clients support this. At least all good e-mail
> clients.


It would appear that on Sep 2, Helge Hafting did say:

> Delta moins wrote:
> > Ok I knew this solution and yeah it works. I will use it.
> > If I'm the only for who an explicit mail subject lacks it's ok.
> 
> There are more who wants this, but also quite a few who don't want it. The
> mail can be sorted by other headers than "Subject".
> Once the lyx mailing list arrives in a folder of its own anyway, having "[LyX]
> in every subject becomes somewhat irritating.

>From my point of view that would "becomes *_VERY_* irritating"...
I subscribe to a list that does do this And I wish they didn't.

But like Helge: Who on Sep 9, also did say:

=> This list was created without subject manipulation, please just respect that.
=> I subscribe to some lists that do mangle the subject. I don't like it, but I
=> don't request a change. It is the list maintainter's choice to make.

I don't ask them to change it... I just sigh a lot...


It would appear that on Sep 2, Murray Eisenberg did say:

> I agree with the O.P. on this. This is something that, surely, is easily fixed
> at the server end, so that each message going out from the server has, say,
> "[LyX]" prepended to the subject.
> 
> Many other mailing lists do this. There should be no need for the subscribers
> to have to filter.

It would appear that on Sep 2, Christian Ridderström did say:

> On Wed, 2 Sep 2009, Manveru wrote:
> > There is many voices in favour of such feature. But not a lot of
> > people vote against. If may I suggest, maybe someone can create a
> > poll/survey for LyX users list subscribers.
> 
> I think the many voices that don't like it are tired of having this
> recurring discussion  ;-)

I suspect that just as many mailing lists differ on this as do on the
"Reply-To:" munging issue somebody mentioned... Because there is such
a thing as free choice on operating systems, mail servers, and
mail clients, neither choice {for either issue} can possibly be a
"one 'size' pleases all" solution. And like "top vs bottom" posting
or the infamous "vi vs emacs" debates, these are all "holy wars" that
simply can NOT be forever put to rest...

EXCEPT that, at least in the case of "Subject: tagging" (IE [LyX]) then 
there is the potential for it to become a non-issue. All it would take 
is for the list server(s) to evolve to include a configuration choice
for tagged, or non tagged Subject: headers, just as there is usually a
choice for digest or non-digest... 

Personally I don't think that's ever going to happen any more than I
think anybody will ever offer a list server with a smart digest option
that includes some kind of "header like" tag in each individual message
of the digest that can be used by a digest only subscriber to request a
personal resend of just those individual messages they wanted to reply
to. Which would provide a way for digest users to avoid messing with the
threaded message reply path.

Like I said, it ain't gonna happen... 

But wouldn't it be nice if I was wrong?




It would appear that on Sep 2, Rich Shepard did say:

>   As long as I've subscribed to this mail list, all messages have the
> subject line prefixed with [Lyx]. Perhaps that's because all I've used is
> procmail and (al)pine as my MUA, but it's always been there.

Hmmmnnn I myself use procmail (with only a minimal understanding of it)
I would be very interested in seeing your ~/.procmail.rc recipe for the
lyx mailing list...

And if perchance, you happen to know how I could use procmail to
strip such tags from the messages I get from lists that do add them,
would you kindly explain it to me???

Because if I knew how to do that I'd no longer mind it when some list
manager decides to add Subject: tags to a list I'm reading...


-- 
|   ~^~   ~^~
|   <*>   <*>  Joe (theWordy) Philbrook
|   ^ J(tWdy)P
| \___/  <<jtw...@ttlc.net>>

Re: [Lyx] explicit mail subject

[Trevor Jenkins]

On Wed, Sep 9, 2009 at 3:19 PM, Helge Hafting helge.haft...@hist.no wrote:

 Murray Eisenberg wrote:

 I agree with the O.P. on this. This is something that, surely, is easily
 fixed at the server end, so that each message going out from the server has,
 say, [LyX] prepended to the subject.


 But we don't want that, so please don't wreck it on the server.
 If you want to see [LyX], set up your own mail software to
 add this to the mail that gets delivered to you.

Easy to do on a UNIX box with procmail; I do it all the time for other
lists. But how do I do this with GMail which is what I use for reading lyx
users? Their label scheme isn't as useful as Subject: line tags like [LyX].


  Many other mailing lists do this. There should be no need for the
 subscribers to have to filter.



 And many other mailing lists don't mess with the subject. There should be
 no need for users to suffer the messed-up headers.
 Nobody _has_ to filter. If they want the mail in a single folder,
 they can have that. Those of us who subscribe to several lists with some
 volume, usually set up filtering to avoid a huge mess. And it'd be a huge
 mess even if the subject fields were abused.

 This list was created without subject manipulation, please just respect
 that. I subscribe to some lists that do mangle the subject. I don't like it,
 but I don't request a change. It is the list maintainter's choice to make.


Then you'd hate that on my Linux workstation I mung the headers of *all*
incoming mail from lists to set a Reply-to back to the list, which is what I
believe how *all* lists should be set up in the first place.Plus munging in
Subject: line tag. Once those messages are on my machine they are mine and
I'll do what ever I like to them. I don't care what or how the list owner
set it up on my Linux machines I'll force all those message to be the way I
expect them to be.

If only GMail were as flexible so the headers of messages to this list could
be munged with an explicit Reply-to: header.

Regards, Trevor.

 Re: deemed!

Re: [Lyx] explicit mail subject

[Julio Rojas]

 Easy to do on a UNIX box with procmail; I do it all the time for other
 lists. But how do I do this with GMail which is what I use for reading lyx
 users? Their label scheme isn't as useful as Subject: line tags like [LyX].

It's also easy. Besides of the tag, you can skip messages from lyx
users from the inbox:

Matches: to:(lyx-users)
Do this: Skip Inbox, Apply label Lyx
-
Julio Rojas
jcredbe...@gmail.com

Re: [Lyx] explicit mail subject

[Murray Eisenberg]

Likewise, I find no way to modify the header in Thunderbird (at least 
the Windows Version), which is a common e-mail client.


In Thunderbird, I can, of course, set up a filter which looks at the CC: 
field and sends any lyx-users@lists.lyx.org messages to a separate folder.


But I don't want to bury the messages to a separate folder. I merely 
want to be able to tell a a glance from the Subject field that LyX is 
the subject.


Trevor Jenkins wrote:

On Wed, Sep 9, 2009 at 3:19 PM, Helge Hafting helge.haft...@hist.no wrote:


Murray Eisenberg wrote:


I agree with the O.P. on this. This is something that, surely, is easily
fixed at the server end, so that each message going out from the server has,
say, [LyX] prepended to the subject.


But we don't want that, so please don't wreck it on the server.
If you want to see [LyX], set up your own mail software to
add this to the mail that gets delivered to you.


Easy to do on a UNIX box with procmail; I do it all the time for other
lists. But how do I do this with GMail which is what I use for reading lyx
users? Their label scheme isn't as useful as Subject: line tags like [LyX].



 Many other mailing lists do this. There should be no need for the

subscribers to have to filter.





And many other mailing lists don't mess with the subject. There should be
no need for users to suffer the messed-up headers.
Nobody _has_ to filter. If they want the mail in a single folder,
they can have that. Those of us who subscribe to several lists with some
volume, usually set up filtering to avoid a huge mess. And it'd be a huge
mess even if the subject fields were abused.

This list was created without subject manipulation, please just respect
that. I subscribe to some lists that do mangle the subject. I don't like it,
but I don't request a change. It is the list maintainter's choice to make.



Then you'd hate that on my Linux workstation I mung the headers of *all*
incoming mail from lists to set a Reply-to back to the list, which is what I
believe how *all* lists should be set up in the first place.Plus munging in
Subject: line tag. Once those messages are on my machine they are mine and
I'll do what ever I like to them. I don't care what or how the list owner
set it up on my Linux machines I'll force all those message to be the way I
expect them to be.

If only GMail were as flexible so the headers of messages to this list could
be munged with an explicit Reply-to: header.

Regards, Trevor.

 Re: deemed!



--
Murray Eisenberg mur...@math.umass.edu
Mathematics  Statistics Dept.
Lederle Graduate Research Tower  phone 413 549-1020 (H)
University of Massachusetts413 545-2859 (W)
710 North Pleasant Streetfax   413 545-1801
Amherst, MA 01003-9305

Re: [Lyx] explicit mail subject

[Murray Eisenberg]

But only a fraction of folks use Unix/Linux!

Julio Rojas wrote:

Easy to do on a UNIX box with procmail; I do it all the time for other
lists. But how do I do this with GMail which is what I use for reading lyx
users? Their label scheme isn't as useful as Subject: line tags like [LyX].


It's also easy. Besides of the tag, you can skip messages from lyx
users from the inbox:

Matches: to:(lyx-users)
Do this: Skip Inbox, Apply label Lyx



--
Murray Eisenberg mur...@math.umass.edu
Mathematics  Statistics Dept.
Lederle Graduate Research Tower  phone 413 549-1020 (H)
University of Massachusetts413 545-2859 (W)
710 North Pleasant Streetfax   413 545-1801
Amherst, MA 01003-9305

Re: [Lyx] explicit mail subject

[Sam Liddicott]

* Murray Eisenberg wrote, On 11/09/09 14:45:
Likewise, I find no way to modify the header in Thunderbird (at least 
the Windows Version), which is a common e-mail client.


In Thunderbird, I can, of course, set up a filter which looks at the CC: 
field and sends any lyx-users@lists.lyx.org messages to a separate 
folder.


But I don't want to bury the messages to a separate folder. I merely 
want to be able to tell a a glance from the Subject field that LyX is 
the subject.



There is also the difference between knowing that a message was sent TO 
lyx-users and whether you received a message FROM lyx-users (or were 
sent it directly).


Sam

Re: [Lyx] explicit mail subject

[Julio Rojas]

What I suggested was for Gmail not for any particular OS. Sorry for
not being clear.
-
Julio Rojas
jcredbe...@gmail.com



On Fri, Sep 11, 2009 at 3:58 PM, Murray Eisenberg mur...@math.umass.edu wrote:
 But only a fraction of folks use Unix/Linux!

 Julio Rojas wrote:

 Easy to do on a UNIX box with procmail; I do it all the time for other
 lists. But how do I do this with GMail which is what I use for reading
 lyx
 users? Their label scheme isn't as useful as Subject: line tags like
 [LyX].

 It's also easy. Besides of the tag, you can skip messages from lyx
 users from the inbox:

 Matches: to:(lyx-users)
 Do this: Skip Inbox, Apply label Lyx


 --
 Murray Eisenberg                     mur...@math.umass.edu
 Mathematics  Statistics Dept.
 Lederle Graduate Research Tower      phone 413 549-1020 (H)
 University of Massachusetts                413 545-2859 (W)
 710 North Pleasant Street            fax   413 545-1801
 Amherst, MA 01003-9305

How many use Linux: was[LyX] explicit mail subject

[Steve Litt]

On Friday 11 September 2009 09:58:04 Murray Eisenberg wrote:
 But only a fraction of folks use Unix/Linux!

I've always assumed that fraction was about 4/5 but never examined that 
assumption. Does anyone know the percentages of LyX users on:

Linux
Windows
Mac
BSD
Other

Just to start the ball rolling, I've always used LyX on Linux (since 2001) and 
am currently using it on Ubuntu 9.0.4.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt

Re: How many use Linux: was[LyX] explicit mail subject

[Paul A. Rubin]

Steve Litt wrote:

On Friday 11 September 2009 09:58:04 Murray Eisenberg wrote:

But only a fraction of folks use Unix/Linux!


I've always assumed that fraction was about 4/5 but never examined that 
assumption. Does anyone know the percentages of LyX users on:


Linux
Windows
Mac
BSD
Other

Just to start the ball rolling, I've always used LyX on Linux (since 2001) and 
am currently using it on Ubuntu 9.0.4.




Just to kick the ball out of bounds, how do you count cross-platform 
users?  I have it on one XP box and two Ubuntu boxes, and I use it 
heavily under both OSes.


When I first came across LyX (which goes back far enough that the only 
Windows version was a port that required Cygwin), Linux users vastly 
outnumbered Windows users.  From list traffic, I suspect Linux is still 
prevalent (followed by Windows, then Mac), but the vastly is likely no 
longer true.


/Paul

Re: How many use Linux: was[LyX] explicit mail subject

[Andrew Sullivan]

On Fri, Sep 11, 2009 at 11:42:22AM -0400, Steve Litt wrote:
 assumption. Does anyone know the percentages of LyX users on:

Given that it is free software and therefore nearly impossible to know
what the user community size is, knowing the relative sizes of
segments of the population seems to be a little ambitious.

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.

Re: How many use Linux: was[LyX] explicit mail subject

[Murat Yildizoglu]

Well, Lyx Website hit statistics could give a very rough idea maybe.
They can record OS statistics, if they are hidden by the user.

2009/9/11 Andrew Sullivan a...@shinkuro.com:
 On Fri, Sep 11, 2009 at 11:42:22AM -0400, Steve Litt wrote:
 assumption. Does anyone know the percentages of LyX users on:

 Given that it is free software and therefore nearly impossible to know
 what the user community size is, knowing the relative sizes of
 segments of the population seems to be a little ambitious.

 --
 Andrew Sullivan
 a...@shinkuro.com
 Shinkuro, Inc.




-- 
Prof. Murat Yildizoglu
Université Paul Cézanne (Aix-Marseille 3)
GREQAM (UMR CNRS 6579)
Centre de la Vieille Charité
2, rue de la Charité
13236 Marseille cedex 02

Bureau 320
Tel : +33 4 91 14 07 27 (standard)
Tel : +33 4 91 14 07 70 (secrétariat)
Tel : +33 4 91 14 07 47 (bureau)
Fax : +33 4 91 90 02 27

e-mail: murat.yildizo...@univ-cezanne.fr
www : http://www.vcharite.univ-mrs.fr/PP/yildi/index.html
http://www.twitter.com/yildizoglu
__

Re: How many use Linux: was[LyX] explicit mail subject

[Graham M Smith]

Paul A. Rubin wrote:

Steve Litt wrote:

On Friday 11 September 2009 09:58:04 Murray Eisenberg wrote:

But only a fraction of folks use Unix/Linux!


I've always assumed that fraction was about 4/5 but never examined 
that assumption. Does anyone know the percentages of LyX users on:


Linux
Windows
Mac
BSD
Other

Just to start the ball rolling, I've always used LyX on Linux (since 
2001) and am currently using it on Ubuntu 9.0.4.




Just to kick the ball out of bounds, how do you count cross-platform 
users?  I have it on one XP box and two Ubuntu boxes, and I use it 
heavily under both OSes.


When I first came across LyX (which goes back far enough that the only 
Windows version was a port that required Cygwin), Linux users vastly 
outnumbered Windows users.  From list traffic, I suspect Linux is 
still prevalent (followed by Windows, then Mac), but the vastly is 
likely no longer true.


/Paul

Well, I have it on a ubuntu 9.04 Thinkpad, a Mint Gloria eePC, a MacBook 
Pro, and two XP desktops (which have Mint Gloria running under 
Virtulisation also running Lyx) So work that one out :-)


Graham