12 ms·

Unix as IDE (2012)

142 points by lrsjng 7y ago

pvg 7y ago
A few times previously: https://news.ycombinator.com/item?id=12653028 https://news.ycombinator.com/item?id=12653028 https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=3594098 https://news.ycombinator.com/item?id=3594098
RcouF1uZ4gsC 7y ago
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.
- pvg 7y ago
  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.
- glouwbug 7y ago
  Keep your declarations on a single line: int fun(void*); And grep -r fun *.h Will tell you everything you need
  - brachi 7y ago
    also, you could use ctags.
- mstwntd_g 7y ago
  vim has basic completion builtin.. and there's a lot of code complemention plugins..
- quicklime 7y ago
  Now that language servers (https://microsoft.github.io/language-server-protocol/ 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.
  - gravypod 7y ago
    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.
    - flukus 7y ago
      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.
- socialdemocrat 7y ago
  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.
  - RcouF1uZ4gsC 7y ago
    > 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.
  - macinjosh 7y ago
    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.
    - alkonaut 7y ago
      How do you add more watches (printfs) without recompiling/restarting though (That seems like a basic requirement for calling it ergonomic tbh)
samsquire 7y ago
I think the desktop can be an IDE. https://github.com/samsquire/ideas#98-the-desktop-is-an-integrated-development-environment https://github.com/samsquire/ideas#98-the-desktop-is-an-inte...
tombert 7y ago
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).
- dntbnmpls 7y ago
  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.
  - tombert 7y ago
    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.
- _jal 7y ago
  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.
  - p410n3 7y ago
    > I despise autocomplete Could you elaborate on why that is? I feel similiar but I cant just tell why
    - gameswithgo 7y ago
      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.
archarios 7y ago
anyone figure out how to do this with Java though? Seems more feasible for C or Go but not all..
- fourmyle 7y ago
  There are language servers for Java now for auto complete in Vim etc.
samsquire 7y ago
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.
- Aperocky 7y ago
  c) Not much else, the ability to jump to code is the primary benefit.
  - socialdemocrat 7y ago
    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 ;-)
    - Aperocky 7y ago
      More trouble than ctrl-B though
    - istjohn 7y ago
      Which terminal lets you do that?
    - alkonaut 7y ago
      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.
socialdemocrat 7y ago
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.
- deleted 7y ago
  [deleted]
- EdwardDiego 7y ago
  > 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)
  - swiley 7y ago
    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.
fourmyle 7y ago
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.
- EdwardDiego 7y ago
  > 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.
  - deleted 7y ago
    [deleted]
  - fourmyle 7y ago
    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.
    - uk_programmer 7y ago
      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).
superkuh 7y ago
I go further. Unix is my IDE and my CMS for my website.
istjohn 7y ago
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.
- asdff 7y ago
  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.
  - _fullpint 7y ago
    Thank you — I’ve often times had to run things interactively and this would have saved me so much time and stress.
  - gwenzek 7y ago
    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 ^^)
- all2 7y ago
  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.
- guessmyname 7y ago
  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 https://linux.die.net/man/1/watch [2] https://linux.die.net/man/1/inotifywait https://linux.die.net/man/1/inotifywait [3] https://github.com/fsnotify/fsnotify https://github.com/fsnotify/fsnotify (written in Go — golang) [4] https://github.com/emcrisostomo/fswatch https://github.com/emcrisostomo/fswatch (written in C++) [5] https://github.com/watchexec/watchexec https://github.com/watchexec/watchexec (written in Rust)
saagarjha 7y ago
> 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…
- asdff 7y ago
  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 https://github.com/scopatz/nanorc
  - anticodon 7y ago
    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.
    - adamskiftw 7y ago
      The same could be said for Emacs.
ohthehugemanate 7y ago
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.
- DictumMortuum 7y ago
  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
  - mucholove 7y ago
    What is `st`? :)
    - siddboots 7y ago
      Probably meant sublime text?
