From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13250 invoked from network); 2 Oct 2021 15:50:20 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 2 Oct 2021 15:50:20 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mWhHG-00EkBg-T3 for ml@inbox.vuxu.org; Sat, 02 Oct 2021 10:50:18 -0500 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1mWhHG-007fMW-Ba for ml@inbox.vuxu.org; Sat, 02 Oct 2021 10:50:18 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1mWhHE-007fMO-4m for ding@lists.math.uh.edu; Sat, 02 Oct 2021 10:50:16 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1mWhHB-005Mij-HW for ding@lists.math.uh.edu; Sat, 02 Oct 2021 10:50:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yXRYi01tfQZqMk/dAPrMhk7RG71Au0ZncxOqBr/A7lY=; b=AkXIn3GECiGeMSQWruru2CvVuy WJj4k9hKtWSe3JUd7sLZ+uowFPCbP22HSuzWs0vX22t8zVt/y/URAhk9k0qRH/UbCVmMHR1ARHivO qdaNFl4zQK8wCOPBUlH4945s4mZSks4iTaOusHXmEsvSkexr/3jHAruE5QeJfDzK/y1M=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mWhH4-0004eN-My for ding@gnus.org; Sat, 02 Oct 2021 17:50:09 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mWhH2-0004k8-Kt for ding@gnus.org; Sat, 02 Oct 2021 17:50:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: Trying to use gnus-cloud: what's the pinentry dialog? (and how can I get rid of it?) Date: Sat, 02 Oct 2021 08:49:57 -0700 Message-ID: <87o887l93u.fsf@ericabrahamsen.net> References: <86ilywektx.fsf@dod.no> <86fsu0k5w3.fsf@dod.no> <86bl4ok58z.fsf@dod.no> <867dfck4g9.fsf@dod.no> <86mto3gwkj.fsf@dod.no> <86v92rwbyw.fsf@dod.no> <86lf3nw6su.fsf@dod.no> <86czozw5mo.fsf@dod.no> <867devd5uu.fsf@dod.no> <8635pjd59t.fsf@dod.no> <86y27b4gmk.fsf@dod.no> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:kLOp8BiBsib6RjrwwE8ic7C5Z7o= List-ID: Precedence: bulk Steinar Bang writes: >>>>>> Steinar Bang : > >>> The .gnus.el file is 487 lines and (- 16241 487) is 15754 and taking the >>> 15754 ends the file in the correct place, so that seems right. > >>> What would be the best way to make this less fragile, I wonder...? > >>> The current value is just the size of the buffer: >>> https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/gnus-cloud.el#n98 > >> To take the length of data in bytes, instead of the size of the buffer, >> should be always correct, without changing any of the other assumptions >> of the code. > > I tried this, but it didn't work (still had 16241 bytes, rather than > 15754 for the .gnus.el chunk in the sync data): > > diff --git a/lisp/gnus/gnus-cloud.el b/lisp/gnus/gnus-cloud.el > index e6cf39c..48653bd 100644 > --- a/lisp/gnus/gnus-cloud.el > +++ b/lisp/gnus/gnus-cloud.el > @@ -97,11 +97,11 @@ easy interactive way to set this from the Server buffer." > (dolist (elem elems) > (cond > ((eq (plist-get elem :type) :file) > - (let (length data) > + (let (data length) > (mm-with-unibyte-buffer > (insert-file-contents-literally (plist-get elem :file-name)) > - (setq length (buffer-size) > - data (buffer-string))) > + (setq data (buffer-string) > + length (length data))) > (insert (format "(:type :file :file-name %S :timestamp %S :length %d)\n" > (plist-get elem :file-name) > (plist-get elem :timestamp) > > Where are the CRLF characters turned into LF, I wonder? > Apparently not in buffer-string...? My understanding is that conversion would have happened if you weren't using a unibyte buffer, and were using `insert-file-contents' rather than `insert-file-contents-literally'. Ie, the code is specifically set up to not do conversion.