bug#15984: 24.3; Problem with combining characters in attachment filename

[Eli Zaretskii <eliz@gnu.org>]

> From: nisse@lysator.liu.se (Niels Möller)
> Cc: 15984@debbugs.gnu.org
> Date: Fri, 29 Nov 2013 13:41:01 +0100
> 
> Today, to remove the dots from an "ä" character, I'll have to delete the
> complete "ä" character and insert a new "a" character.

Not if they were originally two or more characters which were composed
into one.  In that case, we let the user edit them separately.

> I think this "atomic" handling is the desired behaviour in many
> cases.

For "ä", this is arguable.  For more complex script, this is
definitely wrong: users want to be able to edit each component
separately.

> But if you have a complex sequence of unicode combining characters,
> I agree there's some need to be able to edit it. Maybe put point on
> the character and invoke edit-char to go in some special mode which
> explodes the usually "atomic" character into smaller pieces.

We already do that, but if the characters were combined, and Emacs
doesn't even know they were separate to begin with, it cannot do that,
can it?

> > You are mixing display issues with editing issues and with how
> > characters are represented internally in an Emacs buffer.
> 
> I think it's confusing for users if the units of text which forward-char
> skips over, do not correspond to the units matched by "." in
> isearch-forward-regexp.

What happens under the hood with matching and what is shown to the
user doesn't have to be identical.  In fact, it cannot be identical.
Again, please don't mix internal implementation and UI, they cannot be
possibly identical anyway, because there are conflicting user
requirements in different situations.

> My suggested internal representation seems to be a natural way to get
> this correspondence right, at the cost of some memory (or lots of
> complexity in reducing memory usage).

It only seems to be that.  Real life is much more messy, and defeats
such simplicity on many levels.

> Now I've also reproduced it on the same machine, without my normal Gnus
> setup getting in the way. I start emacs with
> 
>   $ rm -rf ~/tmp/home/ && mkdir ~/tmp/home/ && HOME=$HOME/tmp/home emacs -nw -Q -l bug.el
> 
> where bug.el contains
> 
>   (setq gnus-init-file nil)
>   (setq gnus-nntp-server nil)
>   (gnus-no-server)
> 
> Then create the group with G d, pointing out the spool-like directory,
> enter the group (RET), view the message (RET), try to write out the
> attachment ("o" on the attachment button). Still crashes for me.

Thanks.