On Fri, Oct 26, 2007 at 03:42:07PM +0200, Dov Feldstern wrote:
> 
> 
> Martin Vermeer wrote:
> >I have two questions about latex_language: 
> >
> >1)is it true that all it does is prevent the text from being spell
> >checked (and bluelined)? And 
> >
> >2) is is also true that it differs from ignore_language in that the
> >latter means that language _changes_ are ignored ... meaning that, if
> >you have a piece of ignore_language text in the middle of French, it
> >will be spell checked as French text, but if you have a piece of
> >_latex_language text in the same place, it will not?
> >
> >Would it be a good idea to rename latex_language to no_language? 
> >It is usable in all places where code-like stuff is being included.
> >Generally only natural language should be spell checked.
> >
> >- Martin
> >
> 
> Hi!
> 
> I'm still not sure what the original idea behind latex_language was, but 
> here are some thoughts based on what I've seen:
> 
> 1. Spelling should *not* be mixed up with languages --- these are two 
> separate properties of text. Knowing the language is necessary for latex 
> to correctly typeset many languages. So if I want to mark some text in 
> such a language to not be spell-checked, and I do that by switching that 
> text's language to "no-spellcheck", it will no longer be typeset 
> correctly (because the language information was lost). Therefore, if we 
> want to provide "no-spelling", that needs to use a mechanism separate 
> from language. (The reason that we still get confused with this, is that 
> the language *does* affect spellchecking: once it's determined that 
> spellchecking should take place, then the language is used to determine 
> which dictionary should be used for the spellchecking; and if there's no 
> dictionary for that language, no spellchecking can occur. However, using 
> this in order to prevent spellchecking is an abuse, and will not work in 
> the general case, as I just explained.)
> 
> So let's leave spellchecking out of this now. If we determine that 
> latex_language is ever (or only?) being used to prevent spell-checking, 
> then that's wrong, and should ultimately be replaced with a mechanism 
> aimed specifically at spell-check prevention.
> 
> 2. Currently, I think that latex_language's main use may be to force a 
> latin encoding/alphabet. For example, when adding ERT to a Hebrew 
> document, I have to switch to some kind of latin alphabet, because latex 
> commands are in this encoding even for Hebrew documents. However, 
> telling the user to switch to, say, English, inside ERT in order to 
> achieve this is a little funny, because she's not really switching to 
> English! So latex_language provides a way of forcing the encoding to 
> latin, without specifying any natural language, which would be wrong.
> 
> 
> To be more practical, these are the "services" which I think we need, 
> and are currently provided by latex_language:
> 
> *) ignoring spelling --- definitely we should use a dedicated mechanism 
> for this, *not* latex_language. I actually attached a patch which does 
> this (at a low level, high-level use-cases could be built on top of 
> this) to one of the spell-checking bugs in bugzilla.
> 
> *) a way to force the GUI (and the generation of the latex file?) to use 
> the latin1 encoding, without specifying a specific natural language.
> 
> Possibly the best way to find out what else latex_language is being used 
> for is to get rid of it altogether, and see what breaks (I'm more than 
> half-serious!). Things most certainly *will* break --- but most of those 
> things should probably be fixed using a mechanism other than 
> latex_language. The question is if you want to do this now or just leave 
> it for now. However, I would *not* expand the use of latex_language any 
> more than it's currently being used.
> 
> Hope this is somewhat helpful...
> Dov

Yes, it is... thanks. I had completely forgotten about encoding,
/me latin chauvinist pig :-(

But then there is an essential difference between ERT and Listing: the
content of ERT is executable code, i.e., the rendered document contains
its output, not the code itself. An ERT's content will never be natural
language. It can safely be forced to latin-1 and needs never to be spell
checked.

An InsetListing content however -- or LyXCode layout -- contains code
that is _not_ executed, only rendered/printed for human consumption. It
may well contain comments, e.g., in Hebrew, which then need to be marked
as such to get the proper encoding, and which you may want to spell
check too.

Why was InsetListing derived from InsetERT? I don't think that was a
good idea.

(And yes, I agree there should be a separate mechanism to mark natural
language text -- or any text -- as "don't spell check me". Different
problem)

- Martin
 

Reply via email to