From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sandra Snan via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#71017: [PATCH] Flow single-paragraph messages Date: Sun, 07 Jul 2024 10:34:01 +0200 Message-ID: <87plrpbnye.fsf@ellen.idiomdrottning.org> References: <20240706204950.2437581-1-sandra.snan@idiomdrottning.org> <86h6d13gf6.fsf@gnu.org> Reply-To: Sandra Snan Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9149"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71017@debbugs.gnu.org To: Eli Zaretskii , Eric Abrahamsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 07 10:35:16 2024 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 1sQNMY-00025e-84 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Jul 2024 10:35:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQNML-0006AR-EO; Sun, 07 Jul 2024 04:35:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQNMI-00068K-5u for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2024 04:34:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQNMH-0007VT-TU for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2024 04:34:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sQNMM-0002ba-0s for bug-gnu-emacs@gnu.org; Sun, 07 Jul 2024 04:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sandra Snan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Jul 2024 08:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71017 X-GNU-PR-Package: emacs Original-Received: via spool by 71017-submit@debbugs.gnu.org id=B71017.17203412829978 (code B ref 71017); Sun, 07 Jul 2024 08:35:01 +0000 Original-Received: (at 71017) by debbugs.gnu.org; 7 Jul 2024 08:34:42 +0000 Original-Received: from localhost ([127.0.0.1]:47337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQNM2-0002ar-34 for submit@debbugs.gnu.org; Sun, 07 Jul 2024 04:34:42 -0400 Original-Received: from halsen.idiomdrottning.org ([74.207.231.133]:54550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQNLz-0002ah-Gm for 71017@debbugs.gnu.org; Sun, 07 Jul 2024 04:34:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idiomdrottning.org; s=idiomdrottningorg; t=1720341243; bh=xDmA02pY/dqwjXErU8a7G0d37PWYBVptSbS89HjDGWo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lT7+Mnowh53s1wFpkEOrq23RW1Bxwc7quJCIaquBzHYTADJbMxptedCjNfThtcRuT phwK58qqUqx8qXGFEvq/x9XLAv1+OBYEOFMH2cYDZfRayvWOdoYYsv1FpbjuO/BEyV Dcy3EEzuqcNr4qeE+/jmAbZgW6w23jOb2sLd1O2pj7SQx9j0DvJPhEtgaIL00NwZR3 hLCa7sseA894RbJxhoL9NmxYsrBarEp9hbM9KgQCFkbWXIQ/MAGZw2chdVJG03j5xy 5poanjIVqatrfokwoSWy0yxZTcASZvi34vu6eCKBxa4+/tKDK9pqLZaHyDgMHqlXZv gIfAVQW28YeuQ== Original-Received: from localhost (31-211-247-254.customers.ownit.se [31.211.247.254]) by halsen.idiomdrottning.org (Postfix) with ESMTPSA id 8259320F46; Sun, 7 Jul 2024 10:34:02 +0200 (CEST) In-Reply-To: <86h6d13gf6.fsf@gnu.org> Autocrypt: addr=sandra.snan@idiomdrottning.org; prefer-encrypt=mutual; keydata= mDMEZWEIEhYJKwYBBAHaRw8BAQdAahVPtpoqkiV62AL3GSY4JaPS0i3Bu3fhbe5WIFQG9pa0LFNh bmRyYSBTbmFuIDxzYW5kcmEuc25hbkBpZGlvbWRyb3R0bmluZy5vcmc+iJMEExYIADsCGwMFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AWIQSM+QwgZjV9IBEt0Difw0TKEvFISgUCZWJbSgIZAQAKCRCf w0TKEvFIShsYAPsFMXn+tFcAwdI2hrkqqQY8I5EC9UWYC9t57VjiYv2uYQD+PUNVHVSBGQDycf3V /nXqXvZvTfcFMOz0PVMzibPl0AiIkAQTFggAOBYhBIz5DCBmNX0gES3QOJ/DRMoS8UhKBQJlYQgS AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJ/DRMoS8UhK07EA/iV2B5e3r8t8/StJT38d x9YbuoSBmbYZJ6JHH9hoyv0hAPwMiH1M8zZUeQK/TQDqkg2Hjk0xL+U7i9ggocLJEAWQDbg4BGVh CBISCisGAQQBl1UBBQEBB0BqHjRRmoXeZmeeUZOqL1ebAflzYFA3jHwxl2sLMLlMCgMBCAeIeAQY FggAIBYhBIz5DCBmNX0gES3QOJ/DRMoS8UhKBQJlYQgSAhsMAAoJEJ/DRMoS8UhK4o0BAOB7ChkN Jc0oxRDg9WvrbUCnpLU/QdjMFcC8ymLRdzxaAP4gZVL0JQfxulc/JAxotCevk1PAF+UXpY8QalTI dooaAA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288549 Archived-At: Eli Zaretskii writes: > Thanks. (I also see RFC 3676 mentioned -- what is this about?) I mentioned RFC 3676 twice for different reasons. First, it's introduced the delsp parameter which wasn't in 2646 so code related to that parameter shouldn't talk about 2646 but rather 3676. Second, I saw a comment referring to not tampering with the sig line as a hack. I happened to have the section of RFC 3676 open that mandates that behavior so I changed the comment, however, this might be in RFC 2646 also, I don't know that, so in that case that comment might better change to refer to 2646 instead. >> First, the old code didn't refill or encode the last paragraph >> at all unless there was at least one hard newline EOF. > > Isn't this the documented behavior? Re multi-paragraph messages: No, it's not the documented behavior, it was an unrelated bug in fill-flowed-encode. It would refill all the other paragraphs, separated by hard newlines, just not the last one. That was a bug and broke documented behavior. I fixed that bug + another unrelated reflow bug. That was in fill-flowed-encode and that bugfix doesn't rely on the change in mml. With my fix in fill-flowed-encode, multi-paragraph-messages started working fine. Re single-paragraph messages: However, according to the old documented behavior, a message that contained no hard newlines should not be refilled. This documented behavior in mml-generate-mime-1 meant that single-paragraph messages would not be filled even with the fill-flowed-encode bug fixed. That is an unintended bad consequence of the documented behavior, a "bug in the design". I did change that but I updated the documentation to match. > The change seems to be an incompatible behavior change, so I > wonder whether we'd need some way for users to get back old > behavior. There is still the (neglected) defcustom mml-enable-flowed which now becomes more relevant since it's a way to turn off all this meddling and reflowing in the first place. The old documented behavior was bugged-by-design. It's not right that single paragraph messages are hardwrapped and not reflowed. In my day-to-day I write many messages in Emacs that I later see in threads in another MUA (Delta Chat) and these messages stand out in a way that something is wrong with them. However, one intent behind the old behavior was, in spirit, good: It'd be good to detect whether or not users with mml-enable-flowed on have remembered to also turn on use-hard-newlines, which is important for users with that on to do, especially since mml-enable-flowed defaults to t. The old attempt at doing that was flawed since it only worked reliably for multi-paragraph messages. Unfortunately there's currently no way to detect in a single-paragraph message whether or not use-hard-newlines have been turned on, since the variable it sets is buffer local. (One extremely klugy workaround would be to change the message-send-and-exit command to check whether use-hard-newlines is on and if it is, add an extra hard newline EOT just for detecting this. Not super into that solution so hopefully there are other ways.) With this patch, the defcustom mml-enable-flowed becomes _the_ setting for this, which does match a lot of documentation on the books. Perhaps it shall no longer default to t though since it completely borks messages up if it's t but use-hard-newlines are not on! So here we are: The new behavior has a problem: messages will get reflowed if mml-enable-flowed is t (the default!) even when use-hard-newlines is off, meaning that even separate "\n\n" paragraphs will get flowed together which is not what people want. Use-hard-newlines should be mandatory whenever mml-enable-flowed is on. The old behavior is not OK since single-paragraph messages will get messed up, hardwrapped even when those newlines were advertised as "soft", or not softwrapped even when the paragraph consists of just one single super long unbroken line. I also have sent a patch to the messages-are-flowing project highlighting the importance of this variable: https://github.com/legoscia/messages-are-flowing/pull/15/commits/ae432723c2565ceced5d01d9aa2d314bd42aaa3c So how about this idea: If mml-enable-flowed is on but fill-flowed-encode is asked to flow a message that doesn't have any hard newlines, assume Markdown semantics, i.e. special treatment for "\n\n+", " $", and "^ ". I'll see if I have time to implement that this morning. I think I'd place that change in fill-flowed-encode. That wouldn't affect people with mml-enable-flowed off, or people with both mml-enable-flowed and use-hard-newlines on, it'd just be a sort of DWIM fallback based on the guess that markdown semantics are somewhat widely known or expected in 2024, to prevent separate paragraphs to be flowed together for people with "incorrect" settings. Again, if there were a cross-buffer way to reliably detect whether use-hard-newlines is on, that dwimmy fallback wouldn't be needed. I thought about whether it'd have been better if it was instead soft newlines that were marked with a text property, not hard ones, but in the end that wouldn't properly softwrap messages with just one single overly long line.