1. 47
  1.  

  2. 15

    I started researching the GitHub APIs that would be relevant to implement something like this a few months ago, but I’m really hesitant to sink a lot of investment into GitHub and its accompanying monopoly in my free time.

    I’ve moved a bunch of my personal projects over to GitLab, but they’ve been doing stupid stuff like refusing to render static repository content without whitelisting Javascript, or telling my my two-week-old browser is unsupported because it’s outdated, so … not a lot of motivation to invest in that ecosystem either.

    1. 13

      This. I noticed the mandatory JS for rendering nonsense too. I really want to like GitLab, and have tried multiple times to use them as my main, but to me the UX is just inferior to GitHub. The UI is sluggish and feels very bloated.

      It’s been a while since I’ve given up on GitLab for the time being, and have been self-hosting Gitea. Now Gitea uses JS too, but also works quite well without it. And it’s nowhere near as slow as GitLab.

      1. 5

        but to me the UX is just inferior to GitHub.

        Well, GitLab for all its faults doesn’t hijack my Emacs key bindings to do idiotic shit like “bold this thing in markdown” (which was already only two keystrokes to begin with; why are you adding a shortcut for something I never do on ctrl-b that I use all the time?) so I wouldn’t say GitLab has quite sunk to that level yet.

        1. 3

          Interesting. That’s a fair point; though GitHub’s editor isn’t the first to do that. I hadn’t noticed it with GitHub mainly because I use Vimium in Firefox, Evil in Emacs, and bspwm; so I rarely use Emacs-style bindings but I agree that could be frustrating.

          Does exwm’s simulation keys work around the issue, or does GitHub’s in-browser binding take precedence?

          EDIT: There’s also xkeysnail, though it does require running as root.

          EDIT2: It seems like running xkeysnail as root may not be necessary if the user has access to input devices. On Arch (or any distro with systemd >= 215) that can be achieved by adding the user to the input group (see here and here).

          EDIT3: The Emacs-keybinding extension may be another option, though apparently it only works in macOS. There’s also shortkeys but I haven’t tried either one.

          1. -2

            If you’re editing text, Ctrl-B for bold (or Ctrl-F if you’re in Germany) should be expected. Editing text means Word keybindings, not Emacs bindings.

            This also means Ctrl-I for italic (or Ctrl-K in Germany) and Ctrl-U for underlined (this one is actually the same).

            1. 12

              I strongly disagree, at least on a Macintosh, where all native text entry widgetsobey the Emacs keybindings. Web garbage that arrogates system functionality to itself, hijacking my chosen platform experience for a poor copy of some other system is noxious, and broken.

              1. 0

                I just tried in the macOS Notes app and ctrl+b makes the text bold. The Pages app does the same, ctrl+b makes the text bold. These are two native text entry applications developed and provided by Apple themselves.

                1. 6

                  No, you are pressing cmd. Control is reserved for motion.

                  1. 1

                    That’s the problem of your system then – the browser explicitly exposes Ctrl, Alt, Meta. If your keyboard does not offer these, either your browser, OS, or keyboard has to map between these and the actual keys.

                    Users on all other systems (aka 99.5% of users) expect Ctrl-B (or Ctrl-F) to create bold text.

                    1. 6

                      No, users on Macs expect their modifier keys to respect platform convention – Emacs keybindings for movement, cmd for meta. To assume otherwise is disrespectful.

                      1. 0

                        So what do you suggest? Breaking keybindings for all windows and linux users instead?

                        1. 4

                          No, use the proper keybindings for the platform that the user is using.

                          1. 0

                            So how do you suggest to do that without using heuristics on the useragent?

                            I’d be interested in your implementation of a JS function that returns the correct set of modifiers and keys to use for the bold shortcut. And which works reliably.

                            Currently, the browser doesn’t expose this, so everyone gets the most commonly used solution.

                            1. 3

                              Currently, the browser doesn’t expose this, so everyone gets the most commonly used solution.

                              ????

                              Note: On Macintosh keyboards, [.metaKey] is the ⌘ Command key.

                              MOD_KEY_FIELD = navigator.platform.startsWith('Mac') ? 'metaKey' : 'ctrlKey';
                              
                              // lazy
                              if (keyEvent.ctrlKey && ...
                              
                              // bare minimum for any self-respecting developer
                              if (keyEvent[MOD_KEY_FIELD] && ...
                              

                              What I want to know is how you’re commenting from 1997. Just hang tight, in a couple years two nerds are gonna found a company called Google and make it a lot easier to find information on the internet.

                          2. 3

                            Using the proper modifier depending on platform? The browser should expose “application-level modifier” say, for bold, and that would be ^B on X11/Windows and Super-B for Mac.

                            1. 0

                              The browser isn’t exposing this, though. The best chance is sniffing the user agent and then using heuristics on that, but that breaks easily as well.

                        2. 2

                          100 - 99.5 != 12.8, your assumption is off by a factor of 25.

                        3. 1

                          You’re right. Lord I’m an idiot.

                        4. 4

                          Ctrl+b on my Mac goes back a character in both macOS Notes and Pages, as it does everywhere else. Cmd+b bolds text (as also it does everywhere else).

                          In general, Macs don’t use the Ctrl key as a modifier too often (although you can change that if you want). They usually leave the readline keybindings free for text fields. This seems to be by design

                          The standard key bindings are specified in /System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict. These standard bindings include a large number of Emacs-compatible control key bindings…

                      2. 4

                        Editing text means Word keybindings, not Emacs bindings.

                        Those of us who use emacs to edit text expect editing text to imply emacs keybindings.

                        Some of us expect them everywhere, even.

                        1. 3

                          If it was a rich text WYSIWYG entry, I’d be 100% agreed with you. (I would also be annoyed, but for different reasons.)

                          But this is a markdown input box. The entire point of markdown is to support formatted text which is entered as plain text.

                    2. 3

                      It’d be great if we had a language server protocol extension for code review + a gerrit backend. I started taking a look at this a few months ago (I work mostly in Gerrit now) but didn’t have the bandwidth for actually prototyping it. It seems like an obviously good idea, though having to use git hampers some of the possibilities.