[Top][All Lists]

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

RE: highlighting non-ASCII characters

From: Drew Adams
Subject: RE: highlighting non-ASCII characters
Date: Tue, 30 Mar 2010 07:04:05 -0700

> DA> it can also be useful to highlight a character (e.g. curly quote)
> DA> that is similar to but not identical to another character
> DA> (e.g. straight quote).
> OK, but can you say how it's useful in a specific example?  In SQL,
> Perl, Java, Lisp, and TeX editing I would not need the *glyphs*
> highlighted because the mode would detect the mismatch, e.g. in Perl
> $result = `run command here[wrong backward quote here]; # comment here
> would highlight "comment here" as part of the command.  IOW they are
> syntactically significant so a mismatch is not likely to go unnoticed
> anyway by the regular font-lock and the parser.
> In regular text it's legitimate to have any combination of quote marks
> so I don't see the benefit of looking for suspicious combinations.  In
> domain names quote marks of any kind are suspicious :)

Perhaps you're assuming that the code will be used in Emacs, so you say that
Emacs treats all such quotes similarly or highlights them anyway etc. (so no

Emacs might be used to write raw documentation (e.g. including code samples)
that is used to generate HTML or PDF or... Readers of that doc might then copy
and paste such examples into an app other than Emacs for execution - an app that
does not treat all such quotes similarly. 

Just one hypothetical example, extrapolated from why we use straight quotes in
our use of Framemaker.

Beyond that, I would think that there might be a number of use cases where one
might want to visually distinguish characters that are difficult to distinguish
- either exact homoglyphs or approximate ones. That's all.

Remember that it was only recently that Emacs itself started to treat a
non-breaking space in Lisp code the same as a regular space. Nothing guarantees
that an app DTRT with chars that look similar but are different.

And there's the opposite potential problem: not distinguishing similar chars
visually in the case where they do have different behaviors in some app. Suppose
you prepare code (for example) in Emacs for use in some other context, and you
want to be made aware when you use the wrong char, to avoid a problem

Anyway, you get the point, I think. If you don't think there is a problem, I'm
OK with that.

reply via email to

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