1. 2

    That’s impressively small for how usable it looks already. Nice work!

    1. 3

      Thank you - It is my hope it will stay small, yet powerful.

      Much credit to Calvin Rose for creating Janet which is an amazing project.

    1. 3

      This is the one tool that is making me seriously consider flipping my workflow upside down and switching from vim + git cli to emacs.

      That said, if anyone knows of something similar to magit that doesn’t require emacs, I’m interested in hearing about it! I’ve played with tig[0] a bit, but always go back to using git from the cli..

      1. https://jonas.github.io/tig/
      1. 3

        I recently started using spacemacs in vim mode (which is its default) and it’s lovely. It’s been a much better experience getting a decent environment going than I’ve ever had with vim. Haven’t dug into Magit yet but I’m eager to. The docs for spacemacs are a bit scattered but this was the most useful for me to get going:


        1. 1

          How long did you use vim workflows before switching? I’ve been a fulltime vim user for about 10 years, and I’m afraid that my productivity will take a serious spill as I try to unlearn muscle memory and build new ones. If you used vim for a while, I’m curious how that experience was for you.

          1. 5

            I switched mostly to emacs + evil (also used for Spacemacs) after a decade and a half or so on various vi implementations. Evil is very complete, evil often feels more like a complete vi implementation in Emacs Lisp rather than ‘vi emulation’. So far I didn’t have to unlearn any muscle memory.

            I used Spacemacs for the initial switch, but I found it to be very buggy and slow. So, at some point I just switched to Emacs + hand-picked packages. I use use-package to load/install packages that I install with Nix and manage with home-manager. I use general to set up spacemaps-like key bindings (e.g. SPC-p-f to find a file in a project SPC-b-b to search buffers, etc.).

            However, the Emacs ecosystem can be a bit overwhelming, so Spacemacs is a good entry point.

            1. 1

              I never spent longer than six months or so using vim full time, so I’m in a very different situation. You’ll be able to put much of your muscle memory to good use in spacemacs, using the same keystrokes to navigate and edit within a buffer. However you’ll need to re-learn many other common tasks.

              You will absolutely take a big productivity hit at first, but if you stick with it then you’ll start feeling comfortable pretty quickly. Learning is its own reward! :)

          2. 2

            I have used vimagit and fugitive (both Vim/Neovim plugins) together for a while now. Vimagit is far from equal to magit in terms of power, but provides my Vim setup with the main features I missed from magit (visual range staging, easy amends, etc.). Fugitive is also useful on its own, but I currently mostly use it to asychronously push/pull from within Neovim (as vimagit does not yet provide these features itself).

            1. 2
              1. There’s nothing wrong with converting to the true faith ;)
              2. There was a Go project called lazygit that was posted here a while back that a few people claimed was quite nice (haven’t tried it myself, so I can’t say), and reminded me of Magit – maybe that would be worthwhile?
              1. 2

                One thing I’m wondering about trying is a TUI-only Emacs configuration with a virtually completely empty .emacs file, flset up for just magit and nothing else. I’m wondering if the load time with a maximally stripped-down configuration would be short enough to make it feasible to use magit in a non-Emacs-oriented workflow. So, edit in something else, launch Emacs+magic in terminal, stage changes, close Emacs.

                The Emacs daemon mode might be an option too but it adds a bit of complexity to the setup. :/

                1. 1

                  I use tig a lot for browsing commits, but for making commits, vimagit is a pretty cool magit-inspired vim-based git add -p type thing.

                  (Though I keep using add -p anyway lol)

                  1. 1

                    Fugitive is amazing. I use it extensively at work.

                    1. 1

                      I’ve been using its most basic functionality (Gblame, and gutter highlighting) for at least 1 year now. Perhaps it’s time to invest more time in learning the ‘advanced’ features.

                      1. 1

                        Yeah! It’s got good diffing, committing, etc.

                      2. 1

                        If you like fugitive, I’d also recommend checking out gina.

                        1. 1

                          What does it do differently/better?

                    1. 2

                      Would the features they’re talking about be feasible with CRDTs at the core instead?

                      1. 2

                        If you’re interested in this and haven’t already read https://arxiv.org/pdf/1810.02137.pdf then you’ll probably find it interesting.

                        1. 1

                          Yes, but they chose OT and may describe why later.

                          There are several approaches to implementing conflict resolution in real-time collaborative editing. Two main candidates are Operational Transformation (OT) and Conflict-Free Replicated Data Type (CRDT). We chose OT and perhaps one day we will write down our thoughts on the ongoing OT vs. CRDT battle.

                        1. 16

                          This is another case where I feel a low-quality downvote option would be highly useful. There are plenty of inaccuracies in these slides and I would very much not recommend this to someone learning C.

                          1. 5

                            Care to enumerate some examples?

                            1. 20

                              Slide 2:

                              Don’t pick C as your first language.

                              C is fine as a first language – I’m glad it was mine (I’ll grant this is at least somewhat subjective).

                              Slide 3:

                              You only need C for projects that require low-level hardware access or blazing-fast speeds.

                              These are hardly the only valid reasons to write something in C.

                              Slide 12:

                              int my_var = 3; // It’s an int!

                              my_var = “abc”; // COMPILER ERROR! You clearly stated that it was an int!

                              A warning, possibly, but not an error.

                              Slides 17-22: “memory layout”? I’m guessing this is referring to the necessity of avoiding invalid memory access, but “memory layout” means something very different to me (things like which members are where in a struct – which while a valid concern in some cases is definitely not something a beginner would need to care about).

                              Slide 30:

                              I like to think of a pointer as a directory and the value as a file.

                              Not a very good analogy. File names & inodes would perhaps be marginally closer I guess, but still not a good one.

                              Slide 31:

                              int a[] = {1, 2, 3}; // create an array

                              // a is just a pointer to the first element…

                              Wrong, a is decidedly not a pointer; it’s an array. Yes, the expression a will decay to a pointer in some contexts, but it’s still fundamentally an array. They’re different.

                              Slide 42:

                              char letter = ‘a’;

                              int x = (int) a; // look. it’s now an int

                              Kind of a weird choice of example – I’m guessing the author is unaware that the expression 'a' is itself actually of type int, not char. The (int) cast in the second line is just as extraneous as the (char) cast omitted in the first line.

                              Does it throw a warning because ints aren’t the same size as pointers? Yes.

                              Maybe, if you’re on (say) an LP64 platform (but probably silent on ILP32).

                              Does it make sense? No.

                              It certainly could in some contexts.

                              Slide 43:

                              And that covers the all difficult C concepts for beginners

                              Ignoring the spottiness of the topics it attempted to cover, that’s still pretty presumptuous. Just off the top of my head, what about, say, the distinction between stack and heap space? (i.e. why you don’t want to return a pointer to a local variable, which I imagine could easily be confusing to C neophytes.) I’m sure there are plenty of others as well.

                              The whole thing smells very much like a case of someone kind of half-learning C and then deciding they’re qualified to start teaching other people about it.

                              1. 9

                                The idea that a[] is the same as *a is a misconception I see spreading around a lot. The C FAQ on Arrays and Pointers clears up some of the relationship between pointers and arrays.

                                1. 1

                                  In regard to slides 17-22, this also puzzled me. I believe the author was wanting to impress how mindful you need to be with your data types, but that’s as far as I got. If this were a 6502 tutorial I’d probably have those slides as point #1, but…

                              2. 1

                                I feel like low-level languages have a simplicity that allows people to deceive themselves into thinking they understand them more than they do. I know how to write and read C, and I’ve used some of the tools, but I wouldn’t say that I “know C”. It’s actually pretty frustrating that so many C resources are from people who know little more than I do, but who’ve recently become enamored of low-level programming and think they understand it.

                                There’s also an issue of feedback. Undefined behavior may or may not bite you. Often it doesn’t, or the failure is predictable (e.g. a hard crash for division by zero) which misleads a person into thinking that a pattern of behavior works. Most people don’t know that (under typical two’s complement assumptions) MIN_INT / -1 is undefined, for example, because they rarely get bitten by this corner case.