Just like the web itself, any new teminal client needs to be backwards compatible with the capabilities of prior terminal clients, because programs that run in the terminal expect it. And if your terminal can't run the programs everyone runs in their terminals, no one will adopt your terminal. But many of these projects seem to have no intention of maintaining that backward compatibility. Some, like TermKit, fully conflate the terminal and the shell and even many UNIX utilities.
You can't hope to supplant ANSI compatible terminals when you let them have the enormous advantage of running all the software anyone wants to run in a terminal that already exists. It would be like saying you have a new, better web browser that can't open any existing web pages.
No idea if this particular project has learned from past examples and is backwards compatible or not. (EDIT: It doesn't have a terminfo page, so probably not.)
The problem with terminfo is that not every tool relies on it. I've seen many examples (hello, exa), when the codes are hard-coded to operate with xterm-256. So, I decided to pretend to be an xterm.
The problem I see is that you seem to have the terminal doing things like fuzzy matching input against PATH executables. But that's the shell's domain. The terminal should just expose commands for adding text items to a drop down under the cursor, and the shell should send the matches to the terminal. And capabilities like this should be clearly defined in a terminfo page (which you should definitely have, even if for non-custom capabilities it uses the same definitions as xterm), so that well-written apps can send this information if and only if those capabilities are defined.
Of course this is a huge challenge, because if you do it this way your terminal doesn't do anything new until someone writes a program to run in it using its extended capabilities. So this creates a chicken and egg problem. But you can't come up with nearly as many interesting things for your terminal to do with cursor dropdowns as everyone in the world can if you're just exposing that in the same way the character grid is exposed.
Perhaps unexpectedly, Black Screen is both a terminal emulator and a shell. I tried hard to avoid going with writing a shell, but the existing ones simply don't fit. It's even hard to know when a child execution has finished. And I want smart autocompletion, so I have to at least extend a shell.
Traditionally these two are separated, and it must be a good design, but my current goal is to prove the concept. Perhaps, later I'll extract the shell.
As they say above, this thing would halt when you cat a 50MB file.
It takes someone who's familiar with terminals, and can use a language fit for the task (and without too many depenedencies -- so if you built it in Haskell and I need the Platform and half of Cabal to build it, it will never fly -- and it being in Haskell it will not attrack many UNIX hands, who are the people familiar with Terminals most).
So something like C, C++, Rust or Go.
`cat 50mbfile` will not halt a web based terminal if you don't keep it all in the scrollback buffer.
I guess at least since it's based on Electron, it might have more longevity than something built from a cobbled together base. Here's hoping!
Several hundred MB RAM usage for a single Terminal window are just not acceptable.
Somehow many devs today write their software under the assumption that a user with 2GB RAM or 4GB RAM will at all times only run one single piece of software.
Like I know ranger has an option for it, but iirc there's also a way to just run a command ala `cat`ing a text file. If you'd like, I can look into it more if you can't already find out how to do it by searching.
Also, people are mentioning feh, I'd like to plug in sxiv (not my program though).
However, I'm sad to say that when I tried this again rn, it didn't work anymore. (I know for a fact it used to work great because I used to use it.)
The funny thing is, ranger's image preview still works for me (same terminal and everything), so I guess one could start going through the ranger source code to see how they wrap w3mimagedisplay if they really wanted to.
I don't really have the motivation for that though because, although I'm a heavy terminal user (and it would be nice), recently switching to emacs means a lot of my file management can be done with dired (an emacs package). And dired can do image previews quite nicely already [3] (I'm assuming provided you're using GUI emacs^). ^^
^Emacs can fire up terminals inside it anyway, so using GUI emacs is not a problem for me, even though I'm heavily terminal orientated.
^^Although I think I prefer sxiv's thumbnail mode for browsing directories full of images (as opposed to a few here and there).
[1]: http://blog.z3bra.org/2014/01/images-in-terminal.html
And yes, iTerm2 also displays animated gifs.
What are the advantages of that over using a dedicated image viewer program?
Even giving the ability to set a specific pixel to a specific rgb value would get far. Yes, some programs would get it wrong or would be annoying to use. But think what it would enable. Even at 3 fps, you could still show the user a performance graph of your program, or a flame chart. In the terminal. No extra windows required, no fiddling with GUI frameworks, just "set some pixels to some values."
In the short term, being able to set text to a specific foreground and background rgb would be nice. I'm talking 24-bit color. It turns out that this is not possible across all Unix variants: OS X default Terminal doesn't support 24-bit color for text. And there's no reason why it should be like that. The standards are in place, and they are a straightfoward extension to exiting behavior. The toolmakers just haven't enabled the other makers to use it. Of course, it's because it makes no sense for Apple to waste engineering cycles on that. But that doesn't change that it would be true that if they gave us better tools, we would do more.
The issue is that it has to be a minimum spec that's supported by all platforms. (All Unix platforms would be fine.) Simply writing a program that supports a nonstandard way of setting pixels to values wouldn't cut it. At least at first. That's probably how it has to start, though, in order for others to follow.
Combine it with dwm :)
"Yep that looks like it's right"
git add tmp.png
In short: the time savings introduced by shortening the feedback loop tend to add up. There is a reason why Web developers now use auto-reloading solutions, despite the fact that it saves "just one keystroke" (F5 in this case).
http://superuser.com/questions/246825/open-file-from-the-com...
(I suppose a similar thing could be done on *nix with a suitably modified execlp()/execvp().)
On Linux you should be able to wire up binfmt_misc, the plugin system for execve, to xdg-open.
Then you could just call that external difftool when comparing images:
git difftool --tool img-diff
Do you --or anyone reading this-- have a list of these? I would love to check them all out actually (not that I don't get your point).
Not really, they're just poorly documented. They're based on ad-hoc standards that are scattered across many outdated documents.
It'd be nice if somebody could actually pull all that together and publish one comprehensible document that is readable and up-to-date.