> The main reason that I want this change ("the red dot") is for the RTL support:
I recognize that there is a problem here, because the cursor has to
have direction as well as position. When you use the mouse, you only
specify position, and therefore the direction is unspecified at the
borders. Let's call this problem the "direction problem."
The visual dots can resolve this ambiguity.
In order for this to be effective, the visual dots have to be relatively
wide on the screen, because otherwise it will be too hard to hit the right
point when you click.
This, in turn, implies that the visual dots have to be fairly intrusive
in the interface.
How does Emacs (or any other editor) handle this direction problem?
How common is this problem? After all, it only happens when you write
mixed direction documents, and when you have to use the mouse to
position the cursor at the boundary of directions.
It sure sounds like it's fairly uncommon, but I'm not the one to judge
that, since I never write mixed direction documents. So it's up to you,
and other users of Hebrew, to judge whether the dot-solution is the best.
> However, RTL is not the only reason. With the current CVS version, you can
> write a document that contains several languages. But since changing the
> language of a text segment does not have visual effect, it is easy to get
> wrong results.
Let's call this problem the "language problem."
This problem is more related to the font attribute problem.
It basically is a lack of visual feedback. It's not a problem where you
need to have extra positions for the cursor. It's a problem of knowing
what character attributes are active at the point of the cursor.
Therefore, would it not be better just to have the feedback, and not
the meta-characters that introduce extra cursor positions which I
fear are annoying?
What about more up-to-date information in the status bar?
That has the advantage that you can read which language is active.
Of course, it has the disadvantage that you have to position the cursor
to see if the attributes change. I don't know if that is a real problem,
because most often you would know that the attribute is changed either
by visual feedback in the case of font attributes, or by the words them
selves when you write mixed language documents.
Don't get me wrong, I'm just brain storming to find the best solution
for each problem, because I skeptical about more visual clutter on the
screen, which might only be needed when you write mixed direction
documents.
After all, that is a fairly small group of users.
Now you can say that it could be optional, but this is such a fundamental
change in interface that I think we should just find the best solution
instead of having two.
> What you describe above is exactly what it currently done by LyX.
> Doing this sort of things is not a good idea in general, and in particular,
> there are cases where the above scheme gives wrong results:
> If you have "ab CD ef" in \huge font size, and CD is also in bold, then LaTeX
> output of LyX will be "{\huge ab} \textbf{\huge CD} {\huge ef}", which causes
> that the space between "ab" and "CD" to be too small.
LyX should automatically recognize this as
{\huge ab \textbf{CD} ef}
If it does not, that's a bug, IMO.
In general, spaces should adopt to the surroundings in such a way as
to minimize font changes.
I believe that it is possible to use automation for many of these tasks.
I know that many people are skeptical about these things, and this is
justified if you take a look at Microsoft Word. This program is much
too eager and since it's not smart enough, the result is that it is
intrusive and inhibiting to your writing. The end result is that you
are better off by turning it off.
However, it's relatively easy to see when Word (and LyX) does it wrong,
and we have to possibility to do better. I have a feeling that we can avoid
most of these visual dots in the document if we spent a little time
considering the issues more...
I can very likely be wrong about this, and you have already found
the best solution to the problems. In that case, please bear with me
and explain why we really need it for all situations.
My feeling at this point is that the dots are justified to solve the
direction problem, but I still think they are too intrusive to solve
the language, and font, problems.
For the latter part, we should try to solve the problems by providing
more information in the status bar, and adopt more intelligent algoritms
to find out what you mean such that the mix-up problems won't happen
in the first place.
Greets,
Asger
