Daniel Mendler

Thanks! I agree that these packages are orthogonal to each other. I mainly asked because I was wondering if you had somehow given up on eshell or the pcomplete mechanism...

Incidentally just today on reddit https://www.reddit.com/r/emacs/comments/sbdmr7/improving_shell_in_emacs/ with comments like this: > imho: vterm is only one usable terminal solution for emacs without any compromise. Without it i need external terminals....

> Is this specific to compat or does straight just ignore versions of dependencies in general, only ensuring they are installed but not caring what version is installed? It seems...

@progfolio > It's not compat specifically. > It's not a problem that crops up often. > It's a combination of compat being a "young" library and seeing a fair bit...

> Why does compat need to invent its own versioning scheme instead of using semver? Obviously because Compat is tied to the Emacs versions, e.g., `compat-28.1`, `compat-29.1` etc. This cannot...

> That's not obvious to me (or perhaps anyone else who isn't developing compat) why the Emacs version would need to be expressed in compat's versioning. Maybe I should elaborate...

Also note how Compat `Package-Requires` usually look like: ~~~ elisp ;; Package-Requires: ((emacs "27.1") (compat "29.1.4.1")) ~~~ We require Emacs 27.1, API level 29.1, and more precisely Compat version 29.1.4.1....

Yes, it would indiscriminately update and nothing will break since Compat will always stay backward compatible. Note that package.el doesn't know upper bounds for package versions. Newer versions are always...

@progfolio > Personally, I see that as a bug in package.el/Emacs, and I'm betting they'll have to reconcile that design decision at some point. I find it hard to tell....

> Further development in elisp name spacing (or, allegedly, read-symbol-shorthands, though I haven't looked into how) would help here because it would be possible to load multiple versions of a...