Hacker News new | past | comments | ask | show | jobs | submit login

"An iTerm2 exclusive feature. Type the start of a word and press Cmd-;. A popup window opens at the cursor position with completion suggestions."

Surely that is best left as a shell feature...

EDIT: if the author is reading this, you link to a page which describes the incorrect way of enabling 256 colors in Vim (http://kevin.colyar.net/2011/01/pretty-vim-color-schemes-in-...). It suggests using `:set t_Co=256`, but that is generally considered by the Vim community (#vim on freenode) as the improper way of doing it. The correct way to do it is to just set your TERM env variable correctly (iterm does come with or support terminfo that indicates 256 color support, right?).




What in particular should one set their TERM variable as to support 256 colors?


Depends on which terminal emulator you're using and which terminfo descriptions are available. (Ubuntu users: install the "ncurses-term" package.)

Xterm: xterm-256color, Putty: putty-256color, Gnome Terminal: gnome-256color, Konsole: konsole-256color, Screen/Tmux: screen-256color

And for anyone interested, the best TERM for Terminal.app is dtterm.


> And for anyone interested, the best TERM for Terminal.app is dtterm.

I'm interested because the home and end key don't work for me, but when I use this, I get

  Error opening terminal: dtterm.
when running a curses app after logging into a Fedora 14 box.


Maybe you don't have a dtterm terminfo description there. You can get it to your remote system using terminfo and tic.


I use TERM=xterm-256color


Having changed this 256 colors seem to work in Vim with the exception of the background color. I presume this is something to do with the default "white on black" theme that iTerm2 is using?


I updated the FAQ to talk about this. You should set background=dark or background=light in your .vimrc.


Features which utilize or cross over multiple shell instances probably belong in the terminal emulator. Autocompletion could be considered one of these if you were editing multiple files on different machines.


Any auto-completion that the terminal emulator could possibly provide will absolutely pale in comparison to what a properly configured shell can do.

Just copy over your shell config file if you're really in a poor situation like that often, and it's pretty trivial to make a script that'll automate it.


Surely a decent shell could provide some additional functionality to terminal using e.g. D-Bus (I'm not sure what standard desktop IPC is in OSX).

I'm not convinced auto-completion is one of them though. But hey, if you like GUI popups better it's certainly hackable!


It's certainly something that could be done, but also something that shouldn't be done. You would have to make modifications to every possible shell the user might want to use, and these would only be a feature usable in a very select few terminal emulators. It creates way more work because, in short, it's a violation of the Unix design philosophy.

EDIT: The way you'd do this is to provide additional functionality to the shell, not to the terminal.


(Haven't noticed your reply; my guess is you won't notice mine now... oh well)

> It's certainly something that could be done, but also something that shouldn't be done.

I was just thinking out loud how it could be done, so I don't see any disagreement here.

> You would have to make modifications to every possible shell the user might want to use, and these would only be a feature usable in a very select few terminal emulators.

Well, it'd be optional addition. Furthermore...

> It creates way more work because, in short, it's a violation of the Unix design philosophy.

Already shells attempt to detect if your terminal support color output, scrolling etc.

Your shell would still go around its usual business (e.g. auto-completion), the only thing that changes is how you're going to present that functionality to the user. And if terminal you're outputting to is happy to provide a popup, then why not use it? I don't see how that violates Unix design philosophy.

> EDIT: The way you'd do this is to provide additional functionality to the shell, not to the terminal.

Yes, that seems to be more accurate. The shell would make use of the additional capabilities provided by terminal.


Can the shell complete text which was rendered with terminal specific escape sequences, i.e. color? Can it complete stdout from child processes (i.e. cat)?


The use case for this is for those things the shell cannot autocomplete. For example, you might want to get a directory listing with ls and then operate on one of the filenames that it outputs. You can retype the filename, which is error-prone, copy-paste it with the mouse (which takes your hands off the keyboard), or type the first few letters and autocomplete. Autocomplete is by far the fastest way to do this.


"The use case for this is for those things the shell cannot autocomplete."

I think you meant terminal emulator.


You seem to assume we only use our terminal to interact with a shell.


Of course not, for programs that don't provide at least readline capabilities, I suggest `rlwrap`.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: