GNU logs - #75574, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Daniel Colascione <dancol@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Jan 2025 05:43:01 +0000
Resent-Message-ID: <handler.75574.B.17369197492020 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 75574 <at> debbugs.gnu.org
Date: Tue, 14 Jan 2025 21:42:13 -0800
From: Daniel Colascione <dancol@HIDDEN>
User-Agent: K-9 Mail for Android
Message-ID: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=----WJC86OT9YS6QHO8GVCYY2F9V29J17T
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=2600:3c01:e000:3d8::1;
 envelope-from=dancol@HIDDEN; helo=dancol.org
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, HTML_MESSAGE=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)

------WJC86OT9YS6QHO8GVCYY2F9V29J17T
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

The adaptive read buffering code delays reads in the hope that we can read =
in buffer chunks if we wait a little bit between reads from a process produ=
cing a lot of output=2E Sounds good=2E Doesn't work=2E The attempted optimi=
zation reduces performance in various scenarios and causes an 8x regression=
 in performance for me in flows involving mixtures of big and small reads=
=2E

With adaptive reading, we increase the read delay every time we get a shor=
t read and decrease it when we get a full buffer of data or do a write=2E  =
The problem is 1) that there are legitimate flows involving long sequences =
of reads without an intervening write and 2) reads (especially from PTYs) m=
ay *never* report a full buffer because the kernel limits the maximum read =
size no matter how big the backlog is=2E (For example, the Darwin kernel li=
mits PTY (and presumably TTY in general?) reads to 1024 bytes, but the defa=
ult Emacs read size is 64k, so we never recognize a signal that we should r=
educe the read delay=2E

I'd suggest just deleting the feature=2E It's not worth the complexity and=
 edge cases, IMHO=2E

If that's not an option, I'd suggest detecting bulk flows by doing a zero =
timeout select() after we're tempted to increase the delay and actually inc=
reasing the delay only when that select times out=2E

Just tweaking the maximum read size probably isn't a good idea: it's an im=
plementation detail and can change with time and over the types of FD from =
which we read=2E


------WJC86OT9YS6QHO8GVCYY2F9V29J17T
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><body><div dir=3D"auto">The adaptive read buffering co=
de delays reads in the hope that we can read in buffer chunks if we wait a =
little bit between reads from a process producing a lot of output=2E Sounds=
 good=2E Doesn't work=2E The attempted optimization reduces performance in =
various scenarios and causes an 8x regression in performance for me in flow=
s involving mixtures of big and small reads=2E<br><br>With adaptive reading=
, we increase the read delay every time we get a short read and decrease it=
 when we get a full buffer of data or do a write=2E=C2=A0 The problem is 1)=
 that there are legitimate flows involving long sequences of reads without =
an intervening write and 2) reads (especially from PTYs) may *never* report=
 a full buffer because the kernel limits the maximum read size no matter ho=
w big the backlog is=2E (For example, the Darwin kernel limits PTY (and pre=
sumably TTY in general?) reads to 1024 bytes, but the default Emacs read si=
ze is 64k, so we never recognize a signal that we should reduce the read de=
lay=2E<br><br>I'd suggest just deleting the feature=2E It's not worth the c=
omplexity and edge cases, IMHO=2E<br><br>If that's not an option, I'd sugge=
st detecting bulk flows by doing a zero timeout select() after we're tempte=
d to increase the delay and actually increasing the delay only when that se=
lect times out=2E<br><br>Just tweaking the maximum read size probably isn't=
 a good idea: it's an implementation detail and can change with time and ov=
er the types of FD from which we read=2E<br><br></div></body></html>
------WJC86OT9YS6QHO8GVCYY2F9V29J17T--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Daniel Colascione <dancol@HIDDEN>
Subject: bug#75574: Acknowledgement (Adaptive read buffering is a
 pessimization)
