From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?SC4tSi4gSGVpdGzDpG5kZXI=?= Newsgroups: gmane.emacs.help Subject: Re: emacs 30.5.0 editing epub Date: Thu, 16 Mar 2023 16:54:03 +0000 Message-ID: References: <87pm99830a.fsf@gmx.net> <74d91d8b-ac3c-9463-4334-9c1db8df7c13@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22571"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gnu emacs To: Yuri Khan Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 16 17:54:54 2023 Return-path: Envelope-to: geh-help-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 1pcqsP-0005et-S9 for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 16 Mar 2023 17:54:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcqrn-00081w-Od; Thu, 16 Mar 2023 12:54:15 -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 1pcqrk-00081I-8o for help-gnu-emacs@gnu.org; Thu, 16 Mar 2023 12:54:12 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcqrh-0004Pw-QW for help-gnu-emacs@gnu.org; Thu, 16 Mar 2023 12:54:11 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6CE822403E3 for ; Thu, 16 Mar 2023 17:54:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1678985646; bh=TBumABXKnq6lHvynfCYiYpLy8dyg/OwhaUtU/lOqKFo=; h=Date:Subject:To:From:Cc:From; b=ElVkDOVRPwSgvgFeiBxrhU/wO38Morxpfyirqib4jb2v8jcoWL/HBGyjbGyGrCp8N 1fvq6xZ0ZO5EBrayrP54a3kalk/LuLj5iADxafRPIKfrFKC+Lj6wiAd/13Noi3Iv7F /vgk8c0njLxegh1g+KBUki0Th4dZ58aRdq54lKCDXNd2EXCUtXuQeDUKckn1DVIIFx b5oH1YadoApstn8TrCSR7I3NTR1Xx37tICZCVOhT5P55Msp7LSobbUOgF3Sshey2FC FMYTnLjXBVoa1wZuX4Kcs2UdGaQ1dfox2g+iAvtNeyZHV+odVHicz9aPsUshQ4lo+C frAQXC7vTmVbw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PctdR3Cz7z6tpY; Thu, 16 Mar 2023 17:54:03 +0100 (CET) Content-Language: de-DE, en-GB In-Reply-To: Received-SPF: pass client-ip=185.67.36.65; envelope-from=Heiner.Heitlaender@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:143044 Archived-At: Hi Yuri, yes I keep mentioning "editing EPUB" because a) that's my primary use case at the moment (in combination with "calibre") and b) it worked some time ago. (emacs 29.5 and earlier as far as I remember) Even in this buggy scenario it is much more comfortable for me to handle EPUBs this way  than doing it by extracting the zip file and rezipping it. Especially as I lack an "idiot-safe" workflow for unzipping / rezipping. So I shall live with this situation because I can't correct it. | I see ‘archive--extract-file’ initially sets the coding system to | ‘no-conversion’, possibly because it needs that for decompression. It | is supposed to re-decide on a coding system later in | ‘archive-set-buffer-as-visiting-file’, but for some reason it keeps | ‘no-conversion’ in your case. There seems to exist a bug in the migration path somewhere from version 29 to 30. Where do I address the bug report; as I am definetely too dumb for debugging it myself? Cheers and thanks for your patience Heiner Am 16.03.23 um 16:23 schrieb Yuri Khan: > On Thu, 16 Mar 2023 at 20:17, H.-J. Heitländer > wrote: > >> kill buffer up to the top epub >> >> reopen epub >> >> open epub subfile (...html) >> >> C-x RET r ... utf-8 >> >> in minibufer: Revert buffer from file xxx.html? (y or n) >> >> Answer: y >> >> Minibuffer: Cannot revert noexistent file xxx.html > You keep mentioning “editing epub”. Are you even sure it’s supposed to work? > > An EPUB file is a zip archive, typically containing XHTML pages and > some metadata. Emacs covers some basic scenarios where you can browse > the archive, visit files inside, even edit and save them (and they get > re-compressed and updated in the archive). > > Reverting, on the other hand, does not work, probably because of the > way archive-mode is implemented. So when it picks the wrong encoding, > you cannot fix it by reverting. > > You could probably achieve better results if you first extract the > contents of the EPUB archive into a real directory on your file > system, then edit files there. If necessary, re-pack the modified > files. > > I see ‘archive--extract-file’ initially sets the coding system to > ‘no-conversion’, possibly because it needs that for decompression. It > is supposed to re-decide on a coding system later in > ‘archive-set-buffer-as-visiting-file’, but for some reason it keeps > ‘no-conversion’ in your case. >