Add support for smooth cursor for emacs 31

[mkvoya]

The smooth cursor feature adds native cursor movement animation for macOS. The feature extends ksqsf's implementation to support more (if not all) kinds of cursors and cursor blinks.

[daviderestivo]

@mkvoya would you be interested in opening a PR for https://github.com/daviderestivo/homebrew-emacs-head as well :)?

[d12frosted]

Hey @mkvoya

Thanks for PR. Two questions:

1. Where did it come from? Are you the original author?
2. Did you propose it to upstream? If yes, can you share a link to communication? If not - why? :)

As a rule of thumb I try to minimise amount of included patches and I prefer people to contribute to the upstream, so wider audience can enjoy improvements. Besides, practically I lack time and knowledge to support non-trivial patches.

[ksqsf]

Hi, I'm the original implementor of the idea, and the original patch is in my own Emacs fork (ksqsf/emacsmoe#7). Recently @mkvoya improved it greatly, sent it to me, and we thought it might be a good idea to share it with greater audience.

1. @mkvoya can be considered a co-author at the very least, or the primary author in its current form at best.
2. No, this feature will not be accepted by the upstream, because it cannot work on "free operating systems". So there's no communication, since we didn't even try. :)

(Also, to the best of my knowledge, it will be quite difficult to implement it for Linux. Maybe a fun challenge, but the gain does not justify the effort. Personally I think we will not see this any time soon on Linux.)

Besides, practically I lack time and knowledge to support non-trivial patches.

This is a very valid concern. My suggestion is to apply this patch to Emacs 30 (rather than HEAD), so that the maintenance burden is minimal. Unfortunately, we cannot guarantee timely updates to the patch, either.

[mkvoya]

The burden of maintaining the patch should not be large, as it involves only code additions, and the patch is quite stable in my nearly two months of daily work. I can maintain the patch if necessary since I am using it myself. By the way, @ksqsf would you please share your email address so that I can list you in the patch's co-authors?

[ksqsf]

The burden of maintaining the patch should not be large, as it involves only code additions, and the patch is quite stable in my nearly two months of daily work. I can maintain the patch if necessary since I am using it myself. By the way, @ksqsf would you please share your email address so that I can list you in the patch's co-authors?

gmail beginning with justksqsf

[d12frosted]

Thank you for this contribution - I really appreciate the work you've put into it.

I'm genuinely torn on this. I love providing neat features to macOS users, and if upstream won't accept these improvements, it seems natural to offer them through Emacs+. However, my 10 years of experience maintaining this project has taught me what happens to complex patches that remain outside upstream: contributors come and go, patches break, and I simply don't have the capacity nor desire to maintain them indefinitely.

On the maintenance burden:

Whilst I don't doubt the patch's current quality or stability, two months of testing is unfortunately quite short compared to Emacs's development cycle. Even pinning to Emacs 31 only defers the problem - users will eventually request Emacs 32 support, and at some point the patch will likely break. I've seen this pattern repeatedly; even our minimal no-titlebar patch has broken upstream more than three times over the years.

A potential path forwards:

I've been thinking about Emacs+ extensibility more broadly (patches like this, plus custom icons), and I'm increasingly convinced we need a proper mechanism for applying local/remote patches. This would let me keep the core formula simple (Homebrew generally discourages excessive options, and I've already implemented several tricks to manage what we have) whilst still supporting community innovations.

My proposal: I'll develop a custom wrapper that makes it straightforward to apply additional patches, and then we can document your patch in the README as a community-maintained option. This way, interested users can easily adopt it, but without committing the project to long-term maintenance of code that may not survive upstream changes.

What do you think of this approach?

[d12frosted]

ok, this is what I mean - #851

I have something like a design document that I can share if someone is interested, but the rough idea is pretty simple;

implementation will come only after I deal with #783 as both Emacs Client.app and #851 both require to change a few formula internals and I don't want to deal with conflicts

[mkvoya]

The mechanism for additional patches is great. Thanks for your invaluable effort!