Message-ID: <handler.75574.B.17369197492020.ack <at> debbugs.gnu.org>
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
X-Gnu-PR-Message: ack 75574
X-Gnu-PR-Package: emacs
Reply-To: 75574 <at> debbugs.gnu.org
Date: Wed, 15 Jan 2025 05:43:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 75574 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
75574: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D75574
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Jan 2025 15:00:02 +0000
Resent-Message-ID: <handler.75574.B75574.173695316619533 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Daniel Colascione <dancol@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Cc: 75574 <at> debbugs.gnu.org
Date: Wed, 15 Jan 2025 16:59:12 +0200
Message-Id: <86zfjsjf7j.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN> (message from
 Daniel Colascione on Tue, 14 Jan 2025 21:42:13 -0800)
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Date: Tue, 14 Jan 2025 21:42:13 -0800
> From: Daniel Colascione <dancol@HIDDEN>
> 
> The adaptive read buffering code delays reads in the hope that we can read in buffer chunks if we wait a
> little bit between reads from a process producing a lot of output. Sounds good. Doesn't work. The attempted
> optimization reduces performance in various scenarios and causes an 8x regression in performance for me
> in flows involving mixtures of big and small reads.
> 
> With adaptive reading, we increase the read delay every time we get a short read and decrease it when we
> get a full buffer of data or do a write.  The problem is 1) that there are legitimate flows involving long
> sequences of reads without an intervening write and 2) reads (especially from PTYs) may *never* report a
> full buffer because the kernel limits the maximum read size no matter how big the backlog is. (For example,
> the Darwin kernel limits PTY (and presumably TTY in general?) reads to 1024 bytes, but the default Emacs
> read size is 64k, so we never recognize a signal that we should reduce the read delay.
> 
> I'd suggest just deleting the feature. It's not worth the complexity and edge cases, IMHO.
> 
> If that's not an option, I'd suggest detecting bulk flows by doing a zero timeout select() after we're tempted to
> increase the delay and actually increasing the delay only when that select times out.
> 
> Just tweaking the maximum read size probably isn't a good idea: it's an implementation detail and can
> change with time and over the types of FD from which we read.

AFAICS, this feature can be disabled by setting
process-adaptive-read-buffering to the nil value, either globally or
let-binding it around start-process.  Does that solve your problems,
and if so, can we conclude that Emacs allows both using the feature
and disabling it.

AFAIR, in some situation this was really useful, otherwise we wouldn't
have set it to t by default.

Or maybe we should introduce a new special value of
process-adaptive-read-buffering, which would be equivalent to nil when
reading from PTYs, if that case can never benefit from these delays?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Daniel Colascione <dancol@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Jan 2025 15:38:02 +0000
Resent-Message-ID: <handler.75574.B75574.173695543926813 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Cc: 75574 <at> debbugs.gnu.org
Date: Wed, 15 Jan 2025 07:37:10 -0800
From: Daniel Colascione <dancol@HIDDEN>
User-Agent: K-9 Mail for Android
In-Reply-To: <86zfjsjf7j.fsf@HIDDEN>
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
 <86zfjsjf7j.fsf@HIDDEN>
Message-ID: <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>



On January 15, 2025 6:59:12 AM PST, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> Date: Tue, 14 Jan 2025 21:42:13 -0800
>> From: Daniel Colascione <dancol@dancol=2Eorg>
>>=20
>> The adaptive read buffering code delays reads in the hope that we can r=
ead in buffer chunks if we wait a
>> little bit between reads from a process producing a lot of output=2E So=
unds good=2E Doesn't work=2E The attempted
>> optimization reduces performance in various scenarios and causes an 8x =
regression in performance for me
>> in flows involving mixtures of big and small reads=2E
>>=20
>> With adaptive reading, we increase the read delay every time we get a s=
hort read and decrease it when we
>> get a full buffer of data or do a write=2E  The problem is 1) that ther=
e are legitimate flows involving long
>> sequences of reads without an intervening write and 2) reads (especiall=
y from PTYs) may *never* report a
>> full buffer because the kernel limits the maximum read size no matter h=
ow big the backlog is=2E (For example,
>> the Darwin kernel limits PTY (and presumably TTY in general?) reads to =
1024 bytes, but the default Emacs
>> read size is 64k, so we never recognize a signal that we should reduce =
the read delay=2E
>>=20
>> I'd suggest just deleting the feature=2E It's not worth the complexity =
and edge cases, IMHO=2E
>>=20
>> If that's not an option, I'd suggest detecting bulk flows by doing a ze=
ro timeout select() after we're tempted to
>> increase the delay and actually increasing the delay only when that sel=
ect times out=2E
>>=20
>> Just tweaking the maximum read size probably isn't a good idea: it's an=
 implementation detail and can
>> change with time and over the types of FD from which we read=2E
>
>AFAICS, this feature can be disabled by setting
>process-adaptive-read-buffering to the nil value, either globally or
>let-binding it around start-process=2E  Does that solve your problems,
>and if so, can we conclude that Emacs allows both using the feature
>and disabling it=2E

Well, I mean, Emacs is free software, so in theory users can disable any b=
ug with enough elbow grease, even ones we don't know about=2E I have the ra=
dical idea that it shouldn't be slow by default and that users shouldn't ha=
ve to manually disable known bugs=2E

>AFAIR, in some situation this was really useful, otherwise we wouldn't
>have set it to t by default=2E

Plenty of questionable things sound like good ideas at the time=2E

>Or maybe we should introduce a new special value of
>process-adaptive-read-buffering, which would be equivalent to nil when
>reading from PTYs, if that case can never benefit from these delays?

Even if you were to limit the adaptive reading to pipes and sockets, you'd=
 still have the problem with trying to guess the maximum read size even if =
you limit the mechanism to pipes=2E It's just broken=2E I don't see a reaso=
n to continue to maintain the complexity=2E What are we saving? A few conte=
xt switches, maybe? Machines are fast enough that we don't need to make a q=
ueue form for the sake of batching=2E

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 15 Jan 2025 15:57:02 +0000
Resent-Message-ID: <handler.75574.B75574.173695658130308 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75574
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Daniel Colascione <dancol@HIDDEN>
Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org
Received: via spool by 75574-submit <at> debbugs.gnu.org id=B75574.173695658130308
          (code B ref 75574); Wed, 15 Jan 2025 15:57:02 +0000
Received: (at 75574) by debbugs.gnu.org; 15 Jan 2025 15:56:21 +0000
Received: from localhost ([127.0.0.1]:58401 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tY5kj-0007sm-8n
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:56:21 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:40368)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tY5kh-0007sR-99
 for 75574 <at> debbugs.gnu.org; Wed, 15 Jan 2025 10:56:20 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tY5kZ-0003fM-Ow; Wed, 15 Jan 2025 10:56:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=FKTM3tMjx+WXnWqlU1LtwAXX2ZZ4/2jEFhsxOyQ+brk=; b=g6V7oJaMBIFZ
 V6QJ/nyEFXTE1oURwH3VXTp41nUagRXJgQ+2nE4G5Vk79B1PFpdFBvPtvAYchtQ5CZdwExIkrA36q
 sj3xnIWINiY11ZPgGRQUGGZrhm0iE+ybJd3fi6MCPKHNqojcEHF6XPdeSDXJRKWXB00EKoRn+tOF9
 FkdFgrNMcd+euiru5TlqqW1Zf+9gDmfpezX4wpCPIN+MXp++J9iaqjKoNAFmjLxi7JLtr5xWiXlCG
 ySld5tQ6/Qzd4c/A1hPCvF/sG/1MuZLjQzUAFbMPTyPdVdNhjCkQAZXGQMZ21TKcGUI/vrFq50sQi
 00hyWaWBwIzAmsK47oJMFQ==;
Date: Wed, 15 Jan 2025 17:56:04 +0200
Message-Id: <86msfsjckr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN> (message from
 Daniel Colascione on Wed, 15 Jan 2025 07:37:10 -0800)
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
 <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Wed, 15 Jan 2025 07:37:10 -0800
> From: Daniel Colascione <dancol@HIDDEN>
> CC: 75574 <at> debbugs.gnu.org
> 
> 
> 
> On January 15, 2025 6:59:12 AM PST, Eli Zaretskii <eliz@HIDDEN> wrote:
> >> Date: Tue, 14 Jan 2025 21:42:13 -0800
> >> From: Daniel Colascione <dancol@HIDDEN>
> >> 
> >> The adaptive read buffering code delays reads in the hope that we can read in buffer chunks if we wait a
> >> little bit between reads from a process producing a lot of output. Sounds good. Doesn't work. The attempted
> >> optimization reduces performance in various scenarios and causes an 8x regression in performance for me
> >> in flows involving mixtures of big and small reads.
> >> 
> >> With adaptive reading, we increase the read delay every time we get a short read and decrease it when we
> >> get a full buffer of data or do a write.  The problem is 1) that there are legitimate flows involving long
> >> sequences of reads without an intervening write and 2) reads (especially from PTYs) may *never* report a
> >> full buffer because the kernel limits the maximum read size no matter how big the backlog is. (For example,
> >> the Darwin kernel limits PTY (and presumably TTY in general?) reads to 1024 bytes, but the default Emacs
> >> read size is 64k, so we never recognize a signal that we should reduce the read delay.
> >> 
> >> I'd suggest just deleting the feature. It's not worth the complexity and edge cases, IMHO.
> >> 
> >> If that's not an option, I'd suggest detecting bulk flows by doing a zero timeout select() after we're tempted to
> >> increase the delay and actually increasing the delay only when that select times out.
> >> 
> >> Just tweaking the maximum read size probably isn't a good idea: it's an implementation detail and can
> >> change with time and over the types of FD from which we read.
> >
> >AFAICS, this feature can be disabled by setting
> >process-adaptive-read-buffering to the nil value, either globally or
> >let-binding it around start-process.  Does that solve your problems,
> >and if so, can we conclude that Emacs allows both using the feature
> >and disabling it.
> 
> Well, I mean, Emacs is free software, so in theory users can disable any bug with enough elbow grease, even ones we don't know about. I have the radical idea that it shouldn't be slow by default and that users shouldn't have to manually disable known bugs.
> 
> >AFAIR, in some situation this was really useful, otherwise we wouldn't
> >have set it to t by default.
> 
> Plenty of questionable things sound like good ideas at the time.

It wasn't just a good idea, though.  It actually helped fix some use
cases.

> >Or maybe we should introduce a new special value of
> >process-adaptive-read-buffering, which would be equivalent to nil when
> >reading from PTYs, if that case can never benefit from these delays?
> 
> Even if you were to limit the adaptive reading to pipes and sockets, you'd still have the problem with trying to guess the maximum read size even if you limit the mechanism to pipes. It's just broken. I don't see a reason to continue to maintain the complexity. What are we saving? A few context switches, maybe? Machines are fast enough that we don't need to make a queue form for the sake of batching.

I see your point.

However, this area is really tricky, and supports many different usage
patterns.  There are Lisp programs that read relatively small chunks
of input from a subprocess, and then there are other programs which
read huge amounts of data.  I wouldn't risk deciding we have all of
them figured out and can conclude they all don't need this.

You can try searching the bug tracker for
process-adaptive-read-buffering, it will bring up several hits.

We could begin by setting this variable nil by default and see if
someone complains.  If enough time has passed without any complaints,
we could then consider actually removing the feature.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 10 Feb 2025 20:57:01 +0000
Resent-Message-ID: <handler.75574.B75574.173922097111208 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75574
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN>
Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org
Received: via spool by 75574-submit <at> debbugs.gnu.org id=B75574.173922097111208
          (code B ref 75574); Mon, 10 Feb 2025 20:57:01 +0000
Received: (at 75574) by debbugs.gnu.org; 10 Feb 2025 20:56:11 +0000
Received: from localhost ([127.0.0.1]:52722 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1thap8-0002uh-OO
	for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 15:56:11 -0500
Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:47211)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1thap3-0002u1-6w
 for 75574 <at> debbugs.gnu.org; Mon, 10 Feb 2025 15:56:08 -0500
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5de4a8b4f86so5375512a12.2
 for <75574 <at> debbugs.gnu.org>; Mon, 10 Feb 2025 12:56:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1739220959; x=1739825759; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=eSX+RZiaUjlCd7kuhMTNN6/Ij0xTkZMT4N9zcjf2U98=;
 b=iKHYqvwtAqCwAYp1IhGFHLVV0m+v5oJUEwzhJk5KsSA4bSd3yT7A7zmC7SFepwlX1W
 OUL6M+6vGMYRqeKISTNdm6IhtJrf27fN9c88cEeKNJ12pz9y+eNiixIR4dWtc5S7QmqR
 4RlM0oTkVrJV7GWnQtdDOjKKFhPLDFGy6aTYmrTn2CHv2IL22NC1EG4HUiWVg2hPAMWC
 b2+HsvWaFmxAHbrKyW2ZjwAV1Rqp2z8Iqr08topM6KGl1HuPmybKI5w3Wa3745kdQoNU
 C844bF576NZSRj3IlQMRPd3+HavKMIy6Fi4coElY/R4mM2D1fVJtUdytE0Axc2FwWdzO
 K6NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1739220959; x=1739825759;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=eSX+RZiaUjlCd7kuhMTNN6/Ij0xTkZMT4N9zcjf2U98=;
 b=qM/L13PL1PpyUxYW4qtOITbYMTAw7mxFxMDy19T0rW7X7A49ZQcAbTtfxodvYGKqbG
 dApz5VpGGwq9676EjO8pJsI7uVhU6Qq/O78+W2KzyU5/X6CfmRKOMvAN+HQy5gHl6u+H
 BSkhKP+ziCDuliCCfUISr9sriewwNldlsWCv0TGaCa580A7n5nRtZWjVvI/pCX52si1v
 hi5eAp1KQ5WK9I4OjD/eRrSOh/iwihCtDeqWSRrND2xsFYwHq1N0M4o38JKXdUXxSRlY
 vtMxNJrozqtNUGN8Sq9y4ia6OIiP05Y5fB6IzLDpzdB0cFc+SVK6/+kkAOke+nnrKBCM
 4M/A==
X-Forwarded-Encrypted: i=1;
 AJvYcCVSd0VQ8HeGzGXfS2jJtVg4c7auZR52n64/sObxS8GGGIzWOpVAOzKotT+3znPU4whkve7qxQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwZKjBEazqgklqIciswMe76hT3HgW/4mzlDIuNfArngwuR8jKgm
 /LEAm1Q5BY7+rDOlqSv8x13iwFzWyBrmCyhVaW1eWxLAF9Bts/5R2GHTPg3D66G1e4ilXLfvRyy
 829WZOvshDO5YSdWnI8WqIYvGflQ=
X-Gm-Gg: ASbGncuYzJi/1UHYOu0zxCVqdnoMwn9Nr+9/se93ppYNBYpCtOWQieucc+XVnjn+b2M
 pyrJU/G5uSGqyExGHMz9LcD6RpjKBsPdChiRcyOMf5WcRnaqRV2iNTUyEEiq8RUdTDlEYoEACPQ
 ==
X-Google-Smtp-Source: AGHT+IHEi2Wb02rr1PlKBqpouCYpvJChceGhCVQofwxa3F0/kpXhqc9lbbx+xqZG92Tx8orSU5R6Oiw1xUR6+4hcKRI=
X-Received: by 2002:a50:aad0:0:b0:5db:da94:6e7e with SMTP id
 4fb4d7f45d1cf-5de45073388mr11932655a12.24.1739220958673; Mon, 10 Feb 2025
 12:55:58 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Mon, 10 Feb 2025 12:55:58 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <86msfsjckr.fsf@HIDDEN>
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
 <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN>
 <86msfsjckr.fsf@HIDDEN>
MIME-Version: 1.0
Date: Mon, 10 Feb 2025 12:55:58 -0800
X-Gm-Features: AWEUYZnyW3kie2Rz1hu81mLdpnXJrCfim1JhyCtDd0ilo4FxzLkW1ZmPFltH6zg
Message-ID: <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

> It wasn't just a good idea, though.  It actually helped fix some use
> cases.

There is evidence that setting it to nil solved issues too:

https://yhetil.org/emacs-bugs/13742752.post@HIDDEN/
https://yhetil.org/emacs-bugs/1B2B2EF98D55CB41BD16F13B18B9B0080303EF48@HIDDEN/
https://yhetil.org/emacs-bugs/873an4b898.fsf__5420.00031932748$1214278000$gmane$org@HIDDEN/

> We could begin by setting this variable nil by default and see if
> someone complains.  If enough time has passed without any complaints,
> we could then consider actually removing the feature.

So let's do that.  I have now changed the default on master (commit
8437bcb5c96).

Does anyone object to also marking the variable as obsolete now?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Daniel Colascione <dancol@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 10 Feb 2025 21:50:01 +0000
Resent-Message-ID: <handler.75574.B75574.173922416820522 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75574
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Kangas <stefankangas@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org
Received: via spool by 75574-submit <at> debbugs.gnu.org id=B75574.173922416820522
          (code B ref 75574); Mon, 10 Feb 2025 21:50:01 +0000
Received: (at 75574) by debbugs.gnu.org; 10 Feb 2025 21:49:28 +0000
Received: from localhost ([127.0.0.1]:52793 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1thbeh-0005Kw-Op
	for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 16:49:28 -0500
Received: from dancol.org ([2600:3c01:e000:3d8::1]:54356)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1thbed-0005Kk-AD
 for 75574 <at> debbugs.gnu.org; Mon, 10 Feb 2025 16:49:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; 
 s=x;
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:
 References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=ctFCakl3LJpzYpu3ffuuW1MtY7sGCuibNgDKA08oXuY=; b=K0sPeOqz2AfJfpPnL9rvVUpd6C
 FkEo887EqiR0QzpUbdDT4RhkD0j2AoBG35NqGT0/HpSaR5IezeOysw+mTapPF7vK4cSxaEERWBOKM
 36YjJKSqWA7Uw7K4yC686mZb1U1JB8o23CBLyIQ0wGBFVWVuUay6KOBmu7ZnHO095Xqb48vFmPvW4
 7wIOMrOk5sV0t2ucT8B47uPTa92gEeqqQCep5Zk6XCFc34wOp30dlfpHkILCBPYiXAbRhtYaiVkJ0
 oDqAus6vneHJHhuvRhujinsK1871zZHFAiXk/L2na6zFH0KTVpTjpkFnznyRx3g2SuSTDfVR2SZN2
 WJ+ADS4w==;
Received: from [2600:1010:b057:e5c0:0:42:cdde:4d01] (port=38478
 helo=[IPv6:::1])
 by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1thbeV-0001Ue-0L;
 Mon, 10 Feb 2025 16:49:15 -0500
Date: Mon, 10 Feb 2025 13:49:14 -0800
From: Daniel Colascione <dancol@HIDDEN>
User-Agent: K-9 Mail for Android
In-Reply-To: <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN>
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
 <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN>
 <86msfsjckr.fsf@HIDDEN>
 <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN>
Message-ID: <6802F8B6-764D-4214-BA94-2ED9722D79F1@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On February 10, 2025 12:55:58 PM PST,
 Stefan Kangas <stefankangas@HIDDEN>
 wrote: >Eli Zaretskii <eliz@HIDDEN> writes: > >> It wasn't just a good idea, 
 though. It actually helped fix some use >> ca [...] 
 Content analysis details:   (1.1 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 LOTS_OF_MONEY          Huge... sums of money
 1.1 MONEY_NOHTML           Lots of money in plain text
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.1 (/)



On February 10, 2025 12:55:58 PM PST, Stefan Kangas <stefankangas@gmail=2E=
com> wrote:
>Eli Zaretskii <eliz@gnu=2Eorg> writes:
>
>> It wasn't just a good idea, though=2E  It actually helped fix some use
>> cases=2E
>
>There is evidence that setting it to nil solved issues too:
>
>https://yhetil=2Eorg/emacs-bugs/13742752=2Epost@talk=2Enabble=2Ecom/
>https://yhetil=2Eorg/emacs-bugs/1B2B2EF98D55CB41BD16F13B18B9B0080303EF48@=
FFBRUE001=2Ecfmu=2Ecorp=2Eeurocontrol=2Eint/
>https://yhetil=2Eorg/emacs-bugs/873an4b898=2Efsf__5420=2E00031932748$1214=
278000$gmane$org@ambire=2Elocaldomain/
>
>> We could begin by setting this variable nil by default and see if
>> someone complains=2E  If enough time has passed without any complaints,
>> we could then consider actually removing the feature=2E
>
>So let's do that=2E  I have now changed the default on master (commit
>8437bcb5c96)=2E
>
>Does anyone object to also marking the variable as obsolete now?


Thanks=2E I hadn't gotten around to doing it myself=2E Obsolete sounds goo=
d to me=2E

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 11 Feb 2025 12:22:01 +0000
Resent-Message-ID: <handler.75574.B75574.173927649715060 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75574
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Kangas <stefankangas@HIDDEN>
Cc: dancol@HIDDEN, 75574 <at> debbugs.gnu.org, eggert@HIDDEN
Received: via spool by 75574-submit <at> debbugs.gnu.org id=B75574.173927649715060
          (code B ref 75574); Tue, 11 Feb 2025 12:22:01 +0000
Received: (at 75574) by debbugs.gnu.org; 11 Feb 2025 12:21:37 +0000
Received: from localhost ([127.0.0.1]:54744 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1thpGi-0003uo-N0
	for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 07:21:37 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:35030)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1thpGf-0003uW-Ad
 for 75574 <at> debbugs.gnu.org; Tue, 11 Feb 2025 07:21:34 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1thpGY-0005tO-ND; Tue, 11 Feb 2025 07:21:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=bl6vI4jG9DDD7MvIYCR/43ee0rbXtoKkmHcfuHNs8yc=; b=K69x2Ko6JQ28
 wlctLHkIzhzVpa5aEpwWOrIRBXxeWdogw8GiqK8b3x70M+oE+m/SVyoBoE/x5iQrga64sAkcbuTJ+
 snbrAtRVTPnSs9K5fdSQZRfAVyW0XLCVuUjSdN2K6uU6uYRnJ/wuL/UT6i4+WjoEk5qGjwiOgsFDX
 1XzRvA4v+XnQ/TOsaKQGkgOqCDIt10CTwRu7qFjFwqyUHTRgIRJCU87ZVs3mpYXi3/xej6kcSEM/L
 9Q+fkQJnKqZyU9F4c1gB3GmMGHXsbIdyfLPe9tV/XRSS7eBks29re1QQ1UzqzcEAOI6ZtJ+S0VNpE
 w1dhROVOnoFA61Ob5lnZBA==;
Date: Tue, 11 Feb 2025 14:21:23 +0200
Message-Id: <86cyfoy8n0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN>
 (message from Stefan Kangas on Mon, 10 Feb 2025 12:55:58 -0800)
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
 <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN>
 <86msfsjckr.fsf@HIDDEN>
 <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefankangas@HIDDEN>
> Date: Mon, 10 Feb 2025 12:55:58 -0800
> Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > It wasn't just a good idea, though.  It actually helped fix some use
> > cases.
> 
> There is evidence that setting it to nil solved issues too:
> 
> https://yhetil.org/emacs-bugs/13742752.post@HIDDEN/
> https://yhetil.org/emacs-bugs/1B2B2EF98D55CB41BD16F13B18B9B0080303EF48@HIDDEN/
> https://yhetil.org/emacs-bugs/873an4b898.fsf__5420.00031932748$1214278000$gmane$org@HIDDEN/
> 
> > We could begin by setting this variable nil by default and see if
> > someone complains.  If enough time has passed without any complaints,
> > we could then consider actually removing the feature.
> 
> So let's do that.  I have now changed the default on master (commit
> 8437bcb5c96).
> 
> Does anyone object to also marking the variable as obsolete now?

