Same commands for different unicodes?

[Kornel Benko]

Am Sun, 27 Feb 2022 09:41:02 +0100
schrieb Jürgen Spitzmüller <spitz at lyx.org>:

> Am Sonntag, dem 27.02.2022 um 05:05 +0100 schrieb Thibaut Cuvelier:
> > I had a new look at this issue. What do you think about adding a new
> > flag? It would work exactly like "deprecated", but without the
> > implications of having symbols deprecated. I would call this new flag
> > "improper", to indicate that the mapping is typical for LaTeX, but
> > it's improper use of the Unicode symbol: its use should not really be
> > advised in general to use this LaTeX command for that Unicode
> > character. 
> > That would be the case for 0x204e: this asterisk is supposed to be
> > low, but LaTeX always uses a centred asterisk.
> > 
> > Of course, I could just add a "deprecated" flag to all these symbols
> > to trigger the expected behaviour, but it doesn't feel right.
> > 
> > For now, I have implemented the basic change with a "deprecated"
> > flag, with a comment each time to indicate why these mappings are
> > indicated as deprecated. This is enough to eliminate all the cases
> > you mentioned in your file sent on Feb 20. I'm splitting it into two
> > patches, with the second one having potentially more impact than the
> > first one (due to my lesser understanding).  
> 
> I see no reason to state that IPA is less "wanted by users" that Greek.
> I also see no reason to flag 0x025b (or tipa's \textepsilon)
> "deprecated" or "improper" as it is in no way deprecated and a
> perfectly proper command and glyph. Also, it is not as easy as to
> assume an ipacommand analogouous to text and math, as \textepsilon
> (IPA) works outside the \textipa context as soon as tipa is loaded,
> where as \textepsilon (Greek) works inside \textgreek or Greek language
> context.
> 
> IMHO Advance F&R needs to get to grips with the fact that there is no
> 1:1-mapping of command names and semantics in LaTeX and it needs to
> consider the context in which a character is being used. Unicodesymbols
> already provides the necessary information, no need to flag characters
> deviant in addition to that. The latter would lead to the same amount
> of false interpretation if the context is not being considered.
> 
> Jürgen 
> 

That is easy to say.
OTOH, if F&R gets the unicode directly, there is no problem. The whole issue is to
convert command names to unicode. F&R works on unicode only.

	Kornel
-- 
lyx-devel mailing list
lyx-devel at lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20220227/49d4962c/attachment.asc>