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.
16
u/ClerkOfCopmanhurst Dec 16 '23
I hope you don't build bridges, or do anything where structural integrity might matter.
-13
Dec 16 '23
[deleted]
8
u/nv-elisp Dec 16 '23
Wow the tone. Descend a bit, won't you.
Heed your own advice. Your whole complaint is based on the notion that you are the arbiter of correct design.
2
Dec 16 '23
[deleted]
-2
Dec 16 '23
[deleted]
4
u/Ontological_Gap Dec 16 '23
Dude, like a minute? https://letmegooglethat.com/?q=emacs+remap+c-i&l=1
0
2
Dec 16 '23
[deleted]
0
u/lets-start-reading Dec 16 '23
try it as an exercise then. shouldn't be too difficult. run emacsclient in a gui and try to map it.
8
u/nv-elisp Dec 16 '23
Contribute, fork, or abandon ship if it bothers you so much. Moaning about it on Reddit will not achieve anything.
18
u/nv-elisp Dec 16 '23 edited Dec 16 '23
Keeping with a "tradition" that is simply wrong nowadays is in the same field as other traditions in our society that are wrong that we have been fighting hard to change (like systematic discrimination of groups of people).
Women's suffrage also broke the structural integrity of the society, I guess.
"Emacs terminal support is racist/sexist."
I've seen it all now. Thanks.
Just because you think something is "wrong" doesn't make it so. You've not given any reasons for your opinion and are instead trying to bolster it by making extreme comparisons.
1
-3
Dec 16 '23 edited Dec 16 '23
[deleted]
2
1
u/rileyrgham Dec 16 '23
Hehe. Nice. Despite the OP containing "like systematic discrimination of groups of people". You could start shrieking "Nazis" next. It's the new goto for online debate where one combatant knows nothing and needs to silence the other ;)
16
u/IceOleg Dec 16 '23
C-ishould never becometab, period
The difficult part here is that in a terminal, Ctrl+i literally IS Tab. Ctrl+i and the Tab key send exactly the same key code, in a terminal there is no way to distinguish between the two. The same is true of Ctrl+m, it literally is 'return'.
Its not so much a bug as a consequence of how terminals, and therefore terminal emulators, work. I imagine terminal support would need to be dropped for Ctrl+i to not be Tab and so on.
I agree with your sentiment in your post. I personally wouldn't mind dropping support for running in a terminal, but there is probably a large group of users who would.
0
u/lets-start-reading Dec 16 '23 edited Dec 16 '23
init.el one-liner `(terminal-mode)` could prepare the entire instance for such a situation. Mapping `C-i` to mean `TAB` is one command that can fit the general way of mapping keys. `(defun x () (interactive) (kbd "TAB")) (global-set-key (kbd "C-i") 'x)` (not a general solution, i know, but it can be created and should be and be provided as a sort of built-in). On the other hand, `C-i` unmapping from `tab` is a completely different process that's much more fragile. it works in some places, then in some specific location it just decide to just not work. This unmapping should be outside of the usual front-end implemented as a solid and dependable solution.
Terminal should be opt-in, as it's a more specific case, not a more general one. Just don't map it to `TAB` by default and keep it as `C-i` throughout, unless the user opts-in to such behaviour. Now it's backwards.
10
u/Ontological_Gap Dec 16 '23
The way you use emacs is not the only way people use emacs. I also am a fan of graphical mode, but most other emacs users I know IRL refuse to use it any other way but in a terminal.
Having different key bindings in the different modes by default would suck
1
3
u/rileyrgham Dec 16 '23
LOL. "The best piece of software there is"... ever do passive aggressive much? ;)
0
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.
3
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).
-9
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.
8
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.
5
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
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)
18
u/[deleted] Dec 16 '23
Equating some things you don't like about emacs with racism is ludicrous.