I suggest to first see if the new setting causes any problems.
There's no need to hurry with obsoleting it, since un-obsoleting is a
problematic process, as we've seen in the past.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75574: Adaptive read buffering is a pessimization
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 02 Mar 2025 03:54:02 +0000
Resent-Message-ID: <handler.75574.B75574.174088758630812 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75574
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: dancol@HIDDEN, 75574 <at> debbugs.gnu.org, eggert@HIDDEN
Received: via spool by 75574-submit <at> debbugs.gnu.org id=B75574.174088758630812
          (code B ref 75574); Sun, 02 Mar 2025 03:54:02 +0000
Received: (at 75574) by debbugs.gnu.org; 2 Mar 2025 03:53:06 +0000
Received: from localhost ([127.0.0.1]:49369 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1toaO1-00080u-LF
	for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:53:05 -0500
Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:42304)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1toaNz-0007zu-7f
 for 75574 <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:53:04 -0500
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5e4ce6e3b8cso4578752a12.1
 for <75574 <at> debbugs.gnu.org>; Sat, 01 Mar 2025 19:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1740887577; x=1741492377; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=31VKElxShqZ29kzgT/3Jv7G6ldmI0EP8GihWuV330YM=;
 b=Bm1KursDYUlccuxQevH9wCMGxchJftbNxDx4oh6xPeckt2LUIZy7mDMOXI3pMlzmNi
 ntfKIJ/W9cutNm2eg8NSkMYTpzMSDJAv/0ug8rpfFWrZxlqRDqYiRnlyJQFebrea//nb
 AMHpiWGxZwBUY3J2VNrcUvM5Kft0auhrFRu33ze+DspZu0qzyz1+cnm7ADkWj9Fam6lx
 tuavB+IyWnljEg0gejpgslIFhS0D8uIo8I0U/HFmtwSnrAd2E6xPuCBQ8EQMWaBmOjjO
 EDdK2aI/OIYdQTDwZwG3TrGooqDxKHgHJGmZgdRYfqgrsMZvwHON4JLXTo/t0GR0gSC2
 iIGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1740887577; x=1741492377;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=31VKElxShqZ29kzgT/3Jv7G6ldmI0EP8GihWuV330YM=;
 b=F0k1dvMsc7WQDVoDD10k3WLFQzIVQOSZL2qSP4JPsvZYJnUaJpib3ffSPw66G8Aeg0
 dMXDm+iP+fjwnxjVKDQea//OIlNFYhM6ANQKuiKt0tsNql9yStWVgoq8lIa9j4VO4o+E
 vPI063SzoLEO7Ao7TeKa0ao9iOk/NMcCjeRP6Hi1hPPZaoHhiuI4t1scryNwnm2BNRCi
 Tz/L9+6x2lq5mFADqY+Nn+x+9fSHihBAFpjgqxhUviJJDfUr67+dWE0/QnfnOVgcSiS7
 h5Fk4uTA+Mlj2a3p6c8Ucqn4AFoM7K5ZV54mCiLrLsuTcshh0NoyQ7ujTq88lvWjjnC+
 U4+Q==
