Abdelrazak Younes wrote:
Dov Feldstern wrote:
So, does anyone know how it was solved? If we understand why it's now
working, I guess the FIXMEs from r19999 can be removed. Also, if Abdel
says this is not working now in branch, the fix should be ported to
branch, because the problem I'm describing is definitely a regression
relative to 1.5.0.
Hum, just to clarify: in branch, the text in ERT is displayed using the
exact same font as the surrounding text. In trunk, the text is displayed
with the default font, whatever the current environment. I don't know
about 1.5.0 nor 1.5.1.
I'm seeing a mixture of what you're describing, see below...
To reproduce the problem I'm talking about: switch to a non-latin
language (I do it with hebrew), type some text, and them in the same
paragraph open an ERT inset. Inside the ERT inset, the text is still
in the non-latin language,
I still see this.
Yeah, me too :( but see below
and it can't be switched, either. Again, this was the behavior I was
seeing in trunk from r19999 until a few days ago,
Are you sure this is fixed in trunk? The "language" LFUN seems to be
disabled in ERT.
It should be disabled (at least, that's the way it always has been), and
still is in trunk. But:
Abdel.
After a clean compile of trunk (r20239), I'm seeing strange stuff:
*) type a few words, switch to \emph (ctrl-e) and continue typing, and
then start an ERT inset (ctrl-l) and continue typing: The ERT text
appears in the GUI as emph. But if you backspace to delete everything in
the inset, and then start typing again, it's in the correct font now. If
you move out back to the preceding text, move over the emph text and
then move back in to the inset, again, the text will appear
*) very similar behavior regarding Hebrew: when you first start typing,
the ERT is in hebrew. But if you delete everything, it is then back to
normal.
*) In either case (Hebrew or emph), you can't just switch the font in
the middle --- because the commands to do so are disabled, as they
should be, in ERT.
(The truth is, it's all really a little more complicated: moving in and
out of the inset sometimes causes the font to change, and sometimes not...)
This is all consistent with what I'm claiming: at least part of the
problem is the current_font: it used to be set at the time the inset was
constructed (in the text_ object), and then it always remained set to
that, because it couldn't be switched. But now that the font "comes with
the cursor", so it depends on the state of the cursor when entering the
inset, and only if the cursor doesn't "come with a font" (because, say,
we deleted everything, and now the cursor doesn't know what it should be
set to?) does it revert to the default.
Again, I'm in favor of the move of current_font out of text and into
cursor --- I think it is the correct thing to do --- but for these
specific situations (what was marked as FIXME in r19999) we need to find
some solution. My suggested idea is to have some sort of optional hook
which sets the font upon entering and exiting an inset, but I'm not sure
that it's easy to implement and/or that it would work... But we probably
shouldn't port this who;e change to branch until this issue is worked out...
It's not unlikely that there's more to this than just the current_font
--- this may be interacting with some other changes that have happened
lately. But until we can prove that, I think our best bet is to try to
fix the FIXMEs of r19999.
Again though, I'm leaving all the real work to someone else --- Sorry...
I just don't have time right now... :( I'm also going to be offline
until the end of the week now.
Good luck!
Dov
P.S. I'm not sure if this is the same problem that Neal is reporting ---
I've only been talking about the GUI, I don't know how the latex output
is affected by this... But it sounds to me like the things are probably
connected...
