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

91–100 of 106 posts

Re: Unix as IDE (2012)

#91

Post by taeric »

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

Re: Unix as IDE (2012)

#92

Post by adamskiftw »

anticodon wrote: post #89
asdff wrote: post #43

Earlier quoted context omitted.

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

The same could be said for Emacs.

Re: Unix as IDE (2012)

#93

Post by _jal »

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

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.

Re: Unix as IDE (2012)

#94

Post by EnderMB »

eschneider wrote: post #85
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 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.

Re: Unix as IDE (2012)

#95

Post by lgunsch »

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…

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.

Re: Unix as IDE (2012)

#96

Post by bigmanwalter »

felixhummel wrote: post #76
guessmyname wrote: post #51

Earlier quoted context omitted.

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

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!

Re: Unix as IDE (2012)

#97

Post by oso2k »

svlasov wrote: post #59
asdff wrote: post #53

Earlier quoted context omitted.

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

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.

Re: Unix as IDE (2012)

#98

Post by zokier »

nickjj wrote: post #82
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.

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…

> 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

Re: Unix as IDE (2012)

#100

Post by simonblack »

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.

Post reply on HN