The "Emacs doesn't have a file-tree" is when I stopped short and wondered what this person's background is in IDEs.
My emacs days are 1999 during my "functional or get out" phase, but my .emacs had close to 4000 lines in it, including xterm mouse support, a clone of midnight commander + sftp to a wehbost and deep integration with ctags/cscope/c++filt. There was even a line by line debugger with custom .gdbinit commands - look at the php project's gdbinit[1] if you want an idea of how to walk your own super special data structures.
You can't put Emacs in an IDE comparison and say anything about features without at least one person saying "well, actually".
I eventually switched to vim but that had to do with needing to ssh into 100k+ machines on support rotation & never having emacs on any of them.
It also incorrectly says that Emacs has no mouse support. When you first open Emacs the default buffer has clickable links in it, it's impossible to miss the fact that Emacs has mouse support if you ever even open it.
Yeah, speedbar and dired are built-in. Speedbar by default still opens in a new frame I think, but in emacs 31 there’s a config option to make it open in a side window without any additional tweaking needed.
Long time ago, in mid-2000-s I tried to switch to Emacs or Vim from Visual Studio.
I wanted to have a simple project file tree as a side panel and multiple editor tabs on the right. I spent a week toying with various elisp scripts, Vim plugins, and digging out information from a then-moribund XEmacs mailing list.
And I couldn't do what I wanted in the end. Nothing worked seamlessly or reliably.
I have a script that changes the background colour of my terminal based on whatever directory or server I'm in. That's enough beauty for me, I do believe there is such a thing as over configuring and defaults are very powerful.
This seems like all those UI designers who have a crack at redoing Wikipedia and then fail miserably because they just plaster whatever trend on top of something that is universally good.
Yep, I have 2 kids under 1 so this project is either built with AI or it’s not built. I put that line in because the IDE aspect doesn’t need agent management or anything. Other tools are better for that.
I would still be nice if you stated upfront that this is built with AI. The people who are interested in “no AI features” are likely to also be the ones who do not want something built with AI. It would help to be clear about the project’s stance on the matter.
I have so much shit now that I have custom workspaces to deal with because "repository" has stopped being the correct boundary to think about software development (for me). It would be great if _any_ decent editor would support these, especially Zed.
I don't understand the trend of forcing everything into terminals. It's needlessly constraining and it's much more work that just using Qt (or any other UI framework).
> toast is for the developer who wants to stay in their terminal without spending hours getting it up to snuff.
I need a terminal that just works. If it doesn't work out of the box with sensible defaults, it is indeed not up to snuff, and therefore thrown away immediately. Don't ask me to use your buggy-vibe coded thing if it's not up to snuff, right?
This is coming from someone who did spend hundreds of hours learning to customize their terminal, their vim environment, and put all of it in source control to rot away.
Making these kinds of AI projects with fancy READMEs give you a veneer of authority, but the lack of earned wisdom tends to stick out once a few people glance at it.
Yeah maybe not the best wording. It’s more meant that ideally toast can be fully used with a cursor for interactions. I don’t think you can exit vim or emacs just by clicking on a button?
That’s just the theme matching the terminal, there are two others out of the box but I prefer the system theme. And by beautiful I mean it has a cohesive system design and theming. I prefer to to another VsCode clone
Poor wording, more so meant that when I drop into vim, vi, or emacs I have no way to (without some external knowledge) know how to open a file tree. Just a barrier to usage is all.
But this is not what that site tracks. It lists any project with any LLM usage or potential usage (eg. permissive AI usage policy, but no evidence of AI use) without any caveats. It is an extreme, absolutely no AI usage, stance.
My emacs days are 1999 during my "functional or get out" phase, but my .emacs had close to 4000 lines in it, including xterm mouse support, a clone of midnight commander + sftp to a wehbost and deep integration with ctags/cscope/c++filt. There was even a line by line debugger with custom .gdbinit commands - look at the php project's gdbinit[1] if you want an idea of how to walk your own super special data structures.
You can't put Emacs in an IDE comparison and say anything about features without at least one person saying "well, actually".
I eventually switched to vim but that had to do with needing to ssh into 100k+ machines on support rotation & never having emacs on any of them.
[1] - https://github.com/php/php-src/blob/master/.gdbinit
> toast is for the developer who wants to stay in their terminal without spending hours getting it up to snuff.
I think he knows you can get anything you want in emacs/vim. The pitch is that toast is batteries-included.
Long time ago, in mid-2000-s I tried to switch to Emacs or Vim from Visual Studio.
I wanted to have a simple project file tree as a side panel and multiple editor tabs on the right. I spent a week toying with various elisp scripts, Vim plugins, and digging out information from a then-moribund XEmacs mailing list.
And I couldn't do what I wanted in the end. Nothing worked seamlessly or reliably.
Can this be done out-of-the-box now?
Or use any of the various file tree packages in [M]ELPA
"github.com/yourusername/toast/internal/components/breadcrumbs" "github.com/yourusername/toast/internal/components/closedialog" "github.com/yourusername/toast/internal/components/commandpalette" "github.com/yourusername/toast/internal/components/editor"
This seems like all those UI designers who have a crack at redoing Wikipedia and then fail miserably because they just plaster whatever trend on top of something that is universally good.
I have so much shit now that I have custom workspaces to deal with because "repository" has stopped being the correct boundary to think about software development (for me). It would be great if _any_ decent editor would support these, especially Zed.
I wrote this article a while back on how to build a great terminal editor that's better than Emacs and VIM [1], you might find it interesting!
[1] https://gist.github.com/taoeffect/086220456e736cceb30d68834d...
I need a terminal that just works. If it doesn't work out of the box with sensible defaults, it is indeed not up to snuff, and therefore thrown away immediately. Don't ask me to use your buggy-vibe coded thing if it's not up to snuff, right?
This is coming from someone who did spend hundreds of hours learning to customize their terminal, their vim environment, and put all of it in source control to rot away.
I just made a bash script that shells into the container (or starts it if it is not already running) and in there everything is set up.
To me, it's just yet another bland low-contrast dark mode interface.
Also, vim has mouse support. Probably shouldn't use a clanker to write your readme if you're not going to take the time to do a basic fact check.
Christ.
> Sees "Claude"
Now almost 90% of projects on GitHub including existing projects are now slop or are adding slop.
Many projects are getting contaminated with AI, and even Linux is getting contaminated with this.
There is a list of projects that have non-slop alternatives one can use instead.
https://codeberg.org/ethical-foss/open-slopware
The idea that there can be no high quality use of LLMs to aid software development is lacking a lot of nuance.
Yes.
To quote the repository:
"slop: Anything generated by AI, typically code, books, articles, or images."
If you are reviewing AI generated code, you are already reviewing slop which is a lose-lose situation.