From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= Newsgroups: gmane.emacs.devel Subject: Re: Upcoming merge of adaptive-wrap Date: Fri, 26 Jan 2024 09:05:50 +0100 Message-ID: <87cyto4izl.fsf@gmail.com> References: <878r4eqjh8.fsf.ref@yahoo.com> <878r4eqjh8.fsf@yahoo.com> <87ede5u3yd.fsf@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23720"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Po Lu , emacs-devel@gnu.org, Stefan Monnier To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 26 09:06:39 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rTHEU-000623-FR for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Jan 2024 09:06:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTHDs-0001WM-Qy; Fri, 26 Jan 2024 03:06:01 -0500 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 1rTHDq-0001W0-0f for emacs-devel@gnu.org; Fri, 26 Jan 2024 03:05:58 -0500 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rTHDn-00063h-Hf for emacs-devel@gnu.org; Fri, 26 Jan 2024 03:05:57 -0500 Original-Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3394b892691so56065f8f.1 for ; Fri, 26 Jan 2024 00:05:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706256353; x=1706861153; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1Y3ds4WDEb0aPkh2uuw1CiplfWDJYnlcC7rnEQIGC8o=; b=GJzlDMprvxvDutSstqI1nBIOP2k7I4TIG8Rcwl0XXR90DiKPNg7fkqC6L8fUq3CSLg +yZOVeVrkSTB9AUko77tiwovFb3pBmt2X8Aa09H09zRzPtjxLt0cjk9XJCtk919gZ3ob ABRai+3tEeuXyTbbU9ST9Y8P3WucpJIwGIe0PlXUQk5Ezy1frKpGMYjBhPm4NpX+EipT tr6VE21cF9GQjsfuL/qzFoRYjs2/DDL4MUCz2mb6dX1AZEtH7nOGfhBxA6vwLrYRlOBn 87Lg2i4PZahxgFSHocwcjslq44J5ihJjGehVihfxot7bLGfxktbvimK1U0Z/wLSNgUAj L3UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706256353; x=1706861153; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1Y3ds4WDEb0aPkh2uuw1CiplfWDJYnlcC7rnEQIGC8o=; b=X2mFgtsynykC9iHOiRWdB/fTdX4kM0cxmrT1KObrD6Vdff4jVLcmoZGBn4xCYOTWmj +IP0zY9dbd7C9Id/8GX9DxriYHY73FQbvO39QtUFLkU2LY1WJXSqK9JXQDC3Vg5PRqy+ ZABG2C4LRFpoiZB6+88XOlPd1Nw2E3Q9AeJ3TFvblwnTMjlx+DX+oParTb0Gd+fIDpqI mBy17pB1fJs9Ueft3P3pkCVELC2lgb80XD3fu6zHKRq50q/nvfw8qX3cQmNvUF63IkY8 M65jKJM9v9jF73pYB0fJBGX95hOGgO8+BfOJ1yaQP6eQlOFrUSbmhStZD9tqzeLFh/X5 Aa2A== X-Gm-Message-State: AOJu0Ywkt9co+344/XdO/jyChMAk4ziP4dvNYbe6HX4HWMf+ehueCRDt 7nR8i39qTi1mGmjkUcaPgm07kucMdqVZGF9LN5NhBnhxMLQiDZ8a X-Google-Smtp-Source: AGHT+IEFvuwwg0h3JlS7FLm5mGcGuNA3+/SrCDiGosXhFkUJOXJyp+41aJWpZtcgIJxqLFvu9pn8dw== X-Received: by 2002:a5d:4751:0:b0:337:d346:bf4 with SMTP id o17-20020a5d4751000000b00337d3460bf4mr277150wrs.5.1706256352681; Fri, 26 Jan 2024 00:05:52 -0800 (PST) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id bv14-20020a0560001f0e00b0033addd06c67sm52321wrb.6.2024.01.26.00.05.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 00:05:51 -0800 (PST) In-Reply-To: <87ede5u3yd.fsf@gmx.net> (Stephen Berman's message of "Thu, 25 Jan 2024 11:01:30 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=kevin.legouguec@gmail.com; helo=mail-wr1-x42c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315419 Archived-At: Hi, Stephen Berman writes: > Sorry for not responding to your message from last August 10, which I > have just found again; FWIW I have these excuses for my negligence: > First, I was on vacation at the time and didn't see the message till > around two weeks later. Second, you wrote in that message: > >> Stefan, what do you say to this? Since the package in ELPA, migrating >> it into Emacs should not pose any legal difficulties, so the only >> prerequisites are suitable entries in NEWS and the documentation, >> correct? > > From this I thought you were addressing Stefan Monnier, who is nominally > the co-author of the package (but actually is responsible for the most > important part of the implementation). Third, I didn't know (or had > forgotten) that I'm still listed as maintainer of the package, a role > that I've not wanted to have for a long time. In fact, in a private > exchange in June 2020 as followup to bug#41810, Stefan asked K=C3=A9vin Le > Gouguec if he would like to assume the maintainership, though AFAIK > neither that question nor the bug report have been resolved; I've added > both to the Cc:. Thanks for the reminder; my memory was that I had declined as politely as I could, but re-reading my answer back then it was way too=E2=80=A6 I'd= say "tongue-in-cheek", but it contained a character whose name actually includes "STUCK-OUT TONGUE", so that does not sound right. Jokes aside, I think my pattern of contribution to Emacs since then (or lack thereof) confirms my unspoken concern at the time: I don't know that I can give the time and attention maintainership deserves=C2=B9. Certainly not in equal measure to the passion the OP has expressed for this package. (FWIW Po Lu, your message in August did not go unnoticed and has remained "ticked" in my Gnus ever since, to watch for replies) > In any case, I have no objection to moving adaptive-wrap from GNU ELPA > to Emacs core; but whatever the outcome, I would like to be removed as > maintainer. No strong opinion. Thoughts though: * Since adaptive-wrap implicitly relies on adaptive-fill-regexp, it's been on my mind that the mode could achieve better visual results if major modes "cooperated" and adjusted that variable, yet a lot of modes (e.g. read-only special modes) have no incentive to do so, since they are not expected to "hard-fill" text. E.g. adaptive-wrap in diff-mode currently looks inconsistent because ?- is part of adaptive-fill-regexp, but not ?+. This makes removed lines wrapped with extra indent, but not added lines. diff-mode could solve this by adding "+" to adaptive-fill-regexp, but why should it? No-one runs M-q on patches. All that to say: I've been wondering whether having adaptive-wrap in core would be a "good enough" incentive to push for such mode-specific tweaks to adaptive-fill-regexp; maybe it's neither necessary nor sufficient. * Catching up on the rest of the thread: if the goal is discoverability, I think the most likely remedy long-term (NEWS will only help in the "short" term, until it is rotated into NEWS.30) will be pointers from visual-line-mode's documentation (docstring and/or manual). Here too, I can't firmly conclude that moving to core is necessary; can the documentation of core features like visual-line-mode reference features found in GNU ELPA, like adaptive-wrap? If so, I would expect that to offer all the visibility this package needs; at least, not much less than it will get by being moved to core. tl;dr Sure why not maybe I don't know? Anyhoo. Got a couple of pandemonium eruptions to catch up with =F0=9F=98=8A =C2=B9 I have accrued a laundry list of things I would like to fix with adaptive-wrap (account for face backgrounds from overlays; account for face foregrounds from prefixes; heed any prefix's 'display property; play nice with whitespace-mode) and have no patch to show for it. I still use that package daily, but given my track record at scratching my own itches I don't think *stewardship* should be on the table.