6 ms·
These features are nice, but I've never liked the idea of having to use a whole new terminal application to get them. I may be becoming a dinosaur, but it's no
by masto 3y ago
These features are nice, but I've never liked the idea of having to use a whole new terminal application to get them.
I may be becoming a dinosaur, but it's not that I'm not willing to try new things. On the contrary, after many years of being rigid about having one true development environment, I've moved away from Emacs to VS Code, and work from more heterogeneous environments instead of being 100% Mac. So these platform-specific thick client apps no longer feel like the way to go.
- veg 3y agoThere's no need for a new terminal. Their homepage literally says "IDE-style autocomplete for your existing terminal".
- hot_gril 3y agoI also thought the wrong thing at first since the big front and center title on the homepage says "The next-generation command line."
- deleted 3y ago[deleted]
- askew 3y agoYou may be thinking of Warp (https://www.warp.dev/ https://www.warp.dev/)
- rollcat 3y agoTo be honest I do think it's time we move on from emulating teletypes, but I also believe that whatever comes next has to be an open standard, with competing implementations. There's a whole graveyard out there of "next-gen" terminal projects, and none of those still alive seems to be gaining dominance. I don't think writing down a spec would help this, but it would be great if whatever emerged victorious had one.
- oxalorg 3y agoCurious to learn more about your switch from Emacs to VSCode? I'm a super confused soul, and currently I use all of them: - Emacs (for clojure / lisps / big projects). - NeoVim (for when I want to work in the shell, smaller scripts/playground, ssh). - VScode (js / ts / frontend / figma / etc). I've made both my vim and emacs keybindings / features almost identical, so there is limited context switching there. I feel very slow in VSCode, I don't even have one of my most common task optimised in VSCode yet: grepping something and quickly moving to that buffer.
- hot_gril 3y agoSticking to Vim and other very well-established CLIs is partially what enabled flexibility for me. As long as I have access to a *nix machine locally or over SSH, I have a capable dev setup that I'm well-versed in. Same thing for the past 8 jobs I've bounced around in, whether in-office or remote, with whatever security restrictions, with or without a desk, maybe with just a 13" laptop. It's the lowest common denominator. Meanwhile my teammates at my current job are constantly trying to protect their workstation setups so they can use their IDEs locally, and they've also been forced to switch IDEs twice in the past couple of years. And this isn't coming from some FOSS ideology. I don't personally care about any of that, but the best tools are sometimes FOSS. I've got a Mac and can deal with Linux as needed.
- chrysoprace 3y agoIt's not a different terminal application, but an overlay that gives you autocomplete-style suggestions in your existing terminal emulator. I don't know all the terminal emulators it works with since it's MacOS only, but it works in both iTerm2 and the VSCode terminal, granted that you're not using a terminal multiplexer like tmux (which makes it useless for my workflow).
- dangus 3y agoI think the part of this that feels wrong is that it steps into the realm of so many other perfectly good tools, and it seems like it’s there to enshrine crappy local development and deployment practices. If you need reporting on the scripts your developers are running on their local machines, that probably means they have too much access to live environments. Guardrails and reporting should be in your CI/CD process and your source control. Shells like fish or shell plug-ins already handle autocomplete nicely, so that feature isn’t that useful. If you need env/dotfile management you probably need to spend time making a proper development environment rather than shimmying in a tool to make doing the wrong thing easier. SSH key management is so trivially accomplished by numerous methods like configuration management or built-in solutions offered by cloud providers. Plus, most development teams almost certainly give out too much SSH access as it stands. If you need to SSH regularly that means your application isn’t shipping logs and your local development tooling isn’t good enough.
- yieldcrv 3y agoYeah I just stopped paying for Jetbrains to move 100% to VS Code just a few months ago I was using both before but the upcoming annual payment reminded me that its over