Hyper: Support XDG

[caleb531]

Hi,

I just discovered Hyperterm today and I'm really liking the idea of a web-based terminal (I use Atom as my code editor of choice). However, reading through the documentation, I noticed that configuring the editor (plugins and all) creates several files in your home directory (_i.e._ ~/.hyperterm.js and ~/.hyperterm_plugins). I also found issues on this repo like #10 and #14 which propose a possible custom stylesheet file (as well as the addition of an Extensions API).

I'd prefer not to clutter my home directory with more hidden files, if possible. Therefore, I feel that all of these files should be consolidated under a single ~/.hyperterm directory, similar to Atom's. It could have the following structure:

.hyperterm/
- plugins/
  - ...
- config.js
- styles.css (future)

...and whatever else might be added.

I figure to migrate current users to the new hierarchy, some backwards-compatibility code could be added which does the following:

1. Use .hyperterm for all configuration/plugins if the directory exists
2. If it does not exist, create a new .hyperterm directory and move ~/.hyperterm.js and ~/.hyperterm_plugins to their new respective paths

Thoughts? :)
Caleb

[mcchrish]

Or XDG directories.

[webdesserts]

I would highly recommend using the XDG Base Directory Specification and create a hyperterm folder under $XDG_CONFIG_HOME || ~/.config/. For example, neovim now uses this instead of the classic .vimrc & .vim/ folder and I would love it if I could manage the config for all of my apps under a similar folder.

[okabsd]

I've suggested a future-facing change in patch #170 for supporting cross platform config directories (including partial support of the XDG Base Directory Spec). I would argue it's best to make this change sooner rather than later.

[sindresorhus]

HyperTerm should store it in app.getPath('userData'). For example on macOS, apps use ~/Library/Application Support for app data, not the home directory.

[OJFord]

HyperTerm should store it in app.getPath('userData'). For example on macOS, apps use ~/Library/Application Support for app data, not the home directory.

While that might be appropriate for a 'traditional' Mac 'App', hyperterm should use $XDG_CONFIG_HOME, where I can find and edit it.

[danielbayley]

I set XDG_CONFIG_HOME to ~/Library/Application Support, so you are _both_ right… 😄

[OJFord]

That only works if that's where you want everything else that obeys XDG stored.

I can't see that anybody seriously wants shell, editor, and other CLI tools' configuration stored in Application Support...

[webdesserts]

@OJFord uhhh... sounds like @danielbayley is an anybody, no?

[danielbayley]

That only works if that's where you want everything else that obeys XDG stored.

I do… constantly toggling ‘show hidden files’ gets annoying, as does everything constantly forcing junk into my HOME folder without the option not to.

[OJFord]

I don't. What place has a Finder preference in an hyperterm discussion?

"Toggling hidden files" is accomplished easily with -a.

The point here is to have choice; then we both be happy.

On Tue, 13 Sep 2016, 02:19 Daniel Bayley, [email protected] wrote:

That only works if that's where you want everything else that obeys XDG
stored.

I do… constantly toggling ‘show hidden files’ gets annoying, as does
everything constantly forcing junk into my HOME folder without the option
not to.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zeit/hyperterm/issues/137#issuecomment-246545017, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADw2HskB8I3TiC8iSB4QceEkJCnM18bIks5qpfofgaJpZM4JN4NB
.

[sindresorhus]

While that might be appropriate for a 'traditional' Mac 'App'

HyperTerm _is_ a traditional Mac app. As is Chrome.

iTerm, for example, store preferences in ~/Library/Preferences/com.googlecode.iterm2.plist.

hyperterm should use $XDG_CONFIG_HOME, where I can find and edit it.

If you're on Linux, that's what app.getPath('userData') will use. On macOS and Windows, $XDG_CONFIG_HOME is not a convention.

[OJFord]

HyperTerm is a traditional Mac app. As is Chrome.

By 'traditional' I meant "installed via App Store" or "used by non-technical users".

HyperTerm on the other hand is used by many who might otherwise - or do alternately - use Linux anyway.

iTerm, for example, store preferences in ~/Library/Preferences/com.googlecode.iterm2.plist.

Which is annoying. And not the same as the directory which your claiming is so standard and conventional. It also may not last.

On macOS and Windows, $XDG_CONFIG_HOME is not a convention.

