Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> What would a GUI bring to this that isn't possible in the console?

Not being destructive of user input, for starters.



I'm with Kaod here - what do you mean by this?


Not sure I understand what you mean.


For example the fact that the terminal does not make any difference between <c-m> and <ret>. Or <c-i> and <tab>.


You know what? I was ready for bullshit and you actually gave a compelling answer :P Yeah, that's a bummer, but there aren't that many instances of that drawback (it's bitten me a couple times maybe in many years?) and on the other hand text mode gives a lot of convenience like being able to use it from SSH and other niceties.

Anyways, I don't think such behavior is inherent to "the console", only Linux's particular implementation (i.e. it's tty's fault) which admittedly is pretty outdated and relies a bit too much on control characters.

IMHO the original question still stands:

> What would a GUI bring to this that isn't possible in the console?

In my experience text mode brings a lot that GUIs don't, and not the other way around.

Plus it's easier to make a GUI wrapper for a console program than a console wrapper for a GUI program.


Yes it's in no way a dealbreaker, but it starts rearing its head when you want to use keys outside of the alphanumeric cluster.

I also absolutely agree that this is the correct way for an editor to be implemented.


How is that destructive?

Visual editors assign various non-editing tasks to command sequences as well. Pycharm moves the cursor around parenthesis with C-m for example, Cmd-M minimizes windows, and Cmd-I does formatting.


I don't understand what you mean. It's destructive in the sense that the raw input is not even being passed to the application in the terminal.

No applications running in the terminal will be able to tell the difference between these two different key presses.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: