Bye Bye Emojis: Emacs Hates MacOS | Hacker News Reader

Bye Bye Emojis: Emacs Hates MacOS

lunaryorn.com

203 pointscsmonk173 comments

As one of GNU's flagship products, why shouldn't Emacs remind users that it is not in agreement with Apple's treatment of its users? GNU has an agenda, just like Apple does. Intel cripples icc for non-Intel CPUs, making it emit pessimised assembler. Apple makes sure that its hardware only works with other Apple products and that macOS can only be legally virtualised on Apple hardware. Everyone has an agenda.

The difference is that GNU is a lot smaller and has a lot less power and resources than Apple and Intel. So much that it is relatively easy and, in fact, explicitly allowed by the GPL, for someone like Yamamoto to come along and decide that, by golly, Emacs will have unique macOS-only features and Apple deserves to have more money to do whatever it wants to its users because its users enjoy Apple's treatment, smelly GNU/Beards be damned. This is a lot easier than fixing icc for AMD CPUs or putting headphone jacks into iPhones 7.

> We are not welcome, and never will be.

You are welcome. You are very welcome. Apple is not. You should not identify yourself with Apple's operating system.

That is true. Similarly, you shouldn't identify yourself with the FSF or GNU or RMS either. Tribalism in general is a dead end for humanity.

Thanks for this dose of perspective. I found the idea of emacs in macOS being hobbled out of spite very annoying, but what you said also makes sense to me.

Deliberately crippling your product on Apple platforms does not in any way "remind users that it is not in agreement with Apple's treatment of its users". In fact, it's fairly ironic that, in an attempt to protest someone else's treatment of users, Emacs has decided to treat its users badly. Deliberately crippling Emacs will not make Apple change, and will not get people to switch away from Apple platforms. But what it might do is get people to switch away from Emacs.

is removing multicolor font support crippling emacs?

If you prefer it, or rely on it, yes. Yes, as far as a user is concerned it would be

It's a paper cut. On the right finger it could be crippling ️

I'd say it's a feature, not a bug. There is no place for colorful smileys in my text files.

Then don't put them there, or install an alternate font.

And therefore nobody else should be allowed to have them either. Which is the explicit justification given for this decision. Sheesh.

Emojis are characters in the Unicode specification, which have glyphs in the macOS default font, and are rendered by default in native macOS apps that display text. Why should Emacs make the decision that most characters are okay to display in their text editor, but these specific characters are a no-no?

You're sounding like "I'm not using this feature, why does it even exist?". If things worked like that, then everybody would be using Linux on all computers today.

"my" is the key word there...

Your argument sounds like "A man shouldn't be allowed to marry a man because I don't want to marry a man"

Defective by design...

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?)

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.

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.

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/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.

> 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.

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/

You should not identify yourself with Apple's operating system.

If I want I will identify myself with whatever I decide to identify myself with; I don't really care about Apple, but now you've turned it into a matter of principle, moralizing what people shouldn't do.

You should not identify yourself with GNU/Linux. How did you like that?

How about identifying oneself with JustWorks(SM), vertical integration, and things being purposely designed not to get in one's way?

Then you will find yourself compromised when using software made by another school of thought. shrug

Compromised in what way?

There are other, non-GNU free software alternatives out there.

And you are free to use them. Have fun.

I have, and I will. What about the rest of you?

Well, some will join you. Some will consider the lack of multicoloured emojis in emacs on mac a minor issue at best and continue to use what they do.

I wasn't referring to emojis, but to GNU and GNU/Linux. GNU and Stallman are the culprits here; Emacs is just a symptom.

I've always identified with ProDOS.

I always preferred SOS. More sophisticated.

U+1F644 [1]

[1] http://unicode.org/emoji/charts/full-emoji-list.html#1f644

Removing a feature that already existed is a slight against apple users, period. Work was done and committed to REDUCE the feature set for a group of users. There is no watering it down.

It was done for rather childish reasons... and it makes no sense. It doesn't serve them. It doesn't serve anyone...

But its what I expect from GNU, and the FSF hardcore community at large... you know, the PETA of software.

It's supposed to encourage people to bring the functionality to free OSes:

https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg01...

It's not like it's difficult to get Yamamoto's Emacs. So GNU's gesture is almost purely symbolic. If you don't care about getting a free OS and you like the conditions that macOS imposes upon you, you can easily use Emacs with macOS-only features.

"So GNU's gesture is almost purely symbolic"

Yeah... and pedantic. And childish. I support free software, I commit to open source projects, I love just about any form of Linux and I prefer OSS when its as good as proprietary (sometimes it is... like blender... and sometimes its crap in a bucket... like GIMP ...)

I think my aversion and disappointment comes from the fact that, like PETA, this group and the RMS brigade are very much the public face of a movement, but a movement that doesn't need a single face... but regardless, they are the what outsiders see, and when you turn every piece of software into a political statement, you end up hurting the cause.

