Eric,

If you use a compose key on Linux, chances are that ellipsis is bound to `compose-.-.`. I don't think the two-point ellipsis is typically bound to anything.
On Emacs, input methods are easily extensible, but if you use Company Math to write unicode symbols (which is an autocompletion-based approach), which I've never figured out how to configure, then you will have ellipsis bound on `\ldots`, but no two-point ellipsis.

If someone has insight about why the syntax was chosen to be two dots rather than three, originally. I still think that it could inform this discussion.

On Fri, Feb 25, 2022 at 2:49 AM Eric Seidel <eric@seidel.io> wrote:
I agree it's strange to use a three dot unicode ellipsis but a two dot ascii ellipsis.

Joachim, as someone who likes to use unicode in Haskell, is there a reason to think that the two dot ellipsis would be more cumbersome to type? Maybe emacs unicode modes or something?

On Tue, Feb 15, 2022, at 14:37, Vladislav Zavialov (int-index) wrote:
> -1 from me.
>
> The proposed (… U+2026) is three dots, so it could be the UnicodeSyntax
> equivalent to three ASCII dots. However, Haskell’s range notation is
> two ASCII dots.
>
> Personally I use three dots to indicate omissions in the source text, like this:
>
>   f x = …
>
> So that is the meaning I’d like to reserve for three dots, not ranges.
>
> The proposal could use ‥ U+2025 instead.
>
> - Vlad
>
>
>> On 15 Feb 2022, at 14:27, Joachim Breitner <mail@joachim-breitner.de> wrote:
>>
>> Dear Committee,
>>
>> Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov,
>> and I’m shepherding it myself.
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/477
>>
>> https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/477-unicode-ellipsis.md
>>
>> This is a very small proposal that lets GHC understand the nice Unicode
>> syntax `…` in places where in ASCII world we have .., under
>> -XUnicodeSyntax.
>>
>> I am fond of Unicode in general, and I expect that users of -
>> XUnicodeSyntax expect this to work, and therefore recommend acceptance
>> of this proposal.
>>
>> Cheers,
>> Joachim
>>
>>
>>
>> --
>> Joachim Breitner
>>  mail@joachim-breitner.de
>>  http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee@haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee@haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee