Live data from Hacker News

Putting the I back in IDE

blog.janestreet.com

31–40 of 152 posts

Re: Putting the I back in IDE

#31
post #18
post #12

Earlier quoted context omitted.

There's nothing about terminal-like windows that precludes using the mouse. The magic of escape sequences makes e.g. mouse selection in Vim possible. I just don't find it very useful when there are keyboard shortcuts for everything. When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with…

> When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? Really depends on the workflow. If I know where I'm navigating then I prefer cd, if I don't then a gui is better than a cd/ls loop. Fortunately programs like ranger cover the latter quite well too.

Another way to navigate with cd is to use tab completion instead of ls. "cd "+tab and you get a listing of files. You might have your shell configured to cycle among the options with tab or select with arrow keys. If you've selected a directory, press "/"+tab and repeat. If you want to go back up a level, quickly hit ctrl+w to delete the last piece of the path (that's the behavior of vi keybindings, emacs keybindings delete the whole path). You might in the end have found the file you want to work with and forego cd by using key shortcuts to quickly navigate to the beginning of the command line and switch the command.

This is how I do all my file navigation.

Re: Putting the I back in IDE

#32
post #12

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

There's nothing about terminal-like windows that precludes using the mouse. The magic of escape sequences makes e.g. mouse selection in Vim possible. I just don't find it very useful when there are keyboard shortcuts for everything. When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with…

I don't use GUI file explorers that much, but I have to point out even Windows Explorer has path autocompletion.

Just like using CLIs does not preclude using a mouse, using GUIs does not preclude using keyboard shortcuts ;)

Quick Explorer example (sometimes I mix and match, maybe I want to show something to a colleague):

explorer . # does what you'd expect; alternatively Win-e

Alt-d # focus path in Explorer

Start typing, Explorer autocompletes stuff

Enter

Tab around, if need be, to change panels

And this is with what is, basically, the dumbest common GUI file manager out there :)

Re: Putting the I back in IDE

#33
post #25

Earlier quoted context omitted.

Those features are available in emacs, and work in both the GUI and the terminal. For auto-complete, vanilla emacs has dynamic abbreviations; there are several packages for fancier auto-completion; company-mode, for example, works just fine in the terminal, as well of course as in the GUI (X11, macOS or Windows). Likewise with tooltips, which in the terminal generally are generally displayed in a special region of th…

> give emacs a shot. Both Prelude & spacemacs are excellent configs for it. Are there any advantages over Visual Studio + Visual Assist, for C++ or C# languages? Because I see many disadvantages. About text editor features, your workarounds have flaws compared to good GUI. For tooltips, that special region of the terminal is physically separate from the cursor. For folding, a separate, visually distinct indicators of…

Terminals do have rich text, I have to point that out. Not conhost, the default one on Windows (though I think the latest Windows update might have it).

So you can have underline, bold, italic, squiggles, I think even strikethrough. Also you can have tooltip "windows" but since they're harder to create and manage few applications use them. Those that do are generally based on ncurses, a library for TUI (think Norton Commander or Turbo Pascal)

Vim even has a spell checker built in.

What the terminal does not have is usually consistent support because terminal emulators are really shady, there's no actual standard (most just do what xterm does). For the TUI thing, there's also no real conventions plus I'm pretty sure both Vim and Emacs don't use ncurses and roll their own (see: lack of consistency).

You also need to cobble things together out of packages with varying degrees of quality and documentation, from long forgotten wikis and 90's pages belongings to ex post-docs.

Re: Putting the I back in IDE

#34
post #31
post #18

Earlier quoted context omitted.

> When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? Really depends on the workflow. If I know where I'm navigating then I prefer cd, if I don't then a gui is better than a cd/ls loop. Fortunately programs like ranger cover the latter quite well too.

Another way to navigate with cd is to use tab completion instead of ls. "cd "+tab and you get a listing of files. You might have your shell configured to cycle among the options with tab or select with arrow keys. If you've selected a directory, press "/"+tab and repeat. If you want to go back up a level, quickly hit ctrl+w to delete the last piece of the path (that's the behavior of vi keybindings, emacs keybindings…

This is great locally or at home, a lot of the time when I'm "browsing" it's on remote windows shares on another continent though, the latency from windows and the network is simply to high for tab completion to be usable, it makes using FTP over dialup seem snappy.

This is through cygwin, real linux is another story. I don't know what the difference is between how windows and linux mount remote drives, but the performance difference is stark, ls on a mounted network drive in linux is essentially instant but there is a noticeable lag doing the same from a windows machine.

Re: Putting the I back in IDE

#35
post #11

It sounds really cool but also very opinionated workflow. Not to say I don't agree with it but I can only imagine the amount of effort making this whole workflow was also what went into defining what that workflow was. There are a lot of workflows and I personally don't think it's on an IDE to enforce that. Yeah sure it's "integrated" but it's to the extreme which I somewhat disagree with. If their workflow and emacs…

It's probably OK at a company, though. Teams that I've worked on tend to converge on pretty similar workflows with respect to pull requests.

Re: Putting the I back in IDE

#36
come on! just another couple of years and we can have eclipse again (I still miss the integration between the tasks, the revision system, the code and the autodeploy stuff I had in the '90 when I was a junior dev...)

Re: Putting the I back in IDE

#37
post #13

Earlier quoted context omitted.

There are vim plugins for auto-completion and it supports code folding out of the box. I'm not sure what you use tooltips and context menus for, but that functionality is probably available via some : command. But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.

> I'm not sure what you use tooltips They show documentation (pulled from comments) for functions, classes and arguments. > and context menus For context-sensitive commands I use once per week or less often, so I don’t bother memorizing keyboard shortcuts for them. > most command-line editors are actually GUIs in the terminal Most developers don’t use command line editors. Here’s recent data from this year: https://i…

Those stats are also probably skewed in favor of people actually bothering to fill their survey. Those are more likely to be active/proactive, which in my experience is correlated with tinkering with tools (ergo, using Vim or Emacs).

Re: Putting the I back in IDE

#38
If you walked into an office and saw them using 1984 equipment — fax machines, landlines and Rolodexes — you'd think the company is hopelessly behind times.

Jane Street is a cutting-edge technology corporation, but their internal tools use 80*25 text-mode UIs just like the ones you'd find on a 1984 IBM PC/AT.

It's not the company's fault: we developers are stuck in the tar pit of an unfortunate local maximum with all these tools built around text streams printed into a window that emulates a late '70s terminal.

Re: Putting the I back in IDE

#39
post #25

Earlier quoted context omitted.

Those features are available in emacs, and work in both the GUI and the terminal. For auto-complete, vanilla emacs has dynamic abbreviations; there are several packages for fancier auto-completion; company-mode, for example, works just fine in the terminal, as well of course as in the GUI (X11, macOS or Windows). Likewise with tooltips, which in the terminal generally are generally displayed in a special region of th…

> give emacs a shot. Both Prelude & spacemacs are excellent configs for it. Are there any advantages over Visual Studio + Visual Assist, for C++ or C# languages? Because I see many disadvantages. About text editor features, your workarounds have flaws compared to good GUI. For tooltips, that special region of the terminal is physically separate from the cursor. For folding, a separate, visually distinct indicators of…

Another text editor feature hard to do in text mode is spell checking for strings and comments. Color is already used for syntax highlighting, so wavy red underlines come handy.

No wavy red lines, but there's still two different types of coloring (letters vs cell background): https://i1.wp.com/www.tjansson.dk/wp-content/vim-spell-error...

Re: Putting the I back in IDE

#40
post #13

Earlier quoted context omitted.

There are vim plugins for auto-completion and it supports code folding out of the box. I'm not sure what you use tooltips and context menus for, but that functionality is probably available via some : command. But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.

> I'm not sure what you use tooltips They show documentation (pulled from comments) for functions, classes and arguments. > and context menus For context-sensitive commands I use once per week or less often, so I don’t bother memorizing keyboard shortcuts for them. > most command-line editors are actually GUIs in the terminal Most developers don’t use command line editors. Here’s recent data from this year: https://i…

[deleted]
Post reply on HN