X-Forwarded-Encrypted: i=1;
 AJvYcCULtA1AmPe+8lKocK6vqEDHKlFhljD/XzNhMW1+ESEjt71jg5Cerwy5BXmfeEcLZRNF+e9dpg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyCJ4TT9cNPKsyE9fS+f7g8Em33Py/T0TCmMrUdlyozGBjDC/Zu
 ye7aJqjEBtqg7NYw7E4wUg3vHUpMf69HuD3QNKWqi34L3LqzH8NHk8hGXyPZTcsLFZzFwuelGfl
 abhBnnlNGvCY6e3DnDBek0T6INDI=
X-Gm-Gg: ASbGnctvv//XP5SihRIpAu3q6uLoZM25g5wW8iErQKlwu+3je4O26/thQYHzBjKQho/
 klHAgsGqIFu4jkN8UgLWYnoZzNBw9xZ+GJFxBj4lx8JbGCy2pey1NmeE00yYo6C2MKlkc3n3S/j
 pm1hw+CVhK41782rMvnM5SiXup0g==
X-Google-Smtp-Source: AGHT+IHOYMsgiYUyZuHkJnezP9kCl9hMJY6Kn6DguYhH2I/ywYNMNO8bZTcervAb+WPzT7gJQNvAWIFCNnHvGOe0e7M=
X-Received: by 2002:a50:d708:0:b0:5e0:7df0:6623 with SMTP id
 4fb4d7f45d1cf-5e4bfaa6cbdmr13025436a12.6.1740887577173; Sat, 01 Mar 2025
 19:52:57 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Sat, 1 Mar 2025 19:52:56 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <86cyfoy8n0.fsf@HIDDEN>
