361–370 of 418 posts
Earlier quoted context omitted.
Wheelchair users are also pretty unusual and we don’t go removing ramps from everywhere. I’m growing pretty tired of the “your use case is unusual, so fuck you” argument.
> "your use case is unusual, so fuck you" With love, The Chrome Team
Google continues the war against its own users.
I can think of a few UI styles Emacs doesn't support (to my knowledge) – line mode terminals, block mode terminals (such as IBM 3270 and 5250), and HTML. Now, whether any of those UI styles are actually worth supporting is a completely different question. But it is not quite as universal in support of different UIs as this email claims. (You can technically write line mode applications in Emacs Lisp, try `emacs -batc…
Emacs support of non-fixed width fonts is also pretty bad. My language Urdu is basically impossible to write on Emacs - or at least it was 5 years ago when I struggled with it a lot.
(defun fixed-pitch-mode (&optional arg)
(interactive (list (or current-prefix-arg 'toggle)))
(buffer-face-mode-invoke 'fixed-pitch (or arg t) nil))
Earlier quoted context omitted.
Chrome has a "minimum font size" setting that overrides websites that use small fonts. I set my minimum high (16 normal, 14 minimum) and haven't run into any breakage. (I am not sure if the point sizes of fonts have any meaning. I like my text a certain size and it's a different number in Chrome, Powershell, and Putty, which is weird to me...)
IIRC, in typography, a point is 1/72th of an inch. I don't think desktop computers, with the possible exception of the NeXT, ever respected that.
Put a nominally 12pt font on your screen. Now plugin a monitor with 2x the resolution. Now plugin in a projector with 4x the surface area, but the same resolution.
Drag the window around. What happens?
Yes, in highly defined scenarios, where you know for certain the number of pixels per inch and you know it doesn't change, you can generate as 12pt font that is actually 1/6th of an inch high.
Most of the time, software doesn't find itself in these situations.
Earlier quoted context omitted.
It is an interesting historical note that T. V. Raman won the ACM best doctoral dissertation award as a blind scholar [1]. I take an active interest in accessibility partly because my wrists hurt. Technologies initially meant to help blind people have turned out to be useful for people with other conditions as well. [1] https://awards.acm.org/award_winners/raman_4110221
Are there any particular technologies that have helped you with your wrist issues?
Also, Karabiner-Elements helps me to remap some of my awkward key combinations. For example, I avoid doing any typing with my pinky - so shift has been remapped to spacebar long press, and control has been remapped to caps lock. These are standard settings that I think many people use.
I also try to use text-to-speech and voice control to avoid pressing the ridiculous arrow keys on the MacBook Pro.
On other machines, I have an easier time, since I have bought a mechanical keyboard which supports softer keypresses.
When I finally come around to it, I will try to purchase a joystick/accessibility (vertical) mouse. I just don't want to clutter my small desk too much.
Earlier quoted context omitted.
VSCode/Atom/Sublime all operate broadly the same way. To continue the car analogy, there's a wheel right in front of you, two or three pedals by your feet and a gear stick next to you. In this analogy, emacs' accelerator is on the ceiling, the bake hangs off the side and to steer you need to tap out the morse code for the words left and right on the dashboard. Can you become proficient using that kind of interface? P…
I think that is being deliberately unkind to emacs. It would be closer to comparing it to a car designed 30 years ago in a country that drove on the other side of the road. Most all of the major points are the same, just in a different location. Even better, compare it to driving a boat, when you've been used to cars. (Or, for that matter, realize that it is a stick shift car when you've been used to automatic. And s…
This is like a car model that came into existence 40 years ago, but is still making cars today.
Ford is over a 100 years old. Yet I have no problem getting into a rented Ford and driving without consulting the manual.
Earlier quoted context omitted.
> From there it's learning some keystrokes Learning Emacs is VERY clearly not this trivial... to use Emacs to any extent where it's more useful than it's competitors, you have to learn the models it works in, a new programming language- and then there are a LOT of keystrokes
Do you want a trivial learning curve or do you want power? The people who Emacs will please most are power users who are willing to put in the time to learn it and configure it to their liking.
I’ll concede that one can be extremely productive using Emacs or Vim, but the steadfastness to refuse to adapt to changes in how most developers work isn’t going to help win any arguments.
Earlier quoted context omitted.
It is an interesting historical note that T. V. Raman won the ACM best doctoral dissertation award as a blind scholar [1]. I take an active interest in accessibility partly because my wrists hurt. Technologies initially meant to help blind people have turned out to be useful for people with other conditions as well. [1] https://awards.acm.org/award_winners/raman_4110221
Are there any particular technologies that have helped you with your wrist issues?
Earlier quoted context omitted.
I'm not sure I follow. As a power user of computers for years, I would be a liar if I said any of those programs were "quick to get running." Speaking as someone that is getting my kids up and running with computers. Training and tutorial running are the norm and should be. Expecting proficiency in anything with less than a few hours is an exercise in pain. If you want there to be a new tutorial, I don't know anyone…
What I'm trying to say is this: I can pick up almost any text editor and be productive immediately, even if I've never used that editor before. That is manifestly not true with emacs (or vim). Getting back to my point about the emacs documentation, it is simply not optimised to get me productive in the way I can be with other editors anything like as quickly as I can become productive with those editors. Of course yo…
It's true, but I don't see why this is being given much importance. If you pick up any editor and use it only to the extent that you can without ever having to read up documentation, then simply go ahead - you likely do not need power features. If you need to do powerful things, then I suspect you will need to read docs regardless of the editor.
Emacs is a powerful tool. If you only need basic editing, then don't use it. That you can't do basic editing with Emacs without even going through a tutorial is not a flaw of Emacs, and you are clearly not the target audience for the program.
Earlier quoted context omitted.
I think that is being deliberately unkind to emacs. It would be closer to comparing it to a car designed 30 years ago in a country that drove on the other side of the road. Most all of the major points are the same, just in a different location. Even better, compare it to driving a boat, when you've been used to cars. (Or, for that matter, realize that it is a stick shift car when you've been used to automatic. And s…
Given that I love Emacs, I hate to disagree with you, but I must: This is like a car model that came into existence 40 years ago, but is still making cars today . Ford is over a 100 years old. Yet I have no problem getting into a rented Ford and driving without consulting the manual.
And my point is I agree that vanilla Emacs can feel spartan. Thing is, my customizations have aged really well. My config for Emacs hasn't changed too much in over a decade. That kind of stability is hard to put value on. Especially when our industry seems to price itself on instability.
I can think of a few UI styles Emacs doesn't support (to my knowledge) – line mode terminals, block mode terminals (such as IBM 3270 and 5250), and HTML. Now, whether any of those UI styles are actually worth supporting is a completely different question. But it is not quite as universal in support of different UIs as this email claims. (You can technically write line mode applications in Emacs Lisp, try `emacs -batc…
Some time in the late '90s a friend and i sat down and tried to design a UI framework that could cover lots of styles. We started with GUI and line-mode terminal, but hoped to add curses and the web (1.0 of course, so using forms, not JavaScript). I didn't know about block-mode terminals at the time. GUIs and line-mode terminals are radically different, so you have to think of a language of UI primitives that are hig…