From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nisse@lysator.liu.se (Niels =?UTF-8?Q?M=C3=B6ller?=) Newsgroups: gmane.emacs.bugs Subject: bug#15984: 24.3; Problem with combining characters in attachment filename Date: Fri, 29 Nov 2013 13:41:01 +0100 Message-ID: References: <83iovc8eaq.fsf@gnu.org> <83a9gn8yoz.fsf@gnu.org> <831u1z8twg.fsf@gnu.org> <83r49z78jp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1385728933 28654 80.91.229.3 (29 Nov 2013 12:42:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2013 12:42:13 +0000 (UTC) Cc: 15984@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 29 13:42:17 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VmNOj-0007Oz-Gf for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Nov 2013 13:42:17 +0100 Original-Received: from localhost ([::1]:47056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmNOi-00033z-Jo for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Nov 2013 07:42:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmNOa-0002xy-SX for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2013 07:42:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmNOV-0002TQ-KV for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2013 07:42:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmNOV-0002TJ-GL for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2013 07:42:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VmNOU-00056q-9r for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2013 07:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: nisse@lysator.liu.se (Niels =?UTF-8?Q?M=C3=B6ller?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Nov 2013 12:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15984 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15984-submit@debbugs.gnu.org id=B15984.138572887219565 (code B ref 15984); Fri, 29 Nov 2013 12:42:02 +0000 Original-Received: (at 15984) by debbugs.gnu.org; 29 Nov 2013 12:41:12 +0000 Original-Received: from localhost ([127.0.0.1]:49876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VmNNf-00055U-By for submit@debbugs.gnu.org; Fri, 29 Nov 2013 07:41:12 -0500 Original-Received: from bacon.lysator.liu.se ([130.236.254.206]:35044) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VmNNX-000553-Bb for 15984@debbugs.gnu.org; Fri, 29 Nov 2013 07:41:07 -0500 Original-Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id rATCf1lA029775; Fri, 29 Nov 2013 13:41:01 +0100 (MET) Original-Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id rATCf1Cc029774; Fri, 29 Nov 2013 13:41:01 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f In-Reply-To: <83r49z78jp.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Nov 2013 13:26:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81091 Archived-At: Eli Zaretskii writes: > However, we do want to give the user a way to > delete only one or more of the combining characters, so forcing the > entire combination to be a single indivisible entity would not be TRT > for users. Good question, how to handle this. Today, to remove the dots from an "ä" character, I'll have to delete the complete "ä" character and insert a new "a" character. Or similarly for the reverse edit. I think this "atomic" handling is the desired behaviour in many cases. And I don't think it should behave differently depending on the representation of "ä" in the original file. 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. And such a character edit mode might be useful for more things than unicode composing characters, e.g, manipulationg the different sub-parts of a chinese character. Anyway, this user interface is not intimately tied to the internal character representation; its overall effect on the buffer will be the same as replacing any substring. >> When reading text files, the character boundaries may be configurble. > > The important question is what to do by default, I'm pretty sure the default should be that a sequence of one unicode base char and all following unicode combining chars is interned as a single "emacs character". (I think the detailed rules for this are spelled out in the unicode book). With some arbitrary limit to prevent a GByte file with only unicode combining characters to get read as a single emacs character; say at most 10 combining characters. > 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. 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). I'm sure there are other ways, and maybe also a lot better ways, to implement the same thing. > Thanks, I will try that. 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.