References: <895A7BFF-F56E-4C62-B6B7-A3BE83D32556@HIDDEN>
 <86zfjsjf7j.fsf@HIDDEN> <E3E2AE74-4B75-4888-8AE2-A4F9100B51E9@HIDDEN>
 <86msfsjckr.fsf@HIDDEN>
 <CADwFkmmMuQ_XV-1+YVQMTLvuOVmT4f3UHKiTxf5ZY5-Fnsipwg@HIDDEN>
 <86cyfoy8n0.fsf@HIDDEN>
MIME-Version: 1.0
Date: Sat, 1 Mar 2025 19:52:56 -0800
X-Gm-Features: AQ5f1JqNiG_oltL89h4JI_gJ1juLBOfhDF-2uFDTGibzxcUr9dMD1aFN8vi3_BU
Message-ID: <CADwFkmnTrCZRTjzGAfduu28yQEh+E6wjNnXtqKJXJHeTOxKj_A@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Stefan Kangas <stefankangas@HIDDEN>
>> Date: Mon, 10 Feb 2025 12:55:58 -0800
>> Cc: eggert@HIDDEN, 75574 <at> debbugs.gnu.org
>>
>> Does anyone object to also marking the variable as obsolete now?
>
> I suggest to first see if the new setting causes any problems.
> There's no need to hurry with obsoleting it, since un-obsoleting is a
> problematic process, as we've seen in the past.

