Re: Image handling in mutt

2023-12-11 Thread jeremy ardley
On 12/12/23 01:49, Jeremy Nicoll wrote: There's no concept of filetype in file systems used for the MVS side of z/OS systems. (These days there's also Unix/Linux environments & of course they do have more familiar file naming structures.) If you look at the NTFS file system - supported by

Re: Image handling in mutt

2023-12-11 Thread songbird
debian-u...@howorth.org.uk wrote: > songbird wrote: >> wrote: >> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: >> >> wrote: >> >> there is rarely a need to e-mail me directly. >> >> >> ... >> >> > That's why I cringe when people name executables "foo.sh". What >> >> > do

Re: Image handling in mutt

2023-12-11 Thread Jeremy Nicoll
On Mon, 11 Dec 2023, at 13:16, Greg Wooledge wrote: > 4) File extensions are used by programs on every operating system. Certainly on many OSes, but not all. They're not present on native RISC OS systems (as in ex-Acorn micros). Filetype data IS stored, but it is in files' metadata. There's

Re: Image handling in mutt

2023-12-11 Thread David Wright
On Mon 11 Dec 2023 at 10:03:38 (-0500), Pocket wrote: > On 12/11/23 09:52, David Wright wrote: > > On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote: > > > > On Dec 10, 2023, at 3:05 PM, David Wright wrote: > > > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: > > > > > > On

Re: Image handling in mutt

2023-12-11 Thread tomas
On Mon, Dec 11, 2023 at 10:10:31AM -0500, Stefan Monnier wrote: [...] > I think what you're saying is that it would make sense to use > a dedicated extension for executables, like, say, `.exe`, > since "all users rely on it being" executable. I'd prefer ".com", but hey ;-) > FWIW, I agree, but

Re: Image handling in mutt

2023-12-11 Thread David Wright
On Mon 11 Dec 2023 at 10:07:28 (+1100), Zenaan Harkness wrote: > > Second, how do I fix this so that mutt uses feh to display images? > > Here is my mailcap entry, which works for me - had to deal with > annoying filename munging by mutt, and getting the "close the viewer" > bit working - this is

Re: Image handling in mutt

2023-12-11 Thread debian-user
songbird wrote: > wrote: > > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: > >> wrote: > > there is rarely a need to e-mail me directly. > > >> ... > >> > That's why I cringe when people name executables "foo.sh". What > >> > do you do when you decide to rewrite the thing

Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 09:34:09 -0500, Pocket wrote: > On 12/11/23 09:04, Vincent Lefevre wrote: > > On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote: > > > 2) When *receiving* email, mutt will use the sender's MIME type label > > > to decide how to deal with the attachment. > > But the notion of

Re: Image handling in mutt

