4 ms·

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

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.

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.