aumerle

Oh I dont hide the fact that I love kitty. I have good reason to do so, it has almost single handedly fixed so many problems that haveplagues the terminal space for decades. And done so in a robust, thoughtful and well designed manner. If you dont like kitty that's fine. But PLEASE do not advocate broken, badly designed disasters like SIXEL and modifyOtherKeys. they will just doom this ecosystem for decades more.

Yes and PNG is an actual file format widely used and available. SIX isnt. And sure if you want to invent mythical SIX file formats, I can just as well invent mythical KITTY_IMAGE file formats that you can just cat into a terminal, without needing even base64 or bash. The point is, as it stands, the kitty image protocol is FAR easier to USE to display images than sixels. Trying to claim otherwise is just ridiculous. Indeed, if you want to talk of ease of use, the iterm2 protocol is even easier, since iterm supports more image formats without requiring conversion to RGB.

Good that you are out, hopefully you are out of trying to shill sixels as well.

Man what an agenda.

1) sixel has no querying. So if you want to compare apples to apples, you leave out the querying from the kitty protocol as well.

2) The code I linked to above uses only the standard library which I emphasized. You are using some random sizel specific library to add support for sixel to your perl script.

So no, you dont meet the challenge. I can output images with the kitty protocol using pure BASH + base64, available everywhere.

Oh and incidentally the saitoha sixel library is both unmaintained and full of security issues, so save yourself some headaches and dump it. Trying to claim the kitty protocol is harder to use than sixel is beyond disingenuous.

Yes it can as long as you avoid sixel and xterm. https://sw.kovidgoyal.net/kitty/graphics-protocol/

What nonsense, it takes literally 15 lines of code without using anything beyonf the standard library to write a client for the kitty graphics protocol. I challenge you to match that for sixel. https://sw.kovidgoyal.net/kitty/graphics-protocol/#a-minimal...

So now everyone on the planet has to suffer from slow response to esc keys because xterm is too lazy to fix it properly. And its not a "few milliseconds". Terminal bytes can come over networks with arbitrary delays, so you either get inaccurate key presses causing potential data corruption/loss or insufferably long delays. It is this kind of lazy thinking that has bedeviled this poor ecosystem.

Yes programs need to know about an extended set of key combinations, because lots of programs just spill escape codes they dont understand to the screen. So you cannot produce such codes arbitrarily, only when a program indicates it wants them. And as is usual with xterm, it didnt bother to think this through. It has a facility for requesting these extended keys, but that facility may or may not work. And there is no way to detect if it has short of waiting for those keys. So if a program wants to say, present a different interface in terminals that support extended keys, it cant do so, because it has no way to know if the terminal does support it.

I dont need a keyboard that supports physical keys. I can repurpose unused physical keys as modifiers.

Its nice you dont care about num lock and caps lock. Its not so nice that you are foisting your lack of care on the rest of us.

Let me paraphrase what you said about keyboard layouts. "Something was not done previously and therefore it should never be done". Support for layouts means pressing ctrl+letter can work even on a cyrillic keyboard, but of course, terminals have never done that, and everyone speaks english anyway. So no one cares.

You suppose its useful for games? Try making a game that uses keys for real time control without release events. Autorepeat my ass. But ofcourse, no one cares. Are you in the habit of assuming that because you dont care about something, everyone else also must not care about it.

xterm absolutely shouldn't. it would make a pigs breakfast of it. I am very happy it didn't. What you should do is stop advocating for a broken, half assed hack.

You seem to be overlooking the fact the modifyOtherKeys is 1) not well designed. 2) And does not solve the problem comprehensively.

1a) try to figure out what the escape code for the play/pause key is 1b) it still suffers from the issue that esc keypresses cannot be distinguished from other escape codes 1c) The keyboard protocol can be turned on/off by user config, so there is no robust way for software running in the terminal to know if it is available or not. 1d) it does not support any modifiers beyond the basic 4 1e) It has no support for lock keys num lock/caps lock 1f) It has no support for alternate keyboard layouts 1g) it has no support for shifted keys 2) How does one represent release events in modifyOtherKeys?

xterm has a long and convoluted history of coming up with poorly designed hacks that the entire ecosystem has to carry around forever afterwards. Not wanting to support these mis-faetures is an entirely reasonable position.

modifyOtherKeys should not be used. https://sw.kovidgoyal.net/kitty/keyboard-protocol/ is far more comprehensive.

You have been able to draw plots from proper graphing libraries using actual images for years in terminals that support the kitty graphics protocol. See

GNUPlot: https://sw.kovidgoyal.net/kitty/integrations/#tool-gnuplot matplotlib: https://github.com/jktr/matplotlib-backend-kitty Julia: https://github.com/simonschoelly/KittyTerminalImages.jl

The kitty graphics protocol is supported in three major terminals these days: kitty, WezTerm, konsole.

This has existed for years for kitty: https://sw.kovidgoyal.net/kitty/integrations/#tool-gnuplot