fit2rule 7y ago
Rule #1: Use all the Things. Rule #2: vim is all you need.
simonblack 7y ago
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.
luord 7y ago
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.
peter_d_sherman 7y ago
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."

Unix as IDE (2012)

142 points by lrsjng 7y ago

pvg 7y ago

A few times previously: https://news.ycombinator.com/item?id=12653028 https://news.ycombinator.com/item?id=12653028 https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=4105768 https://news.ycombinator.com/item?id=3594098 https://news.ycombinator.com/item?id=3594098

RcouF1uZ4gsC 7y ago

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.

pvg 7y ago
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.
glouwbug 7y ago
Keep your declarations on a single line: int fun(void*); And grep -r fun *.h Will tell you everything you need
- brachi 7y ago
  also, you could use ctags.
mstwntd_g 7y ago
vim has basic completion builtin.. and there's a lot of code complemention plugins..
quicklime 7y ago
Now that language servers (https://microsoft.github.io/language-server-protocol/ 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.
- gravypod 7y ago
  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.
  - flukus 7y ago
    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.
socialdemocrat 7y ago
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.
- RcouF1uZ4gsC 7y ago
  > 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.
- macinjosh 7y ago
  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.
  - alkonaut 7y ago
    How do you add more watches (printfs) without recompiling/restarting though (That seems like a basic requirement for calling it ergonomic tbh)

samsquire 7y ago

I think the desktop can be an IDE. https://github.com/samsquire/ideas#98-the-desktop-is-an-integrated-development-environment https://github.com/samsquire/ideas#98-the-desktop-is-an-inte...

tombert 7y ago

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).

dntbnmpls 7y ago
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.
- tombert 7y ago
  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.
_jal 7y ago
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.
- p410n3 7y ago
  > I despise autocomplete Could you elaborate on why that is? I feel similiar but I cant just tell why
  - gameswithgo 7y ago
    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.

archarios 7y ago

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

fourmyle 7y ago
There are language servers for Java now for auto complete in Vim etc.

samsquire 7y ago

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.

Aperocky 7y ago
c) Not much else, the ability to jump to code is the primary benefit.
- socialdemocrat 7y ago
  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 ;-)
  - Aperocky 7y ago
    More trouble than ctrl-B though
  - istjohn 7y ago
    Which terminal lets you do that?
  - alkonaut 7y ago
    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.

socialdemocrat 7y ago

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.

deleted 7y ago
[deleted]
EdwardDiego 7y ago
> 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)
- swiley 7y ago
  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.

fourmyle 7y ago

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.

EdwardDiego 7y ago
> 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.
- deleted 7y ago
  [deleted]
- fourmyle 7y ago
  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.
  - uk_programmer 7y ago
    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).

superkuh 7y ago

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

istjohn 7y ago

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.

asdff 7y ago
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.
- _fullpint 7y ago
  Thank you — I’ve often times had to run things interactively and this would have saved me so much time and stress.
- gwenzek 7y ago
  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 ^^)
all2 7y ago
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.
guessmyname 7y ago
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 https://linux.die.net/man/1/watch [2] https://linux.die.net/man/1/inotifywait https://linux.die.net/man/1/inotifywait [3] https://github.com/fsnotify/fsnotify https://github.com/fsnotify/fsnotify (written in Go — golang) [4] https://github.com/emcrisostomo/fswatch https://github.com/emcrisostomo/fswatch (written in C++) [5] https://github.com/watchexec/watchexec https://github.com/watchexec/watchexec (written in Rust)

saagarjha 7y ago

> 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…

asdff 7y ago
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 https://github.com/scopatz/nanorc
- anticodon 7y ago
  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.
  - adamskiftw 7y ago
    The same could be said for Emacs.

ohthehugemanate 7y ago

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.

DictumMortuum 7y ago
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
- mucholove 7y ago
  What is `st`? :)
  - siddboots 7y ago
    Probably meant sublime text?

fit2rule 7y ago

Rule #1: Use all the Things. Rule #2: vim is all you need.

simonblack 7y ago

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.

luord 7y ago

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.

peter_d_sherman 7y ago

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."