GNU bug report logs - #14484
24.3.50; doc of `after-find-file'

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Mon, 27 May 2013 15:14:02 UTC

Severity: minor

Found in version 24.3.50

Fixed in version 26.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14484 <at> debbugs.gnu.org
Subject: bug#14484: 24.3.50; doc of `after-find-file'
Date: Fri, 29 Apr 2016 01:39:11 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> 1. The parameter is named _AFTER-FIND-FILE-FROM-REVERT-BUFFER, not
> AFTER-FIND-FILE-FROM-REVERT-BUFFER.

This is how `C-h f' on that starts:

after-find-file is a compiled Lisp function in ‘files.el’.

(after-find-file &optional ERROR WARN NOAUTO
AFTER-FIND-FILE-FROM-REVERT-BUFFER NOMODES)

So it's consistent, even if the arg is "really" _'d.

> 2. This makes no sense:
> "(see `revert-buffer-in-progress-p' for similar functionality)."
>
> Similar functionality to what?  The parameter is _ignored_!

I think it means "if this is what you used to use, use this similar
thing instead".  Seems clear to me.

> 3. And since _AFTER-FIND-FILE-FROM-REVERT-BUFFER is ignored, why
> does `recover-file' continue to make a point of using it?  Why doesn't
> it just use `(after-find-file)'?  Again, it seems like someone made an
> incomplete change to the code, neglecting to clean up here and there.

It calls

(after-find-file nil nil t)

so if it did, it's been fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




This bug report was last modified 8 years and 231 days ago.

Previous Next


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