Unix as IDE (2012) | Hacker News Reader

Unix as IDE (2012)

sanctum.geek.nz

142 pointslrsjng103 comments

I'm a terminal jockey and an i3 junkie, and for a long time vim+extensions+Unix tools were my IDE too... but ultimately there is a difference between a powerful editor used like an IDE, and an actual IDE. there are lots of features which get first class.attention in an IDE, which were just kludgy hacks in my beloved vim... and some that simply weren't possible.

For example, VSCode Remote container development. The IDE is split into client and server portions, with the server living in a container (or group of containers) of your definition. So your host environment is clean, but you still get tools that are a PITA or impossible to run remotely, like certain debuggers or linters. And best of all, the configuration is saved in the repo. Commit it, and everyone in your project gets a "one button option" to use the same developent environment as everyone else.

It's not IMPOSSIBLE to do something similar with vim+Unix. Docker compose and enough automation will get you most of the way there. But not without a tremendous amount of work and time spent maintaining it for everyone's unique environment. And certainly not in a fashion that i could call "one button".

There are a few features like that. So I stopped spending hours (and hours and hours) maintaining a collection of hacks that approximated a modern development environment, and started using software for what it was designed to do. Vim is still my superpowered editor of choice, but when i'm working on a significant codebase, I use an IDE.

I am this kind of guy, too - i3 + st + vim bindings almost everywhere.

But it's a mixed bag, like I can use vim and do something complex in an instant, e.g. replacing a column of characters with something else, but I'm too used to the regular expression replace all mode of vscode. Or the file manager on large projects, I'm pretty much used to using one file at a time with vim.

I feel no shame xD

What is `st`? :)

Probably meant sublime text?

Not GP, but I suspect they’re referring to this terminal emulator:

https://st.suckless.org/

terminal emulator by suckless https://st.suckless.org/

suckless terminal I love the "externalpipe" functionality, which is the main reason I switched from terminator.

I tried VSCode several times, but always came back to vim. I think there is a fundamental difference to a purely terminal based workflow.

Learning a new commandline tool has almost always been something that paid back for years: CLI cares much more about backwards compatibility than a GUI because it's used in shell scripts. And that's another advantage: you are only one step away from automating stuff. A homogeneousness set of keybindings over all applications are just the icing on the cake.

I use both VSCode (in Vim mode) and Vim+Tmux in my work these days.

VSCode is good for working in TypeScript codebases—I couldn't find any way to show helpful and long TS compiler errors in Vim nicely.

However, VSCode’s terminal is semi-broken and sessions do not persist, so for other kinds of work that might involve grepping around, running builds and one-off data migration scripts, etc., Tmux+Vim (with respective shortcuts to unify pane navigation) work perfectly.

I've been using both VSCode and JetBrains IDEs with their VIM plugins. The VSCode one is kind of shitty, but overall both do the job well enough that as a not-super-proficient-vim-master-guru I don't really lack any features.

And you get all the IDE stuff as well. Pretty much a win-win there. (if the vim functionality is good enough for you)

I was doing remote development with code completion and navigation using Emacs TRAMP years before this feature you talk of. So... Not as difficult as you seen to be implying.

I've gotten made fun of because I've said my "IDE" is `tmux` in the past; my typical development environment is a tmux split, where an editor (usually NeoVim, sometimes Emacs) does editing, and the bottom half is a terminal running either a dev server or just the compiler command.

It's not perfect, but I like how I can basically swap any component out (except tmux itself).

You could throw an extra layer of fun and use a windows manager with multiple workspaces/screens that serves as your IDE. One workspace could be for coding/debugging, another workspace could be for servers/system diagnostics/etc. Another could be for multimedia/distraction/etc.

I actually do something similar to that when doing any kind of GUI apps; usually I have a workspace for my browser, another workspace for VLC, etc.

That's what I do, too. Vim and a couple shells and I'm happy.

I despise autocomplete and will not use things that force it on me. IntelliJ has options to make it not aggressively, in-your-face annoying, so I can live with it, and do use it for access to some tooling we built at $dayjob.

But after spending a day turning off all the bullshit, installing vim bindings, etc. I get... a slow, memory-pig semi-substitute for my shell environment that still is less flexible.

Progress.

> I despise autocomplete

Could you elaborate on why that is? I feel similiar but I cant just tell why

A lot of autocomplete systems will put text into the document FOR you, like when you press enter or space or something. It is infuriating. Having the suggestions that you can access if you want is usually fine, but sometimes also having that bubble pop up and cover code below or above that you need to see is also infuriating.

Thanks for the answer

I find it extremely distracting. A little hard to describe, but it is sort of like trying to remember one number while someone is babbling other numbers, or trying to keep a train of thought while listening to multiple other conversations.

There's also the visual noise - I hate it for the same reason I hate tool tips and similar. Popping up flyovers on top of whatever I'm trying to focus on is utterly infuriating and I've never understood why people think that's good UI. It is like shoving your hand in my face if I look at you.

I've been using this sort of setup for over a decade. I try IDEs from time to time but typically I find it just gets in the way or buries the things I care about among 100 other features I would never use. Additionally, IDEs are often optimized for one platform or language but not others or for general use. With vim I can use one editor to code, write email, write documentation, etc.

With neovim you can have autocompletion, error checking, git integration, project file navigator, and many other IDE like features but without the cruft.

Performance and stability is stellar compared to the IDEs I have experience with (eclipse, visual studio, xcode, and PHP storm). Especially if you use a terminal that uses the GPU to render the screen. With startup times there is no competition, tmux can keep your terminal session alive even after quitting the terminal which means their is essentially zero startup wait.

I tried to get into tmux but it started to get frustering as someone coming from using the native shell. I even fell down the rabbit hole of wonking with my tmux config, trying different versions, etc.

I just could not stand the mouse behavior, ultimately. Switched to screen for some things. Sometimes its just easier to use the trackpad to scroll than page up/down or select text with the cursor vs. with the keyboard. Can't do both in tmux; either you can scroll in programs and not in the shell, or loose 'modern' copy paste and select behavior with the mouse as well as scrolling in programs to get scrolling in the shell. I just couldn't figure out how to have it both ways like the native shell.

You can but you need to change the mouse mode

In newer versions of tmux

   set -g mouse-mode on
   # make scrolling with wheels work
   bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"
   bind -n WheelDownPane select-pane -t= \; send-keys -M

I'm getting invalid option: mouse mode in tmux 3.0a, and unknown option: mouse-mode in tmux 1.8.

That's the thing with these .tmux.conf hacks you see floating around github and stack overflow. The tmux devs changed the relevant settings practically every other release and offered no compatibility, so most of what you find just doesn't work with your build.

But even those snippets that do work with my builds, you can't have it all. Either scrolling up takes you past the panes and into the std output of the native shell, or you enable mouse mode and can scroll in your shell but loose the ability to scroll in editors like nano and programs like less.

Maybe if there was a way to automatically turn off mouse mode when running programs and flick it back on when exiting to the command line, but I'm not well versed enough in the .tmux.conf syntax to figure it out without too much trouble.

I created something that enables the scroll based on process name https://github.com/noscript/tmux-mighty-scroll

Ohh...nice. And to GP, if this doesn’t work well for you, try the combination of abduco and dvtm. Before I joined Red Hat, that was my terminal multiplexer combination of choice. However, because they’re in EPEL which most of my customers don’t use, I forced myself to revert to tmux. I remember initially missing abduco + dvtm but get 95% of what I want with tmux. abduco feel slightly better about maintaining session state.

Lately, I've been playing with the idea of combining tmux, nano or purpose-built kilo editors[0], fff [1] or slmenu [2][3], and kanban.bash [4] into my own little "agile" terminal IDE.

[0] https://github.com/antirez/kilo

[1] https://github.com/dylanaraps/fff

[2] https://www.youtube.com/watch?v=SlJto75auCA

[3] https://github.com/joshaw/slmenu

[4] https://github.com/coderofsalvation/kanban.bash

I think tmux is overrated, at least when running locally. Tiling WM gets you the same efficient screen layout and keybind driven navigation, and it'll manage also graphical windows that you'll inevitably end up having (like browser). Also you'll avoid any tmux-in-tmux issues if you do connect to remote hosts, and all the terminal features (copypaste, urlgrab, scrolling, search etc) actually will work properly.

I would stop using tmux entirely and switch to this, but the cluster I work on has 2 factor authentication which is absolutely annoying.

You may wish to investigate the ControlMaster directive in your SSH configuration. Depending on how the two factor authentication system works, you may be able to authenticate just once for many concurrent SSH sessions.

Here's what I use to keep SSH connections open for 4 hours: https://blag.felixhummel.de/apps/ssh.html#config

It took a while to find out that `Host *` should be at the end of the file if you want to override things.

> I think tmux is overrated, at least when running locally. Tiling WM gets you the same efficient screen layout and keybind driven navigation

Funnily, I have made the opposite path, moving from a tiling WM to tmux into a simple xterm. Tiling wm are overrated, since tmux gives you the same functionality, and you can detach your session easily.

What I'm sorely missing is a way to "freeze" all my tmux processes so that they can be recovered in the case of a system reboot.

Seems like a great idea. Lack of persistence bugs me about my i3 / tmux / emacs setup.

Google brings [1] but I haven't tried it yet.

1: https://github.com/tmux-plugins/tmux-resurrect

yes, but this is a mock-up of a real freeze. What I want is independent of tmux: a way to freeze a process and all its children and save it into a file. The file is then opened when rebooting, or even on a different computer. There was this:

    https://github.com/maaziz/cryopid

Have you looked at CRIU?

Yes, but does it really work? The documentation is written in the future tense.

It works for most things. You can always try it for your usecase and see how it goes.

Rather than freeze them I have a tmuxinator[0] config per project that opens all of the panes and tools I tend to use. Usually something like: editor, extra (often my rails console or database prompt), git, tests, server, logs.

I know the numbers off by heart so can switch without looking.

[0] https://github.com/tmuxinator/tmuxinator

Tmux Resurrect works pretty well:

https://github.com/tmux-plugins/tmux-resurrect

> since tmux gives you the same functionality

Unless you're browsing HN on Lynx I suspect you'll have at least a graphical browser running, which means you still need some way to manage graphical windows, because that is simply something that tmux does not do.

Also proper WM is unsurprisingly more capable/flexible for window management because it's not limited by a fixed character cell grid and other idiosyncrasies of terminals

> Unless you're browsing HN on Lynx

I actually use elinks to read HN and many sites, but I also use regularly a web browser.

However, I try to keep web-browsing usage as sparse as possible. I launch firefox from the terminal, browse tho wherever I need, and then close the browser window. I abhor to have a browser "always open".

tmux offers a level of abstraction that's missing from a tiling WM alone.

You can have 1 tmux server running locally with many sessions (let's say 1 session per project).

Then each session can have many windows (separate terminals that are full screen).

And then each window can have many panes (splitting that window however you see fit).

But if you went with a tiling WM alone without tmux, the WM's workspaces become sessions and your terminal becomes a window. So now you're stuck having to lean on your terminal emulator for tabs and splitting windows, but you're also on the hook for it having buffer searching, copying URLs, scrolling and other things. Most terminals are really bad at those tasks but tmux is great with them when combined with something like xterm (a low input latency terminal).

Plus with tmux you have the option to easily save and restore everything with tmux-resurrect, and you can take your whole set up and replicate it on Linux, MacOS and even Windows with WSL and it all works the same as long as you find a good light weight terminal on each platform.

I think there's a lot of value in using both a tiling WM and tmux together. tmux basically super charges any terminal into having world class support for everything a terminal needs to do. Even if it didn't persist sessions, it would still be really valuable. IMO it's severely underrated. People's eyes widen and still get impressed when terminal emulators add basic tab support. If they only knew what was lurking around the corner with tmux!

> So now you're stuck having to lean on your terminal emulator for tabs and splitting windows

If you have tiling wm, why would you want tabs or especially splitting in terminal emulator?

> Most terminals are really bad at those tasks

Just don't use bad terminal emulators? And good terminal emulators are better at those tasks than tmux

> If you have tiling wm, why would you want tabs or especially splitting in terminal emulator?

Splitting is useful so you can see more than 1 thing at a time. You know, tiling. :D

This is especially true if you have a high resolution display such as 2560x1440 or 4k. You can fit a ton of info at once across multiple panes.

> Just don't use bad terminal emulators? And good terminal emulators are better at those tasks than tmux

I've tested dozens across multiple operating systems and haven't found one that that has as low input latency as xterm along with having a better implementation of tabs, splits, searching, being able to name windows, zoom toggle into windows, and everything else tmux does. None of them were even in the same ballpark.

I honestly just use tmux as a tabbed terminal with saveable state. For someone who works remotely from multiple locations, attach/detatch is life changing.

I'm glad I'm not the only one.

I love tmux, but I prefer vscode to vim, and I'd rather just keep tmux as the place where I keep all my terminal panes/windows. A lot of people look at my tmux screen and assume that I'm using vim or emacs.

I use nested tmuxes, one per workspace, and one to hold all of them, with small scripts to launch new ones making sure that the top-level tmux window is named the same as the workspace tmux session.

In every C/C++/Java workspace I run cscope on tmux window #0, with a CSCOPE_EDITOR script that launches the real $EDITOR in a new window in the same session, with the window named after the basename of the file being edited.

This makes it trivial for me to find my way around all my shells and running $EDITORs.

Altogether this allows me to avoid using the mouse a great deal.

Compile mode on emacs is pretty sweet. You can bind it to a shell command for a particular major mode and compile from a couple keystrokes. The compile buffer can be interactive (for debugging) which is also pretty sweet ! And Ctrl-g makes the compilation buffer disappear so it's heaven :)

I don't like either extremes. I quite hate working in big bloated IDEs. But I don't like trying to accomplish everything at the terminal. I always use GUI and shell tools together.

My editor of choice TextMate is usually launched from the terminal. I work a lot in a REPL environment and when I get a stack backtrace my terminal program iTerm2 automatically identifies paths in the stack backtrace, so I can mouse click them and open in TextMate at the correct line.

I use a separate git GUI client called Tower a lot, but I also use the git command line. I mix and match a lot.

I really dislike monolithic tools. If you try to do absolutely everything from the CLI you get many of the same problems as in a IDE GUI: You get too much complexity in your interaction. Too many special keystrokes and commands to remember.

I quite like the old NeXT idea of an IDE, kind of how the old xCode was when interface builder was a separate program. As you integrate more tools complexity just grows.

We already have a multitasking OS with windows. We where meant to use multiple tools and not just sit in one big maximized monolithic program.

> My editor of choice TextMate is usually launched from the terminal.

My issue is, I need an editor that knows that a field annotated with @Resource with a type and name of SomeService foo is injected by a DI framework and makes it easy for me to navigate to implementations of SomeService with a name of `foo`.

Sure, I could put hundreds of hours into half-way replicating what an IDE does. Or, I could just use an IDE that was written by people who've felt the same pain as me. TextMate might be good for the occasional Ruby or Python script, but even then - do I have to manually manage virtualenvs while working on this script, or can my IDE do it for me? (Spoilers: Intellij can)

My understanding is that people who want this sort of thing use a client server set up with a server that does all of the AST parsing and linting separate from the editor.

I feel like there’s a weird power thing some people get sucked into that ends in forcing everyone around them to use their preferred (often IntelliJ or vscode) editor often via the argument that the linter configuration only works in it.

Textmate was my first love as far as text editors go. Such a great program! I had to leave it for vim eventually though for various reasons. I have no evidence but in its time I really think TextMate helped push text editors forward. I often see its influence in Sublime, Atom, and VSCode.

> iTerm2 automatically identifies paths in the stack backtrace, so I can mouse click them and open in TextMate at the correct line.

That sounds super convenient! How do I learn more? A quick search didn't turn up anything relevant. What should I be searching for?

I recently discovered the "watch" command. With an autosave plugin in Vim, I can put some "print()" statements in my code and run "watch python3 mycode.py" in a small Tmux pane to get nearly instant feedback as I debug something. Or if I'm refactoring, I can do "watch pytest". It's pretty sweet.

I started on a Qt4 Mac8 login screen clone. My repl was a similar shell script to rebuild and run on changes. Watch is pretty cool for stuff like that.

Watch is great if you are using an hpc cluster as well. Our workload manager is slurm, so 'watch -n5 squeue -u my_username' is a great way to keep track of the progress of batch jobs submitted to a compute node. I put it in an alias.

Thank you — I’ve often times had to run things interactively and this would have saved me so much time and stress.

This is a bad practice. squeue will hit the scheduler directly. If a lot of people do that your scheduler will be busy answering squeue calls, not scheduling. (Saying this just in case we are working on the same cluster ^^)

Using “watch” [1] to run your program is a bad idea. The watch command executes a program at regular intervals, by default it runs once every second.

What you should use instead is “inotifywait” [2] to execute your program(s) whenever there is a change. This way the program will run, for example, every time you save your changes. There are many utilities that make use of inotify (the library that powers inotifywait) some of them are fsnotify [3], fswatch [4] and watchexec [5].

[1] https://linux.die.net/man/1/watch

[2] https://linux.die.net/man/1/inotifywait

[3] https://github.com/fsnotify/fsnotify (written in Go — golang)

[4] https://github.com/emcrisostomo/fswatch (written in C++)

[5] https://github.com/watchexec/watchexec (written in Rust)

If you like inotify, you might also like entr [1].

I only found out about it few days ago, but it seems nice so far.

[1]: http://eradman.com/entrproject/

Wow this is amazing. You made my day with this tool!

If you're going to be using any system like this (either watch or inotifywait), be careful. It's a good chance it's going to run in an "intermediate" state when it's not supposed to run and can do harm to your system (delete files or whatever). Bash scripts are especially dangerous, but it applies to any language.

A good idea would be to at least run the script in some kind of sandbox, so you don't accidentally do something dumb.

A few times previously:

https://news.ycombinator.com/item?id=12653028

https://news.ycombinator.com/item?id=4105768

https://news.ycombinator.com/item?id=3594098

I think code completion is missing. Sure you can always try to grep your function call, but seeing the parameters and return type of a function you are calling as you are coding is really nice.

Also a real IDE does much better debugging. Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

The author addresses some of that directly - the series is really a collection of tutorials on how to get various programmer-ish things done in Unix. The title is a stroke of viral genius.

Keep your declarations on a single line:

    int fun(void*);

And

    grep -r fun *.h

Will tell you everything you need

also, you could use ctags.

vim has basic completion builtin.. and there's a lot of code complemention plugins..

Now that language servers (https://microsoft.github.io/language-server-protocol/) are a thing, the code completion in terminal-based editors like vim and emacs can be just as good as what you'd get in an IDE.

Does anyone have a good solution for orchestrating language servers? With a mildly complex code base (grpc/thirft + python + build system) there's a lot of languages in play. At any small to medium company you're looking at around >5 different languages used. Downloading, configuring, starting, and providing context to (what files can see what other files, what the final build looks like, etc) to all of the language servers you want to use can sometimes be a huge pain. This is something that IntellJ with gradle does very easily.

What works for me is having a script per project/directory a script that set all the configs (as environment variables) and various other functions for that project. If the script exists then it runs when I cd in and other scripts can use the environment variables. So a script like start-language-server would check for the environment variable PYTHONLS and PYTHONLSPORT and start it if it's not running, or it can be started straight from the cd.

Never had to handle multiple languages in one project though, I find vims builtin completion enough for the rest.

You can do that in a lot of editors. Don't need an IDE for that. You got standardized language servers now which are often easy to integrate in a multitude of editors.

But personally I don't like IDE style completions that much. In editors I often prefer completions based on what is in the file I am editing. But I also work a lot in a REPL environment.

I personally think a good REPL is a much better debugging tool than most IDE debuggers.

> Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

That does not really have anything to do with IDE vs command line. My experience as a C++ developer for many years on Linux is that debuggers just don't work that well. Many of the issues has to do with the complexities of C++ and how gcc stores debug information.

Most IDE style debuggers on Linux are quite crappy, because they are slow and undependable. Printf is faster, more dependable and gives more flexibility in how you display data you are interested in.

> My experience as a C++ developer for many years on Linux is that debuggers just don't work that well.

That has been my experience on Linux. On Windows, Visual C++ debugger works amazingly well.

Not sure why you're being downvoted. IMHO, printf based debugging is more ergonomic and requires less context switching. Instead of using my mouse to work with debugger or remembering a myriad of shortcuts for navigating through it I can just keep typing right in my editor where I already am. For me it fall under the keep it simple stupid category.

How do you add more watches (printfs) without recompiling/restarting though (That seems like a basic requirement for calling it ergonomic tbh)

What is it about an IDE that you need?

a) The ability to do an end-to-end build with one click (we've lost that with cloud being part of the equation)

b) Guranteed buildability

c) Intellisense/autocomplete