There are people out there who will, through some sick twisting of the mind, treat animals poorly or not care about actual animal abuse because PETA has been the face of the animal cruelty movement (or GreenPeace, another great example of this effect, I'm sure it has a name) ... even though the cause is good, and there are good organizations (ASPCA)... the annoying, loud, politically charged reactionary groups like PETA, GreenPeace, GNU, RMS/FSF ... those groups turn people away from free software...

Maybe I'm ranting more about the politicalization of software... maybe its all tied together and one and the same... I just know that I've heard plenty of people say they don't use Linux because it doesn't have X application, or X drivers... when it really does, but the common distros don't include them because they aren't in-line with their political view of the situation...

And several other Mac features were stopped before they made it into the official release. This is Richard Stallman's policy: "GNU Emacs should never offer people a practical reason to use some other system instead of GNU. Therefore, when someone implements a useful new feature but only for a non-GNU system, we do not accept it that form."

https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg01...

Yes, yes. Hold Emacs hostage Mr. Stallman. That'll make everyone stay up all night hacking to bring your lackluster platform to parity with its competition.

There's a real need for innovation and great ideas to better support all manner of open community resources, free software and beyond. But stupid control games are totes better than all that.

>That'll make everyone stay up all night hacking to bring your lackluster platform to parity with its competition.

Do you know any other platform that managed to form a foundation for org-mode? Until there is, emacs may not be called a "lackluster platform".

I'm not referring to Emacs with that, but rather to Stallman holding Emacs functionality hostage to boost GNU OS platform(s). Which are definitely lackluster.

Its not because its not shiny and not pricey that its lackluster. At least you can customize stuff on your OS instead of having to follow the only way designed by Apple.

Eh.

It's RMS being RMS. I think he's ridiculously dogmatic and unpractical, but you can't be surprised by this - he has his ideologies to push with fervent absolutism. I doubt he's all that concerned about the market share of his text editor.

If the goal is to encourage people to use GNU software and potentially even migrate to a full GNU system, I find this policy counterintuitive. It comes off as needless and antagonistic and it pushes me further away from GNU and towards free software that's not so tangled up in rigid philosophies, or worse, proprietary software.

Then, by all means, go use whatever software you want.

There's a place for ideological purists in software and I for one am glad RMS is around.

Did you expect anything tasteful or coherent from RMS?

> It comes off as needless and antagonistic

That's because that comes directly from the commercial companies rulebook. Apple (for example) will not make an application that runs better on Android or Windows than on one of its OS.

It would not be beside any of the big brand to remove something that was working before just because that remove a tiny bit of interest in their own platform. That makes cruel business sense ... and they are also hated for it when it happens.

If you discover Emacs on macOS, and like among other things the multicolor feature, then decide to try the Full GNU Experience™ and find that that feature is not supported on the flagship (!) GNU product, well, then maybe you’ll be back to macOS after all.

Let’s not forget that thanks to its libre licensing this is a strategic issue, but not a technical one – recovering the removed features on macOS is a few patches away.

Thank you for this. It validates and reaffirms my hate of GNU.

GNU is not UNIX, and no amount of "freedom" peddling changes the fact that it purposely violates UNIX principles. The only thing that could change that is their code (for example ditching info in favor of man pages, removing the z option in GNU tar, or dropping --long-options), and that's one thing they'll never change. I'm so glad I don't have to put up with the likes of Stallman "setting me free" by removing features GNU/Linux doesn't support.

Is there any non-dead UNIX that doesn't, nowadays? The BSD tar also has -z, as does SmartOS.

As much as I enjoy "cat -v considered harmful", it seems the battle is lost for UNIX itself.

http://harmful.cat-v.org/cat-v/

At least on FreeBSD, I'm on BSD (don't have to use GNU), and on illumos / SmartOS I'm on AT&T System V release 4.0. As long as those alternatives exist GNU holds no power over me and provides no value that I care about, or need. Both BSD and SmartOS are free software.

Remove z option in tar? Where did that come from?

From the fact that tar is a tape archiver, and according to the UNIX philosophy of "do one thing and do it well" it should empathically not dub as a (de)compressor. GNU implements tools inside of other tools. Emacs is a perfect example if that.

GNU didn't originate from a unix mindset. You should know this.

That doesn't mean their software is bad.

Also, Emacs is incredibly useful, and one of the best general-purpose text editors out there.

GNU didn't originate from a unix mindset. You should know this.

I do and oh-how-right you are. What I have major difficulty with is comprehending why people like it, and why they tolerate Stallman's nonsense when there are alternatives. The "rip it all out because it's not ours and re-invent everything just because" attitude is so fundamentale broken.

