panel: implement string_file_ext() for extension column display

[karpovilia]

Proposed changes

The extension panel field used string_file_name as its display callback, showing the full filename instead of just the extension. The code already had a TODO comment acknowledging this (// TODO: string_file_ext).

This PR adds two new panel format fields:

• extension — displays only the file extension (part after last dot). Empty for directories and extensionless files.
• basename — displays the filename without extension (without the trailing dot). For directories, identical to the full name.

Example format: half basename | extension | size | mtime

Both fields are documented in the man page.

Checklist

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

[zyv]

Suggested change

	string_file_ext (const file_entry_t *fe, int len)
	{
	const char *ext;
	(void) len;
	ext = extension (fe->fname->str);
	string_file_ext (const file_entry_t *fe, MC_UNUSED int len)
	{
	const char *ext = extension (fe->fname->str);

[zyv]

Please remove; the changelog for the next release is collected on the wiki and updated during the release process.

[egmontkob]

Shouldn't you also add basename as a possible column? I can't see how either of basename and extension is useful without the other.

[egmontkob]

'basename' might be a misleading terminology to use; see e.g. https://stackoverflow.com/questions/13362022/what-do-you-call-a-file-name-without-the-extension

[karpovilia]

'basename' might be a misleading terminology to use; see e.g. https://stackoverflow.com/questions/13362022/what-do-you-call-a-file-name-without-the-extension

@egmontkob, thanks! basename (displays the filename without extension) added, news cleared, proposed changes updated.

[egmontkob]

I still don't quite get where this is going, why it's deemed useful, nor how the details are worked out.

You add to the documentation: "For directories and files without an extension, ...". For me, it parses like "For (either directories or files) without an extension, ...". This is not what the code does. What the code does is better described by something like "For directories, and for files without an extension, ...".

Why is that, though? Why do you want to handle directories differently?

For "dotfiles" ("hidden files") that begin with a dot, the entire filename is treated as the extension. I don't think it's desireable.

The entire idea of trying to autodetect the extension is a weak heuristics only. There's /etc/ld.so.conf.d, /etc/mysql/my.cnf.fallback, mybook.pdf.bak, stuff.tar.gz, /etc/gtk-2.0, config.h.in, foo.cc.template, mc-4.8.33, mc.1 or mc.1.gz, libfoo.so.1.2.3..., it's unclear to me how applying some heuristisc (separating at the last dot) which gets it semantically wrong so many times is deemed useful.

Both basename and extension are silently truncated if too long and don't fit in the space. Just like with the full filename, truncation should be denoted and the contents should scroll horizontally for Alt-( and Alt-).

Basename and extension receive equally wide space, even though in practice the basename is usually quite long, while the extension is usually up to 4 characters. That's quite a waste of the often scarce real estate. Would it make sense to make the Extension column be 4 characters narrow (and scrollable, as per the previous point)?

Honestly, I'd just remove the current broken "extension" support. What's your story, your use case, why would you find this feature (with its inherently often incorrect guess) useful?