d) Widgets that can be moved into any which way.

I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop IDEs.

Not much else, the ability to jump to code is the primary benefit.

Pretty much every programmer editor lets you jump to code. I can even do that from my Terminal program. If I run a program and it produces and error my terminal interprets paths in the error message and let me click them to open my code editor at that file and line number. No IDE needed ;-)

More trouble than ctrl-B though

Which terminal lets you do that?

That's presumably because the error had some format including rows columns and filenames.

Navigating from a symbol to another symbol (e.g. from a variable use to its declaration) requires more than simple pattern matching.

The editor needs to know (or be able to find out) the symbolic meaning of every word on the screen to do that. If syntax hihglighting isn't just basic regex matching, e.g. if you want different colors for mutable/immutable fields etc, then the editor needs to know the syntactic meaning of everything not just when navigating but when displaying.

e) Some kind of debugging or program introspection.

> I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click

Isn't that what "make" is for? A Makefile and an IDE project file are quite similar in structure.

> I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop IDEs.

I use "bazel test ..." to build stuff on the command line and my CI system runs "bazel test ..." to build stuff in CI. They can even share the same cache, and the cache actually works. (I admit for that 90% of go stuff I just use their build tool, though.)

I think IDE-integrated build systems are an artifact of times where people didn't write multi-language projects and there weren't good open source build systems. Things have changed a little, and now you can have your cake and eat it too.

