Mime types and apps

[NorfairKing]

Issue description

Looking at the way the programs.emacs option is implemented, it looks like installing mime apps and mime types should work.
However, I have this package added to my packages and nothing about it shows up in ~/.local/share/applications or ~/.local/share/mime/text (or even ~/.nix-profile/share/applications and ~/.nix-profile/share/mime/text):

{ stdenv
}: stdenv.mkDerivation {
  name = "smos-mime-setup";
  buildCommand = ''
    # Set up the types
    mkdir -p $out/share/mime/text
    cp ${../mime/smos-text.mime-type} $out/share/mime/text/smos.xml

    # Set up the .desktop files
    mkdir -p $out/share/applications
    cp ${../mime/smos.desktop} $out/share/applications/smos.desktop
  '';
}

Technical details

I'm using home manager version 472ca211cac604efdf621337067a237be9df389e.

nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.62, NixOS, 20.03.2882.51d115ac89d (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.6`
 - channels(root): `"nixos-20.03.2882.51d115ac89d"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[NorfairKing]

For completeness sake, I've also got this:

  xdg = {
    enable = true;
    mime.enable = true;
    # Until https://github.com/rycee/home-manager/issues/1213 is solved.
    configFile."mimeapps.list".force = true;
    mimeApps.enable = true;
    # Some mimeapps here
  };

[NorfairKing]

I also tried setting programs.emacs.enable = true; and services.emacs.client.enable = true; and no .desktop file shows up either, so I'm thinking this is a real bug. @rycee

[NorfairKing]

#1439 This seems relevant. Also pinging @Kha because he's pinged there as well.

[NorfairKing]

I also tried resetting my home-manager version to https://github.com/nix-community/home-manager/commit/9f396fddc61cb649b7989f3f51389c228bad13ff, the commit where emacs' .desktop file is added, but even then I don't get a .desktop file anywhere it seems.

[rycee]

The files should show up in /etc/profiles/per-user/$USER/share or $HOME/.nix-profile/share and from there be picked up through $XDG_DATA_DIRS.

[NorfairKing]

@rycee Yes that's also how I understand it, but they don't and I have no clue why.

Edit: To be clear: both the emacsclient and my new files don't show up.

[NorfairKing]

I also pushed my code here: NorfairKing/smos@9721d02 in case you want to see the details.

[NorfairKing]

@rycee I wrote a regression test in #1499 Does that help to figure out what the problem is?

[NorfairKing]

It looks like this was a false-positive. It looks like there are some special cases for text for example and you're supposed to put your mime type file in .local/share/mime/packages instead of .local/share/mime/text for example. (strace ftw!)

[NorfairKing]

Ok now I'm extra confused.
I got things working on my desktop computer. (xdg-open something.smos) opens that file in smos.
But then I tried the same thing out on my laptop and I get this:

$ xdg-open ~/something.smos             
/run/current-system/sw/bin/xdg-open: line 883: www-browser: command not found
/run/current-system/sw/bin/xdg-open: line 883: links2: command not found
/run/current-system/sw/bin/xdg-open: line 883: elinks: command not found
/run/current-system/sw/bin/xdg-open: line 883: links: command not found
/run/current-system/sw/bin/xdg-open: line 883: lynx: command not found
/run/current-system/sw/bin/xdg-open: line 883: w3m: command not found
xdg-open: no method available for opening '/home/syd/something.smos

It looks like the files are in the right places and have the right contents:

$ cat /etc/profiles/per-user/syd/share/mime/packages/smos.xml
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
  <mime-type type="application/smos">
    <glob pattern="*.smos"/>
  </mime-type>
</mime-info>

$ cat /etc/profiles/per-user/syd/share/applications/smos.desktop 
[Desktop Entry]
Type=Application
Exec=smos %u
Name=Smos
Terminal=true
MimeType=application/smos

cat  ~/.local/share/applications/mimeapps.list 
[Added Associations]

[Default Applications]
application/smos=smos.desktop

[Removed Associations]

Even weirder is that xdg-mime says the right thing:

$ xdg-mime query default application/smos

smos.desktop

[NorfairKing]

Two (?) reboots later it seems to work. I'm not sure why that is, but once we figure that out, I can add the relevant command to #1499 and get the tests to pass, i think.

[sareyko]

$ xdg-open ~/something.smos             
/run/current-system/sw/bin/xdg-open: line 883: www-browser: command not found
/run/current-system/sw/bin/xdg-open: line 883: links2: command not found
/run/current-system/sw/bin/xdg-open: line 883: elinks: command not found
/run/current-system/sw/bin/xdg-open: line 883: links: command not found
/run/current-system/sw/bin/xdg-open: line 883: lynx: command not found
/run/current-system/sw/bin/xdg-open: line 883: w3m: command not found
xdg-open: no method available for opening '/home/syd/something.smos

[...]

Even weirder is that xdg-mime says the right thing:

$ xdg-mime query default application/smos

smos.desktop

From experience I can say that the output of xdg-mime and what xdg-open actually does do not correlate most of the time.

The actual behavior of xdg-open actually depends on things like $DISPLAY, the desktop environment being used and the existence of other tools like run-mailcap and mimeopen.
IIRC xdg-open tries to use all kinds of web browsers as fallback application to open files.
If you have a bit of time to spare and want to experience a few WTF-moments just open xdg-open in your favorite editor (xdg-open is actually just a shell script) and have a look.

Actually, I have the following hack in my HM configuration to make the behavior of xdg-open somewhat predictable:

let
  runMailcap = pkgs.writeScriptBin "run-mailcap" ''
    #!${pkgs.stdenv.shell}

    # Skip first argument
    ${pkgs.perlPackages.FileMimeInfo}/bin/mimeopen "''${@:2}"
  '';
in {
  home.packages = [ runMailcap ];
}

[NorfairKing]

@sareyko Thanks, that makes me feel a lot less stupid about this situation! Do you think it's better to give up on getting the test in #1499 to pass?

[sareyko]

I just had a quick look at #1499 and I'm not familiar with testing in HM, but to me those tests don't make any sense at all as HM test cases. This is because I don't see any of the HM modules actually being tested in there.

[NorfairKing]

@sareyko I'm happy to just close the PR but my understanding is different: There is something going on between reboots that fixes xdg-open and I am hoping that that's something that can be triggered automatically so that a reboot is not necessary, like update-mime-database. This would something that the HM module for xdg-mime is responsible for.

[sareyko]

I'd agree with you there @NorfairKing. But AFAICT the xdg-mime module does not provide or depend on xdg-open. And since xdg-open is merely a tool that might use the .desktop files in some situations I don't feel like it is valid to base the tests on it.

IMO a valid way to define a test would be by reading and understanding the relevant XDG specs and basing the tests on that without relying on any external tools that might (incorrectly) implement said specs.

Apart from that your xdg-mime query test probably depends on an entry in mimeapps.list which you'd need to enable (and make use of) the xdg-mime-apps module for.

[NorfairKing]

Aha! Now I better understand your view, let's just close the PR then, because I can't justify the time to go through that spec at the moment.

[sareyko]

Don't get me wrong, I'm just trying to help out with understanding the mess that is xdg-utils.
But since I'm not even a contributor to HM you should probably wait with closing the PR until someone more knowledgeable in HM chimes in?