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
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.
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.
