ndegruchy
I wonder if most folks have different expectations from it. Most of the HN crowd are probably already familiar with the usual suspects, so the lack of options and visibility into the process are probably concerns. For most folks, though, I imagine it's turn it on and forget it.
`<thead>` and `<tfoot>`, too, if they're needed. I try to use all the free stuff that HTML gives you without needing to reach for JS. It's a surprising amount. Coupled with CSS and you can get pretty far without needing anything. Even just having `<template>` with minimal JS enables a ton of 'interactivity'.
Rest in peace, Jane.
%APPDATA% is _fairly_ consistent for the past ~20 years. Local and LocalLow are odd distinctions, but have some interesting backgrounds. I don't find many programs abusing them. Roaming being the only real oddball that I find preferences for that aren't overridden by one of the other two folders.
User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.
This is a fair take, and something that I've considered when going down the obsessively organized path.
Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_.
However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec.
> This isn't silly. At all.
I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of .<whatever> files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user.
> but Windows isn't a monolith
It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way.
WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.
macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would put data in `$HOME/.Application Data/Local/` on Linux. Why would macOS get bundled in with Linux? Because it's a unix? That's silly.
Personally, I have my zsh config repoint those directories into `~/Library/Application Data`, though (as some have pointed out) it's probably better to put some of those folders in `~/Library/Preferences`.
Eshell shines when you're looking to use Emacs to do stuff in the shell, but not really deal with the shell itself. It will dutifully run whatever program you feed it, but the real magic is when you want to deal with the output. You can redirect outputs to buffers, which you can then manipulate with Emacs familiarity. You can even handle remote sessions just as easily as you would open a remote file in TRAMP. I've used this on many occasions to edit a remote config file, then trigger Eshell, which puts me in that directory, to then restart the service without having to launch a separate SSH session or terminal.
While there are a lot of clunky bits of Emacs, I feel like Eshell gets an especially bad rap. Some of it's justified: It presents itself as a bash-like interface, while actually having vastly different ways of handling things. I feel like folks don't really get the idea that it's an interactive Emacs session, a worksheet for the command-line that lets you ingest data from external tools in a more ergonomic way than doing `shell-command` or similar.
Calling retail stores to do anything other than to see if they're open or, in the case of restaurants, get a reservation is just wasting time. At least for the retailers that I've communicated with.
It's fine to nail a $10m verdict against a guy with no money, but dare to tread on the beloved and bespoke * aI iNdUsTrY * and suddenly you've got better things to do?
I guess it really matters what you need. Is Numbers going to take over accounting firms? No, they need Excel because it's Excel and that's what they use. If you need a free spreadsheet program, there are plenty. Google Sheets, Numbers, LibreOffice, Gnumeric. They're not going to change the way you use spreadsheets, but they'll put shit in columns and calculate to varying degrees of accuracy. Which is what most folks want/need.
Seems like Mozilla is dead-set on grinding up any good will they get from users.
[1]: https://discourse.mozilla.org/t/pocket-source-code/43686/11 [2]: https://github.com/Pocket/pocket-monorepo
Couple this with the idea that we soft-spy on our Allies and then trade that data for their spying on our people and yeah, wow.
What? By what definition? Is there evidence of this?
I mean, you can get yourself any old laptop and run Linux on it, but it won't compare with a system that is run by the company building the hardware.
I agree, though, seems like a ripe piece of low-hanging fruit that could be better integrated and safer. Even if the lower level stuff just hands it off to a dedicated tool that handles the replacement text, at least the OS/WM should be the one watching the keys.
In System Settings > Keyboard > Text Input > Text Replacements
Basically, it's a simple replacement tool, which works for some repetitive stuff (i.e. my name, my email address, my phone number, or a short string for closing out emails). Epsanso, and tools like it, do so much more.
Edit to add: Data detectors on macOS/iOS look for existing strings of text that you can then get more contextual options for. Things like dates and times might open up a calendar view, phone numbers might offer a menu to dial it, or addresses might offer the ability to open a map for it. Absolutely useful, but not the same thing.
Plus, the only thing I need to do to transfer it to a new disk or network location is to move the `.fossil` file, since everything is nicely self-contained.
It just needs some more 'modern' themes
...I'll see myself out.
I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.