2023-12-11 Thread Stefan Monnier
> (Note that I'd even make a difference: where the implementation matters, > e.g. some shell code to be sourced in, I'd be more lenient in calling > the thing ".sh": after all, its users rely on it being shell code. When > you can change the implementation without changing the function, e.g. > a

Re: Image handling in mutt

2023-12-11 Thread Pocket
On 12/11/23 09:52, David Wright wrote: On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote: On Dec 10, 2023, at 3:05 PM, David Wright wrote: On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: On Fri 08 Dec 2023 at

Re: Image handling in mutt

2023-12-11 Thread tomas
On Mon, Dec 11, 2023 at 08:52:37AM -0600, David Wright wrote: > On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote: [...] > > File names in Linux are a character string of 255 chars. Again there are > > not file extensions in a Linux file name. > > > > People are conflating the issue. > >

Re: Image handling in mutt

2023-12-11 Thread David Wright
On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote: > > On Dec 10, 2023, at 3:05 PM, David Wright wrote: > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: > >>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: > >>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M

Re: Image handling in mutt

2023-12-11 Thread Pocket
On 12/11/23 09:34, Vincent Lefevre wrote: On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote: On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote: I do not care about the "microsoft world", and I doubt that this is required there at the low level (what would be the equivalent

Re: Image handling in mutt

2023-12-11 Thread tomas
On Mon, Dec 11, 2023 at 03:34:28PM +0100, Vincent Lefevre wrote: > On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote: > > On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote: > > > I do not care about the "microsoft world", and I doubt that this is > > > required there at the low

Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote: > On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote: > > I do not care about the "microsoft world", and I doubt that this is > > required there at the low level (what would be the equivalent of the > > Linux kernel) [...] > >

Re: Image handling in mutt

2023-12-11 Thread Pocket
On 12/11/23 09:04, Vincent Lefevre wrote: On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote: 2) When *receiving* email, mutt will use the sender's MIME type label to decide how to deal with the attachment. But the notion of filename extension is even used in this context too. Quoting the

Re: Image handling in mutt

2023-12-11 Thread tomas
On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote: [...] > I do not care about the "microsoft world", and I doubt that this is > required there at the low level (what would be the equivalent of the > Linux kernel) [...] This depends: the FAT file system (which still is the lowest

Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote: > 2) When *receiving* email, mutt will use the sender's MIME type label >to decide how to deal with the attachment. But the notion of filename extension is even used in this context too. Quoting the Mutt manual:

Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 07:32:30 -0500, Pocket wrote: > > On 12/11/23 07:12, Vincent Lefevre wrote: > > On 2023-12-10 15:51:02 -0500, Pocket wrote: > > > On Dec 10, 2023, at 3:05 PM, David Wright > > > wrote: > > > > ¹ Re the argument raging in this thread about "extension", the > > > > term is clearly

Re: Image handling in mutt

2023-12-11 Thread Greg Wooledge
On Mon, Dec 11, 2023 at 01:41:09PM +0100, Arno Lehmann wrote: > I do not see the relevance of the discussion about file name extensions, > types, suffixes for Debian. Even more so as you are at the stage of > repeating statements without bringing new value. In fact, there seems to be > no goal

Re: Image handling in mutt

2023-12-11 Thread Loris Bennett
David writes: > Hi, the filename extension is usually irrelevant on Linux, because > Linux tools typically > use the standard 'file' command to inspect the content of the > fileinstead of relying on > the filename to indicate content. It is very often not irrelevant for files that you might

Re: Image handling in mutt

2023-12-11 Thread Eric S Fraga
On Monday, 11 Dec 2023 at 07:32, Pocket wrote: > No it is microsoft non sense I'm not an MS fanboi but please stop blaming MS for something they did not invent! -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: Image handling in mutt

2023-12-11 Thread Arno Lehmann
All, I do not see the relevance of the discussion about file name extensions, types, suffixes for Debian. Even more so as you are at the stage of repeating statements without bringing new value. In fact, there seems to be no goal with this thread. I would ask you to continue this

Re: Image handling in mutt

2023-12-11 Thread Pocket
On 12/11/23 07:12, Vincent Lefevre wrote: On 2023-12-10 15:51:02 -0500, Pocket wrote: On Dec 10, 2023, at 3:05 PM, David Wright wrote: ¹ Re the argument raging in this thread about "extension", the term is clearly appropriate, as a glance at /etc/mime.types demonstrates. The literature

Re: Image handling in mutt

2023-12-11 Thread Pocket
On 12/11/23 06:39, Vincent Lefevre wrote: On 2023-12-08 17:06:15 -0500, Pocket wrote: On 12/8/23 16:53, David wrote: Hi, the filename extension is usually irrelevant on Linux, because Linux tools typically use the standard 'file' command to inspect the content of the fileinstead of relying

Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-10 15:51:02 -0500, Pocket wrote: > On Dec 10, 2023, at 3:05 PM, David Wright wrote: > > ¹ Re the argument raging in this thread about "extension", the > > term is clearly appropriate, as a glance at /etc/mime.types > > demonstrates. The literature is full of the term. > > > > I

Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-08 17:06:15 -0500, Pocket wrote: > On 12/8/23 16:53, David wrote: > > Hi, the filename extension is usually irrelevant on Linux, because > > Linux tools typically > > use the standard 'file' command to inspect the content of the > > fileinstead of relying on > > the filename to indicate

Re: Image handling in mutt

2023-12-10 Thread songbird
wrote: > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: >> wrote: there is rarely a need to e-mail me directly. >> ... >> > That's why I cringe when people name executables "foo.sh". What do you >> > do when you decide to rewrite the thing in C (or Rust, or whatever)? >> > >> > Do

Re: Image handling in mutt

2023-12-10 Thread Zenaan Harkness
> Finally, occasionally I need to cleanly dump html, this one seems a bit > simpler: > > text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s I meant "cleanly _view_ html ..."

Re: Image handling in mutt

2023-12-10 Thread Zenaan Harkness
> Second, how do I fix this so that mutt uses feh to display images? Here is my mailcap entry, which works for me - had to deal with annoying filename munging by mutt, and getting the "close the viewer" bit working - this is quite a few years ago and now I can't even remember why the ; test=test

Re: Image handling in mutt

2023-12-10 Thread Pocket
Sent from my iPad > On Dec 10, 2023, at 3:05 PM, David Wright wrote: > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: >>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: >>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: I'm on Debian

Re: Image handling in mutt

2023-12-10 Thread David Wright
On Sun 10 Dec 2023 at 19:48:29 (+0100), to...@tuxteam.de wrote: > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: > > wrote: > > ... > > > That's why I cringe when people name executables "foo.sh". What do you > > > do when you decide to rewrite the thing in C (or Rust, or whatever)? >

Re: Image handling in mutt

2023-12-10 Thread David Wright
On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote: > On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: > > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: > > > > > > I'm on Debian bookworm, using neomutt for email. Where there is an image > > > to > > > view,

Re: Image handling in mutt

2023-12-10 Thread tomas
On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote: > wrote: > ... > > That's why I cringe when people name executables "foo.sh". What do you > > do when you decide to rewrite the thing in C (or Rust, or whatever)? > > > > Do you go over all calling sites and change the caller's code? > >

Re: Image handling in mutt

2023-12-10 Thread songbird
wrote: ... > That's why I cringe when people name executables "foo.sh". What do you > do when you decide to rewrite the thing in C (or Rust, or whatever)? > > Do you go over all calling sites and change the caller's code? no, i would just consider it a transition or a change in versions. :)