(Autocompletion has also moved out of IDEs and into things maintained by languages themselves.)

An full build is always the easiest build.

Building as little as possible and having quick iteration is the hard bit when you have statically typed languages and large projects. If I edit a file and change the name of the function, the call sites should all light up with red squiggles. In a statically compiled language. Without requiring a recompile.

> If I edit a file and change the name of the function, the call sites should all light up with red squiggles. In a statically compiled language. Without requiring a recompile.

which is what all IDE support ? most even allow you to automatically fix it nowadays

Well it requires quite a bit from the compiler/language server infrastructure to not just behave like a batch compiler and give up after e.g. a failed parse. The ability to analyze incomplete or incorrectly parsing syntax is very tricky compared to doing it in sequence parse -> analyze etc.

Many IDE's manage this but far from all languages (compilers) do, simply because their compilers are simple batch compilers.

The features that really set it apart are the sophisticated refactoring tools that are context and language aware. It goes so far beyond snippets and auto-complete.

Being able to dive into any source by clicking, and also full awareness of unused or incorrect code is very valuable.

> Some of the principles discussed here will be applicable to those using Emacs as well, but probably not for underpowered editors like Nano.

Nano actually can do well over half of the things mentioned…

I love nano! No 40 year old mentality with the keybinds like vim and emacs. No text editor should require a learning curve imo. You can make a .nanorc too and tailor your experience. Some syntax highlighting: https://github.com/scopatz/nanorc

