GNU bug report logs - #15984
24.3; Problem with combining characters in attachment filename

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: nisse <at> lysator.liu.se (Niels Möller)
Cc: 15984 <at> debbugs.gnu.org
Subject: bug#15984: 24.3; Problem with combining characters in attachment filename
Date: Fri, 29 Nov 2013 16:50:44 +0200

> From: nisse <at> lysator.liu.se (Niels Möller)
> Cc: 15984 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.