5 ms·

"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 i

"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-iterm2/?utm_source=rss&utm_medium=rss&utm_campaign=pretty-vim-color-schemes-in-iterm2 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?).

kordless 16y ago
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.
- burgerbrain 16y ago
  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.
  - deno 16y ago
    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!
    - burgerbrain 16y ago
      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.
      - deno 16y ago
        (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.
      - deno 16y ago
        (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.
  - codex 16y ago
    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)?
- swaits 16y ago
  You seem to assume we only use our terminal to interact with a shell.
  - burgerbrain 16y ago
    Of course not, for programs that don't provide at least readline capabilities, I suggest `rlwrap`.
- gnachman 16y ago
  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.
  - burgerbrain 16y ago
    "The use case for this is for those things the shell cannot autocomplete." I think you meant terminal emulator.
patrickod 16y ago
What in particular should one set their TERM variable as to support 256 colors?
- pivo 16y ago
  I use TERM=xterm-256color
  - patrickod 16y ago
    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?
    - gnachman 16y ago
      I updated the FAQ to talk about this. You should set background=dark or background=light in your .vimrc.
- graywh 16y ago
  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.
  - onedognight 16y ago
    > 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.
    - graywh 16y ago
      Maybe you don't have a dtterm terminfo description there. You can get it to your remote system using terminfo and tic.

kordless 16y ago

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.

burgerbrain 16y ago
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.
- deno 16y ago
  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!
  - burgerbrain 16y ago
    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.
    - deno 16y ago
      (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.
    - deno 16y ago
      (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.
- codex 16y ago
  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)?
swaits 16y ago
You seem to assume we only use our terminal to interact with a shell.
- burgerbrain 16y ago
  Of course not, for programs that don't provide at least readline capabilities, I suggest `rlwrap`.
gnachman 16y ago
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.
- burgerbrain 16y ago
  "The use case for this is for those things the shell cannot autocomplete." I think you meant terminal emulator.

patrickod 16y ago

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

pivo 16y ago
I use TERM=xterm-256color
- patrickod 16y ago
  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?
  - gnachman 16y ago
    I updated the FAQ to talk about this. You should set background=dark or background=light in your .vimrc.
graywh 16y ago
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.
- onedognight 16y ago
  > 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.
  - graywh 16y ago
    Maybe you don't have a dtterm terminfo description there. You can get it to your remote system using terminfo and tic.