It is incredibly sad that prejudices like "40 years old mentality" stop people from using vim.

It's not outdated or limited, it's extremely convenient and powerful. Yes, there's some learning involved, but after learning a few keystrokes, you become extremely productive with vim.

nano or other editors can't even come close, because vim allows to edit the text with the speed of your though without pressing a lot of keys.

The same could be said for Emacs.

Excerpt:

How is UNIX an IDE?

"The primary rationale for using an IDE is that it gathers all your tools in the same place, and you can use them in concert with roughly the same user interface paradigm, and without having to exert too much effort to make separate applications cooperate. The reason this becomes especially desirable with GUI applications is because it’s very difficult to make windowed applications speak a common language or work well with each other; aside from cutting and pasting text, they don’t share a common interface.

The interesting thing about this problem for shell users is that well-designed and enduring Unix tools already share a common user interface in streams of text and files as persistent objects, otherwise expressed in the axiom “everything’s a file”.

Pretty much everything in Unix is built around these two concepts, and it’s this common user interface, coupled with a forty-year history of high-powered tools whose users and developers have especially prized interoperability, that goes a long way to making Unix as powerful as a full-blown IDE."

I think the desktop can be an IDE.

https://github.com/samsquire/ideas#98-the-desktop-is-an-inte...

I don't muck about with having to use tabs or maybe keycodes to change the current view(s) of a terminal/xterm.

I simply open sufficient xterms on one or more virtual desktops to cover all of my needs.

Ferinstance: I can have the warnings and errors of the last compile displaying in one xterm, I can be editing the relevant xxx.c source file in a second xterm, the associated yyy.h header file being edited in a third xterm, and the man page for a library function showing in yet another fourth xterm.

All of them immediately visible, and all of them interactive.

Unix as IDE 'just works' for me.

IntelliJ Editors just straight up not working on Wayland right now has driven me insane. I really like Sway (i3) and Wayland is a must for mixed DPI setups. Now I have started using Kakoune and LSP for Go and Python and it works great. I tried Neovim for a while but having another window manager inside of Sway is too much of a burden. Kakoune opens new windows in Sway (or tmux). Combined with a plugin to make Firefox open tabs in a new window always I found my dream setup.

> IntelliJ Editors just straight up not working on Wayland right now has driven me insane

Maybe don't use Wayland then. Or, at least, suffer the slings and arrows of outrageous fortune with some grace. You chose to use Wayland, making you a minority (Wayland users) of a minority (Linux users). All power to you to make your own choices, but to paraphrase an old favourite - "Freedom may be mankind’s natural state, but so is sitting in a tree eating your dinner while it is still wriggling."

TL;DR - you choose to use tech not supported by Jetbrains, so please feel free to eat your dinner while it's still wriggling.

If Firefox can pull it off so can Jetbrains. X does not work for mixed dpi and xrandr isn’t a solution. Wayland has been a thing for 15 years. If Apple released a new window system devs would support it why not Linux? Your view is essentially there are starving kids in Africa so you should starve too.

Because there are probably more developers using MacOS and it is officially supported by Apple. Wayland may have been available for 15 years but it isn't defacto (doesn't work with the nvidia driver).

I only started using vim constantly around a year ago because I wanted to get used to it in case I needed it. Now I only use the shell for development and haven't touched an IDE or graphical text editor in months.

This is a treasure trove, there are quite a few tools I wasn't aware of that I shall start using consistently now.

I go further. Unix is my IDE and my CMS for my website.

anyone figure out how to do this with Java though? Seems more feasible for C or Go but not all..

There are language servers for Java now for auto complete in Vim etc.

Rule #1: Use all the Things.

Rule #2: vim is all you need.

Reply on news.ycombinator.com