Can you name anything else (non-Electron; so not hit by the same problem) that follows the XDG spec on Linux, but ignores it on macOS?

Shells use it, vim uses it; anything that I use on both Linux and Mac respects it on Mac as well.

I'm not saying don't fallback on whatever ~/Library path - just that if the XDG paths exist, they should be used.

[danielbayley]

The point here is to have choice; then we both be happy.

I agree… I’m not sure what the debate here even is? HyperTerm should just respect _XDG_ and then everyone is happy, and the user can just set it to whatever they think it should be.

[matheuss]

We're wasting time here. IMHO there's no point on not respecting $XDG_CONFIG_HOME if process.env.XDG_CONFIG_HOME !== undefined.

[octref]

@matheuss
As you said, we just need to make a decision.
Do you mind if I send a PR using app.getPath('userData') as @sindresorhus suggested?

This resolves to:

%APPDATA%\Hyper on Windows
$XDG_CONFIG_HOME/Hyper or ~/.config/Hyper on Linux
~/Library/Application Support/Hyper on macOS

[OJFord]

@octref

As [matheuss] said, we just need to make a decision.
...
~/Library/Application Support/Hyper on macOS

Actually, he said:

there's no point on not respecting $XDG_CONFIG_HOME if process.env.XDG_CONFIG_HOME !== undefined

So can we _please_ do:

if (process.env.XDG_CONFIG_HOME !== undefined) {
    path = process.env.XDG_CONFIG_HOME + '/hyper';
} else {
    path = app.getPath('userData');
}

until such time as Electron does this (essentially) itself? (I'm 85% sure I've seen an issue on it, trying to find.)

[octref]

@OJFord

So it boils down to which one you use on OS X. But XDG_CONFIG_HOME is not an official thing on OS X. Even using ~/.hyper makes more sense, as this is what Atom does.

[OJFord]

@octref On how many Linux distros is XDG_CONFIG_HOME an "official thing"? Just Arch?

In the snipped I posted above, it will be used if it is available. There is zero chance of a macOS-using developer having the environment variable set and not wanting to use it (even if some software set it itself because it didn't exist - which I've seen - at least Hyper would be reusing something known to be in use).

If it is not set, fall back on your suggestion, which will use %APPDATA%, ~/.config (the XDG check now being redundant), or ~/Library/Application Support according to platform.

[octref]

@OJFord

Electron does its fair share of respect for XDG_CONFIG_HOME on Linux.
If 99% of people don't set their XDG_CONFIG_HOME on Mac, and 99% of Mac app doesn't use XDG_CONFIG_HOME, supporting it on Mac only adds confusion.

Atom, VSCode, Slack, and a lot other popular Electron app all use ~/Library/Application Support on Mac.
Hyper should follow the convention.

Seems someone already did it #170. I'll just wait for it to land.

[OJFord]

@octref

99% of Mac app doesn't use XDG_CONFIG_HOME

This just isn't true though!

• Hyper users are developers or otherwise 'powerusers'
• Developers or 'powerusers' use Unix tools
• Many Unix tools respect XDG spec
• Unix tools which don't respect XDG spec are asked to by their users
• What shell will be used with Hyper? Modern ones (e.g. fish, xonsh) use $XDG_CONFIG_HOME, but even if not, they certainly won't be using ~/Library/Application Support/!

Even if your 99% _is_ true, it's not good statistics. How many of those 99% apps are configured on the command line? Not many. Of those not many, how many are using ~/Library/Application Support? I would think roughly none - they'll be ~/.appname.config or similar.

I don't want to vim ~/Library/Application\ Support/Hyper/config.js to change my config when I don't feel like using, or don't remember to use, like right now).

I also don't want to manually symlink that location to my backed-up/version-controlled dotfiles. I don't have to do anything (other than git clone and set the env var) if $XDG_CONFIG_HOME is used. Even if $HOME is used, at least all I have to do is cd $XDG_CONFIG_HOME && stow hyper.

As @matheuss said, what's the harm in using $XDG_CONFIG_HOME if it exists?! If you're so concerned that it's "not an official thing", then fine, $HYPER_CONFIG_DIR, anything, just don't mandate that I use some obscure directory because it's what non-developer tools that will never be configured from a command line use under the hood.

[octref]