OK, let's wait a bit.

I'm leaving this bug open as a reminder to consider doing this later.

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 2 Mar 2025 03:53:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 01 22:53:11 2025
Received: from localhost ([127.0.0.1]:49372 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1toaO7-00081q-1R
	for submit <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:53:11 -0500
Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:50423)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1toaO4-00080R-1T
 for control <at> debbugs.gnu.org; Sat, 01 Mar 2025 22:53:08 -0500
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5e04064af07so6091974a12.0
 for <control <at> debbugs.gnu.org>; Sat, 01 Mar 2025 19:53:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1740887582; x=1741492382; darn=debbugs.gnu.org;
 h=to:subject:message-id:date:mime-version:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=L8KW79gG8RwrlkjsnhoYu2ohKMABq+JUJ2FefYQQQZ8=;
 b=XjM8fP2xivcWLKFz9SNoPy/cmUyriSblLrkaobm6DL9+Nxzz1ollJ6b9yQKJR4ckgP
 akmT91cN639MtJG/Rsz7D6vBy7bKN10ATl2aIGn9W7LW6xv61gpWz3pHxjayUjBaHY3w
 GgJoaZAWMezeLzQ2bGd0meX4xJOMsbalveGYd3Ywf4kqcVD1w1IjkEMtRP6SXPnM8E7l
 TcIwabQqmNTbfHs9oM5awkxZ2/lZm9R5d7dNFoSiAmsVhNksOqadEQLqE3anyz1vZhfD
 jkwiVcZU1MnDUgcIuVzZceZU7w/eo8DIh0lMUfgeGjJDxs9n8pHCIGNLDdQev/2R1nIB
 pqvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1740887582; x=1741492382;
 h=to:subject:message-id:date:mime-version:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=L8KW79gG8RwrlkjsnhoYu2ohKMABq+JUJ2FefYQQQZ8=;
 b=FA4NiczvPKGMvPA4CGuE0vS1Vi1xpFrzQRsTPOmTEG7Xy8eysp0PfcjoP8g9AZnGMA
 SSYIy94s/iwPnxAAsmTJ92TM0ofFQJ77dxDcUjS4GUF5AN24unqiCqqowLGvWEW2JZT1
 IF8GwRURRiqEjqaP615FgZC3sEGhmNQPyG8aptMttZ2YunWcBKbXJ7cpPH3AIaCMaSKy
 LW+oAX+j+vUafa/bR7iMlcSSqDmmUfoB9nFWMt1w3R2eNv2jcNGFo5nqYoz3YGjOtmRg
 VS3fhywTODfpsCPJCCNk4tEzSXehXg9hK1eO4ovh6rKG7uLgc8OR/L6sesU6nFchmFeu
 FFcw==
