91–97 of 97 posts
Nice, another application that eats away tons of RAM because it comes with it's own WebKit engine.
Earlier quoted context omitted.
Whoopee, you saved one keystroke (`eom tmp.png` "Yep, looks good. Presses Escape ") and if you become interested in any data from previous commands' output you'll have to scroll up more / live with a larger window than otherwise because now you've got an image sucking up n rows in your terminal.
Look at IPython and DrRacket to see why inline images can be useful in REPLs. With DrRacket you can not only view, but also create and combine images one step at the time, always seeing the latest form of it. And then you naturally end up with a script for doing the transformations needed to get your desired result. In short: the time savings introduced by shortening the feedback loop tend to add up. There is a reaso…
One of these seems to pop up every few months, which is great, terminals are old crusty awful things, but it seems like they always die out in development before they can run existing things like Vim which makes them fun POC's and not much else :/
I would really love it if one of these web-based terminals managed to stick around. Just being able to view images in a terminal would be amazing. The trouble with building on web technologies seems to be that the overhead is just too high (eg. Atom) considering how many terminals the average developer has open at a time. I guess at least since it's based on Electron, it might have more longevity than something built…
Earlier quoted context omitted.
Hey. Not snooty at all. I understand your pain: once I tried to open Vim in this Kickstarter terminal project - Xiki - and was disappointed in the same way. 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…
I think for this to work you just have to create a shell and a terminal, to have a killer app that your terminal is the paltform for (realizing this is what kept me from ever moving on the idea). But my point is that I think the shell component absolutely must communicate with the terminal component over the tty subsystem using an extension of ANSI Escape Codes, defined in a terminfo page, so that the terminal compon…
Screenshot looks awesome! I get this error on mac os Yosemite, I made a github issue here: https://github.com/shockone/black-screen/issues/21 black-screen$ gulp [17:35:09] Using gulpfile ~/black-screen/gulpfile.js [17:35:09] Starting 'default'... [17:35:09] Starting 'watch'... [17:35:09] Starting 'clean'... [17:35:09] Finished 'default' after 359 ms [17:35:09] Finished 'clean' after 58 ms [17:35:09] Starting 'typescr…
Hello. I'm the author of Black Screen, and I'm upset this post has appeared on Hacker News. The terminal is at a very early stage; I don't even use it by myself. Although, it's nice to see that people show some interest.
A new terminal/shell is a very hard sell, as I know from my own experience. Six years ago I wrote my own terminal/shell combination ( http://wiki.tcl.tk/23446 ). It works well enough that I've been using it myself full-time at work ever since, but although a few other people have tried it, no-one else ever adopted it. My own attempt is implemented in Tcl/Tk, an older but much lighter-weight framework (it has no problem with cat-ing a 50MB file).
I combined the functions of shell and terminal because I found the shell/terminal split made some of the functionality I wanted difficult or impossible. One example is that I colour text written to stderr in red - standard shells mix stderr and stdout together before the terminal even sees them.
I decided early on that I would not support terminal escape sequences. I set the TERM environment variable to "dumb" which tells well-behaved programs not to use escape sequences. So you can't run vi/vim in one of my windows, but I always use gvim so I don't find this a problem.
Similarly after some experimentation I decided not to use ptys as they created as many problems as they solved. So programs which change behaviour based on whether they are connected to a terminal behave as if running from a script. Eg. running "man command" lists the whole man page rather than trying to page it - but this is what I want since one can page up/down in the shell anyway.
However it seems that people who use a terminal get very attached to its idiosyncracies and will reject anything even slightly different. Since it's very difficult to make any real improvements without introducing incompatibilies, attempts at improving the terminal/shell user experience rarely catch on. In contrast, a few other tools I have implemented using the same technology have been adopted by a worthwhile user community at work. I think the difference is that they are used for more specialised tasks and don't require the user to change their everyday workflow.
Anyway, good luck with your endeavour!
Nice, another application that eats away tons of RAM because it comes with it's own WebKit engine.
I don't disagree, but as someone who has written a bunch of personal tools (including a Tinder assistant lol) with electron and nwjs, think about why people are using these runtimes before you rip on it. Since so many people are doing it, there must be some good reasons.
EDIT: Just think of the major performance problems these electron based editors had and still have. Our compurters have become faster, so we just write more bloated and slower software?