Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix as IDE (2012)

sanctum.geek.nz

Post reply on HN
Print view View original

51–60 of 106 posts

Re: Unix as IDE (2012)

#51

Post by guessmyname »

istjohn wrote: 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.

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)

Re: Unix as IDE (2012)

#52

Post by ohthehugemanate »

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.

Re: Unix as IDE (2012)

#53

Post by asdff »

oso2k wrote: post #47
asdff wrote: post #41

Earlier quoted context omitted.

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

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.

Re: Unix as IDE (2012)

#54

Post by asdff »

zokier wrote: post #46
tombert wrote: 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.

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

Re: Unix as IDE (2012)

#55

Post by bcbrown »

socialdemocrat wrote: post #15

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…

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

Re: Unix as IDE (2012)

#57

Post by DictumMortuum »

ohthehugemanate wrote: post #52

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

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

Re: Unix as IDE (2012)

#58

Post by jclulow »

asdff wrote: post #54
zokier wrote: post #46

Earlier quoted context omitted.

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.

Re: Unix as IDE (2012)

#59

Post by svlasov »

asdff wrote: post #53
oso2k wrote: post #47

Earlier quoted context omitted.

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

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

Re: Unix as IDE (2012)

#60

Post by enriquto »

zokier wrote: post #46
tombert wrote: 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.

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

Post reply on HN