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

81–90 of 106 posts

Re: Unix as IDE (2012)

#81

Post by gwenzek »

asdff wrote: post #42
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.

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.

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

Re: Unix as IDE (2012)

#82

Post by nickjj »

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.

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!

Re: Unix as IDE (2012)

#83

Post by timw4mail »

enriquto wrote: post #60
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 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…

Tmux Resurrect works pretty well:

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

Re: Unix as IDE (2012)

#84

Post by jcelerier »

alkonaut wrote: post #71
samsquire wrote: post #10

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

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

Re: Unix as IDE (2012)

#85

Post by eschneider »

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 honestly just use tmux as a tabbed terminal with saveable state. For someone who works remotely from multiple locations, attach/detatch is life changing.

Re: Unix as IDE (2012)

#86

Post by gameswithgo »

p410n3 wrote: post #79
_jal wrote: post #17

Earlier quoted context omitted.

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…

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

Re: Unix as IDE (2012)

#87

Post by enriquto »

madmax96 wrote: post #74
enriquto wrote: post #69

Earlier quoted context omitted.

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.

Re: Unix as IDE (2012)

#88

Post by alkonaut »

jcelerier wrote: post #84
alkonaut wrote: post #71

Earlier quoted context omitted.

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.

Re: Unix as IDE (2012)

#89

Post by anticodon »

asdff wrote: post #43
saagarjha wrote: post #34

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

Re: Unix as IDE (2012)

#90

Post by p410n3 »

gameswithgo wrote: post #86
p410n3 wrote: post #79

Earlier quoted context omitted.

> 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
Post reply on HN