IDEs we had 30 years ago and lost (2023)
191–200 of 607 posts
Re: IDEs we had 30 years ago and lost (2023)
#192Borland C++ 3.1 & Application Frameworks for DOS and Windows 3.1 came with an entire library of paper books. It was probably the heaviest and largest boxed retail software package ever because 4.0 skimped on paper books and didn't include real mode versions of the IDE for DOS.
The Pascal almost equivalent was Borland Pascal 7.0 with Objects.
It was possible to link assembly, C++, and Pascal in the same executable assuming the memory model and function calling convention were set correctly.
Re: IDEs we had 30 years ago and lost (2023)
#193Earlier quoted context omitted.
Magit is mind blowing. 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.
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…
Re: IDEs we had 30 years ago and lost (2023)
#194Re: IDEs we had 30 years ago and lost (2023)
#195Re: IDEs we had 30 years ago and lost (2023)
#196Re: IDEs we had 30 years ago and lost (2023)
#197Earlier quoted context omitted.
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 Transi…
> 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…
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.
Re: IDEs we had 30 years ago and lost (2023)
#198Re: IDEs we had 30 years ago and lost (2023)
#199Do you think there’s anything like that out there today? The only ones I can think of that are closed are nano and micro editors, but I wouldn’t really call them IDEs.
Re: IDEs we had 30 years ago and lost (2023)
#200Earlier quoted context omitted.
Neovim is my favorite editor and is a brilliant TUI. I think what TUIs get right is that they are optimized for use by the keyboard. I don’t care if they are a pain for devs to write vs OS APIs, they have the best keyboard control so I use them. I despise the mouse due to RSI issues in the past.
Neovim instantly becomes a superior piece of software if you use any of the GUI frontends. If you use neovim inside a terminal you are just straight up using an inferior product, with less features and more problems. The terminal version is most likely slower as well as you now also have the entire legacy terminal overhead. >I think what TUIs get right is that they are optimized for use by the keyboard. Neovim is jus…
I use neovim like that and the selling point for me is that it's 1 less program that I have to install and learn with the added (crucial) benefit that it doesn't update on its own, changing UI and setting that I was used to.