From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: How to get buffer byte length (not number of characters)? Date: Thu, 22 Aug 2024 16:50:53 +0300 Message-ID: <86o75ksm2q.fsf@gnu.org> References: <87wmkbekjp.fsf@ushin.org> <86o75nwilg.fsf@gnu.org> <87bk1lhkvg.fsf@ushin.org> <86y14pu5rp.fsf@gnu.org> <871q2hfn7c.fsf@ushin.org> <86plq1td4n.fsf@gnu.org> <87ed6hdnpe.fsf@ushin.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27030"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joseph@ushin.org, emacs-devel@gnu.org, schwab@suse.de To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 22 15:51:46 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 1sh8E5-0006lK-Ey for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Aug 2024 15:51:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sh8DM-0000dE-Bd; Thu, 22 Aug 2024 09:51:00 -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 1sh8DK-0000d5-Oa for emacs-devel@gnu.org; Thu, 22 Aug 2024 09:50:58 -0400 Original-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 ) id 1sh8DJ-00026g-Gp; Thu, 22 Aug 2024 09:50:57 -0400 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=XutI/t7FBbGoR3frw5QdVYfWNZSX6akt8/3VeY4wrZE=; b=IfgwuGkUWHGD p7wBaA/MGrlgmTPjqAaLy6Rergxe39fNPktj5AJ0y0H31+YkpUZ/dsF+oVIAVin081JaZ8myK4dj1 cIbg0beSulH36lac6JK4FYwdAFQva//CrfxE/MJLj4NlkV394wTqMprPzFuFwohaNLknIdsKSFfUN HQbub1cMP/TwBgZoDcsh8FrU6WhogkU1btMsYsGPmVBQIoGYY1w2ne+DlTzHdripf1tkJaoHgUMcg 7esFOta/FQlXec83ODNOGewBxTCDJjndYHWjXjJe/oatnSxtiXw/Q0NQEQGmFVjJcBMFALmtNz3u1 nw7rgWH/W5HeN0t3d1jwNw==; In-Reply-To: (message from Adam Porter on Thu, 22 Aug 2024 07:26:58 -0500) 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:323046 Archived-At: > Date: Thu, 22 Aug 2024 07:26:58 -0500 > Cc: emacs-devel@gnu.org, schwab@suse.de > From: Adam Porter > > > It could be. Eli, Adam, what do you think about the default coding > > systems for encoding the request body in the attached patch? > > From an API perspective, I'm not sure. My idea for plz.el is to > provide a simple, somewhat idiomatic Elisp API for making HTTP requests > (and, of course, to make "correct" requests, in compliance with > specifications and expectations). Given the relatively few clients of > plz thus far, some issues are yet to be fully explored and developed, > and encoding/decoding may be one of those rougher edges. For the use > cases I'm aware of, it seems to work well and correctly, but there are > undoubtedly improvements to be made. > > Encoding/decoding is not exactly a simple matter, especially with regard > to API design. Ultimately, no library can abstract it away from users' > need to understand it. And I want plz's API to not have to change any > more than necessary over time, so I'd want to be very deliberate with > any changes to it. So it's appealing to do as little as possible in > this regard, leaving as much as possible to the upstream user to handle > outside of plz. But AFAICT, plz.el does decode the stuff it gets from curl, which doesn't seem to be consistent with what you say above. If plz.el would accept unibyte text and return unibyte text, that would be consistent: it would mean that any callers of plz.el need to do encoding and decoding themselves. But that doesn't seem to be the case now. Am I missing something?