TerminalView – A terminal inside Sublime Text 3(github.com)
github.com
TerminalView – A terminal inside Sublime Text 3
https://github.com/Wramberg/TerminalView
69 comments
Hi all, I am the author of Terminus. The biggest reason I started this project is because TerminalView doesn't support continuous scroll history.
I’m using terminus since it was announced over at the sublime forums. It’s definitely the best terminal experience inside sublime. TerminaView was lagging and was hard to style from my experience. Also it had some lagging terminus doesn’t have.
>21MB of gifs on the readme
Why?
Why?
I would imagine because the author wants to show moving pictures of the project.
yes, but a 15 fps gif, where a majority of frames are just duplicates of the previous image? AND 265 colours? (Photoshop crashed my GPU trying to even display the this)
I could cut this shit down to less than 1MB if I tried, retaining the horrible gif format.
There's no excuse for the file sizes to be this dramatic, apart from outright laziness
There's no excuse for the file sizes to be this dramatic, apart from outright laziness
I was using a software to capture the screen as GIF. The original file size for a single file was around 2x mb. I am by no mean an image expert, so I only used ImageOptim and some online services. And they are what I got. I will be glad to know if you know how I could downsize improperly a GIF.
Depending on how the desktop is encoded (sometimes it's a video encoded to a gif), you may get artifacts etc. that make every frame different. But if that's not the case, and the snapshot of each frame is pretty much 1:1 on what's on the desktop, you can use Imagemagick to remove duplicate frames
https://www.imagemagick.org/Usage/anim_opt/#removedups
And right above this paragraph is a dope technique to use overlays and a non-dispose of frames to make the gif only change which pixels are being updated (like a video format I guess).
This might sound pretty complex, and sure, That's fair, we are coming up on 30 years since an update to the format. People just generally use videos these days for desktop recording since they're more suited for the job, at a even lower filesize
https://www.imagemagick.org/Usage/anim_opt/#removedups
And right above this paragraph is a dope technique to use overlays and a non-dispose of frames to make the gif only change which pixels are being updated (like a video format I guess).
This might sound pretty complex, and sure, That's fair, we are coming up on 30 years since an update to the format. People just generally use videos these days for desktop recording since they're more suited for the job, at a even lower filesize
> This might sound pretty complex, and sure, That's fair, we are coming up on 30 years since an update to the format. People just generally use videos these days for desktop recording since they're more suited for the job, at a even lower filesize
Out of curiosity, any idea what formats you'd choose to embed in a Github readme? Videos or otherwise, I'm not sure which play well when embedded, and are GitHub allowed, etc.
Out of curiosity, any idea what formats you'd choose to embed in a Github readme? Videos or otherwise, I'm not sure which play well when embedded, and are GitHub allowed, etc.
A good solution would be termtosvg[1] styled to look like Sublime Text 3.
[1] https://github.com/nbedos/termtosvg
[1] https://github.com/nbedos/termtosvg
Or just an mp4 video. I converted (with ffmpeg) one GIF and it turned from 6MB to 1.5MB without any parameters settings, and still looking perfect.
Not supported in all browsers I thought? I recall a browser couldn’t do SVG animations
Nice one!
I've never understood the appeal of integrated terminals or viewers in text editors, file managers or IDEs. They will never be as good as dedicated terminals/viewers. Is Alt/Cmd-Tab so hard?
I use terminals almost exclusively inside Emacs, and it is strictly better than any terminal emulator on my system. I get really easy navigation on both command and output history, search (including regexes on command output), autocomplete, complex text manipulation (including cutting rectangles etc), integration with the clipboard (I can paste anything from my editor's history into a command). I can create complicated multi step commands in a buffer and send them, individually or one at a time, to the shell to be executed with simple key combinations. I can insert command output into a buffer at my cursor. But more importantly, Emacs is fullscreen and it's what I'm looking at anyway. I don't _want_ to switch away from it. My muscle memory is mostly trained on moving between Emacs buffers, and even with readline bindings, very few window managers and terminal emulators come close to supporting everything I want from a shell buffer.
I also exclusively do SQL in Emacs, and dataframes and plots in R, and tailing log files, and no end of other stuff, and if there's ever anything, no matter how little, that bothers me about interacting with these things, I can write code to make it behave exactly how I want it to.
The only thing I _don't_ do with terminals inside Emacs is SSH into a screen on a server that's already running Emacs, but even then, little jobs are generally easier with tramp, which makes it transparent when you're editing stuff and issuing commands remotely.
I also exclusively do SQL in Emacs, and dataframes and plots in R, and tailing log files, and no end of other stuff, and if there's ever anything, no matter how little, that bothers me about interacting with these things, I can write code to make it behave exactly how I want it to.
The only thing I _don't_ do with terminals inside Emacs is SSH into a screen on a server that's already running Emacs, but even then, little jobs are generally easier with tramp, which makes it transparent when you're editing stuff and issuing commands remotely.
Once I realized terminal emulators are more defined by their limitations then their features, I started running all my shells in emacs. Never looked back.
That does sound like a very cool work flow.
You have probably never experienced the efficiency when you can access terminal contents as plain text. E.g. it is searchable with the same commands as your text buffers, very easy to copy large chunks of output from it, etc.
Editable plain text terminals are wonderful. Especially for running interactive programming sessions (like ghci, or python).
Unfortunately, some programs treat the teminal emulator as a screen with fixed positions to put coloured characters in. And this breaks down when your terminal is a text buffer.
Unfortunately, some programs treat the teminal emulator as a screen with fixed positions to put coloured characters in. And this breaks down when your terminal is a text buffer.
What large chunks do you need to copy? The only thing I really copy often are file paths.
Output from scripts, for example. Not necessarily large. E.g. I run various scripts, and then I need the output of some them later. Then I don't have to rerun the script and redirect to a file, or scroll back trying to find it. I just search for some string in it, and then it is right there and I can copy or even edit the output right in place in the terminal buffer if I don't want something from it and copy that.
It's quite useful and convenient.
It's quite useful and convenient.
Your reply to my question is basically "the output of scripts". I get that. But what _kind_ of scripts?
You're executing a big import job that fails on a few items, so you want to go back and parse out the IDs of those items, transform them into an SQL command and look up the data in the database to poke about at what's wrong. This is trivially few operations in Emacs when you're running your shell and SQL client side-by-side and have brilliant regex and text manipulation tools in the middle. Sure, you could do this just on the command line if you'd logged to a file and could do the sed or awk bit in the middle to pipe a command to psql etc, but why bother? Doing it inside your editor is so much more forgiving.
Surely the OP could be referring to any number of kinds of scripts. What does it matter what kinds of scripts? Bash scripts? Logs files? The output of scripts is surely enough.
KDE had the solution to this, long time ago: KParts allows you to embed the dedicated terminal (Konsole) into any other KDE program.
That said, I agred that alt-tabbing isn’t hard, and a tiling window manager makes it even easier (less window administration).
That said, I agred that alt-tabbing isn’t hard, and a tiling window manager makes it even easier (less window administration).
I must admit I don't use KDE these days, for no really good reason, but back in the day I used to love booting up Konqueror, opening my company's web-based timesheet system in one tab, a KSpread spreadsheet in another, a KWord doc in yet another. And then being able to edit remote files transparenly in Kate etc. It was a very nice integrated system, basically everything you'd hope for in a well architected piece of C++ software.
That makes a lot of sense I think. You get a terminal, but don't have to reinvent the wheel.
> Is Alt/Cmd-Tab so hard?
Its annoying with a bunch of programs open. I prefer to have a keybind to get the terminal with dropdown, akin to Guake [1]. This is possible with iTerm2 as well. Also, Expose-like or tiling window feature of a desktop comes in handy. For that, I can recommend Amethyst.
[1] http://guake-project.org/
Its annoying with a bunch of programs open. I prefer to have a keybind to get the terminal with dropdown, akin to Guake [1]. This is possible with iTerm2 as well. Also, Expose-like or tiling window feature of a desktop comes in handy. For that, I can recommend Amethyst.
[1] http://guake-project.org/
I run a dev server trough grunt for a project, now I can open that terminal window in the same project I'm working on and close it when I'm done with the project.
It will never replace my "main terminal" but makes my life a little bit easier.
It will never replace my "main terminal" but makes my life a little bit easier.
"it supports [...] Basically everything you would expect from a terminal" against "8 color support for now" is an interesting juxtaposition.
This is documented here to be copying the Linux kernel's built-in terminal emulator and so compatible with the "linux" terminfo record. The Linux kernel's built-in terminal emulator, however, supports the 16 CGA colours, and nowadays also recognizes the SGR sequences for both ISO 8613-6 Indexed and Direct colour.
The underlying terminal emulator is, in its own documentation, moreover, documented as emulating a VT100, which is a rather different beast to the Linux kernel's built-in terminal emulator in several ways. But this is the usual mis-use of that designation, that Thomas Dickey points out, because VT100s had no notion of multiple colours at all.
So it's not supporting everything that I would expect, and it's not equivalent to either of the terminal types that its doco says that it is.
I haven't found what it does for DECFNK and whether it even generates it, let alone supports modifiers. That's another very common expectation nowadays.
This is documented here to be copying the Linux kernel's built-in terminal emulator and so compatible with the "linux" terminfo record. The Linux kernel's built-in terminal emulator, however, supports the 16 CGA colours, and nowadays also recognizes the SGR sequences for both ISO 8613-6 Indexed and Direct colour.
The underlying terminal emulator is, in its own documentation, moreover, documented as emulating a VT100, which is a rather different beast to the Linux kernel's built-in terminal emulator in several ways. But this is the usual mis-use of that designation, that Thomas Dickey points out, because VT100s had no notion of multiple colours at all.
So it's not supporting everything that I would expect, and it's not equivalent to either of the terminal types that its doco says that it is.
I haven't found what it does for DECFNK and whether it even generates it, let alone supports modifiers. That's another very common expectation nowadays.
Source seems to be freely available so they would probably welcome pull requests
This feature has been missing since the beginning! The lack of a proper terminal is actually what made me switch to a tiling window manager.
Even though I use something else, this is cool for reducing context switching.
I used to need to hop between many tools and windows and I found that, similar to the doorway effect, this switching had the chance to distract me from what I was doing. That split second of switching contexts was enough to let my mind drop the balls it was juggling and think about something else.
So in my chosen tool I now have the terminal, editor, debugger and database as tabs or tool panes. It has helped my concentration immensely as I am not switching contexts to a new window and my focus remains on the task.
I go to great lengths to stuff tools into the platform I use in order to reduce switching, even down to making tool buttons for things like enabling ssh tunnels needed for remote debugging, compiling assets from a button and so on. For everything I can't stuff into a button, shortcut or tool pane, there is the terminal pane. Learning my tool thoroughly has been a real boon for my working efficacy.
I used to need to hop between many tools and windows and I found that, similar to the doorway effect, this switching had the chance to distract me from what I was doing. That split second of switching contexts was enough to let my mind drop the balls it was juggling and think about something else.
So in my chosen tool I now have the terminal, editor, debugger and database as tabs or tool panes. It has helped my concentration immensely as I am not switching contexts to a new window and my focus remains on the task.
I go to great lengths to stuff tools into the platform I use in order to reduce switching, even down to making tool buttons for things like enabling ssh tunnels needed for remote debugging, compiling assets from a button and so on. For everything I can't stuff into a button, shortcut or tool pane, there is the terminal pane. Learning my tool thoroughly has been a real boon for my working efficacy.
Open ST3.
Launch a terminal.
Start Emacs.
M-x term
Run vim.
Launch a terminal.
Start Emacs.
M-x term
Run vim.
I'm (sadly) moving from Emacs to Visual Studio Code. But I won't give up magit[1], because it is awesome, and neither the VS Code git integration nor the git command line tool come close to it. Hence, I've stripped my emacs config down so that it essentially does nothing but run (magit-status) on startup. When I need to do git operations in VS Code, I open the integrated terminal and run emacs.
[1]: https://github.com/magit/magit
[1]: https://github.com/magit/magit
Emacs is still useful for me even if I'm doing coding in some IDE. Magit is one thing, also Org mode for notes and tasks, etc.
Have you tried GitLens for VS Code? It’s what keeps drawing me back to VSC.
The question really is have you tried magit?
Run :terminal.
Run ed.
Run ed.
I made an animated gif in the spirit of your joke a while ago: https://atom.io/packages/script-runner
"The best of both worlds"
That got me.
That got me.
Is there a reason to favour an embedded terminal with a fixed viewport + an N-line scroll-back, over one that just uses a text-editing buffer as the moral equivalent of a serial-terminal (where line-editing escape sequences edit the ST buffer) or even as an append-only log (i.e. regular TTY output is output; but escape sequences are ignored)?
This would give you the ability to use any REPL as (something close to) a Jupyter-style notebook. Sure, curses apps wouldn’t work very well... but why are you running curses apps inside an IDE?
This would give you the ability to use any REPL as (something close to) a Jupyter-style notebook. Sure, curses apps wouldn’t work very well... but why are you running curses apps inside an IDE?
Program like iPython doesn't work in serial-terminal. The simpliest reason is that it needs the ability to go back to the previous line to allow multi line editing.
Input in a text-buffer-backed system usually involves a "baked" line discipline where the text editor isn't submitting individual characters to the process as you type them, but rather holds onto your input as regular text, allowing you to edit it as you please, until you do something to "commit" it as input to the program—at which point it becomes available all at once on that program's stdin.
In some editors with shell support, this just happens when you type a newline; but in others, even newlines are treated as ordinary text, and you have to press Ctrl+Enter or somesuch to submit the (multi-line!) command.
In Plan9's Acme editor, for an interesting example, there is no shell mode as such; rather, in any buffer, you can make a text selection, and then middle-click that text selection, and it will feed that input to the stdin of whatever forked interpreter process is configured for the buffer (usually determined by the buffer's filetype); and then the output from the stdout of the program will be inserted in the same buffer, just below your text-selection; or, if you middle-click while holding shift (I think?), it'll replace your selection.
In other words: you don't rely on a REPL for multi line editing, because that's what text-editors are for! :) Your REPL can see your editor as a dumb serial terminal—most REPLs gracefully degrade in such situations.
In some editors with shell support, this just happens when you type a newline; but in others, even newlines are treated as ordinary text, and you have to press Ctrl+Enter or somesuch to submit the (multi-line!) command.
In Plan9's Acme editor, for an interesting example, there is no shell mode as such; rather, in any buffer, you can make a text selection, and then middle-click that text selection, and it will feed that input to the stdin of whatever forked interpreter process is configured for the buffer (usually determined by the buffer's filetype); and then the output from the stdout of the program will be inserted in the same buffer, just below your text-selection; or, if you middle-click while holding shift (I think?), it'll replace your selection.
In other words: you don't rely on a REPL for multi line editing, because that's what text-editors are for! :) Your REPL can see your editor as a dumb serial terminal—most REPLs gracefully degrade in such situations.
Yeah, this is exactly how the emacs `shell` mode works, and it's fucking awesome + completely addictive.
The only bad thing about it is emacs is so shit-ass slow at rendering text that I have to drop back to a normal shell for commands that spew a bunch of shit (like maven, ugh).
It's one of the can't-live-without-it things that's keeping me on emacs.
(Also how dumb is it that a text editor is slow at rendering text? Emacs is amazingly flexible, but the implementation is just junk. I dream of an editor w/ the speed & implementation quality of Sublime, with the flexability of emacs, that'll still run in a terminal. And a pony. I want that too.)
The only bad thing about it is emacs is so shit-ass slow at rendering text that I have to drop back to a normal shell for commands that spew a bunch of shit (like maven, ugh).
It's one of the can't-live-without-it things that's keeping me on emacs.
(Also how dumb is it that a text editor is slow at rendering text? Emacs is amazingly flexible, but the implementation is just junk. I dream of an editor w/ the speed & implementation quality of Sublime, with the flexability of emacs, that'll still run in a terminal. And a pony. I want that too.)
* dream of an editor w/ the speed & implementation quality of Sublime, with the flexability of emacs, that'll still run in a terminal. And a pony. I want that too.)*
And configurable in language that can also be used outside the editor (unlike vimscript, elisp), it could be js, python, scheme, lua, I don't care ;)
JS or Python being the most appropriates IMO.
And configurable in language that can also be used outside the editor (unlike vimscript, elisp), it could be js, python, scheme, lua, I don't care ;)
JS or Python being the most appropriates IMO.
Not sure what you mean about elisp here. Provided you aren't doing anything super specific to emacs, most lisps can actually move around quite easily.
Though, I have a somewhat irrational dislike of python. JS I accept, but most of the ecosystem has caused me to greatly question our profession. :)
Though, I have a somewhat irrational dislike of python. JS I accept, but most of the ecosystem has caused me to greatly question our profession. :)
Try micro: https://github.com/zyedidia/micro
Plugins are written in Lua.
Plugins are written in Lua.
Do you know Kakoune?
I've used a month and like it. Fast, lean, work with other unix tools well, extend by sh,
Never heard of it. Initial thoughts: Very vi-inspired. Snappy on small files at least. Terminal only? Is it easy to extend? Anything comparable to emacs "shell" mode?
Appreciate the tip, though!
Appreciate the tip, though!
> Terminal only?
Yes, but there's a GTK proof of concept: https://gitlab.com/Screwtapello/kakoune-gtk
> Anything comparable to emacs "shell" mode?
No, it's design goal is to be just an editor, things like shell mode are left to something like tmux or a tiling window manager.
> Is it easy to extend?
Yes, but not in the same way as emacs or vim, it's very much built around the unix as an IDE philosophy so it makes interacting with external tools easy through shell scripts.
Yes, but there's a GTK proof of concept: https://gitlab.com/Screwtapello/kakoune-gtk
> Anything comparable to emacs "shell" mode?
No, it's design goal is to be just an editor, things like shell mode are left to something like tmux or a tiling window manager.
> Is it easy to extend?
Yes, but not in the same way as emacs or vim, it's very much built around the unix as an IDE philosophy so it makes interacting with external tools easy through shell scripts.
As a sibling post points out, you are basically discovering what many people come to love about emacs. I've even taken to loving eshell because of its transparent integration with remote filesystems using TRAMP. Add in the ability to redirect output of a command to a new buffer that you can then treat like any other text file, and things can be a ton of fun.
Once you get even slightly addicted to this, take a peek at org-mode and find an environment that can already compete with jupyter in pretty much every way. All without a giant json blob backing it, so that reviewing your changes can stick within your current version control world.
Once you get even slightly addicted to this, take a peek at org-mode and find an environment that can already compete with jupyter in pretty much every way. All without a giant json blob backing it, so that reviewing your changes can stick within your current version control world.
I use iTerm2 as a terminal, and it comes with a handy option to use [option] + [space] as a command to switch between the terminal and the current application. So basically, a terminal is almost as accessible as the space bar, and I've never seen anything that even looks half as easy or convenient.
This is one of my favourite things about VSCode, awesome!
Very nice feature - now its even easier for me to break into vim and do something I can't figure out how to do in ST3. ;)
One thing though - whats up with key repeat? It doesn't seem to be working at all .. (macOS, ST3 Build 3176) .. this kind of makes the whole thing unusable for me, personally.
Also its not processing any of my ~/.bash* scripts .. I guess this is by design since its not guaranteed to be a full-featured Term yet?
One thing though - whats up with key repeat? It doesn't seem to be working at all .. (macOS, ST3 Build 3176) .. this kind of makes the whole thing unusable for me, personally.
Also its not processing any of my ~/.bash* scripts .. I guess this is by design since its not guaranteed to be a full-featured Term yet?
MPW - Macintosh [Classic] Programmer's Workshop - had a combined text editor/shell. That inspired Eddie (http://www.el34.com) for BeOS which was later ported to OS X.
I just use i3.
The repository root has a file named LICENSE containing the MIT license. But the file GateOne/terminal.py says __license__ = "AGPLv3 or Proprietary (see LICENSE.txt)"
and doesn't include LICENSE.txt. I wonder what went wrong?
On Linux Mint, I had to use `{ "keys": ["ctrl+alt+o"], "command": "terminal_view_open" }` in Preferences > Key Bindings because "ctrl_alt+t" was opening up my system Terminal.
A solution to having the unnecessary terminal inside an editor is to have some type of tiling window manager.
This can be Awesome, i3, bspwm, or anything out there.
You can also try using tmux or even gnu screen.
This can be Awesome, i3, bspwm, or anything out there.
You can also try using tmux or even gnu screen.
Started off using ST3 when I began developing but switched to VSCode because of its integrated terminal. Looking forward to checking this out
One of those things I've always wanted to have in ST but somehow never took the time to look up. This is really nice, thanks OP!
Can this replace the build results panel? Support for color and other terminal escape sequences would be a godsend there.
so it is becoming emacs?
$ size /usr/local/plan9/bin/acme
text data bss dec hex filename
356886 14680 52332 423898 0x677da /usr/local/plan9/bin/acme
Unlike TerminalView it also supports Windows and its various shells (cmd.exe, powershell.exe, wsl.exe).