forge VS transient

you can clone, browse, modify, fork, make pull requests from Magit without leaving Emacs a single time. checkout https://github.com/magit/forge

However, i'm still unable to create issues or pull requests from within forge, returning error in process filter: Failed to submit post: (error http 404 ((message . "Not Found") (documentation_url . "https://developer.github.com/v3/pulls/#create-a-pull-request"))). Do you know how to solve this as well? I've tried looking around for resources, and so far have only come across issue #273 on magit/forge repo, which was resolved using the correct token permissions. My token was set up with the repo, user, and read:org permissions as per the documentation, but am facing the same issue. I have also run (setq url-debug t) for more verbose debugging, but I'm not seeing any additional help either.

You can also manage via a holistic UI: - Bisection - Log and reflog, stashes - subtrees, submodules - certain third party subcommands like git-absorb, and extend it with your own - interact with issues and pull requests via forge - pretty much all of the hundreds of CLI flags via a modal UI that got generalized and extracted to a lib called transient - well-integrated diff and conflict resolution (which is mostly just smerge) - the rebase/cherry-pick workflows I liked the best, including support for --update-refs - at any time you can always press a key to see the raw commands and output that it's using, which taught me a ton of corner cases - IMO it has a great manual

Following up here with a feature request, in case anyone else reading this is interested: https://github.com/magit/forge/discussions/580

Yes :). Basically all you need to be able to fork and pull request is the Forge package. It's made from the author of Magit: https://github.com/magit/forge Just follow the manual, you basically need to create a token on GitHub and share it with Forge through your authinfo. I tested it recently (cloned, forked, made changes, committed, pushed and pull request to original repo) and I didn't have to open Firefox even once. https://magit.vc/manual/forge/

how is it different from forge?

orgit package, which provides Org link types pointing to Magit buffers (including log and revision buffers). Optionally, magit/forge and orgit-forge packages might be useful too, for noting issues and pull requests.

Not projectile-specific, but see browse-at-remote and forge (of interest are forge-browse-* commands).

There is also https://github.com/magit/forge, which I haven't looked at. Instead, I do all the proprietary github things through their proprietary website.

For magit users, there's https://github.com/magit/forge - ultimately the store of record is still centralized as it's GitHub/GitLab/etc., but it does integrate a local copy of it nicely with your other git operations.

> Even in this article just a few sentences after stating we should start from first principles he then jumps into the assumption of the "desktop".

Agree. Although I can see how the idea of "first principles" can be a very difficult starting point. A blank sheet of paper is a scary monster.

There's a huge breadth and depth of non-"desktop" GUIs out there, some (like smartphones) are even wildly successful. It's good to explore them for inspiration. Some of my favourites:

- Arcan (https://arcan-fe.com/about/) - I won't attempt to summarize, just dive in!

- SailfishOS (https://sailfishos.org/) - mobile UI focused on interaction through gestures / swipes; I've used it as my daily driver for a couple years.

- Speaking of mobiles, classic Nokia UIs allowed you to navigate to a specific item in the menu by pressing the corresponding digit on the dial pad. Once you learned where a particular item is, accessing e.g. your SMS inbox was extremely quick.

- Apple Watch / WatchOS (https://www.apple.com/watchos/) - I've always loved the idea of a device where one of the primary interaction methods was a wheel/dial of some sort. The watch even gives you context-sensitive tactile feedback.

- ZUIs in general (https://en.wikipedia.org/wiki/Zooming_user_interface) and the work of Jef Raskin in particular: https://en.wikipedia.org/wiki/Archy_(software) - this is the guy who helped design the Macintosh, but his other work took a radically different route.

- Magit (https://magit.vc/). Many common git operations are reduced to a couple of keystrokes; the obscure features are more discoverable, and the cumbersome procedures (such as rebasing, or staging individual hunks) become simple and intuitive. Also check out transient (https://github.com/magit/transient), which is the "UI toolkit" that powers Magit.

True, and I'd personally rather move away from Emacs to something more modern. (Helix is great, although I appreciate the irony of it being terminal-only, while Emacs supports several different window systems natively.) Magit is the only real reason I'm sticking with Emacs.

Magit itself is powered by <https://github.com/magit/transient>, which I see more as an interaction paradigm than a library; it could enable more ergonomic interaction with other stateful tools that are typically native to the command line / terminal (such as docker/kubectl, systemctl, mpd/mpc, etc). Rather than using Emacs as a middle layer, Transient could build on top of pluggable native toolkit backends, such as Cocoa, Gtk, Win32, or even web or a terminal.

We continue investing into terminals because the terminal remains the lowest common denominator of interacting with a computer. On the other end of the spectrum we have Electron, which has very clear and obvious downsides. I think there is low-hanging fruit with amazing ROI somewhere in the middle, and Magit/Transient is an example of what it could be.

You can also manage via a holistic UI: - Bisection - Log and reflog, stashes - subtrees, submodules - certain third party subcommands like git-absorb, and extend it with your own - interact with issues and pull requests via forge - pretty much all of the hundreds of CLI flags via a modal UI that got generalized and extracted to a lib called transient - well-integrated diff and conflict resolution (which is mostly just smerge) - the rebase/cherry-pick workflows I liked the best, including support for --update-refs - at any time you can always press a key to see the raw commands and output that it's using, which taught me a ton of corner cases - IMO it has a great manual

See https://github.com/magit/transient/issues/239 .

More information can be found on my blog and in the release notes.

AFAIK :if etc. do not "live update", but only function on initial prefix setup (see this issue). You could use a sub-prefix that evaluates settings from its parent to set the available options. Another tip: add an incompatible list so you can't get two desserts:

Yeah, ok, simplest is then to just trash the transient folder and either let Emacs clone it again on startup, or manually clone it: https://github.com/magit/transient

M-x khoj RET c via transient

This is about resizing the frame, but might also be relevant: https://github.com/magit/transient/issues/216.

Will a hydra or a transient menu?