bug#49144: 28.0.50; find-file-literally asks whether to visit literally

bug#49144: 28.0.50; find-file-literally asks whether to visit literally

[Eli Zaretskii]

To reproduce:

  emacs -Q
  M-x find-file-literally RET LARGE_FILE RET

Emacs asks:

  File LARGE_FILE is large (XX.Y MiB), really open? (yes, no, literally, ?):

But I already asked for it to be visited literally...

In GNU Emacs 28.0.50 (build 1441, i686-pc-mingw32)
 of 2021-06-20 built on HOME-C4E4A596F7
Repository revision: aefe8fe65a4fb0d426007b03ff02b96a3d35c715
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny dired dired-loaddefs rfc822
mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc seq byte-opt gv bytecomp byte-compile cconv
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 57155 11436)
 (symbols 48 7770 1)
 (strings 16 21554 2008)
 (string-bytes 1 629928)
 (vectors 16 13263)
 (vector-slots 8 170727 11078)
 (floats 8 23 130)
 (intervals 40 261 79)
 (buffers 888 10))

bug#49144: 28.0.50; find-file-literally asks whether to visit literally

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> To reproduce:
>
>   emacs -Q
>   M-x find-file-literally RET LARGE_FILE RET
>
> Emacs asks:
>
>   File LARGE_FILE is large (XX.Y MiB), really open? (yes, no, literally, ?):
>
> But I already asked for it to be visited literally...

Yup.  This should now be fixed.

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

bug#49144: 28.0.50; find-file-literally asks whether to visit literally

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 49144@debbugs.gnu.org
> Date: Mon, 21 Jun 2021 14:58:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To reproduce:
> >
> >   emacs -Q
> >   M-x find-file-literally RET LARGE_FILE RET
> >
> > Emacs asks:
> >
> >   File LARGE_FILE is large (XX.Y MiB), really open? (yes, no, literally, ?):
> >
> > But I already asked for it to be visited literally...
> 
> Yup.  This should now be fixed.

Thanks, closing.