What are you talking about?

In JS, an event is triggered when a key is pressed, and we can read the logical value including the state of flavoring keys.  

So if I'm writing an editor or similar (which in fact I am at the moment, and which is what prompted my wishlist post), I can use whatever keypresses I like to invoke various functions.  That's very straightforward: just look at the event struct and it's all there.  There's no horsing around with fgetc() on STDIN, flushing buffers, et tedious cetera, which (afaiaa) is what must be done with php.  

So right now I'm writing the editor in a mix of js to do the human-factors and php to talk to the disk.  It's be much nicer if it were all doable in php.

So... you want to make an editor in PHP? That runs from the command line, like vim or emacs? I guess reading keyboard state is alright, but that sounds like a job for a PECL extension (if there isn't already one that can do it).

Probably gui, not command line.  Too hard to keep track without a stable window, and php already knows how to talk to a browser window.

I'd argue that all basic i/o functionality (and there's surely nothing more basic than being able to get keypress events) belongs in php itself.

> php already knows how to talk to a browser window
Uh, no. PHP does not "talk to" the browser. The browser sends data in a request and PHP sends data back in the corresponding response. There's also WebSockets but that's still in the same vein as the sending/receiving process.

PHP on a server does not monitor keyboard events on a client. It doesn't monitor typing, mouse clicks, DOM events, browser resizing, or anything at all that happens on a client. Nor is it even possible to do so. The only way PHP can know about that is if the browser tells it.

That is client/server 101. If I knew a good single-source explanation for it then I'd give you that link. So instead I'm going to give you
https://www.google.com/search?q=web+client+server+architecture

But I have good news for you: if you want to watch for the user pressing keys like Ctrl or Shift *in Javascript* then you can use the keydown/keyup events.

> I'd argue that all basic i/o functionality... belongs in php itself.
How about mouse movement? You think PHP should be responsible for that too?
You can argue all you want about what you think PHP should be responsible for, that doesn't make it possible.

Oh c'mon - that's shorthand.  Php does "talk to the browser", if there's a browser involved --it's called "echo", and it writes to port 80 on the client machine using http protocol or to 443 using https, yada yada.  It also listens to the browser, because otherwise it would never get anything in the GET and PUT buffers. Is it really fruitful to quibble about the level of abstraction in the description of what's going on?

Yes, php only knows what the browser tells it.  And why does the browser tell it anything?  Because some human tells it to!  The php developers, being human, could insinuate some js code in a broadly similar way to all the capitalist crap that burdens every web page to report keypress information.  

Such keypress information is wanted mainly, or only, in cases where the php job is running interactively, typically locally, and is hf-bound. That's how the editor I'm writing will run, only I can't write it or anything similar in php because php doesn't afford the keypress information.  

Yes, I could kludge a little ajax or perhaps even websocket job to do nothing but pass keystroke information back to the php job.  But I shouldn't have to:  keystroke information couldn't be more basic.  Php is no longer a tiny, bounded, special-purpose language.  It's a general language and should have a full array of general capabilities -- including the ability to get keystrokes without everyone having to write their own routines to do the work.

Node.js is part of a movement to make php obsolete:  (When I read their "one language everywhere" goal, the first thing that popped into my mind was "Ein Volk, Ein Reich, Ein Führer" (I was born during the Battle of Britain), and the second thing was "One Ring to bind them all!"). I don't use node.js, but millions do. Without a full array of basic capabilities, php is vulnerable to being pushed aside.

Did you seriously just invoke Godwin's Law?

There's one very basic fact here: if you are using a browser then you are not interacting with PHP directly. That's fundamental. Just as I would not expect Chrome to know my keystrokes when I'm using Netbeans, I would not expect PHP to know my keystrokes when I'm using Chrome. Even if that webpage on Chrome was rendered by PHP. Even if both are running on the same machine.

If you had used Node.js then you would know the same thing applies over there. This isn't a matter of PHP supporting behavior. This is a matter of the behavior not being possible in the first place - and if you were at all familiar with how the internet works (and with your "explanation" of how PHP "talks" to the browser, I doubt it) then you would understand why this is not possible.

And this is all completely separate from the argument that the UI layer should be what's responsible for the user interface (literally), not the backend.

PHP cannot monitor for events on a web client. Nor can Node.js, or C#.NET, or Ruby, or Python, or any other web-capable language. Go anywhere else and they will tell you the same thing. But you know what they will tell you? Same thing I said: Javascript can do it. So use that.

stop it - you don't understand client/server architecture and PHP has really no business in listening to events since there is no thinkable glue between client - server - php for that 

or to say it in other words:there are different programming languages and when you are not capable to figure out which part belongs to the client and which one to the server does not mean php needs to be modified 

frankly it's idiotic to even consider php listening directly to key events instead handle that part on the client because even if it could work in theory it would be a terrible user experience because of the introduced latency

I understand client-server fine, and I've no interest in being abused by you.