emacs-bidi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emacs-bidi] Points composition - status.


From: Eli Zaretskii
Subject: Re: [emacs-bidi] Points composition - status.
Date: Mon, 24 Dec 2001 12:36:24 +0200

Yair Friedman (Jerusalem) wrote:
> 
> > The composition isn't missing: it's there, but it just isn't displayed,
> > because a character terminal doesn't support that.  This is how display is
> > supposed to work on a tty: it displays the first character of a composition
> > and ignores the rest.
> 
> Yes, but the user doesn't have any indication of the presence of those
> composed characters, this is exactly the same situation that was with
> silent EOL conversion.

Sigh...  Not another Mule-is-source-of-all-evil argument, please!

Anyway, your analogy is wrong: the EOL conversion was never silent, it
always indicated the file's EOL format on the mode line, people just
weren't looking.  Amazingly enough, the complaints about that simply went
away; I don't think I've seen any of them for many months, neither on
gnu.emacs.help nor on gnu.emacs.bug.  Perhaps people just needed to get
used to this.

> Emacs should clearly notify the user that there
> are more "invisible" characters. A notice when reading the file (like
> when invoking region-upcase), and some sort of mark in the mode-line
> when the cursor is over a composed character is required.

I think you contradict yourself: if the EOL type indication on the mode
line is not good enough, then neither will be the mode-line indication
about diacriticals.  And a one-time message isn't enough, either: people
just don't pay attention.

I don't see any good solutions except a special editing mode where
diacriticals are displayed by simulating them with ASCII characters (and
the composition is suppressed).  Users who want to see all the diacriticals
on a tty will use that mode.  But by and large, it should be obvious to
anyone that editing on a tty has disadvantages, including some parts of
text that aren't displayed.  We have the same situation today with inline
images.

> Specifically for Hebrew points, if the user will not see the points, she
> might use "ktiv malé", making the final result awkward.

Given the extremely low frequency of using diacriticals throughout the
whole document, I don't see a problem here, even if they do mistakenly
decide to use ktiv male (which in itself is a low-probability decision).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]