Martin Vermeer wrote:
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.
Exactly! This is a very important distinction, which I've been trying to
point out over the last few days, but I didn't know how to explain it
well. You've phrased it much better than I did.
There's another consideration which you may already be aware of, but
which I only just found out now, after playing around with this: part of
the problem is that some of these latex commands process their contents
in a verbatim fashion. For example, \url does not allow other latex
commands inside it --- e.g., typing "\selectlanguage{hebrew}" inside a
\url just gets processed verbatim. I had not realized that this was a
latex --- rather than a LyX --- limitation. So I guess that that's what
the 'verbatim' option is signifying in this case.
Now, there's also another problem with the URL inset. Currently, I'm
having the same problem we were having a few weeks back with the ERT
insets: if I try to insert a URL while typing Hebrew text, the font
inside it is Hebrew, and I can't switch it to English (well, again, I
guess what I actually want is latin, not English per-se?) because we
disabled the lfuns. So we should be forcing the font inside the inset to
latin, and I guess the best way we have for doing that is by forcing the
font to latex_language. Does this sound right (despite what I was saying
above about not expanding the usage of latex_language :( ) --- i.e.,
should we be forcing latex_language for all 'verbatim' insets?
But here is where the distinction you mentioned above comes into play:
whereas for ERT, we don't want any commands for switching the language
to be output, in the other cases (such as URL) we *do* need such a
command, because we're going to output, not just to the latex file. I'm
not sure how this would work in other non-latin languages, but in the
case of RTL languages, what's really needed is just a command for
switching back into LTR mode. In fact, it turns out that such a
mechanism is already in place (see
http://www.lyx.org/trac/browser/lyx-devel/trunk/src/Paragraph.cpp?rev=21230#L719):
what's needed is to add to the "if" another case: if the inset's layout
is 'verbatim' and the inset is not ERT. That should do the trick for RTL
languages, at least. I'm not sure how to get to check the inset's
'verbatim', though...
Why was InsetListing derived from InsetERT? I don't think that was a
good idea.
I thought so too, at first; and then I wasn't so sure anymore. Listings
is complicated. It's code is currently quite a mess, and is doing
certain things which it really shouldn't be doing (e.g., using a
hardcoded encoding). I sent in a series of patches a few weeks back
which somewhat fix it up (to which I got no responses), but I'm still
not sure what the really correct way to deal with Listings is. The
problem is that listings latex package is very finicky about how it
deals with encodings: it requires latin1, but it does allow another
encoding through escaping, but it seems to allow only *one* other
encoding besides latin1; and this applies also to the caption, not just
to the contents... See
http://permalink.gmane.org/gmane.editors.lyx.devel/91323, and more
recently
http://thread.gmane.org/gmane.editors.lyx.cvs/14263/focus=95506, for
more details)
(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
Dov