@OJFord
Hyper is not a CLI app. It's first an Electron app. Then it's a Mac app on macOS.
Mac app and Electron app both says app data should be stored in ~/Library/Application\ Support.

XDG just isn't a convention on macOS. Can you name one major Electron app that uses XDG dir on macOS?
If not, why don't you open a PR for HYPER_CONFIG_DIR?

[matheuss]

@octref why you're so against it? I don't see any cons on supporting XDG_CONFIG_HOME if it's set on the user's system. Your point other electron apps don't do this makes no sense.

[OJFord]

Hyper is not a CLI app.

No, it's the app that gives me the CLI!

Can you name one major Electron app that uses XDG dir on macOS?

The only relevant Electron app I can name is Atom, where this issue is also complained about - and it doesn't follow XDG on Linux either currently anyway.

If not, why don't you open a PR for HYPER_CONFIG_DIR?

Why? It's so quick and easy to implement - the hard part is agreeing on something, which we're hopefully in the process of doing here. I'll happily write it if it comes to that, but I don't care about the credit for something so trivial, so let's discuss first before we rush to having several competing config dir PRs...

[octref]

@OJFord

No, it's the app that gives me the CLI!

So it's not a CLI app.

The only relevant Electron app I can name is Atom

So following XDG is not a convention for Electron app on macOS.

@matheuss

Not following the convention. Supporting a non-standard. Need to document another non-standard behavior.
A specific env var dedicated to hyper like ATOM_HOME would be much better.

I've said all I want to say. I just hope the maintainer could make a decision and not leave the PR #170 lingering.

[OJFord]

No, it's the app that gives me the CLI!

So it's not a CLI app.

I think you're missing my point entirely: like CLI apps, Hyper is used by developers.

The only relevant Electron app I can name is Atom

So following XDG is not a convention for Electron app on macOS.

By "only relevant", I mean "only other exclusively used by developers". I don't care what "other Electron apps" do on macOS - it doesn't matter, why should a user care how Hyper is built? Hyper should do what makes sense for Hyper.

You also chose to ignore the point that a tonne of people are asking for Atom to support XDG, the maintainers cautiously want to, and people are annoyed at the suggestion of using Library/Application Support for their Atom config for the same reasons that I am here.

A specific env var dedicated to hyper like ATOM_HOME would be much better.

That's not better; it's why XDG_CONFIG_HOME exists. The documentation required is more confusing, because now you have to say "uses $HYPER_HOME on macOS, or $XDG_CONFIG_HOME/hyper on Linux.

[jcrben]

If a Mac user has went through the effort of setting XDG_CONFIG_HOME, as I do, then the application should use it. It shouldn't care if it's Mac or Linux.

When a user deliberately sets an environment variable like that, they want their configuration to go there.

I end up storing it all together in a repo and symlinking it into Application Support if it's not respected, but that's a step I'd rather not have to deal with. I like to be able to switch back and forth between Linux and OSX without too much friction.

[chabou]

There is a PR to support XDG: #1595 (#170 rewriting)

[ELLIOTTCABLE]

:+1: for ~/Library/Application Support, at least by default. I develop on macOS. I want to use macOS. I do not care what Linux does, I do not care for Linux conventions, or I would be developing on Linux.

… that said, @jcrben's point makes the most sense to me: if someone sets an XDG config-option, they're probably somebody who cares about that XDG config-option, whatever the hell that is; and I see no reasonable reason to ignore it? That'd be just plain bone-headed, given how little implementation-work this requires!

tl;dr be a good Apple citizen and put it in app-support until the user explicitly asks otherwise (perhaps by setting that envvar.)

[OJFord]

Does everyone commenting about how they use macOS and macOS uses Application Support realise that probably the majority of dotfile directories or *rc files in ~ on their Mac is there only because whatever owns it has fallen back on $HOME == ~ when $XDG_CONFIG_HOME didn't exist?

Almost everything development-related on my Mac behaves this way, it's not some weird Linux quirk people are asking for out-of-blue for Hyper. It's pretty standard.

[xgdgsc]

Please use the electron API and merge https://github.com/zeit/hyper/pull/2948

[philoserf]

In reference to macOS.

Since the ~/Library is by default hidden on Mac, the XDG should be used by command line applications leaving the ~/Library to native macOS applications .