X-Gm-Message-State: AOJu0Yyo47VLl+GL4HeqUCEg1THF6J6vFABD57UIAFtrsk3bhdkKjWsO
 nSKTKJTDkWk0bKalIzbi+I/TPdeei1MFtXAPuO2VdyLk+p0BYIrQ9yUyk+Q5wbWRHaEQFmtCaRR
 2Gx7WWvRLcLL1sbKON2d9qrL9JAFwENLzntk=
X-Gm-Gg: ASbGncspmPXaUacUqy6d2zmjjhRqy1AMhcKJg0iyySr+U86SA/U9QmxcBQRSzsz0sKQ
 NT4Bx4VJg2eDhw768QIh0IeM37RqO0jNxil8kBNWGyRcT8Ss66dlLnh1M2qHn+qDo4y0Ecered7
 YkrRj9XDeOyYKACP2lExVxE6Z7oQ==
X-Google-Smtp-Source: AGHT+IG9vpQRmFieCtoXArlhijU1qa/JS0KnGD4O9xMpc2cB5yPKJDm7sdwoqj5aslBKwMSXfexPIjXlhUIGYrHWOrU=
X-Received: by 2002:a05:6402:3582:b0:5e0:2e70:c2af with SMTP id
 4fb4d7f45d1cf-5e4d6b62663mr7851289a12.26.1740887581698; Sat, 01 Mar 2025
 19:53:01 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Sun, 2 Mar 2025 03:53:01 +0000
From: Stefan Kangas <stefankangas@HIDDEN>
MIME-Version: 1.0
Date: Sun, 2 Mar 2025 03:53:01 +0000
X-Gm-Features: AQ5f1JprDrZMg6GiPEUVBpJ0x0kDX1ZMsfNt8y1kuZGSz4QR8Wyd7FkSUOsgMEE
Message-ID: <CADwFkm=nHLt-qOh6Qzmgs5izCmr=TSxMbtCUmCs5OGmOtVOueQ@HIDDEN>
Subject: control message for bug #75574
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

severity 75574 wishlist
quit

Last modified: Sun, 2 Mar 2025 04:00:02 UTC

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