Live data from Hacker News

Unix as IDE (2012)

sanctum.geek.nz

41–50 of 106 posts

Re: Unix as IDE (2012)

#41
post #8

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

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.

Re: Unix as IDE (2012)

#42
post #32

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.

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.

Re: Unix as IDE (2012)

#43

> 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

Re: Unix as IDE (2012)

#44
post #42
post #32

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.

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.

Re: Unix as IDE (2012)

#45
post #8

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

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

Re: Unix as IDE (2012)

#46
post #8

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

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.

Re: Unix as IDE (2012)

#47
post #41
post #8

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

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

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

Re: Unix as IDE (2012)

#48

Earlier quoted context omitted.

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…

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.

Re: Unix as IDE (2012)

#49
post #8

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

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.

Re: Unix as IDE (2012)

#50

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…

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

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.

Post reply on HN