Re: Image handling in mutt

2023-12-10 Thread tomas
On Sun, Dec 10, 2023 at 04:15:22PM -, Curt wrote: > On 2023-12-09, Eric S Fraga wrote: > > On Friday, 8 Dec 2023 at 17:06, Pocket wrote: > >> In Unix and Linux there isn't a file extension, that is a microsoft > >> invention. > > > > Predates MS by years. Systems like RSTS/E on PDP-11s,

Re: Image handling in mutt

2023-12-10 Thread Curt
On 2023-12-09, Eric S Fraga wrote: > On Friday, 8 Dec 2023 at 17:06, Pocket wrote: >> In Unix and Linux there isn't a file extension, that is a microsoft >> invention. > > Predates MS by years. Systems like RSTS/E on PDP-11s, just to name one. They certainly are convenient. I must be stupid

Re: Image handling in mutt

2023-12-09 Thread Eric S Fraga
On Friday, 8 Dec 2023 at 17:06, Pocket wrote: > In Unix and Linux there isn't a file extension, that is a microsoft > invention. Predates MS by years. Systems like RSTS/E on PDP-11s, just to name one. -- Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: Image handling in mutt

2023-12-08 Thread Pocket
On 12/8/23 17:55, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote: Greg writes: cc(1) and make(1) would like to have a talk with you. Those are applications and can do whatever they want. The OS does not care about extensions. What do you consider "the OS"

Re: Image handling in mutt

