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.bugs Subject: bug#51523: 29.0.50; gnus-mime-view-part-externally very slow Date: Mon, 01 Nov 2021 18:46:14 +0200 Message-ID: <83zgqnlt7t.fsf@gnu.org> References: <87v91dmcyz.fsf@gnus.org> <7b7f5641fcf9629c6074@heytings.org> <875ytcwxp7.fsf@gnus.org> <6abcac838b0dd46d94cf@heytings.org> <87sfwgvi73.fsf@gnus.org> <6abcac838bc0f53a0f78@heytings.org> <6abcac838bb83b0904d7@heytings.org> <6abcac838b7f89ee4e21@heytings.org> <831r3zncow.fsf@gnu.org> <6abcac838b521de77925@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5563"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51523@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 01 17:47:14 2021 Return-path: Envelope-to: geb-bug-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 1mhaSj-00017N-FP for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Nov 2021 17:47:09 +0100 Original-Received: from localhost ([::1]:52522 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhaSh-0003On-Fd for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Nov 2021 12:47:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhaSb-0003OQ-WB for bug-gnu-emacs@gnu.org; Mon, 01 Nov 2021 12:47:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52664) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhaSb-0002Wj-NM for bug-gnu-emacs@gnu.org; Mon, 01 Nov 2021 12:47:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mhaSb-00085b-JA for bug-gnu-emacs@gnu.org; Mon, 01 Nov 2021 12:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Nov 2021 16:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51523 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 51523-submit@debbugs.gnu.org id=B51523.163578520431070 (code B ref 51523); Mon, 01 Nov 2021 16:47:01 +0000 Original-Received: (at 51523) by debbugs.gnu.org; 1 Nov 2021 16:46:44 +0000 Original-Received: from localhost ([127.0.0.1]:35977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mhaSJ-000854-9s for submit@debbugs.gnu.org; Mon, 01 Nov 2021 12:46:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mhaS4-00084Z-Mv for 51523@debbugs.gnu.org; Mon, 01 Nov 2021 12:46:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35722) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhaRx-0001yD-S4; Mon, 01 Nov 2021 12:46:21 -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=2YkxRz9ZxDHJ9t3w0AQ9POsRvb797enOYMcOh/1pXHg=; b=LF26LJ5S/8Fv JfVOO3Za+8qYeA4ze0kvj/4s4gd43WOP9PYZOUR7ueUPLl7dJgEoMy1GEWuWHNIOF+rAhxXrbT86a TEWs6aWcyXOHdW571i15bycV7SYoGnQ1UG4AumBHbbGVTcHE8kxiOT73oow30cTGHZdCsOpJoJiKA JnJUFHe5geNOwU0QLQGMdY7v2PiajJRXwWhdCgnXoYjMYSWYz4iO1mRtFc85q49wGZXwbCTgt1rPe xeQIQdBuJUDYLKuDSK9zpG0FXScDKtHO8Yxot7XI788QI6hMrE+1NTVOQFQcPZAJxQTAl9f0WvUIK iLZdKQ+ZeNGkSXkNRc/vew==; Original-Received: from [87.69.77.57] (port=3258 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhaRx-0002nY-Ap; Mon, 01 Nov 2021 12:46:21 -0400 In-Reply-To: <6abcac838b521de77925@heytings.org> (message from Gregory Heytings on Mon, 01 Nov 2021 15:20:38 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:218771 Archived-At: > Date: Mon, 01 Nov 2021 15:20:38 +0000 > From: Gregory Heytings > cc: 51523@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > > > . it uses the literal file name without even expanding it to an absolute file name, so the same FILE might mean different files if default-directory changes > > . file names are generally not reliable enough for unique identifiers of files (think symlinks on all systems, letter-case and numerical tails on Windows, etc.), so we should at least use file-truename > > . interning the file names could produce many unnecessary symbols in the global obarray > > > > Can we make the implementation more robust by fixing these? > > > > Sure, I'll do that. Am I right that the first two points are fixed by > using file-truename, and that the third one would be fixed by using > (intern ... nil)? Yes for the first two, but I don't understand the last one: using nil as the 2nd argument is the same as omitting it, and they both stand for the global obarray. You need to specify a different obarray to avoid "polluting" the global one. > > The name of the function also doesn't reflect what it does: it only > > looks at the file's last modification time, so maybe at least "time" > > should be in the name? > > Perhaps we could also check the file size? If what we really want is to detect changes in contents, yes, I think we should also check the size. > > I also question the decision of testing modification time for equality: > > why not check if the time stamp is newer, and disregard the changes to > > an older time stamp? > > This wouldn't be right I think, because the user might replace a file with > another one with an older modification time. What would be the purpose of replacing with an older file, but keeping the old time stamp? And why is Gnus obligated to support such strange use cases? We can always tell the users to bump the file's time stamp by 'touch'ing it, no? > > When looking this way at this function, I ask myself whether extending > > file-newer-than-file-p to do this job would be a better idea? > > You mean, using file-newer-than-file-p with two identical arguments? No, that'd be silly. I mean something like (file-newer-than-file-p FILE t) should have the special meaning of doing what file-has-changed-p does now. > > Or maybe I don't understand the general use case for this function. > > The use case is the one of this bug: check whether a file has changed > since the last invocation of file-has-changed-p. But then the time stamp and the size might not be enough. What if the inode changed, for example? > It's used to solve this bug: mailcap-parse-mailcaps parses the > mailcap files again only when at least one of them has changed. Yes, but the function is supposed to be more general than just this one case, and I'm asking about the more general use of it.