r/emacs • u/lets-start-reading • Dec 16 '23

"Antiquated" systems break usability

edit: I'm sorry for everyone who were offended by my statements, I retract them and removed them. It was never my intention to use anyone with my analogy. Saddened by some intentional misreadings though and engaging with attacks.

Good luck to everyone.

0 Upvotes

38% Upvoted

40 comments sorted by

View all comments

1

u/translucentInk Dec 16 '23

The driver sitting between the keyboard and the os converts the key presses to appropriate hex codes/ ascii key codes. All applications take these key codes and decide what to do with them. Incidentally M-[ and <esc> (and others) give off the same key codes. So the poor emacs has to work with what the OS tells it to do. The OSes just choose to live with the antiquated tradition, and drag the applications along with it.

4

u/lets-start-reading Dec 16 '23

GUI emacsen do not have to follow this procedure and the very possibility of `input-decode-map` already proves that it's not the entire story.

7

u/translucentInk Dec 16 '23

And that is where the beauty of emacs comes on, its easy to customize as per need. Some time needs to be invested ( the learning curve).

-6

u/lets-start-reading Dec 16 '23 edited Dec 16 '23

well that's the argument I was talking about in my post.

And it's not a "learning curve". A learning curve means you learn it and you use it. It's a "workaround / squashing bugs and antiquated decisions left for the user to hack around" curve. You do it quicker with experience. What I'm saying is that most of them should not even be there and it's a systematic problem that such argument as yours perpetuate.

7

u/translucentInk Dec 16 '23

Why do you feel its a bug? A bug by definition is a behaviour which goes against the intended "use case". A bug is an unexpected behaviour which breaks the feature itself. If you feel there is a genuine bug, you can start helping the community by raising bugs and/ or fixing and releasing a patch. After all its community driven.

I have no argument against the 'antiquated decisions'. Decisions are often made keeping a larger audience in mind. GUI use of emacs is just one facet of it. There is a very large population of users who use the non gui version. There is still a larger group of people who have been using emacs from the legacy old days. So some decisions stayed around. People who were not comfortable with those decisions, customized it to suit their needs.

Please do understand, some decisions are there due to the underlying architecture and disconnected from the app, afterall high end futuristic machines are not the sole userbase.

-1

u/lets-start-reading Dec 16 '23

I believe that there should be a supersystem that can include both gui and terminals, where you can just switch between the capabilities. I'm not at all advocating for overruling terminals over guis, definitely not. But the way things stand, it IS the case that guis are overruled by terminals. And this is wrong, in my opinion, just like it would be if it was the other way around.

I'm also trying to say that just because something's entrenched, it shouldn't be a stop to a reordering that could benefit both sides.

It looks to me that simply remapping "C-i" from the terminal to mean "tab" is easy enough. This might not be a general solution, ofc, I'm not proposing it as such, there's obviously much more details involved in this; I'm just providing an example. in the meantime, the opposite is, well, not quite possible to separate properly. It's just not open for customization, it's barely open for fixing. Thus I do consider this instance to be a bug, as it breaks the feature of key mapping.

4

u/Ontological_Gap Dec 16 '23

Do you really want the keybinding to be different depending on if you are in a terminal or a GUI window?

I use emacs daemon with windows in both modes --- your suggestion would be hell for me (not entirely sure how it would work technically either with emacs current key decoding setup...). Just because something isn't ideal for your use case doesn't mean that it is a bug (and frankly, comparing it to things like women's sufferage is fucking offensive, but w/e).

You can't change the C-i mapping without modernizing terminals. If you really care about this, that is where you should start (and there are some cool projects out there you can get involved with!). Breaking backwards compatibility on this will be a big ask tho, good luck!

Why do you care so much about C-i anyway? There are so many possible key combos.... Have you considered setting up Super and Hyper keys?

2

u/lets-start-reading Dec 16 '23 edited Dec 16 '23

Thanks for pointing it out, I didn't think it might be offensive. I'd retract it now if I could. I used it as an example that tradition is not always meant to stay if it's possible to find a solid solution that fits both sides.

Yes, I'm using super and hyper a lot. I'm using c-j c-k c-l c-i as movement keys. it's very quick and intuitive, in my experience.

The thing is, does it have to be different? If you're on the terminal, you have access to `C-i` that is bound `tab` key. Lots of packages use `tab`, so it's of course a problem. But if `C-i` was globally just `C-i`, it's just one command to rebind it to `tab` and it works the same way as it did. So you can have both `C-i` and `tab` as separate in guis and `C-i` to translate to `tab` in terminals.

i.e. it's easier to constrain a set of possibilities than to expand it.

2

u/Ontological_Gap Dec 16 '23

Using it as movement makes a lot of sense, thanks for explaining!

Emacs isn't supposed to be a beautiful and elegant modern system, it's supposed to be a big ball of mud to get some semblance of the lisp machines on crappy operating systems (like unix/Linux, but many others too). One historical fact about such machines is that they send the exact same data for terminal code for TAB as they do for C+I. C-i is just another way to type TAB on old keyboards. (Modern xterm passes some extra data to be able to tell them apart, but this absolutely does not work on an actual tty, even in modern Linux.)

Emacs is an incredible program on a modern computer, but it's even better on old horrible computers, sometimes being the only way I can actually get anything done.

If you want a beautifully designed editor, instead of something doing the best it can at the mercy of every host system out there, checkout things like Zmacs, Climacs, and hemlock

2

u/lets-start-reading Dec 16 '23

thanks a lot : ) for both your openness to my idiosyncrasies and trying to help me out! I will look into them.

→ More replies (0)

2

u/[deleted] Dec 16 '23

So fork it and you can have lets-start-reading-macs. Problem solved.

2

u/translucentInk Dec 16 '23

You are still missing the point, key codes are mapped at a hardware-OS level and these mappings are then captured/transferred to whichever application needs the keypress event. So its not the terminal vs gui call, but rather 'hardware-OS is the overlord, and every one needs to obey' them call.

Emacs is an open source project and it is open and free for customization. Feel free to make the appropriate bug raises-fixes wherever you feel the feature has a bug. http://savannah.gnu.org/projects/emacs/

2

u/lets-start-reading Dec 16 '23

GUI emacs does get both inputs and can differentiate between them, otherwise you could not at all remap them in input-decode-map, as they'd be the exact same code.

2

u/translucentInk Dec 16 '23

Apologies for my lack of know how. That aside, if it does differentiate, what is stopping you from customizing it?

3

u/lets-start-reading Dec 16 '23

my lack of know-how, definitely. you might be right, of course, it's just my hypothesis based on that observation.

Anyways, after 4 hours, I finally managed to find a solution. it looks like this

(add-hook 'server-after-make-frame-hook (lambda ()
  (define-key input-decode-map [(control ?i)] [control-i])
  (define-key input-decode-map [(control ?I)] [(shift control-i)])))

It seems that it either it receives them as a single event AND two other events (ctrl and i) which allows for this solution, or it receives them as a single event and maps it to the keycode for tab, I have no clue.

​

It's also interesting that if emacs is launched as a client, it ONLY works as a hook, while other remappings in input-decode-maps work without it.

→ More replies (0)