4 ms·

Upstream GNU Emacs can no more be called "crippled" on macOS than it can be called "crippled" on linux, because on neither does it support multi-color emoticons

by ploxiln 10y ago

Upstream GNU Emacs can no more be called "crippled" on macOS than it can be called "crippled" on linux, because on neither does it support multi-color emoticons. Maybe it seems "unfair" because macOS users could easily have the feature advantage over a free/libre OS user, but upstream GNU Emacs denies macOS the advantage. It is kind of funny. But also funny because GNU's adherence to their licensing philosophy means it's just as easy for you to get the full macOS-enhanced fork. So the angst seems unreasonable to me. (Also, the whole emoticon trend is pretty annoying, from an implementation perspective. First it was just B/W icons, fine. But then users wanted color, and now fonts have to do something they've never done before, embed multiple colors for a glyph. There were multiple proposals for font formats to do this, IIRC Microsoft proposed a new TrueType table with color references, and Mozilla proposed just stuffing most of SVG into OpenType, I didn't follow this story to the end. Fonts were already pretty complicated and prone to vulnerabilities, and this more than doubles that complication. But it gets better, now that there's color and high detail, in this brave new politically correct world we need to be able to have a range of skin tones and genders for all emoticons with a person in them! Now we need color and gender "zero-width" modifiers, multiple for small groups! More than double the complexity again! Can't we just go back to B/W symbols and let people use PNG/JPG/SVG if they want an arbitrary fucking picture?)

lilyball 10y ago
From the original article, Emacs had this feature, and then they removed it. That's crippling it. Deciding not to implement the feature in the first place, well, that's a reasonable decision given their desire for functionality to be cross-platform. But accepting it, then turning around and removing it later even though it was already implemented, that's just spite.
- blowski 10y ago
  Crippling sounds like the entire software is unusable. If they stopped MacOS users being able to type the letter 's' that would be crippling. This is just disabling one small feature. If crippled is a broken spine, then this is preventing some people from wearing a funny badge until everyone can wear funny badges.
- gshulegaard 10y ago
  I don't know...from what I can tell it sounds like they removed the usage of Mac OS specific APIs from mainline:: https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00389.html https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00... Doesn't sound like crippling to me. > Deciding not to implement the feature in the first place, well, that's a reasonable decision given their desire for functionality to be cross-platform. But accepting it, then turning around and removing it later even though it was already implemented, that's just spite. Well this ignores the challenge of maintaining an open source project.
  - eridius 10y ago
    > Well this ignores the challenge of maintaining an open source project. Presumably Emacs is still using platform-specific APIs for the actual drawing of the text, yes? So properly supporting Mac font rendering should not adversely affect maintenance of Emacs in general, and similarly it should not be any more work to maintain the correct Mac font renderer as it is to maintain the incorrect Mac font renderer.
    - aecay 10y ago
      AFAIK vanilla GNU emacs uses NeXTStep APIs, which are also implemented by the GNUStep project[1]. So if/when X11 (and the many libraries that sit on top of it) learns how to do color emoji, then GNUStep can implement the Mac OS API, and emacs will support it. The GNU position wrt. Mac support is that only the APIs that GNUStep also supports can be used. You may disagree with the principles underlying that choice, but it is a long-standing policy of the project. It was a mistake (according to this policy) for them to merge the emoji support, and when the mistake was pointed out they removed it. So it's a bit more nuanced than your comment makes out. [1] http://www.gnustep.org/ http://www.gnustep.org/

by ploxiln 10y ago

lilyball 10y ago

From the original article, Emacs had this feature, and then they removed it. That's crippling it. Deciding not to implement the feature in the first place, well, that's a reasonable decision given their desire for functionality to be cross-platform. But accepting it, then turning around and removing it later even though it was already implemented, that's just spite.

blowski 10y ago
Crippling sounds like the entire software is unusable. If they stopped MacOS users being able to type the letter 's' that would be crippling. This is just disabling one small feature. If crippled is a broken spine, then this is preventing some people from wearing a funny badge until everyone can wear funny badges.
gshulegaard 10y ago
I don't know...from what I can tell it sounds like they removed the usage of Mac OS specific APIs from mainline:: https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00389.html https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00... Doesn't sound like crippling to me. > Deciding not to implement the feature in the first place, well, that's a reasonable decision given their desire for functionality to be cross-platform. But accepting it, then turning around and removing it later even though it was already implemented, that's just spite. Well this ignores the challenge of maintaining an open source project.
- eridius 10y ago
  > Well this ignores the challenge of maintaining an open source project. Presumably Emacs is still using platform-specific APIs for the actual drawing of the text, yes? So properly supporting Mac font rendering should not adversely affect maintenance of Emacs in general, and similarly it should not be any more work to maintain the correct Mac font renderer as it is to maintain the incorrect Mac font renderer.
  - aecay 10y ago
    AFAIK vanilla GNU emacs uses NeXTStep APIs, which are also implemented by the GNUStep project[1]. So if/when X11 (and the many libraries that sit on top of it) learns how to do color emoji, then GNUStep can implement the Mac OS API, and emacs will support it. The GNU position wrt. Mac support is that only the APIs that GNUStep also supports can be used. You may disagree with the principles underlying that choice, but it is a long-standing policy of the project. It was a mistake (according to this policy) for them to merge the emoji support, and when the mistake was pointed out they removed it. So it's a bit more nuanced than your comment makes out. [1] http://www.gnustep.org/ http://www.gnustep.org/