As somebody who does tolerate Stallman's nonsense, I can tell you why: It's because some of his software is really good. Like Emacs. I'm willing to bet that you're a VI user, but for us Emacs users, there really is no substitute. And if you want a Scheme package, Guile is a really good one (although it's not as efficient as some of the compiled schemes): Andy is doing a great job with it.

There are other examples, like tar (I know you would disagree, but dammit, GNU tar is so useful). When there isn't, or Stallman deliberately cripples his software, there are usually alternatives (clang, etc.) which we use, unless "we" are FSF people. Which most of us aren't.

Yes, his attitude is somewhat broken, although I understand why it exists. Also, he's not quite as NIH as you seem to think: There are several cases where he advocates use of software that isn't his own (heck, he advocates clang, or at least has no problem with it).

Also, I have no objection to long options, or to utilities that are a little bit richer (just so long as they still interoperate, and you can still use the standard options, which is usually the case).

I'm willing to bet that you're a VI user,

And you'd win that bet. Not even a vim user (except on Amiga), but straight vi. Why? Because vi was always there when I needed a text editor, and by learning vi, I automatically learned ed, sed, and ex. All of a sudden, I could write multi line sed programs.

Hey, I get it. I've always have the sneaking suspicion that VI users are way more productive at actually editing. But I know for a fact that they don't have the extensions that make editing dynamic languages (especially lisp) in Emacs so efficient. And there's no use learning another editor just to write C: What do you think I am, and IDE user?

In that case you mean option -x not -z.

Either way, there are several philosophies and schools of thought. Many of them yield good results in different situations. "Do one thing..." is not the same as "do _only_ one thing..." and there are exceptions to the rules and _we_ made the rules so _we_ can/may change them.

Sticking to rules when they don't make sense is stubbornness and locks one in a local maximum.

Using a dedicated (de)compressor and then piping that as input to a tape archiver makes perfect sense to me:

  tar cf - file | xz -9evc > archive.tar.xz

  xz -dvc archive.tar.xz | tar xf -

tar is a utility for creating and extracting .tar and .tgz files.

No, gzip compressed tape archive has nothing to do with the tape archiver or the archiver format. Pipe the format to stdout without using compression and then it should be pretty obvious. This isn't Windows, Atari TOS or AmigaOS where archivers like pkzip and lha or lzx are also (de)compressors: that is precisely why on UNIX, gzip, compress, bzip2 or xz can only compress one single file and aren't archivers. They're dedicated (de)compressors. cpio, ar, pax and tar serve as dedicated archivers.

If it's a tape archiver, why is it allowed to write to disk? Check and mate.

tar isn't allowed or disallowed to write to disk -- f specifies a device, and that device just happens to be a file on a filesystem. Since everything on UNIX is a file, even a tape drive, even a huge 6,000 tape silo with 128 tape drives is multiple files under /dev/rmt/, this does not violate the principle.

To put this into perspective for you, you could use the block device /dev/dsk/c0t0d0s2 as a tar file to write a tape archive to:

tar cvf /some/path /dev/dsk/c0t0d0s2

The manual page for tar clearly states that tar is for tape archive manipulation:

  BSDTAR(1)                 BSD General Commands Manual                BSDTAR(1)

  NAME
       tar -- manipulate tape archives

Tape.

Your statement is an indication that what you really need is to read AEleen Frisch's Essential System Administration so that the UNIX concepts would sink in, because if you're making such statements, you're just not there yet.

I've been using unix since 1992, starting with ultrix, then going to sunos, netbsd, solaris, linux, tru64, osx, and I think aix was in there somewhere too.

But how much have you really learned? And were you an end user or a system administrator? I work with people who have used UNIX for 20-30 years and still don't understand why configuration packages should automatically (re)start a service upon upgrade, stop the service before removal, and start it upon initial install of the configuration package. 30 years of using all kinds of UNIX operating systems and they haven't learned a thing beyond being an end user. And some of these people are developers. So the length of usage isn't crucial, but how much one has learned about the subject -- with an understanding of concepts and ideas behind it. I used all of those you list -- but as my breadth and usage deepened, I sought to understand the principles and ideas behind UNIX.

The -z option is just a more convenient way of piping the tarball through gzip at the appropriate time. GNU tar doesn't actually contain its own (de)compressor. You can also get it to use a compression program of your choice.

Seems to be a lot of hate for this policy, but the goal is simply universal interoperability, which is laudible. Otherwise we might as well go back to the days of IE6, since apparently there is absolutely no problem with Embrace-Extend-Extinguish, as long as we can have emojis on our Macbooks.

Edit: I should add that, since it doesn't appear to be a true interop issue, it may not be a sound decision here. I'm defending the rationale for the policy, not this particular application of it.

The goal is "the lowest common denominator", while when making a cross-platform software it makes sense to have features that use the strength of each platform.

> the goal is simply universal interoperability

No, the goal is that "GNU Emacs should never offer people a practical reason to use some other system instead of GNU".

Universal interoperability is just a side effect.

You've got it backwards. Stallman may be disagreeable at times, but he's no fool. It's written this way to address the root cause of interop issues, which are themselves a secondary effect.

Of course he wants people to choose GNU, but most importantly, he wants to preserve people's freedom to choose GNU, which means it must not become a second-class citizen to proprietory additions from Apple, Microsoft, or anyone else. If it's portable to GNU, the issue goes away. He says so explicitly.

And nobody will pick the GNU solution when the non-GNU solution works better regardless of the OS

Though under this wording emacs would theoretically accept a GNU OS-only feature. It just happens that GNU OSes rarely offer extra features that emacs can take advantage of.

This kind of thing is exactly why I will always support and use Mitsuharu Yamamoto's macOS Emacs port (https://bitbucket.org/mituharu/emacs-mac), which has been consistently rock solid and committed to implementing nice to haves on macOS that this sort of political bullshit holds back on official development.

Homebrew tap here: https://github.com/railwaycat/homebrew-emacsmacport

he is the author of the commit http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=934461...

And the commit seems to be in emacs-mac too - https://bitbucket.org/mituharu/emacs-mac/commits/9344612d3cd... (Going by the author date, it was in emacs-mac first.)

Well he seems to have re-enabled colour bitmap fonts at some point on his fork. I'm running his latest emacs-mac 25.1.1 @ head and it supports native emoji.

The strong adherence to "political bullshit" is why such forks are possible.

The Free software movement needs a few extremists like RMS.

Correct me if I'm wrong, but if Emacs was licensed under a more liberal license (MIT, BSD) such forks would still be possible. (Non-free forks would also be possible)

The question is can such licenses alone (without radical copyleft GNU) can sustain the free software movement's spirit.

I side with camp which thinks copyleft is major way to push towards free software.

It comes down to wether you ideologically support idea that software should essentially be distributed with the source code always. (RMS's view).

I think software like LLVM, PostgreSQL, Xorg, Hadoop, etc have shown that you don't need a radical copyleft to push forward free software. You need something better than exists elsewhere, and this kind of behavior from Stallman holds back free software out of fear of bogeymen.

> MacOS users we will always be second-class citizen in Emacs land3.

GNU Emacs is part of GNU/Linux. Why are you surprised that [other OS] is a second-class citizen for a project which already has a clear OS target.

Besides, the guidelines for GNU packages clearly states that GNU packages cannot emphasise features of proprietary OSes. So it's not really the maintainer's fault, it's one of the rules for GNU packages (you can blame the FSF, but you've got to look at it from their perspective).

GNU packages are different from other projects, because they're actually part of an OS. So they have an obligation to support the OS they're a part of more than other operating systems (especially proprietary operating systems).

After using Emacs on Windows for years, including debugging graphics drivers, the only OS with first class support is Linux.

You're lucky. I literally have never gotten Emacs to run properly on Windows.

Here's the diff:

    -          /* Don't use a color bitmap font unless its family is
    -             explicitly specified.  */
    -          if ((sym_traits & kCTFontTraitColorGlyphs) && NILP (family))
    +          /* Don't use a color bitmap font until it is supported on
    +	     free platforms.  */
    +          if (sym_traits & kCTFontTraitColorGlyphs)

https://github.com/emacs-mirror/emacs/commit/9344612d3cd1643...

As a product developer, maintaining a consistent feature set across OSes makes perfect sense to me. It is a struggle to get consistent behavior across different versions of Windows, let alone entirely different OS types.

Some level of consistency is absolutely desirable but I'm not sure that full-on lowest common denominator is the right approach.

On a technical level I totally agree, supporting tweaks and quirks in a codebase is a massive pain in the ass.

That's not the reason that has been given here - there was no claim that the technology was difficult to bring up to current spec. The reason was that non-GNU platforms had better font handling and now that's not allowed for a GNU project.

Consistency isn't the objective though. If there are features on free platforms that don't exist on proprietary platforms, this policy would be no barrier to implementing them.

1) It's perfectly okay (and good) that GNU maintainers do not want to have features that are needlessly exclusive to a given platform.