2023-12-08 Thread Pocket
On 12/8/23 18:17, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 05:59:58PM -0500, Pocket wrote: On 12/8/23 17:54, Greg Wooledge wrote: cc(1) looks at the file extension to decide what kind of content each named argument file is expected to contain. No it looks for a suffix So Debian files

Re: Image handling in mutt

2023-12-08 Thread Greg Wooledge
On Fri, Dec 08, 2023 at 05:59:58PM -0500, Pocket wrote: > On 12/8/23 17:54, Greg Wooledge wrote: > > cc(1) looks at the file extension to decide what kind of content each > > named argument file is expected to contain. > No it looks for a suffix So Debian files have "suffixes" and Windows files

Re: Image handling in mutt

2023-12-08 Thread mick.crane
On 2023-12-08 22:55, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote: Greg writes: > cc(1) and make(1) would like to have a talk with you. Those are applications and can do whatever they want. The OS does not care about extensions. What do you consider "the

Re: Image handling in mutt

2023-12-08 Thread Pocket
On 12/8/23 17:54, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote: On 12/8/23 17:31, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote: In Unix and Linux there isn't a file extension, that is a microsoft invention. cc(1) and make(1)

Re: Image handling in mutt

2023-12-08 Thread Greg Wooledge
On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote: > Greg writes: > > cc(1) and make(1) would like to have a talk with you. > > Those are applications and can do whatever they want. The OS does not > care about extensions. What do you consider "the OS" to be, then?

Re: Image handling in mutt

2023-12-08 Thread Greg Wooledge
On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote: > > On 12/8/23 17:31, Greg Wooledge wrote: > > On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote: > > > In Unix and Linux there isn't a file extension, that is a microsoft > > > invention. > > cc(1) and make(1) would like to have a talk

Re: Image handling in mutt

2023-12-08 Thread Pocket
On 12/8/23 17:41, Pocket wrote: On 12/8/23 17:31, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote: In Unix and Linux there isn't a file extension, that is a microsoft invention. cc(1) and make(1) would like to have a talk with you. Linux/Unix filenaming specs

Re: Image handling in mutt

2023-12-08 Thread John Hasler
Greg writes: > cc(1) and make(1) would like to have a talk with you. Those are applications and can do whatever they want. The OS does not care about extensions. -- John Hasler j...@sugarbit.com Elmwood, WI USA

Re: Image handling in mutt

2023-12-08 Thread Pocket
On 12/8/23 17:31, Greg Wooledge wrote: On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote: In Unix and Linux there isn't a file extension, that is a microsoft invention. cc(1) and make(1) would like to have a talk with you. Linux/Unix filenaming specs would like to inform you. file

Re: Image handling in mutt

2023-12-08 Thread Greg Wooledge
On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote: > In Unix and Linux there isn't a file extension, that is a microsoft > invention. cc(1) and make(1) would like to have a talk with you.

Re: Image handling in mutt

2023-12-08 Thread Pocket
On 12/8/23 16:53, David wrote: On Fri, 8 Dec 2023 at 21:45, Paul M Foster wrote: On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: I'm on Debian bookworm, using neomutt for email. Where there is an image to view,

Re: Image handling in mutt

2023-12-08 Thread David
On Fri, 8 Dec 2023 at 21:45, Paul M Foster wrote: > On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: > > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: > > > I'm on Debian bookworm, using neomutt for email. Where there is an image > > > to > > > view, viewing it in

Re: Image handling in mutt

2023-12-08 Thread Paul M Foster
On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote: > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: > > > > I'm on Debian bookworm, using neomutt for email. Where there is an image to > > view, viewing it in neomutt calls up one of the ImageMagick programs. I've > > set

Re: Image handling in mutt

2023-12-08 Thread David Wright
On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: > > I'm on Debian bookworm, using neomutt for email. Where there is an image to > view, viewing it in neomutt calls up one of the ImageMagick programs. I've set > the mailcap_path variable in my neomutt config to point to ~/.mailcap,