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, notifications@github.com 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
#137 (comment), 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, <Cmd-,> (or when that's broken, 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]

👍 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 #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 .

[mayurankv]

Is this still unimplemented in any form? I can see a lot of discussion about it but I can't identify if any final position was taken (or followed through).
Just my two cents if its at all relevant haha, I prefer the use of XDG to application support as anyone moving hidden files most likely has some affinity with the system and application support being hidden means editing the config would be confusing for newcomers.

[fredericrous]

XDG is implemented. However you have to set XDG globally (before hyper.app is launched).
Do not expect XDG to work just by setting the env variables in your shell. Indeed the way it is implemented, it uses process.env instead of getting the variable from the spawned shell.

To work around this issue I added the following lines to my shell config file on macos

 launchctl setenv XDG_CONFIG_HOME "$XDG_CONFIG_HOME"
 launchctl setenv XDG_DATA_HOME "$XDG_DATA_HOME"
 launchctl setenv XDG_BIN_HOME "$XDG_BIN_HOME"
 launchctl setenv XDG_CACHE_HOME "$XDG_CACHE_HOME"
 launchctl setenv XDG_RUNTIME_HOME "$XDG_RUNTIME_HOME"
 launchctl setenv PATH "$PATH"

I don't think this is documented, it should because the XDG implementation creates several issues:

• the config file and plugin folder is not saved where expected
• the hyper i <plugin> command does not work because it cannot find the .hyper.js file. indeed the command line is expecting the config file in one place (XDG_CONFIG_HOME) while the terminal is expecting it elsewhere (home)