Configure kitty to do that if that's what you like: https://sw.kovidgoyal.net/kitty/conf/#shortcut-kitty.Copy-to...

And ctrl-backspace can similarly be conf though in your shell not the terminal.

You mean like

vhs terminal

does not seem very specific to me.

And you can do that when "now" is encoded as unix time as well, provided you know what local is. Although, encoding "now" is by definition pointless, since "now" changes with every instant.

That's true regardless of how you choose to encode time and is a problem of local time zones not unix time.

Yes, I know. I remember several years ago being super excited about Wayland. But every time I have tried it, it just falls over in so many different ways. I have given up.

About copy/paste in particular, I have solved it for myself because I work almost exclusively in the terminal and the browser, both of which stay running all the time and therefore acts as a clipboard manager for any copy/paste that happens in it. I am just waiting for my terminal of choice to get support for copy/pasting arbitrary mime types, which its maintainer has said he is going to implement.

That's generally true of most things in Wayland. It's poorly designed and then badly implemented, by multiple different compositors in different ways, leading to endless bug reports and broken software.

Use a terminal like kitty that does not close as long as some launched program is still connected to it. https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.close_on_chi...

You dont need to overwrite anyone elses config files, see https://sw.kovidgoyal.net/kitty/kittens/ssh/#a-real-world-ex...

TO make using SSH more ergonomic, use it with a terminal that integrates with it, such as kitty: https://sw.kovidgoyal.net/kitty/kittens/ssh/

That makes using SSH ControlMaster automatic, scoped to the lifetime of the terminal session, and allows for easy automatic syncing of local shell and editor rc files to the remote host, as well as easy opening of remote files in the local editor and can even clone shell sessions into new terminal windows.

Oh man, this is rich :))) Let me just leave this for posterity. kitty has had a socket for remote control for years: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.allow_remote... (see socket-only). It can allow remote control from specific windows while disallowing it generally: https://sw.kovidgoyal.net/kitty/launch/#cmdoption-launch-all...

Furthermore the next release of kitty has capability based security for remote control with public key crypto to keep the data safe: https://github.com/kovidgoyal/kitty/discussions/5320

I suggest you find a better place to move the goalposts in your attempts to smear and spread FUD.

Ah so classic FUD, "its unknown what it can do". Why dont you spend some effort figuring out what it can actually do instead of making driveby comments with an obvious axe to grind.

You very conveniently left out the fact that pretty much anything that views untrusted content has to parse files. If parsing files is where your "security boundaries" lie, I suggest you drop your computer off at the garbage dump. Hell if your editor has a preview function it too will parse untrusted content. Basically, to do anything software has to parse untrusted content. And just by the way, /etc/passwd is not attacker controlled. If the attacker has access to your filesystem already, she really doesnt need to use kitty to do anything. And "opening" README.md will not cause kitty to parse files, unless by "opening" you mean catting without -v. In which case we are back to your mommy told you to know better but you didn't listen.

At this point its obvious you are deliberately trying to spread FUD. I am done interacting with you. Good bye.

Are you being deliberately obtuse? Yes obviously when asked to display a file, kitty will read it. But it wont send the file contents on the TTY, so the *program sending the request* cannot read it. Which is what we are discussing here. You are trying to make it seem like the ability of a program to get kitty to read an arbitrary file is a security issue. I suggest you go do the following: strace your editor, then ask it to open /etc/passwd, and then be shocked when you see it doing so in the strace log. Seriously, why am I wasting time replying to you.

Everyone?? No just you. And read the rest of my post. Yes, kitty will delete files in /tmp if asked to. That's what I said. And no unlike your claim, it does not read them. If you cannot tolerate the theoretical possibility of something deleting a file in /tmp ever, then set TEMP before you launch kitty to /tmp/my-mommy-told-me-not-to-put-valuable-things-in-tmp-but-i-didnt-listen

No, kitty does not let stdout out read or delete arbitrary files. First of all stdout is an integer in a lookup table in your kernel, It cant read or delete anything. I assume you mean it lets programs read or delete arbitrary files by writing to and reading from the tty device. And even that is not true. The kitty graphics protocol does let a program delete arbitrary files in the TEMP directory. It does not let anyone either read or list the contents of any part of the filesystem.

Write your program around an event loop which if its an interactive program it already has. And read man signalfd.

Proof! the entire field of cryptography can prove absolutely nothing other than that a single use of One time pad is secure. the rest is all hand waving, that boils down to no-one I know knows how to do this, and I cant do it myself, so I believe it's secure.

So the best we have in cryptography is trusting "human instincts/judgements" about various algorithms. Which then further reduces to trusting humans.

That is obsolete and wrong in many ways: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#bugs-in-f...

You dont need to do anything fun. Just convince emacs developers to support a modern terminal keyboard protocol. https://sw.kovidgoyal.net/kitty/keyboard-protocol/ and you get support for hyper out of the box.

You want a proper html 5 parser that can handle non valid documents. And the fastest one is https://github.com/kovidgoyal/html5-parser over 30x faster than html5lib