bug#73727: dired-view-file vs. emacs -nw

bug#73727: dired-view-file vs. emacs -nw

[Dan Jacobson]

v runs the command dired-view-file which works great even on images etc.
except when the user is using emacs -nw, in which case it just spews the
a lot of binary stuff on the screen which the user was not expecting.
Therefore it should say "xyz.jpg cannot be shown properly on your
terminal." (If they really want to see the bytes, they can use
find-file.)

bug#73727: dired-view-file vs. emacs -nw

[Eli Zaretskii]

tags 73727 notabug wontfix
thanks

> From: Dan Jacobson <jidanni@jidanni.org>
> Date: Thu, 10 Oct 2024 18:41:48 +0800
> 
> v runs the command dired-view-file which works great even on images etc.
> except when the user is using emacs -nw, in which case it just spews the
> a lot of binary stuff on the screen which the user was not expecting.
> Therefore it should say "xyz.jpg cannot be shown properly on your
> terminal." (If they really want to see the bytes, they can use
> find-file.)

That's not the Emacs way.  Emacs allows users to visit any kind of
files, including those which display as binary garbage.  Moreover,
even on GUI frames, users can customize Emacs to never show image
files as images when they are visited.  Refusing to visit an image
file just because it cannot be displayed as an image is something
Emacs never did and should not do.

dired-view-file's doc string says:

  In Dired, examine a file in view mode, returning to Dired when done.
  When file is a directory, show it in this buffer if it is inserted.
  Otherwise, display it in another buffer.

There's nothing here about showing image files as images or not at
all.  Perhaps you were confused by the "view" part, but that refers to
view-mode, not to "viewing" an image.

So I don't see any bugs here, and don't think we should "fix" anything
in this matter.

bug#73727: dired-view-file vs. emacs -nw

[Dan Jacobson]

All I know is a couple more erroneous keystroks, and one ends up
accidentally editing one of these files, with its regexp parser choking
long lines... might end up using all the CPU...

bug#73727: dired-view-file vs. emacs -nw

[Eli Zaretskii]

> From: Dan Jacobson <jidanni@jidanni.org>
> Cc: 73727@debbugs.gnu.org
> Date: Fri, 11 Oct 2024 16:16:22 +0800
> 
> All I know is a couple more erroneous keystroks, and one ends up
> accidentally editing one of these files, with its regexp parser choking
> long lines... might end up using all the CPU...

dired-view-file visits the file in read-only mode, so you are not
supposed to edit it unless you really mean to...

IOW, it sounds like there was some cockpit error in your case, and you
somehow decided that it's Emacs's fault.  It isn't.

bug#73727: dired-view-file vs. emacs -nw

[Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> dired-view-file visits the file in read-only mode, so you are not
EZ> supposed to edit it unless you really mean to...

(Actually there are tons of keys that will, if held down a little too
long, end up inserting characters into the top of JPGs:

RET		dired-find-file
e .. f		dired-find-file
o		dired-find-file-other-window

Yes, users should then use "undo".)

bug#73727: dired-view-file vs. emacs -nw

[Eli Zaretskii]

> From: Dan Jacobson <jidanni@jidanni.org>
> Cc: 73727@debbugs.gnu.org
> Date: Sat, 26 Oct 2024 06:05:29 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> EZ> dired-view-file visits the file in read-only mode, so you are not
> EZ> supposed to edit it unless you really mean to...
> 
> (Actually there are tons of keys that will, if held down a little too
> long, end up inserting characters into the top of JPGs:
> 
> RET		dired-find-file
> e .. f		dired-find-file
> o		dired-find-file-other-window
> 
> Yes, users should then use "undo".)

I don't see how this changes what I already told above.

bug#73727: dired-view-file vs. emacs -nw

[Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> I don't see how this changes what I already told above.

If you used emacs -nw exclusively for two months, like I have, you would
notice even more problems.

E.g., every time the user opens an image file by accident,
they will see, along with the binary mess,
"File mode specification error: (error Display does not support images)"
It would be better to warn them
"emacs -nw has no image support.  Use find-file-literally if you really want to edit this image."
and not open the file.

What's worse is view-mode doesn't even have a warning. Sure, it is
tailored for the 1% of users who really are using emacs -nw to view the
guts of JPGs.

bug#73727: dired-view-file vs. emacs -nw

[Eli Zaretskii]

> From: Dan Jacobson <jidanni@jidanni.org>
> Cc: 73727@debbugs.gnu.org
> Date: Sat, 26 Oct 2024 16:57:44 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> EZ> I don't see how this changes what I already told above.
> 
> If you used emacs -nw exclusively for two months, like I have, you would
> notice even more problems.

I'm using "emacs -nw" all the time.  As are others.

bug#73727: dired-view-file vs. emacs -nw

[Eli Zaretskii]

> Cc: 73727@debbugs.gnu.org
> Date: Fri, 11 Oct 2024 12:28:14 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Dan Jacobson <jidanni@jidanni.org>
> > Cc: 73727@debbugs.gnu.org
> > Date: Fri, 11 Oct 2024 16:16:22 +0800
> > 
> > All I know is a couple more erroneous keystroks, and one ends up
> > accidentally editing one of these files, with its regexp parser choking
> > long lines... might end up using all the CPU...
> 
> dired-view-file visits the file in read-only mode, so you are not
> supposed to edit it unless you really mean to...
> 
> IOW, it sounds like there was some cockpit error in your case, and you
> somehow decided that it's Emacs's fault.  It isn't.

No substantial new information or comments about this in more than 2
weeks, so I'm now closing this bug.