aumerle

Of course, I didn't mean to put you in a spot. We can always continue this later once your thoughts have matured. Sadly I have an extremely full schedule so I dont think I have the badwidth to noodle on this at this stage but if and when you have something more concrete please do post it somewhere public and I will try to contribute to the discussion.

So if I am to understand your proposal more concretely it is something like implement an escape code that the shell can use to turn off all other escape codes (presumably with some kind of listing mechanism) and then have the shell do that before launching any third party script/program/function? How would the shell know which escape codes the program it is running needs?

I can, kind of, see the utility of a pledge() type system within a single program, but in a shell, whose whole job is basically running programs it knows nothing about beyond their name? How would that work?

Yup kitty revolutionized my terminal experience, hence the passion. I am sorry but since you seem to be passionate enough about ghostty to try to shill it in a article about a security vulnerability in it, I don't think you have a leg to stand on when it comes to complaining about my posts.

If you want to claim that ghostty is developed very rapidly it behoves you to do a little research and compare it against its peers before making that claim.

You proposal does not address this issue since shells would still need full privileges.

This entire class of exploits (query responses with user controlled data leading to shells executing commands) would be removed if shells just moved to using the kitty keyboard protocol with all key events represented as escape codes and implemented a full escape code parser for data received form the terminal. You cannot embed an escape code inside another, or while technically you can, it is trivial to implement a security policy of disallowing these in both terminals and shells. Then barring implementation bugs in the escape code parser (which can easily be shipped as a standalone native code library) you dont have this entire class of issues and the associated one that the bracketed paste hack was created to address.

Yes, but this is two well known and understood functions we are talking about, wrapping them is really not that hard.

It's not even slightly tricky, just use self pipe. I have no idea why the maintainer of make rejected it. He says select has different signatures, but select is in POSIX, so unless he is porting to a non POSIX platform, it's irrelevant and even if he is, I doubt it is that hard to write a wrapper to abstract the non POSIX compatible implementation of select. Then he complains about needing to do CLOEXEC on the self pipe. This is trivial (one line) on Linux using pipe2 and about 5 lines of code on other platforms. Given that he says make does not use threads its also perfectly robust without pipe2.

Opting for a harder algorithm just to avoid a few lines of compatibility shims seems like very much the wrong tradeoff.

Or run

kitty --dump-commands program-whose-output-you-want-to-inspect

You can even save the --dump-commands output as edit it and then replay it with

kitty --dump-commands program > commands.txt

kitty --replay-commands commands.txt

Ah yes, in that case there no terminals that implement it indeed. Though there are a few that implement changing window size via escape code, though in units of cells not pixels. Generally speaking I dont see how applications can use tcsetwinsize() robustly, given that the size in pixels of a cell is determined by font properties and applications runing in the terminal have no knowledge of these, therefore cannot set both the pixel and cell sizes at the same time.

Lots of modern terminals support ws_xpixel and ws_ypixel. Hell even the venerable xterm supports it. It is used primarily for displaying raster graphics in modern terminals, see for example: https://sw.kovidgoyal.net/kitty/graphics-protocol/#getting-t...

And nowadays modern terminals even support in-band resize notification so there is no need for SIGWINCH: https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3...

And we are all delighted to be spared from your personality in the kitty community. Enjoy your day as well.

Then stick to commenting on posts about such software instead of trying to mislead people about software you know nothing about.

Sigh. Go read the docs:

remote control has both a socket only mode, and has the ability to allow tty connections only with a password: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.allow_remote...

Furthermore, remote control in kitty has capability based security where you can lock down the protocol to allow individual actions with arbitrary granularity:

https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.remote_contr...

Nope, native applications are not ever going to get the ridiculous level of sandboxing demonstrated by the restrictions on accessing the clipboard in the article. Nor are they ever going to be prevented from accessing the file system as web applications are.

Again, no non mobile OS prevents native applications from using the clipboard as it should be used. And none of them show any signs of changing that.

And that's just what he did until someone showed up to do the grunt work of porting to Python 3, at which point he co-operated with that person and helped make the port happen, just as he said he would. I suggest a more facts based narrative in the future.

List of all python3 PRs merged by the developer in minutes to hours: https://github.com/kovidgoyal/calibre/pulls?q=is%3Apr+py3

Ah, you are back with your "the kitty protocol doesn't support my pet feature that nothing else supports, aka left and right distinct modifier states" so it must be bad. I was wondering when you would show up again.

If you mean mobile OSes sure, I can agree with you they are becoming worse with time. OSes for real computers, not so much.

I dont run a single native application across five operating systems that requires a popup nag to access the clipboard or that is unable to put any data other than text, html and PNG on the clipboard.

This article is a perfect illustration of why Webapps will never be as good as native ones. Webapps are always "untrusted" code so they are arbitrarily and artificially restricted from accessing resources on your local machine.

Now, the OP has to remember, df -h -x tmpfs instead of df -h. The proper solution for this is to not have commands that are both meant for interactive and script usage. Then the defaults for their output can be changed over time to suit the evolving landscape. Or if you do want a single command for both have a --script flag that makes its output suitable for usage in scripts.

The end of the article says the bug isn't fixed, so presumably, the root cause identification was wrong?

Let's discuss the parts you left out in your carefully constructed attempts at character assassination.

1) kitty has a template for issue reporting that the person that reported that issue didn't use, which means it isn't a carefully constructed report.

2) The issue is probably with kkp.el. I don't know about you, but I don't expect maintainers of open source projects to debug all issues in their own projects let alone unrelated ones. Kovid went out of his way to tell the OP exactly how to provide useful debug information. And he did so within a few minutes of the issue being opened.

3) The part you complain about is him saying he has zero interest in debugging kkp.el and emacs. Which is perfectly reasonable, again, why should he have an interest in it. He provided the OP with the means to give him information that he would be interested in debugging instead.

4) He then gets told that the OP would rather use some other terminal rather than provide the debug information he was asked for. Do you have any conception of how rude it is to go to some projects issue tracker and then state you are going to use a competitors product.

5) You tried again to insert an unjustified swipe at Kovid, with "the keyboard protocol he insists everyone get on board with". In reality that keyboard protocol is completely optional, an no one has to use it. The fact that everyone does actually use it, is testament to its being light years ahead of any of the alternatives and represents weeks of hard work on the part of Kovid to finally bring sanity to this corner of the terminal ecosystem. An effort he made for the good of the community. And an effort that has succeeded, since pretty much all modern/maintained terminal software support the protocol as it is clearly superior to the alternatives.

6) You were at best mistaken in making your claim that he doesnt like settings, but given you clearly have an agenda against someone who has done nothing to you other than provide the world free software, I think the default assumption is malice not incompetence on your part.

And yes by all means dont use kitty, I have a strong feeling that Kovid, who has been providing software used by millions of people for decades has reached a point in his life where he recognizes that some users cost way more than others. He is likely very happy that you and people like you give his work a miss.

A position I greatly sympathise with. People that report issues to open source projects need to remember they are asking for help, it behoves them to put in the maximum effort they can to reduce the burden of the free help they are NOT entitled too.

OK so you are not lying, you are just wrong. Now that you have reduced the scope of your personal attack from he doesn't like settings to he doesn't agree with me about one thing, perhaps you should exercise your new found honesty a bit more and link to the issue where he refused to implement bold as bright and gave his reasons, which are perfectly sensible, namely that having that option means that the developers of terminal programs cannot rely on having a bold font face. Terminals are already limited to using only a single font size, you want to take away the ability to use bold faces as well. And you are trying to sell this as the kitty developer being unreasonable. Shame on you.

You shouldn't believe things you read in hacker news comments. saurik is lying, probably because he once requested some feature that the kitty maintainer didnt like and refused with good reasons, which made saurik want to curl up into a ball and cry. To say kitty has no configuration options is the exact opposite of the truth. Proof: https://sw.kovidgoyal.net/kitty/conf/

Wave your hands harder, you might achieve lift-off.

Most decent linux terminals let you configure this. For example in kitty:

map ctrl+c copy_or_interrupt

https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_inte...

timing footclient -e true is not actually measuring what you think its measuring. It's measuring the time it takes to open a socket and write a few bytes to it. Not the time it takes to run true in a new window and then close it. And just FYI both alacritty and kitty have server/client modes too. foot without server client mode does indeed startup faster than any GPU based terminal emulator because GPU based terminal emulators have to probe the GPU card(s) ont he system for their capabilities which is approx 100ms of unavoidable delay until someone convinces the kernel developers to cache this data.

In client server mode all of foot/alacritty/kitty/urxvt will open windows in a few ms.

Sure I can patch any software to do anything I want. Which is what an extension is doing. I can patch any software I want to treat the A key as a modifier too. Still doesnt make it a good idea. And my point remains, Chrome, unpatched, does not support left and right modifier keys as modifiers. Not to mention I dont actually believe you. Post a link to this supposed extension of yours. I am guessing you wrote it and only you use it. And if you want to call the browsers used by 99.9999% of the population terrible in favor of some shit you cooked up yourself just to try to rescue your ridiculous point, good luck to you.

I'll just leave you with this promise, anytime you try to denigrate the kitty keyboard protocol I will be right there calling you out.

Name one windows application used by more than 10 people that supports independent left and right modifier keys used as modifiers. One application. Just because the windows API for some inexplicable reason exposes those states. Meanwhile let me name some of the most popular applications in the world on Windows that explicitly dont support this.

1) Chrome 2) Edge 3) Microsoft Word 4) Windows Explorer 5) Windows command prompt and windows terminal 6) VLC 7) LibreOffice 8) Every terminal emulator under the sun 9) Firefox 10) Pick any windows application at random

Just because you WANT left and right modifiers to be different doesnt make it a good idea. Learn that.

I did and I comprehended that you want left and right modifiers to be different. The rest of the world disagrees with you. That does not give you the license to go around maligning other people's work.