If Unicode does not have a rule of ZWNJ handing, to delete ZWNJ, how a user know which to type; C-d or BS? And while doing cut&paste repeatedly, are there any chance of having the second and third lines of the attached file? They have two and three consecutive ZWNJ. How does a user notice such a (perhaps incorrect) situation? As a user, I’ve been in this situation before and it simply doesn’t have any effect on the user and the user simply can’t figure it out (unless represent ZWNJ as something else). This is why ZWNJ-as-Thin is a workaround hack and not a solution. ZWNJ takes no space it’s like 3x0=0. To delete, some editors like Gedit and many more simply take any number of consequent ZWNJs as one. I’ve seen some which count each ZWNJ and the user have to delete each to reach the character before. On Sat, Sep 16, 2017 at 6:03 AM handa handa@gnu.org wrote: In article <83y3phmca8.fsf@gnu.org>, Eli Zaretskii writes: > > > > Each Arabic character constitutes a grapheme cluster. Then, for the > > > sequence "0646 0645 06CC 200C 0634 0648 062F", to which neighboring > should > > > 200C belongs to? Does Unicode define it? > > > I don't think Unicode defines that, but I thought the shaping engine > > gives us back glyphs that don't include ZWNJ itself. Evidently, > > that's not true, which I find strange. > > If ZWNJ is WITHIN a grapheme cluster (i.e. not at the edges > of the cluster), the m17n lib does not return ZWNJ glyph. > > > > Anyway, is it convenient or inconvenient to be able to edit ZWNJ > directly? > > > It's convenient. But we already support deletion of composed > > characters, so I didn't think it mattered. > > If Unicode does not have a rule of ZWNJ handing, to delete ZWNJ, how a > user know which to type; C-d or BS? And while doing cut&paste > repeatedly, are there any chance of having the second and third lines of > the attached file? They have two and three consecutive ZWNJ. How does > a user notice such a (perhaps incorrect) situation? > > --- > K. Handa > handa@gnu.org > > ​