Reduce "$HOME/foo/baz.png" to "~/foo/baz.png"

[0ion9]

This is a fairly straightforward change that makes some long absolute paths easier to read at the cost of slightly increased complexity in update_info()

The only related possible change I can think of that might be reasonable to incorporate is, thumbs.c also reads $HOME. Since this PR makes homedir a global variable, thumbs.c could be simplified slightly by just using the global variable instead.

EDIT: actually, neither main.c nor thumbs.c simply 'reads $HOME'. I didn't notice this initially, but both of them read a XDG_* variable, or HOME if that doesn't exist. Which means homedir may be set to either something like /home/me or something like /home/me/.config. That's a little hacky, and I'd like to try to fix it properly in this PR.

[N-R-K]

actually, neither main.c nor thumbs.c simply 'reads $HOME'. I didn't notice this initially, but both of them read a XDG_* variable, or HOME if that doesn't exist.

There's a couple other problems with this PR.

[N-R-K]

files.name is given by the user, as is. So this won't work if the user gave relative path.

$ cd $HOME
$ nsxiv ../user/pic/a.png

in this case, .name will be ../user/pic/a.png

[0ion9]

..that is intended. I don't see why it would make sense to shorten the absolute path in the case where the user hasn't given an absolute path. That would be confusing IMO.

[N-R-K]

Overall, I'm not too sold on this since this is something that doesn't really provide any functional benefit and is merely visual.

[0ion9]

.. isn't being able to see the filename in full a functional benefit? I made this patch because i had the font size set largish and couldn't actually see the full basename of the current image.

[N-R-K]

isn't being able to see the filename in full a functional benefit?

Replacing home with ~ doesn't fully solve that problem. Also I think what you're trying to do in this pr can be more easily done in image-info, can't it?

[0ion9]

.. No it cannot be done with image-info, as image-info doesn't apply to thumbnail mode AFAICS. Sorry i wasn't clear that this is for thumbnail mode - the actual commit message does specify that.

Agreed that $HOME abbreviation doesn't fully solve the issue. It was the answer that seemed to be moderately effective while also being uncontroversial. (as opposed to something like ellipsizing the pathname section until it fits in the bar width)

I've pushed an update, not sure yet whether I need to do something here with 'resolve conversation' to indicate it addresses these issues.

[N-R-K]

.. No it cannot be done with image-info, as image-info doesn't apply to thumbnail mode AFAICS.

Ah my bad. But now that makes me realise that if we do it for thumbnails mode, then it's probably going to be expected for this to be done on image mode as well.

I'm personally not too against the idea of drawing ellipsis at the front in case of truncation. But that's going to be messy due to utf8.

Now I'm wondering if it's worth it to just have a thumb-info as discussed here https://github.com/nsxiv/nsxiv/issues/88, which will just receive the image name.

[0ion9]

thumb-info seems like a nice idea. I would definitely have a use for it personally (sometimes I want the bar to show image-info even in thumbnail mode.)

I guess plain $HOME substitution would be less of a problem in the case that it came to be expected that the shortening was applied in image mode too. As there is no implication of adjusting directly to bar width, a user could just use sed "s,^$HOME/,~/," on the filename provided and get a comparable result.

utf8 ellipsization.. yeah, messy and either additional data or an additional dependency required.

[N-R-K]

I would definitely have a use for it personally (sometimes I want the bar to show image-info even in thumbnail mode.)

We had to abandon the thumb-info idea due to this: https://github.com/nsxiv/nsxiv/issues/88#issuecomment-1029682293

But now I'm remembering that Imlib2 claims to not decode the images straight away (if possible, might not be possible on some image formats), so maybe loading the original image to get the height/width might not be that bad performance wise.

But even if we just provide the image path as a single argument, users can still get the w/h from it via some cli tool if they wish; so I guess it won't be entirely useless.

---

@XPhyro Any thoughts on the matter?

[XPhyro]

I think this PR should just be left as a patch on nsxiv-extra, or be superseded by thumb-info.

---

On thumb-info, I don't have a pronounced opinion on whether and how we implement it. I imagine it would be useful, but would also add some unneeded complexity if we strive to provide arguments that need the image to be decoded or the metadata to be parsed.

The single-argument case you mention seems like a good balance between feature and non-complexity. This would also mean the image would not have to be processed twice if the user wants to show more than what we provide.

[N-R-K]

This would also mean the image would not have to be processed twice if the user wants to show more than what we provide.

Good point. There's cli tools for displaying things like exif data which users might want to use. For image-info passing w/h didn't matter since we already had those info.