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...
My point was not that the terminals don't report ws_xpixel and ws_ypixel, but rather that none support the application setting the resolution using tcsetwinsize() with the terminal subsequently changing its video mode / resizing itself to the requested size.
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.
Correct, that was one of the concerns. Note that tcsetwinsize() is mainly provided so that the pty master (i.e. the terminal emulator) can set the window size to be seen by the slave (i.e. the application running in the emulated terminal). The other direction is not explicitly banned though.
FYI, there are a few terminals that can set the window size in pixels (with `CSI 4 t`). And it's also worth mentioning that there were already terminal emulators back in the 1980s that supported in-band resize notifications (lookup `VTEEWR` - Enable Window Event Reports).
Furthermore, remote control in kitty has capability based security where you can lock down the protocol to allow individual actions with arbitrary granularity:
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.
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.
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.
Untrusted by default is a feature. No user would be able to protect themselves, unless perhaps they are a highly trained security expert always on alert, which is not a thing.
This is not the exciting early days of the interwebz where script kiddies run amok and it’s mostly for the geeks anymore, it’s where government-affiliated gangs are launching ransomware attacks on critical infrastructure in order to finance nuclear programs. Accessing arbitrary resources on your local machine is how that happens.
Web apps, given a modern browser, naturally have stricter sandboxing, but native apps are treated as untrusted on any modern OS, too. If I launch anything new, the dialog will have me confirm before it accesses anything other than its isolated app data directory.
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.
Every mobile OS from Apple would show a popup if an app tried to access clipboard without your explicit pasting. Obviously, if you tapped “paste” then popup would be unnecessary since you would be approving your own action, not app’s action.
It is somewhat crazy that macOS doesn’t do that yet.
But the comment I replied to was talking in general terms. Yes, for some APIs native apps are for now more trusted than Web apps, depending on the OS, but the trend is that they are becoming less and less trusted.
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.
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.
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/
I mean I might be "lying"... or I might be confusing him with the Gnome Terminal developers, with respect to that one specific tiny quote about "not liking settings".
(FWIW, the setting in question with respect to make menuconfig is "use bold as bright", where the kitty developer is on a vendetta to refuse the historical precedent. He is very adamant that he knows better than most everyone else on this point.)
Either way, I have never claimed to have talked to the kitty developer: I -- as well as multiple others on this thread -- are saying we've read how he handles arguing about terminals, and we don't like it.
Regardless, I do happen to be curled into a ball, and I do happen to look like I am crying... but it is merely because I am sick: I use xterm and I am very happy with the software and like the author.
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.
Look: my issue is that the kitty developer clearly thinks of himself as "God's gift to terminals". I pointed at one specific issue that I think is "telling" of an attitude of "I know better than everyone else", but I am not at all relying on that issue.
I just went through and started looking at recently closed issues on GitHub. I got through four before I found an example of what I think is the problem, and while this is a fairly benign one it is also clearly awkward enough that it shouldn't happen this often and is more than sufficient to clarify the complaint.
In this one, someone carefully points out an issue with a common script for emacs designed to implement the kitty-specific protocol (the one that kovid insisted everyone get on board with, as opposed to the prior art that already had traction, so now we have two competing ones; but that's my complaint, not the poster's).
Kovid then decides to pick a fight by being abrupt and a bit snarky in his response. Again: the issue was just technical and is good enough that I can probably debug the issue... I dream of getting bug reports like this, so this isn't the kind of response I would expect.
> I'm afraid I have zero interest in debugging emacs and kkp.el.
This is just downright mean-spirited. You can say something similar in a way that isn't grating in the same way, but Kovid prefers being grating, and clearly the person in the issue also took it this way and they get snarky back:
> If you aren't interested that's okay, of course.
> OTOH, I have zero interest in debugging Kitty. I'll just use Alacritty or iTerm :-)
Given Kovid's comment, I think this is in some sense a leveled response: Kovid is demonstrating he has little interest in being collaborative or helpful, even in an ecosystem that he created. I certainly don't act like that, even when people would use tools I actively disagreed with, I still would always help them debug it.
Kovid, of course, escalates this one further and leaves the thread in a pretty demoralizing place.
> Excellent! Don't let the door hit you on the way out.
Damn :/. That is what I am talking about. He isn't just grating in the way Linus was grating -- though Linus, to be clear, was also an asshole who, at some point, started to realize just how much of a problem he was being and is a lot better today -- and I also don't think he is just grating in the way that people who moralize (I am guilty of this one) do... he's just kind of mean, even when it makes no sense, and the result is that many issue threads with him get this "edge" about them where everyone is slowly escalating the burn until they just drop out of the thread entirely for their mental health.
(Part of me actually wants to now debug this specific issue, but I'd be doing it out of spite, and I do not want to be dragged into that. I only commented on this at all as I didn't want the person further upthread of me to feel alone in commenting on the problem with Kovid, and so I think it is reasonable that I get some of the flak here as I'm willing to bring the receipts.)
So, no: I simply don't think it is fair to say I am being dishonest, and the specific thing you quoted from me about him not liking settings is obviously not the point and wasn't something I delved into, as it didn't matter why: the issue was how... FWIW, in a thread where a bunch of people are all agreeing that Kovid turned them away from using kitty, maybe at least some of us have a point?
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.
> where the kitty developer is on a vendetta to refuse the historical precedent
I mean, he's not wrong. Everyone else should update their shit to be proper so that he doesn't have to deal with all this legacy nonsense. It's just annoying as hell for people using it right now.
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
reply