From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: dick.r.chiang@gmail.com Newsgroups: gmane.emacs.bugs Subject: bug#39506: patch Date: Sat, 08 Feb 2020 14:01:44 -0500 Message-ID: <87o8u8ewdj.fsf@dick> References: <87tv419ail.fsf@dick> <877e0xf72p.fsf@dick> <87v9ohdr21.fsf@dick> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125537"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.60 (gnu/linux) Cc: 39506@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 08 20:02:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j0VMp-000WWi-5g for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Feb 2020 20:02:11 +0100 Original-Received: from localhost ([::1]:44476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0VMn-0005i5-R7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Feb 2020 14:02:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47791) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0VMg-0005ho-Uq for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2020 14:02:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j0VMf-0003NF-Vj for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2020 14:02:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45829) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j0VMf-0003N7-SO for bug-gnu-emacs@gnu.org; Sat, 08 Feb 2020 14:02:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j0VMf-00049u-Oi; Sat, 08 Feb 2020 14:02:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: dick.r.chiang@gmail.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Sat, 08 Feb 2020 19:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39506 X-GNU-PR-Package: emacs,gnus Original-Received: via spool by 39506-submit@debbugs.gnu.org id=B39506.158118851315973 (code B ref 39506); Sat, 08 Feb 2020 19:02:01 +0000 Original-Received: (at 39506) by debbugs.gnu.org; 8 Feb 2020 19:01:53 +0000 Original-Received: from localhost ([127.0.0.1]:51802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0VMW-00049Y-Vi for submit@debbugs.gnu.org; Sat, 08 Feb 2020 14:01:53 -0500 Original-Received: from mail-qk1-f173.google.com ([209.85.222.173]:32946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0VMV-00049L-Ey for 39506@debbugs.gnu.org; Sat, 08 Feb 2020 14:01:51 -0500 Original-Received: by mail-qk1-f173.google.com with SMTP id h4so2624621qkm.0 for <39506@debbugs.gnu.org>; Sat, 08 Feb 2020 11:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=HtaJaYDkbjlo4X4oycci0Drn/SgT01ekOhTmM2tL6CE=; b=KAHzYiDAED7PV+eAVYnxl0WHJETlxpdQo2NhPFc82QZ1JuEXovIDXwoB5OO5lNGibM Ac0CHIhdNp2TVNPXA0phbLgFOKK+Ij61SbyoqdPcxBcpYLEm2AE/X08By29/yRNvN7bW syt0GAbgRqtjG2kK07i2MsScOwtBJfJH5Yeiy/1B6xvC7SKIgLMUpu86SPQ/Km4olBnP eOtkILFAzCQzvgyl75YOyn77+tj1baSanwCL8FebN+n+9/+JzV52ZxylU+AggPsR3Rak fGcVxC1OaJ7gfUnnbo2rzYgzVEee7RjPILpgjwgpXr0UFdE7vTPTqdrIZC4nX5HyZ0Y+ D6fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=HtaJaYDkbjlo4X4oycci0Drn/SgT01ekOhTmM2tL6CE=; b=DFWXYZyn/dXiqOCxQfGEUJXj6B+Az84kK6/LYxYi3sXHOi31X7zNlZnsH1JY+2ETi0 Mu/JenCd9bqnOs81N7s62Z6Za/zJcPKc3K58NXBKuJPjqPkiiXOFCqiqcvYonbkfroAn 77pXxWu+b6GzrrhIF+XjkuLg432O9y0tH6TJRKSPkKLsAadjyU1LQqkLQwnZJPiaBXBO ht32G7uEqIrcnFD8RLqYWd7LTadS8aJ7NENo5spBblp/rl6caNxm8e8TYR+fhjEd+Mr3 pdA+3dhcrPcan6p75KUwjfA0PLA3HQnkzk3T0TSU1GgY/sOZU3ET4/NVL9nfTrA6Osn2 SnEQ== X-Gm-Message-State: APjAAAWhfeudLKitiTo2T2Yi+qo7Iukyn5asN9abe1v/p4yo8kUnx8b2 UFmfCj2s1grlnkalQfunAm0= X-Google-Smtp-Source: APXvYqzR1T4CL/5MDz3SM8CXXa3rztaVdL/t/DCwKM6kZnHGwtaqWmiK8eySOharaQrztYiqFLwjGw== X-Received: by 2002:ae9:edc8:: with SMTP id c191mr3541946qkg.393.1581188505775; Sat, 08 Feb 2020 11:01:45 -0800 (PST) Original-Received: from localhost (pool-100-33-98-8.nycmny.fios.verizon.net. [100.33.98.8]) by smtp.gmail.com with ESMTPSA id o10sm3383272qko.38.2020.02.08.11.01.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Feb 2020 11:01:45 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sat, 08 Feb 2020 13:32:11 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:175805 Archived-At: > The focus of the sentence is on "before": the previous code already set the > buffer to unibyte, but it did it afterwards. Ah, so the buffer in question is merely the working temp-buffer, not the handle-buffer. Indeed, the previous code did it afterwards, and therein lies my salvation because insert-buffer-substring of multibytes to a unibyte buffer corrupts. I think the Miles Bader code replicated the multibyteness of the handle-buffer to the temp-buffer, called insert-buffer-substring, and then converted the temp-buffer to unibyte. > - How does `mm-with-part` relate to `mm-shr`? mm-shr calls mm-with-part. > - Before deciding whether unibyte or multibyte is the right choice, the > main question is whether the buffer contains bytes or chars. My buffer contained some Chinese multibytes. You can see my unit test in the patch. > AFAIK `mm-with-part` should only ever handle bytes (otherwise calling > `mm-decode-content-transfer-encoding` doesn't make much sense). Okay, maybe mm-decode-content-transfer-encoding is a noop when it doesn't make sense. I'm not completely on top of all this, but my individual use case rather prefers the old Miles Bader order of ops. I can easily work around it if you feel your 2008 change genuinely fixed something that was broken (my patch is largely speculative and inconsiderate of broader ramifications).