On Sun, Oct 28, 2007 at 02:27:25AM +0200, Dov Feldstern wrote:
>
>
> 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.
Thanks.
> 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?
Have you tried to change the language around the URL inset (i.e., at the
location
of the inset in the external lyxtext) to English?
The problem with forcing URL to latex_language is -- besides that it's *wrong*
--
that nowadays URL's can be in Unicode, i.e., any language. The same may apply
for
other (not yet existing) verbatim insets.
...
> > 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,
The LaTeX package? Or our code?
> 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)
Hmmm. Sounds a bit hopeless. I would say, don't force latex_language and warn
the
user about the limitations.
> > (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
- Martin