2) It's perfectly okay (and good) that they want their software to behave consistently across platforms, as otherwise those are not really cross-platform.

3) Coloured typeface are illogical, just use pictures, which is what emoji are. It's fairly easy to insert images into a buffer in Emacs.

> It's fairly easy to insert images into a buffer in Emacs.

Sure and how it is represented in the underlying file? Is this platform independent?

Emoji are just a part of Unicode. As far as I care, I wouldn't mind if Emacs would just render it as [GRINNING FACE U+1f600]

An emoji minor mode that replaces :emoji: strings is one option. Emoji are unfortunately part of unicode, but here the patch is about coloured face, not emoji specifically.

We're not talking about Emojis, but coloured typeface. Emojis are part of Unicode, coloured typeface are not.

Typefaces are not part of Unicode, coloured or not.

Unicode is a list of glyphs, typefaces are sets of shapes which represent glyphs. Emoji are pictures. Coloured glyphs in Unicode, which include emoji, require compliant typefaces to include some shapes that have a preset colour, and this is illogical, as colour is not the property of the shapes of a type, but of the rendered text. This must stop before Mona Lisa makes it into the Unicode.

20 years ago the FSF had some very forward-looking ideas. Now we have the ornery opinion of old men - it was good enough for us two decades ago, it's good enough for you now.

The point of free as in speech and not free as in beer is that the choice you make does not need to be right or wrong by the standards of other humans. Holding back technology because it's not available on "your" platform is just as monopolistic as any corporate entity they have butted heads with.

The point of free as in speech and not free as in beer is that the choice you make does not need to be right or wrong by the standards of other humans.

No, it may be yours, but I'm pretty sure that was never the FSF's point. Not now, and not 20 years ago.

Holding back technology because it's not available on "your" platform is just as monopolistic as any corporate entity they have butted heads with.

- It's not "their" platform, it's free platforms.

- The tech is still available, it just won't be included in their official release. Other MacOS ports are free to use it.

It's not the FSF's point to have freedom of ideas? Then please explain what it's point is. You disagreed but haven't explained why.

If it's not "their" platform then how is it available elsewhere? If other distributors have access and can make it available then it is very much a GNU political standard and not a side effect the technology.

How are those platforms free if existing features have been removed due to politics? I stand by my point, 20 years ago the FSF was a foundation that wanted to make technology available to all - without having to worry about IP ownership. They have removed a feature that was technically sound due to it's status as a commercial work. How am I free to use this if I can only do so in designated zones?

It's not the FSF's point to have freedom of ideas?

Freedom of ideas is supposed to be a given in a free society. The FSF certainly supports it, but they weren't created for the purpose of promoting it.

In any case, your initial statement was that "the choice you make does not need to be right or wrong by the standards of other humans", which is actually the opposite of the FSF's position, which is that some choices (like developing, distributing or even promoting proprietary software) are unethical and should be opposed. That's the definition of making a standard and holding other humans to it.

