I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive.
For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.
I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.
The thing is that emacs predates Apple developing cmd-z/x/c/v and Microsoft copying Apple in Windows. Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products.
Also OP apparently has no knowledge of the far better IDEs we had 30-40 years ago including but not limited to:
- Apple MPW, 1986. GUI editor where every window is (potentially) a Unix-like shell, running commands if you hit Enter (or cmd-Return) instead of Return. Also the shell scripting has commands for manipulating windows, running editing actions inside them etc. Kind of like elisp but with shell syntax. There's an integrated source code management system called Projector. If you type a command name, with or without arguments and switches, and then hit option-Return then it pops up a "Commando" window with a GUI with checkboxes and menus etc for all options for that command, with anything you'd already typed already filled out. It was easy to set up Commando for your own programs too.
- Apple Dylan, 1992-1995. Incredible Lisp/Smalltalk-like IDE for Apple's Dylan language
- THINK Pascal and C, 1986. The Pascal version was orginaly an interpreter, I think written for Apple, but then became a lightning-fast compiler, similar to Borland on CP/M and MS-DOS but better (and GUI). The C IDE later became a Symantec product.
- Metrowerks Codewarrior, 1993. Ex THINK/Symantec people starting a Mac IDE from scratch, incorporating first Metrowerks' M68000 compilers for the Amiga, then a new PowerPC back end. Great IDE, great compilers -- the first anywhere to compile Stepanov's STL with zero overhead -- and with a groundbreaking application framework called PowerPlant that heavily leaned on new C++ features. It was THE PowerPC development environment, especially after Symantec's buggy PoS version 6.
- Macintosh Allegro Common Lisp (later dropped the "Allegro"), 1987. A great Mac IDE. A great Lisp compiler and environment. Combined in one place. It was expensive but allowed amazing productivity in custom native Mac application development, far ahead of the Pascal / C / C++ environments. Absolutely perfect for consultants.
Really, it is absolutely incredible how slick and sophisticated a lot of these were, developed on 8 MHz to 33 or 40 MHz M68000s with from 2-4 MB RAM up to maybe 16-32 MB. (A lot of the Mac II line (and SE/30) theoretically supported 128 MB RAM, but no one could afford that much even once big enough SIMs were were available.)
All your example are in the Apple ecosystem. Depending on where the author is from, it may not be that surprising that they wouldn't know about them. In my corner of the wolrd, Apple was basically non-existent until the iPod and iPhone.
Fortunately my little isolated island chain [1] in the South Pacific Ocean was one of the places where there was someone who brought in early Commodore, Tandy, and Apple machines only a couple of years after the USA and by 1979 or 1980 there were stores in my nearest 40,000 pop provincial city that stocked and repaired them. My school got an Apple ][+ right at the end of 1980, just as I graduated, but the Math HoD [2] asked me to take it home for some of the holidays before I started university and figure it out and come and explain it to him.
A few months after I got my first job after university I persuaded my boss to get the new Apple LaserWriter (in fact the demo unit from the launch), which I connected to the company's Data General "mainframe" (MV10000) and programmed in raw Postscript. In 1987, when the Mac got good enough (e.g. Mac II) we got on those those too as it was just sooo much better than a PC/AT.
[1] NZ
[2] who died just over two years ago, aged 99 1/2, we'd kept in touch the intervening 40+ years
In most corners of the world, actually. Apple was reasonably popular in the US, the UK and a few developed countries (think marketshare of 5% in 1999) and basically non existant everywhere else.
> Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products.
Borland switched to https://en.wikipedia.org/wiki/IBM_Common_User_Access shortcuts in the last few versions of their TUI - Ctrl+Ins, Shift+Ins, Shift+Del for clipboard, for example. Since Windows also supported them (and still does!) this actually made for a nice common system between Turbo Vision TUI apps and actual GUI in Windows.
And I only recently discovered that Ctrl+Ins and Shift+Ins worked in my Emacs despite me never configuring it; and it even works in the minibuffer. It also worked in a couple of terminal emulators I have tried on Linux. It's really more universal than one might think.
It's unfortunate that the accidental standard also happened to be the one requiring the use of both hands. I think that's why Ctrl+X/C/V won in the end.
It doesn't. Shift+Del, Ctrl+Ins,... can be done just using the right hand, while Ctrl+X/C/V uses the left hand. And sometime you may want to use two hands, which can be done in both cases by using the other Ctrl and Shift key. I actually use both kinds of shortcuts, depending on the situation.
Del and Ins are also conveniently close to the cursor navigation keys (arrows, home, end, PgUp, PgDn).
The reason I think Ctrl+X/C/V won out is that it is more convenient when using the mouse, it is also better with nonstandard keyboards where the "Ins" key is awkwardly placed, if not missing entirely.
From my own experience, Think Pascal was fantastic for the time. MPW was serious and high-powered stuff for pro development on a late 80s/early 90s microcomputer; used it professionally for 2 or 3 years and loved it. Never tried the other ones you mentioned.
As you say, it's incredible how slick and sophisticated those systems were, given the hardware of the day. I mean sure current IDEs may be preferable but we're also using 4 Ghz systems these days instead of 40 Mhz or whatever.
(Edit:) Let me start by thanking you, I love these stories about the glory days of computing generations past! I really must try some of these; obviously there are so many fantastic ideas to take.
Irrelevant aside: I've been using emacs 20 years but I very recently gave up and mapped ctrl-V to paste because I still made the mistake of hitting that too often. (I don't hit ctrl-C accidentally, because to select text I've already switched to emacs for at least a few seconds.)
> It is however fully self-documented and interactive.
Unfortunately not true. I've fired up emacs once or twice, and couldn't even figure out how to save a document because it didn't show me how to do that. It might be more documented than vi (but that bar is *on the floor, vi has one of the most discovery-hostile user interfaces ever made), but it's not self-documented enough to just pick up and use with no instruction.
I'm pretty sure that if you have an unmodified install and no .emacs that is configured otherwise, when you start emacs you are prompted with a help screen that includes instructions on using the built-in tutorial. If you do that, you'll learn the basics in about 10-15 minutes. If you skip that, yeah it's pretty different from most other software conventions.
And if you don't have anything configured, graphical Emacs will have a tool bar with a button to save and a menu bar that also gives the binding for the command.
GUI is different because there is no tool bar, but in Emacs 31 `xterm-mouse-mode' will be enabled by default so you can use the menu bar like a TUI.
Yeah the entire emacs tutorial might take a long time. I don't think I ever went through it to "the end" but learning cursor movement, opening and saving files, etc. is right up front.
Problem is most people start it the first time by providing a text file instead of firing it on its own and be greeted by the tutorial. I guess that is because they are blindly following another tutorial instead of trying to understand what they are doing.
My opinion is that "self documentation", "Getting started" pages and "tutorials" is a disease. People would actually get up to speed quicker by reading real manuals instead. They are just lured into thinking they will learn faster with tutorials because they get their first concrete results quicker but at this stage the harsh reality is thay they still usually don't know anything.
First time I used vi, I just had my operating system manual on my desk and I quickly learned to open man pages in a separate tty.
VI or VIM? VI has no welcome screen. It drops you straight into a blank screen of '~' from where you just have to know to enter the insert mode, which is also not indicated anywhere unlike in VIM.
There was a time when manuals was kinda big physical books. I think I have a word perfect one that is the size of a textbook. It was not about getting a result (any result) in 5 seconds. It was more about having a goal and browsing through relevant sections to learn how to do it.
That's a fair criticism, although once you learn how to access the documentation and where to look for/expext it I find that most things, including add-on packages and whatnot, can be learned from within Emacs itself just fine. But it does take some knowledge to get to that point in the first place for sure.
One thing that greatly helped this in the DOS / early Windows era was standardizing on F1 being the key for "online help" (meaning, usually, a hyperlinked document that shipped with the product). That was basically the only thing you had to know to start learning any app.
I think is not fair at all, as a default installation has a menu bar, and you can save a file in file->save. While doing so it will tell you the shortcut.
>it's not self-documented enough to just pick up and use with no instruction.
If they just plop you in front of a 3-d printer never having seen one and having no documentation, it'll probably take you a good while to produce something useful with it.
That's really not the case. I learned programming in the DOS Borland apps and did it with next to no instructions. I don't think I've ever seen the manual. Just read about the language itself. They were that easy to understand and use. Emacs is not in the same class as far as discoverable interface is concerned.
It is (counts on fingers) 43 years since I got my first computer of my own, and I've been using Unix-like OSes since just 6 years later in 1988... So, 37 years?
Still, even now, Emacs is this bizarre thing that teleported in from 1962 or something. Older than Unix, older than -- well, anything else still used by almost anyone except Cobol and Fortran.
I am old, starting to think about retirement, and Emacs is weird and clunky and ugly. It uses weird nonstandard names for things like "files" and "windows" and even the keys on your keyboard.
I know they are native and natural for the fans. I'm not one. I'm a fan of the great era of UI standardisation that happened at the end of the 1980s and start of the 1990s.
I wish someone would do a distro of Emacs with ErgoEmacs built in, on by default, and which could pick up the keyboard layout from the OS.
ErgoEmacs is a brave attempt to yank Emacs into the 1990s but you need to know Emacs to use it, so it's not enough.
In unconfigured emacs, you can literally just go Buffer>Save in the toolbar. If you didn't know to look in the buffer menu, then you didn't read even a little bit of the tutorial that appears when you open it
How did the magit guy or people even come up with the data model? Always had the feeling that it went beyond the git data model. And git porcelain is just a pile of shards.
Transient was factored out much later. It's not just transient that makes magit great, though. It's the only alternative porcelain for git that I'm aware of and one that makes git both easier to use and understand. I'm the "git guy" at every place I've worked but I owe it all to magit. Other git frontends just do the CLI stuff with point and click, they don't help you understand what's going on at all.
For reference, I did use Magit for my short stint with Emacs (and then Spacemacs/Doom Emacs). I've always been more into Vim. I tried the Atom editor several years ago with lots of Vim emulation and quite a bit of customization - one of those being a Magit clone.
I moved to NeoVim many years ago and have been using NeoGit (a supposed Magit clone) the entire time. It's good but I'm missing the "mind blowing" part. I'd love to learn more though! What features are you using that you consider amazing?
Maybe it's Stockholm syndrome for me, but I never really understood what was so unusable about the vanilla command line git interface.
If you want to do some really advanced stuff, sure it's a little arcane, but the vast majority of stuff that people use in git is easy enough. Branching and committing and merging never seemed that hard to me.
Wnen I do anything more than commit/push/pull at the command line I will quickly get myself so confused that I end up deleting the directory and cloning it again. That doesn't happen to me (much) with magit.
Fair enough. I feel like I do a fair amount of the more advanced features (interactive add and rebase, bisect, worktrees) without any fancy tooling and I don't have a problem much anymore, but admittedly they did confuse me at first.
i don't remember confusion. i find it's mostly understanding the data model and in particular the branches and references/reflog. when i am worried i might break something then i tag the the checkout where i am at and i know i can always revert to that. i also compare the original with the new state. i usually know what that diff should look like, and even if the operations in between are confusing, if the diff looks like what i expect then i know it went all right. trust the process but verify the results.
the big thing i am missing from it is a branch history. a record for every commit to which branch it once belonged to. no improved interface can fix that. that would have to be added to the core of git.
To navigate a Turbo-Vision-style IDE and explore its functionality, you basically only need to know how the Alt and Tab keys work (okay, and Return and Esc and arrow keys), as alluded to in TFA. Emacs doesn’t quite have that base level of operating uniformity I think.
To navigate emacs, you really only need to know ctrl, alt, and the basic norms of keyboard usage (return for newline/accept, shift for capitals)
Really, compared to what I see here, the chief difficulty with emacs is the sheer volume of possible commands, and the heterogeneity of their names and patterns, which I believe is all a result of its development history. But the basics are just as you describe.
It’s a good question to what complexity (volume) the approach scales, but dialog boxes can get you quite far, and menus are fundamentally “just” a tree like keyboard shortcuts are.
Emacs has Elisp commands first, then keyboard shortcuts for them, then maybe (not as a rule) menu items, and rarely dialog boxes. The Turbo Vision approach, from its design philosophy, has menus and dialogs first, then keyboard shortcuts for them.
One approach isn’t strictly better than the other, nor are they mutually exclusive. Ideally you’d always have both. My disagreement is with the “I think Emacs still does all of this” above. Emacs is substantially different in its emphasis, presentation, and its use of dialogs.
Yeah that’s fair. In many ways the spacemacs/doom model is more akin to what you describe, with a lot of caveats; it’s not a total rework of all key bindings. In emacs novice affordances are usually an afterthought, not part of the core design and community norms.
Of course, I must say there is a trade off here: you can design for novices or for advanced users, but very often not both.
The base input of emacs is ‘M-x’. From there, any command is accessible. And you have ‘M-:’ for evaluating any bit of elisp code. There’s a few UI concepts to learn (frame, window, buffers, point, mark, region,…), but that would fit in a single sheet of paper.
The keys I enumerated are sufficient to discover and execute all available operations in that style of TUI. You don’t have to type commands or command-specific keyboard shortcuts, like you have to in Emacs. It’s analogous to how in a traditional GUI you can discover and execute everything just using the mouse.
Like in the GUI analogy, you can then choose to remember and use the displayed keyboard shortcuts for frequently used operations, but you don’t have to.
It’s easy when you have a small amount of commands. And distributions like Doom Emacs is fairly discoverable too. But emacs have a lot of commands and while it offers menus, it’s only the surface level of what’s available.
It's possible I might once have given emacs a try, if the way people talk about it did not sound like such baffling moon-language: when I encounter stuff like "so I C-x C-f’d into my init.el, M-x eval-buffer’d, then C-c C-c’d an org-babel block before C-x k’ing the scratch buffer" I just want to back away slowly and leave them to it, whatever it is they're doing. Y'all have fun with your C-r X-wing mork-butterfly porg fluffers, I'm going to edit some code over here, using a text editor, that edits text files.
All the keybindings you mentioned are commands accessible with M-x. The thing with Emacs is that a chord is always attached to a keymap. The global keymap is always accessible while all the others are accessible through a keybind in another keymap, recursively.
So the only thing you need to know are those commands. And that's the main appeal of Emacs, to have commands that augment text editing. One of the most powerful examples is org mode, which is just another markup language, but there's a lot of commands that makes it an organizer, a time tracker, an authoring platform, a code notebook.
Each mode is a layer of productivity you put on the bare editing experience.
Thank you for your helpful reply. I'm afraid I don't have enough familiarity with emacs to quite follow your explanation - I didn't actually write the bit of emacs-speak in my previous message, and I don't know what its terms mean. I just asked ChatGPT to invent something one emacs user might plausibly say to another!
It has always sounded like emacs is extraordinarily powerful and configurable, and that must be great for people who want to do extraordinary things with their text editor. There was a time when I enjoyed tinkering with my environment more, but these days I prefer simple, ordinary tools I can easily understand. I don't really want to think about the tools at all, but focus on the task I'm doing with them. I'm content to let emacs be something other people appreciate.
I get you. Emacs is one software that you must invest some time to get the famous ROI. The promise is one unified interface for all the tools you may need (editor, tasks runner, shell, spellchecking, file manager,...). But the learning curve is there, although not as steep as some would make it appear.
One of my major motivation for putting in the time is that Emacs is very stable. You can coast for decades on a configuration. I don't mind learning new stuff, but it's grating to for it to be taken away, especially if there's no recourse (proprietary software).
Well, that's ironic. I actually do spend all day, every work day, in a piece of software which unifies most of the tools I need - editor, file manager, make console, find/grep frontend, etc. It's as stable as can be, since I'm the only person who maintains or even uses it, and it's as simple as can be, since I don't bother to write features in unless I really want them.
I've always supposed that emacs was for people with inscrutably complex text-editing needs, far beyond the bounds of my "nano is plenty" imagination, but if my cozy little coding environment is the kind of thing people are doing with emacs, I can understand why they would like that.
Agree about Emacs, and I used it already in MS-DOS back in the day. You could launch the compiler (or make, more likely) using M-x compile or use C-z to open command.com to run commands on the prompt and then exit from that back to Emacs. Almost like multitasking!
I never really liked any of the typical late-MS-DOS era TUI applications and have no nostalgia for those. I think a small TUI like a OS installer is fine, but I realised it is the command-line I like. Launching into a TUI is not much different from opening a GUI, and both break out of the flow of just typing commands on a prompt. I use DOSbox and FreeDOS all the time, but I almost never spend time in any of the TUI applications.
Despite that, I am currently working on a DOS application running in 40x25 CGA text mode. I guess technically it is a TUI, but at least it does not look much like a typical TUI.
So, I have been using emacs on and off for 32 years at this point, and I my emacs all set up with eglot and rustic and magit and the like and it's great.. but I still find I just fall back to RustRover when doing development because (unlike some the classic TUI IDEs mentioned in TFA) it just never feels like it's fully glued together and it's always a bit fragile and I never remember how to do certain things -- even though I'm the one who set it up.
That and lack of a decent visual debugger situation.
So I have this weird thing where I use emacs for interactive git rebasing, writing commit messages, editing text files and munging text... and then RustRover for everything else.
It's sorta like the saying, "I wish I was the person my dogs think I am"... "I wish emacs was actually the thing that I think it is" ?
> The Magit experience is due to the use of the transient package for its UI.
(I'm the author of Magit and Transient. (Though not the original author of Magit.))
The transient menus certainly play an important role but I think other characteristics are equally important.
A few years ago I tried to provide an abstract overview of Magit's "interface concepts": https://emacsair.me/2017/09/01/the-magical-git-interface/. (If it sounds a bit like a sales pitch, that's because it is; I wrote it for the Kickstarter campain.)
This is my experience. While transient mode helped at the beginning for discovery. I learned fast the 10 things I use constantly, and never look the transient buffer. When I want to do something, I see the documentation, for me it is often easier than guessing and searching. Things like spin-off are absolutely gold.
Indeed! I went back just to mention it owes its incredible UX to the transient package, I am going to look up more uses for it. Do recommend more if you can, please!
Transient is the worst part about Magit IMO (the best parts are how you can prepare a commit to just include the right changes, or the functionality bound inside the transient menus that make complex operations such as fixups or rebases trivial). Transient UIs are consistently uncomfortable to work with, and could usually be replaced by just using a regular special-mode keymap in a custom buffer. The fact that Transient hooks into the MVC and breaks elementary navigation such as using isearch or switching around buffers has irritated me ever since Magit adopted the new interface.
The real neat thing about Emacs' text interface is that it is just text that you can consistently manipulate and interact with. It is precisely the fact that I can isearch, use Occur write out a region to a file, diff two buffers, use find-file-at-point, etc. that makes it so interesting to me at least.
A far more interesting example than Magit is the compile buffer (from M-x compile): This is just a regular text buffer with a specific major mode that highlights compiler errors so that you can follow them to the referenced files (thereby relegating line-numbers to an implementation detail that you don't have to show the user at all times). But you can also save the buffer, with the output from whatever the command was onto disk. If you then decide to re-open the buffer again at whatever point, it still all looks just as highlighted as before (where the point is not that it just uses color for it's own sake, but to semantically highlight what different parts of the buffer signify) and you can even just press "g" -- the conventional "revert" key -- to run the compile job again, with the same command as you ran the last time. This works because all the state is syntactically present in the file (from the file local variable that indicates the major mode to the error messages that Emacs can recognize), and doesn't have to be stored outside of the file in in-memory data structures that are lost when you close Emacs/reboot your system. The same applies to grepping btw, as M-x grep uses a major mode that inherits the compile-mode.
> Transient UIs [...] could usually be replaced by just using a regular special-mode keymap in a custom buffer.
For people who can look at a list of key bindings once and have them memorized, maybe. Turns out most people are not like that, and appreciate an interface that accounts for that.
You also completely ignore that the menus are used to set arguments to be used by the command subsequently invoked, and that the enabled/disabled arguments and their values can be remembered for future invocations.
> The fact that Transient hooks into the MVC and breaks elementary navigation such as using isearch
Not true. (Try it.) This was true for very early versions; it hasn't been true for years.
> or switching around buffers
Since you earlier said that transient menus could be replaced with regular prefix keys, it seems appropriate to point out that transient menus share this "defect" with regular prefix keys, see https://github.com/magit/transient/issues/17#issuecomment-46.... (Except that in the case of transient you actually can enable such buffer switching, it's just strongly discouraged because you are going to shoot yourself in the foot if you do that, but if you really want to you can, see https://github.com/magit/transient/issues/114#issuecomment-8....
> has irritated me ever since Magit adopted the new interface.
I usually do not respond to posts like this (anymore), but sometimes the urge is just too strong.
I have grown increasingly irritated by your behavior over the last few weeks. Your suggestion to add my cond-let* to Emacs had a list of things "you are doing wrong" attached. You followed that up on Mastodon with (paraphrasing) "I'm gonna stop using Magit because it's got a sick new dependency". Not satisfied with throwing out my unconventional syntax suggestion, you are now actively working on making cond-let* as bad as possible. And now you are recycling some old misconceptions about Transient, which can at best be described as half-truths.
> For people who can look at a list of key bindings once and have them memorized, maybe. Turns out most people are not like that, and appreciate an interface that accounts for that.
To clarify, the "custom buffer" can list the bindings. Think of Ediff and the control buffer at the bottom of the frame.
I am not saying that transient offers nothing over regular prefix keys, there is a common design pattern that has some definitive and useful value. My objection is that the implementation is more complex than it should be and this complexity affects UX issues.
> Not true. (Try it.) This was true for very early versions; it hasn't been true for years.
Then I was mistaken about the implementation, but on master C-s breaks transient buffers for me on master and I cannot use C-h k as usual to find out what a key-press execute. These are the annoyances I constantly run into that break what I tried to describe in my previous comment.
> Except that in the case of transient you actually can enable such buffer switching, it's just strongly discouraged because you are going to shoot yourself in the foot if you do that
I did not know about this, so thank you for the link. I will probably have to take a closer look, but from a quick glance over the issue, I believe that the problem that you are describing indicates that the fear I mentioned above w.r.t. the complexity of transient might be true.
> I usually do not respond to posts like this (anymore), but sometimes the urge is just too strong.
I understand your irritation and don't want to deny its validity. We do not have to discuss this publicly in a subthread about DOS IDEs, but I am ready to chat any time. I just want you to know that if I am not saying anything to personally insult you. Comments I make on cond-let and Magit sound the way they do because I am also genuinely irritated and concerned about developments in the Emacs package space. To be honest, it often doesn't occur to me that you would read my remarks, and I say this without any malicious or ulterior motives, in my eyes you are still a much more influential big-shot in the Emacs space, while I see myself as just a junior janitor, who's opinions nobody cares about. But these self-image and articulation problems are mine, as are their consequences, so I will do better to try to remember that the internet is a public space where anyone can see anything.
Odd, I can `C-s` just fine in transient buffers. It works exactly like in other buffers.
The `C-h` override is pretty cool there too, e.g. if from magit-status I do `C-h -D` (because I'm wondering what "-D Simplify by decoration" means), then it drops me straight into Man git-log with point at
--simplify-by-decoration
Commits that are referred by some branch or tag are selected.
(Ooh, I learnt a new trick from writing a comment, who say social media is a waste of time)
- Search for something using C-s
- Exit isearch by moving the point (e.g. C-n)
- Is the transient buffer still usable for you? In my case it becomes just a text buffer and all the shortcuts just got mapped to self-insert-command.
Dayum, given Transient's prickliness (I always feel like I'm walking on
eggshells when I'm in it) I've never dared to C-s. But I tried this,
and yeah, the transient reverts to a plain text buffer, and you're left
in the lurch.
Yeah I agree. I think transient is one of the less appealing things about magit and isn't really very emacs-y. Also, you still have to memorise them anyway
You say a lot of dumb ____ (but to be fair, I said a lot more when I was
your age), but your disdain for transient is on the money. I'm a
satisfied magit user, but transient is a blatant UX error and a
confounded implementation. Some guy spends his 20% time hawking an
entire suite around transient. No one cares.
It's not about being arcane, it's about the lack of discoverability. Emacs and vi don't have (by default) affordances like a menu that enables a user to discover and learn the interface at their own pace. The learning curve is much smoother and allows for casual uses without having to pull a book each time.
FWIW, I started a project last year to build Transient menus for major Emacs modes called “Casual” to address discoverability. Interested readers can find more info about it here: https://kickingvegas.github.io/casual/
Emacs does have a menu by default. It's one of the things I appreciate most about it (especially the Help menu) and I'm always befuddled to see frameworks like Doom Emacs or Spacemacs disable the menubar.
I've been using Magit for years, and have never noticed any bugs.
The interface is unique and takes a lot of getting used to. I did need to leverage my extensive experience with Git and Emacs to understand unexpected behaviour but the fault always lay with me.
Given the implications of bugs in such a critical part of a developer's workflow, can you be more specific?
Mainly random lisp errors being thrown in certain cases, likely just unimplemented functionality, I didn't record them since there are so many. I probably see one every other day but usually it's somewhat outside of the normal operation of magit. It still feels like a bug though, and very likely is.
I mean, magit is not some perfect piece of software. Of course it has bugs, I just hit them quite a lot. The slowness is more annoying though. Sometimes it takes seconds to open magit after hitting C-x g
I've also had magit get stuck in a 100% CPU usage loop a couple times
That sounds frustrating! It hasn't been my experience at all.
I'm an enthusiast when it comes to [Vanilla] Emacs. I enjoy customizing my editor, jumping into the Lisp when I find an error, and contributing - though my own config is usually the problem.
This sounds like an opportunity to improve the day-to-day for developers!
Please report any verified bugs to Github. There are only 12 open issues, most of them enhancement requests. The maintainers are celebrated in the community for their diligence and attentive engagement, and I'm sure they'd love to help.
Yeah, basically when they said that it should’ve begged the question “why is he not used to those conventions?” And the answer would be because the conventions it uses aren’t used by anything else (which means they can barely be called conventions), and makes no effort to adopt any conventions of the platform it’s running on even just to get you started.
Also, another user said it has a tutorial when opened which should teach the basics in “10 to 15 min” but I have a feeling I would need 0 minutes to learn the basics of turbo c++.
I get that there are diehard eMacs and vim fans and honestly I’m happy for them. But at the end of the day scientifically speaking ease of use is not JUST down to familiarity alone. You can objectively measure this stuff and some things are just harder to use than others even with preloaded info.
> I have a feeling I would need 0 minutes to learn the basics of turbo c++.
Well, Turbo C++ (at least the one in the article) does use common conventions but those were conventions of 1992 :-P. So Copy is Ctrl+Ins, Paste is Shift+Ins, save is F2, open is F3, etc. Some stuff are similar to modern editing like Shift+motion to select, F1 for help, F10 to activate the menu bar, etc. And all shortcut keys are displayed on the menu bar commands so it is easy to learn them (some of the more intricate editor shortcut keys are not displayed in the menus, but are mentioned in the help you get if you press F1 with an editor window active).
How quickly does your laptop start? I like this idea a lot, I am now going down the rabbithole of finding which distributions boot the fastest (I remember this mattered a lot to linux users about 20 years ago)
It is as complicated as you want or need it to be. You can avoid any magic and stick to a subset that is easy to reason about and brings the most value in your context.
For our team, it is very simple:
* we use a library send traces and traces only[0]. They bring the most value for observing applications and can contain all the data the other types can contain. Basically hash-maps vs strings and floats.
* we use manual instrumentation as opposed to automatic - we are deliberate in what we observe and have great understand of what emits the spans. We have naming conventions that match our code organization.
* we use two different backends - an affordable 3rd party service and an all-on-one Jaeger install (just run 1 executable or docker container) that doesn't save the spans on disk for local development. The second is mostly for piece of mind of team members that they are not going to flood the third party service.
[0] We have a previous setup to monitor infrastructure and in our case we don't see a lot of value of ingesting all the infrastructure logs and metrics. I think it is early days for OTEL metrics and logs, but the vendors don't tell you this.
"It might help to go over a non-exhaustive list of things the offical SDK handles that our little learning library doesn’t:
- Buffer and batch outgoing telemetry data in a more efficient format. Don’t send one-span-per-http request in production. Your vendor will want to have words."
- Gracefully handle errors, wrap this library around your core functionality at your own peril"
Maybe the confusion here is in comparing different things.
The InfluxData docs you're linking to are similar to Observability vendor docs, which do indeed amount to "here's the endpoint, plug it in here, add this API key, tada".
But OpenTelemetry isn't an observability vendor. You can send to an OpenTelemetry Collector (and the act of sending is simple), but you also need to stand that thing up and run it yourself. There's a lot of good reasons to do that, but if you don't need to run infrastructure right now then it's a lot simpler to just send directly to a backend.
Would it be more helpful if the docs on OTel spelled this out more clearly?
The problem is ecosystem wide - the documentation starts at 8/10 and is written for observability nerds where easy things are hard, and hard things are slightly harder.
I understand the role that all the different parts of OTel plays in the ecosystem vs InfluxDB, but if you pay attention to that documentation page, it starts off with the easiest thing (here's how you manually send one metric), and then ramps up the capabilities and functionality from here. OTel docs slam you straight into "here's a complete observaility stack for logs, metrics, and traces for your whole k8s deployment".
However, since OTel is not a backend, there's no pluggable endpoint + API key you can just start sending to. Since you were comparing the relative difficulties of sending data to a backend, that's why I responded in kind.
I do agree that it's more complicated, there's no argument there. And the docs have a very long way to go to highlight easier ways to do things and ramp up in complexity. There's also a lot more to document since OTel is for a wider audience of people, many of whom have different priorities. A group not talked about much in this thread is ops folks who are more concerned with getting a base level of instrumentation across a fleet of services, normalizing that data centrally, pulling in from external sources, and making sure all the right keys for common fields are named the right way. OTel has robust tools for (and must document) these use cases as well. And since most of us who work on it do so in spare time, or a part-time capacity at work, it's difficult to cover it all.
First time it takes 5 minutes to setup locally, from then on you just run the command in a separate terminal tab (or Docker container, they have an image too).
I did not find that manual instrumentation made things simpler. You’re trading a learning curve that now starts way before you can demonstrate results for a clearer understanding of the performance penalties of using this Rube Goldberg machine.
Otel may be okay for a green field project but turning this thing on in a production service that already had telemetry felt like replacing a tire on a moving vehicle.
My whole career I’ve been watching people on greenfield projects looking down on devs on already successful products for not using some tool they’ve discovered, missing the fact that their tool only functions if you build your whole product around the exact mental model of the tool (green field).
Wisdom is learning to watch for people obviously working on brownfield projects espousing a tool. Like moving from VMs to Docker. Ansible to Kubernetes (maybe not the best example). They can have a faster adoption cycle and more staying power.
... if (and only if) all the libraries you use also stick to that subset, yea. That is overwhelmingly not true in my experience. And the article shows a nice concrete example of why.
For green-field projects which use nothing but otel and no non-otel frameworks, yea. I can believe it's nice. But I definitely do not live in that world yet.
> * I am a bit unhappy with the battery life; I hope I will tune it at some point.
> * the screen is a little dark, so the "frontlight" needs to be on more often than a black and white e-ink device
This is why I ultimately decided to go for a Boox Note Air 3 (sad they discontinued the B&W line). Apart from the lack of support for Boox firmware version 4, all the upsides apply without any of the downsides.
Well you can make the case that people don't have to dress a certain way because we are much better insulated (metaphorically and literally) from the environment. And there are of course no sumptuary laws.
So clothing can be more fun, if people want to of course - look at how music subcultures have incredibly varied ways of expression through clothing - metalheads, hiphopheads, punks etc.
I think you hit gold there, todays lack of interesting clothes is in my eyes related to two things:
- market logic made work clothes boring (think about guild clothing, the only interesting thing I see from time to time is the chimney sweeper)
- less people are inclined to feel part of a subculture and/or express that in their fashion choices
As someone who was a teenager in the 2000s, back then I had at least 6 different outwardly recognizable subcultures in my school class (Metalhead, Punk, Hiphop, Emo, Raver, Goth) and that was more or less normal within my generation.
My small brother and nieces were teenagers during the mid 2010s and in their class all people looked the same. Not only did they look the same, they felt the pressure to all look the same and get similar brands and so on. It just appears that it is a more conforming generation, maybe due tonthe role social media started to play for them. When I grew up social media existed but in a class of 25 maybe half would use it (maximum). And all social media algorithms were strictly chronological.
Young people today have as many self imposed rules as my grandmother used to have. Rules about being cool. Rules about gatekeeping. They would 100% be calling people out for wearing white during the wrong season back in the day, only they'd call it clowning on them as if it's any different.
These are things that go in cycles. When people have been doing things in a bunch of subcultures it becomes "ugh, why are you trying so hard to be different" and when people have being all doing the same thing for a long time it's "ugh, why are you trying so hard to fit in". You hit a peak then everybody gets disillusioned and starts doing something different. It's cool to be ahead of the trend.
So how, instead of with clothing, do subcultures express themselves now? By choice of memes? Which fanfic they read? Do people wear boring clothes but pick subculture-signifying avatars?
What happened is all of the counterculture/subcultures/whatever got so popular and kind of mellowed out and melted together into a bunch of samey stuff.
Like how music went through this phase where "not mainstream" music started getting really cool but now all of those sounds are just what everything sounds like now, you can't rebel against mainstream music right now.
That may be true, but I'd be willing to bet that in 2038 we'll be able to go on whatever the successor to YouTube might be, and find someone commenting, somewhere, that a particular clip "was the last of the real ${ADJ} ${NOUN} genre" and that the young people don't realise that what they call music can't hold a candle to 2031.
The way that I've heard it described is that capitalism now appropriates any subcultures that arise. That both serves as an avenue for profit and has the added benefit of suppressing anything that might inspire people rebel against the status quo.
This is just a weird attempt at being edgy about capitalism.
A new subculture either grows or dies, if it grows people start making money off of it and it gets diluted by the popularity into something more beige and palatable. It isn't about capitalism it's just when you add more people, they take it less seriously and hardcore becomes bland.
>look at how music subcultures have incredibly varied ways of expression through clothing - metalheads, hiphopheads, punks etc.
Metalheads? Huh? I like metal, but metal fans are some of the most boring dressers I've ever seen. Go to any metal show and you'll just see a bunch of guys wearing jeans and black T-shirts from their favorite bands' prior concert tours. Some of the musicians used to dress pretty flamboyantly back in the hair-metal days of the 1980s, but those days are long past; the musicians these days are in their 60s and dress rather casually and plainly.
Datomic Pro doesn't need AWS, I don't see what complications it can cause. It has some helpers for running it in AWS (like a bucket to export to CloudWatch), but none of them are mandatory. And if your use case is small you can run with dev storage (https://www.h2database.com/html/main.html); pretty much the same as you would SQLite.
It might be slightly harder to get started with, but then the simplicity comes in when it is time to solve common business problems. A trivial example would be - we have this nice db, now our clients want reports. You run your reporting as a separate clojure process, it doesn't impact production at all, without needing to setup reporting databases and log-shipping.