If other distributors have access and can make it available then it is very much a GNU political standard and not a side effect the technology.

I don't disagree. It's still not their platform, it's all platforms they consider ethical.

I completely disagree with your portrayal of the FSF of 20 years ago. The whole point of the creation of the GPL, instead of using the existing permissive licenses, was to legally enforce the position that the Freedom of the software, not its technical superiority, is the fundamental goal. This is a markedly political position, and one which prevented the creation of many features. Being "technically sound" was never enough to be considered good software by the GNU project.

Your characterization of the concept of freedom is profoundly flawed. You are FREE to reinstate this feature and equally FREE to share the results of your labors with your million closest friends. You are not ENTITLED to tell other people what they ought to work on and what they ought to ship nor are they somehow betraying the idea of freedom by making your life slightly less convenient.

The diff is 6 lines (2 lines of code) and the source is there, you can fork it. Which is more than can be said for Intel (intentionally crippling icc on non-intel chips), Microsoft (UEFI), Apple (their entire OS), or most other companies products. Even after this the FSF is still morally better than their opponents.

,,Let’s sink this in: The Emacs developers deliberately disabled a feature that was working perfectly fine for MacOS users just because it is not available for free systems1. What a daft decision.''

- well, right now, it's just bloating Emacs for the rest of the world. If one needs it on MacOS, I'm sure it can be added it to a personal installation.

It's easy to see this is but one side to the story from the level of emotion in the blog post. Does anyone have more information regarding the decision itself?

The post also misses the second half of the paragraph, which suggests a method to get emoji working again:

  If some symbols, such as emoji, do not display, we suggest to install
  an appropriate font, such as Symbola; then they will be displayed,
  albeit without the color effects.

So instead of using the native font rendering on OS X which they had actually done, they suggest installing a secondary font which doesn't work as well to fix the problem they created by disabling the working font rendering?

Yeah. I'm sure everyone's happy with that answer.

You're being just as short-sighted as the blog author, do you know the reasoning why it was removed in the first place?

It's fairly obvious the second part of the paragraph is a workaround, not a fully fledged solution.

I understand the reason why they did it. I understand your view of why it should be done.

I'd be A LOT more sympathetic if they hadn't been shipping it working for two years. At that point it's a little late to put the horse back in the barn.

Some of Stallmans list seems insane to me. They withheld accurate scrolling until all the other platforms had it? They are crippling font rendering to the lowest common denominator? They don't want background transparency on OS X because what is ostensibly a console program doesn't have it on other OSs?

This is the kind of stuff that "free software" people do that turns off normal people. I do understand some features. I can see why they wouldn't want to use the system spellchecker if they didn't have a spellchecker on other platforms. Very significant features like that that really could divide the platform makes some sense to me.

But breaking font rendering? Making scrolling work worse? Not having some generic cosmetic effects like background transparency? That seems way too dogmatic.

Worse is that Stallmans email seems to imply that some of the things that they held back on OS X should have been available for a while, but no one was keeping track of when the free platforms caught up to parity. Does that mean it's possible that OS X could have supported something to years ago, doesn't have it today, but Linux has had it for a year? If you're going to impose a rule like that you should be tracking it.

I feel like there is some lost perspective here.

> But breaking font rendering?

I would instead see at is making font rendering work equally across platforms.

> Making scrolling work worse?

Again, making scrolling work equally across platforms.

> Not having some generic cosmetic effects like background transparency?

Again, equally.

I am more than a little surprised that this is so surprising to people...it seems rather par for the course for GNU philosophy.

If you truly want to make a platform agnostic piece of software, then you end up limiting yourself to the "lowest common denominator".

People seem to have gotten used to the presumption that if you want to make software, you have to make platform specific versions for the best user experience. Want to write a mobile application? Well the best user experience comes from "native" apps...so you should make one specifically for iOS and then one specifically for Android.

That. Is. A. Huge. Problem. (*at least in the eyes of GNU)

And in principle I agree most of the time. Locked/incentivized eco-systems lead to the dominance of a few "popular" platforms as choosing which platforms to support (as a developer) becomes a function of market coverage. This has been demonstrated time and time again for better and for worse...although usually the latter.

So yes, GNU can be kind of extreme into their adherence to their core philosophies...but, honestly, I don't think this is a "fight" (so-to-speak) that can be made with half measures and exceptions.

Isn't it funny how it is the Mac OS people implementing these changes while the Linux people aren't coming up with equivalents?

And yes, you can have a transparent terminal on Linux, make emoji work, have better scroll, etc

As Mac OS has a corporate entity behind it I don't think it is too surprising that Mac OS is in front...sort of.

> And yes, you can have a transparent terminal on Linux, make emoji work, have better scroll, etc

Well...sure, but it looks like all they did is remove the usage of Mac specific APIs from mainline:

https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00...

So they aren't so much sabotaging Emacs when it is on Mac, they are just refusing to utilize platform specific APIs and tools. Again...see my first comment.

> So instead of using the native font rendering on OS X which they had actually done, they suggest installing a secondary font

Can't you define fontsets on OS X?

> we suggest to install an appropriate font, such as Symbola

It's worth pointing out that this is not the official 'Apple Color Emoji' font, so it will always lag behind Apple's implementation. That, and have completely different (IMHO, ugly) artwork, which can be a real issue

http://www.npr.org/sections/thetwo-way/2016/04/12/473965971/...

http://samedaytranslations.com/blog/lost-in-translation-emoj...

Arguably, your NPR link backs-up the decision. The fact that Apple's emoji's often diverge considerably from the Unicode standard (and set their own, divergent emotional meanings) is a pretty good argument --- for an avowedly cross-platform app such as Emacs --- to maintain consistency across operating systems.

Is it really Apple's font? I believe WhatsApp on Android uses the same. I guess everyone identifies them as Apple's because WhatsApp is not popular in US. I find it way uglier than Google's, too much detail makes them unusable at small sizes.

Anyway I find emoji worsen the communication. There was a time where I could just use :) when I was smiling and :D when really laughing. Now there's so much different smiling variants that you have to use at least 3 laughing-with-tears to convey even a little amount of joy so the other side doesn't think you're just dismissing them with a normal non-laughing smile.

PS what's going on with scrolling in the second link?

Yes, it is Apple's artwork. While Apple might have licensed it to some third parties, I'm more inclined to believe that they turn a blind eye to others using it 'inappropriately' because it still plays in their favour.

I tried to hunt it down, but the trail went cold at a message [1] in which YAMAMOTO Mitsuharu refers to an unspecified "discussion about the inclusion of the Mac port". My best guess is that a broader policy decision about not supporting Mac-specific features in mainline was made a while ago, and this was something that slipped through in a bigger merge.

[1] https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00...

Thank for this! Good piece of detective work.

> We are not welcome, and never will be.

It's quite silly that the the author of this post thinks non-free support was a top priority for the free software foundation.

Especially when the emacs homepage explicitly is anti-nonfree systems.

You do have the freedom to change Emacs! You can fork it and create "MacEmacs". You probably only have to change a few lines to get it working again.

Not even that; such a fork already exists (as mentioned elsewhere in this thread).

I wish there was a way to force other applications to disable color emjoi.

There is a special char to disable colorful emoji but seems no way to deal with the font issue.

FSF policy is that GNU software should not have features that will only work on non-free operating systems. The decision to remove multicolor glyph support was made on that basis.

The FSF don't want to make their software better on non-free operating systems which, given their goals, doesn't seem particularly unreasonable to me.

"Therefore, when someone implements a useful new feature but only for a non-GNU system, we do not accept it that form."

Users of non-GNU systems that use GNU software: the FSF is actively trying to make your life more difficult.

Just as if you don't agree with Apple, you are welcome to use the alternatives. If you don't agree with GNU, you are welcome to use the alternatives.

That's exactly how this is going to go down, at least in my case.

Well if you'll switch away from Emacs because of coloured typeface, they you're not using Emacs at all anyways, so farewell.

More like, you chose to make your life more difficult by using free software on non-free OS.

Yeah, kind of true. But Apple not letting others implement iMessage is pretty similar. (I'm sure I could come up with examples for almost every other tech company as well.)

I admit it feels weird that GNU is doing it, since the others can be explained by them wanting to make more money, and this can't. But I guess we should be as understanding of them trying to "win" the thing they want (software freedom, defined as they choose) as we are are of companies trying to "win" (money).

Emojify[0] provides all the emoji support I seem to need on both Ubuntu and macOS. It uses non-proprietary emojis though. If that's unacceptable, it can take arbitrary directories for emojis[1].

I must say, Emacs still runs better on macOS than Xcode does on Linux.

[0]: https://github.com/iqbalansari/emacs-emojify

[1]: https://github.com/iqbalansari/emacs-emojify/issues/19

Seems to use EmojiOne, which is all the emoji you could need.

If you want to help adding multicolor fonts to free platforms:

https://wiki.dequis.org/notes/emoji/

https://lists.x.org/archives/xorg-devel/2015-August/047175.h...

The last time Emacs came up here, there was some discussion about Stallmans obsession with free OS purity and some separately-maintained macOS releases were suggested https://news.ycombinator.com/item?id=12832486

These multicolored fonts can cause problems. E.g. firefox on linux was at one point rendering the unicode char "black right pointing triangle" as light blue for me despite the font and text around it being black! Can be fun for some, but not if you intend it to look like the text font! This character was in unicode since 1993 long before emoji existed and now we can't even insert a simple triangle in text without being certain it won't look ridiculous on some people's screens.

http://www.fileformat.info/info/unicode/char/25b6/index.htm

Does anyone really need colored emoji in Emacs? It's a programmer's editor.

I can imagine having a debugger or repl open in an emacs buffer, which could be printing out arbitrary strings, which could include emoji. Though non coloured glyphs would be fine in that case.

Also, people use emacs for all kinds of crazy stuff, like IM and email and so on ...

In my day we did all our programming with uppercase letters. Code should be congruent to speech, which does not have letter case. Best practices dictate that identifiers and keywords should never differ only in case. Thus as a programmer I have no need for lower case letters to do my job.

Unfortunately the "normies" won this battle and now I have to deal with the complexity of pressing the Shift key all the time.

A colour emoji font is available for Linux [1][2] so it doesn't really make any sense to disable the feature on macOS.

[1] http://www.omgubuntu.co.uk/2016/03/enable-color-emoji-linux-...

[2] https://github.com/eosrei/emojione-color-font/releases/

That only appears to work in Gecko-based applications, such as Firefox.

There are actually a couple now. They currently only render in Gecko apps (though apparently it's possible to get them working in Chromium apps now, too). There's a bug filed in FreeType[0] to support SVG-in-OT fonts like this one, but no implementation yet.

I believe that having this implemented in FreeType would be sufficient to get it to work in GTK3 Emacs; not sure about plain X toolkits.

[0]: https://savannah.nongnu.org/bugs/?46141

And here i can't grok the appeal of emojis outside the tween girls segment...

Seems like they are generally popular: http://www.adweek.com/news/advertising-branding/infographic-...

Once more i find myself worried about the "positive" feedback loop found in mass media, marketing, and popular culture...

Get off the high horse

Different people like different things. 1337-speak and obscene levels of abbreviation largely came into being as SMS and text in-game chat were popular because, for a lot of people, spelling out words was much slower (or costly). The former mostly faded whereas the latter is still useful for twitter and people who actually still do SMS due to restrictions

Emoji (and emoticons before them) are similar. It is a way to convey an emotion or have a bit of fun in a concise manner. Some people like to type "That is hilarious". Others will type "LMFAO". And others still will put a pacman that is laughing. All convey the same message just in a different way.

Forget GNU making a point, maintenance wise having several versions of your program with several different features could easily become hell. As these coloured smilies grow additional features, get bugs, etc - Emacs for OSX begins to fork. You then have divided developer time, with typically one fork eventually dying due to lack of funds.

Apple users: Take the temporary pain to protect your future.

I started poking around the emacs mailing list archives looking for drama, and found some messages from this month from RMS getting nervous about the idea of removing support for windows 9x.

That's great! Have you got a link?

https://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00... https://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00...

From what I read, they may look at removing support based on user agent strings which is a terrible idea. Many websites don't support browsers outside of Firefox, MS, Chrome and Safari recent releases, which is why people often hard code their user agent string.

Still, it's great to see them take their user base so seriously!

Feature parity across platforms makes it easier to develop and debug by removing platform-specific corner cases (of which there are already quite enough in Emacs). My init.el makes decisions based on which windowing system (if any) it's running on because some features work and some don't depending on the machine I'm on. I wish it didn't have to.

Can you say: “U+1f4a9 U+1f32a”?

Those of you complaining about RMS's curmudgeonly demeanor, perhaps you would rather be using Apple iEmacs™ and “Microsoft Visual Emacs 2013”, with about the same freedom as you have with macOS / iOS, Android, TiVo, etc., which would play about as well together as ntfs on mac and hfs+ on linux? (or maybe that alternate universe would be Google Mosaic on FranklinOS?). While you're at it, you should thank the couterpointedly curmudgeonly jwz that Emacs is not tty only, and you have at least one viable non-corporate(-ish) browser choice.

Or you could just run emacs in your iTerm. Or you could get all the big software pimps (Apple, Microsoft, Google, Adobe, and maybe the W3C) to agree on a good (please not bitmaped) format, then patch Freetype, again. But I really hope it's already being worked on? I'm sure Emacs will work with it then.

My immediate reactions after reading this:

1. Why would you even WANT this?

2. Find this unacceptable? Then recall what Apple did to Logic and Final Cut Pro users on Windows.

I wish all emojis just disappeared. They're stupid, don't add any value, waste unicode space and developers' time.

> waste unicode space

The desirability of emoji aside, Unicode has plenty of space for this. The bulk of Unicode code points are CJKV (Chinese, Japanese, Korean, and Vietnamese ideographs) characters. Compared to that, a few emoji outside of the BMP don't really amount to much.

In fact, I am under the impression that the popularity of emoji had an unintended benefit. It seems to have contributed to a much better support of non-BMP¹ Unicode characters across the board. Until the extended emoji set came along, most characters outside of the BMP where fairly specialistic or extremely regional, so bugs didn't show up as fast as they do now. It used to be a tiny miracle of you managed to view a PDF containing non-BMP characters properly, nowadays that is just how things work.

1: https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilin...

> They're stupid

That's literally just your opinion, users find them useful and convenient.

> don't add any value

1. they provide user value, that's why they were integrated in smartphones in the first place

2. they provided significant technical value in forcing developers to correctly handle astral codepoints, which they previously had no incentive to. Case in point, MySQL only added support for astral characters (at all, not even correct handling just storing them) in 5.5.3 in 2010, the same year emoji were added to Unicode and about 2 years after emoji were added to iOS

The new crop of "variable" emoji is doing the same thing with composite grapheme clusters (aka that codepoints don't map 1:1 to user-visible "characters")

> waste unicode space

Utter bullshit.

As of Unicode 9 there are 1085 "emoji" (including back-specified dingbats and the like going back to Unicode 1.0, according to current specifications Unicode had 139 emoji in 5.2, before japanese emoji were formally added in 6.0) in a codespace of 1114112 with 128237 allocations as of 9.0.

By comparison, the Tangut block added in Unicode 9.0 contains 6125 codepoints, and the separate Tangut Components block contains an additional 755. There are no extant Tangut users and we have no knowledge of the script having been used after 1502.

> developers' time.

Tough shit?

It is a strange interpretation of freedom, if you are free to run the software how you want, except if RMS disapproves your OS. I think this way of "defending free software" is rather counterproductive. I say this as a strong supporter of free and open source software and both a Mac and Linux user. I want Linux or any other free operation system to be strong in the market. But this should be reached on features and capabilities, not on limiting software on other operation systems. Fortunately thanks to its open source nature, it should be possible to maintain a branch of Emacs for the Mac which keeps this feature alive. This is where open source is strong.

Yet RMS disapproval of MAC OS does not make Free software less free. The fundamental rights of free software are still preserved:

"the users have the freedom to run, copy, distribute, study, change and improve the software"

Yes, those rights are not limited. Still I find it a strange thing, that working features are removed, because they affect only "disapproved" operating systems. I don't like it, if technical questions and political ideas are too strongly mixed.

Just ask your money back!

Emacs-Gud Will never support llvmdb either... sad...

sigh.

Yep.

Somebody needs to implement this. If not for the practicality, just to irritate Stallman.

Not true. They've repeatedly said they will happily accept patches for lldb. There was a thread on the devel email list just a week or 2 ago. No one has stepped up yet.

Get off your high horse, Richard: In fighting software that restricts its users and doesn't respect their freedoms, you've become the thing you despise.

Oh, and the rest of the Emacs team: Don't think you're getting away with this, either: it's despicable.

I may well actually work on exporting the GCC AST in protest.

> In fighting software that restricts its users and doesn't respect their freedoms, you've become the thing you despise.

GNU Emacs is still under the GPL. Feel free to modify it to re-add the feature that was removed. The only reason you have the freedom to do that is because of Richard Stallman's "high horse".

> Oh, and the rest of the Emacs team:

Reminder that GNU Emacs is part of GNU/Linux, and thus features are developed against GNU/Linux first and other operating systems later. In addition, it is part of the requirements of GNU packages that they not encourage users to use proprietary operating systems. This includes having features on proprietary operating systems that do not exist on free operating systems.

Surely you see why that's important, right?

> I may well actually work on exporting the GCC AST in protest.

Have fun using the freedoms that the GPL grants you while protesting against the movement that caused free software to exist in the first place. Hypocrisy is so much fun.

>Reminder that GNU Emacs is part of GNU/Linux, and thus features are developed against GNU/Linux first and other operating systems later.

Yes, but that's terrible. Making your software demonstrably worse for a subset of your users isn't acceptable. If any other group did this, you'd likely be enraged. What if .NET Core dropped support for an API on Linux? Would you really be comforted by the people saying: "it's open source: fork it if you want the features back"?

>Have fun using the freedoms that the GPL grants you while protesting against the movement that caused free software to exist in the first place. Hypocrisy is so much fun.

I have no wish to protest GNU as a whole. I do wish to protest the pig-headedness of RMS and others, which keeps us from actually moving Emacs and other packages forward. Not allowing Emacs to touch the GCC AST isn't protecting freedoms: it's needlessly obstructive, and utterly pointless.

It's the same situation here: not patching in functionality until there's cross-platform support? Okay. Actively removing functionality that doesn't work cross-platform (yet)? Not cool.

> Making your software demonstrably worse for a subset of your users isn't acceptable.

Which is why they removed a feature after realising it made GNU/Linux users have a worse experience than on other platforms.

> What if .NET Core dropped support for an API on Linux? Would you really be comforted by the people saying: "it's open source: fork it if you want the features back"?

Yes, because I guarantee that someone would fork it. Just like someone already has a fork of Emacs that is macOS-friendly. And it probably already has the patch reverted.

> Actively removing functionality that doesn't work cross-platform (yet)? Not cool.

It was a mistake for them to merge it, and they're fixing their mistake. That's how I see it. GNU packages have to be "portable to GNU", specifically all of their features have to be portable to GNU. A feature which is not portable to GNU is not a feature that the package should have -- otherwise you're both encouraging people to use proprietary operating systems as well as fragmenting your userbase.

Can you just recompile it with that feature enabled?

Probably not. I won't be surprised if someone doesn't add a patch though. From NEWS:

   On the OS X Cocoa ("Nextstep") port, multicolor font (such as color
   emoji) display is disabled.  This feature was accidentally added when
   Emacs 24.4 included the new Core Text based font backend code that was
   originally implemented for a non-mainline port.  This will be enabled
   again once it is also implemented in Emacs on free operating systems.
   If some symbols, such as emoji, do not display, we suggest to install
   an appropriate font, such as Symbola; then they will be displayed,
   albeit without the color effects.

IMO: this is the least important thing of this week to me. It certainly doesn't deserve the "Emacs Hate MacOS" subtitle.

If you've been shipping a feature for two years it's a little too late to pull it and say "oops we didn't mean to give you that yet".

Yep: git revert 9344612d3cd164317170b6189ec43175757e4231

For all those who constantly whine against decisions of RMS, you can atleast go start a fork of emacs if you wanted. Unlike macOS which is commercial jail , you have to beg for years for any bug fix/feature you want, and even then it won't be implemented.

Someone has to be ideologically pure, in a world of jailed software.

delete (this comment)

This is probably a hint that the title can be reworked.

atom probably has emacs emulation

Emacs has gone downhill ever since RMS removed this emoji from the ultra-hot screen management package source code.

http://donhopkins.com/home/archive/emacs/skull-and-crossbone...

Absolutely sickening.. Stallman needs to leave the crib and join the real world.

Reply on news.ycombinator.com