On Thu, Aug 11, 2016 at 7:36 AM, Kazunobu Kuriyama
<kazunobu.kuriy...@gmail.com> wrote:
> Hi Tony,
>
> 2016-08-11 10:05 GMT+09:00 Tony Mechelynck <antoine.mechely...@gmail.com>:
>>
>> On Thu, Aug 11, 2016 at 1:39 AM, manuelschiller.pimail via vim_dev
>> <vim_dev@googlegroups.com> wrote:
>> > On Wednesday, 10 August 2016 02:35:04 UTC+2, Tony Mechelynck  wrote:
>> >> Manuel:
>> >>
>> >> In the past there have been "unofficial" features published as patches
>> >> which remained outside of the "official" Vim repositories but publicly
>> >> available, sometimes for years, before Bram finally decided to take
>> >> them in. The +conceal and +float features, now part of mainstream Vim,
>> >> are two examples of such which I've seen remain "unofficial
>> >> third-party patches" while several successive minor versions of Vim
>> >> came and went.
>> >>
>> >> Maybe you could publish your patch (as a patch that could be applied
>> >> by running "patch -p1 ligatures.diff", or something like that, at the
>> >> top level of a Vim repository clone), upload it somewhere on github or
>> >> vim.org or wherever, and let anyone use it who wants. Then after
>> >> letting it bake there for some time, we'll know better how popular it
>> >> is. Assuming that the new version currently being made ready will be
>> >> called Vim 8.0 and be released before the end of 2016, we might then
>> >> have a poll about your patch when getting ready for 8.1 or 8.2, and
>> >> let's hope that that will arrive long before 8.0 is at patchlevel
>> >> 8.0.2200 — Vim 7.4, whose original release was almost exactly three
>> >> years ago, seems to have been quite successful in its own way.
>> >>
>> >> If you choose to go this way, please set it up so that it could be
>> >> disabled at compile-time (I mean, place the changes  behind #ifdef
>> >> FEAT_LIGATURES or something equally distinctive), it will help it
>> >> being accepted into the main code, since anyone not wanting it would
>> >> be able to disable it at compile-time — and similarly, an option (to
>> >> enable or disable it at runtime if present at compile-time, let's say
>> >> in the vimrc or gvimrc before starting the GUI) would IMHO be equally
>> >> welcome.
>> >>
>> >>
>> >> Best regards,
>> >> Tony.
>> >
>> > Hi Tony,
>> >
>> > you (and others) are making very good points here, and I appreciate the
>> > feedback.
>> >
>> > Following your suggestion, I have created a vim fork with a branch for
>> > this kind of development:
>> >
>> > https://github.com/manuelschiller/vim/tree/glyphs
>> >
>> > Currently, it contains two patches:
>> >
>> > - gui_gtk_x11: force shaping one character at a time for ASCII glyph
>> > cache
>> >
>> >   This one does what it says. It'll get fonts like PragmataPro or
>> > Hasklig
>> >   working in gvim without ligatures, and without the drawing caveats we
>> >   discussed earlier. I imagine that this patch might make inclusion in
>> > vim
>> >   quite a bit earlier (I'd hope soonish, but that may be wishful
>> > thinking)
>> >   than the next item, because I do not think it does anything
>> > controversial.
>> >   If you'd like to see style improvements etc., please let me know, I'm
>> >   happy to accomodate you. :)
>> >
>> > - gui_gtk_x11: enable poor man's ligatures
>> >
>> >   This one is the bit that enables ligatures, and will require a couple
>> > of
>> >   iterations on my side before it's ready to be considered for
>> > inclusion.
>> >   (For example, I'd like to make the set of characters that disable the
>> >   ASCII glyph cache user-configurable, and I have to find out how C code
>> >   gets access to variables inside vimscript...) For the curious, this is
>> >   something they might want to try out, and give feedback...
>> >
>> > I would again like to thank you all for the friendly and constructive
>> > atmosphere. And let me know if you have suggestions, please!
>> >
>> > Manuel
>>
>> Hm. gui_gtk_x11.c is of course only for gvim with GTK GUI running on
>> Linux-X11. GTK2, and now even GTK3 ("new in 8.0"), are of course the
>> preferred GUIs for Vim on Linux these days, and for X11 in general
>> (though a few older ones are still supported IIUC); however, what
>> about other flavors of gvim? Such as gvim for Windows, and, maybe
>> worse, MacVim (gvim for Mac-Cocoa IIUC), of which I think, but am not
>> sure, that all its sources are included in the current "official" Vim
>> sources. Do Windows and/or Mac have similar fonts? Won't they feel
>> left out? The mechanisms to implement the corresponding Poor Man's
>> Ligatures will of necessity be different because we're at too low a
>> level for cross-platform programming to be possible all the way. Maybe
>> you don't have the necessary OSes to build and test the corresponding
>> gvim versions (neither do I) so it might perhaps be useful if some
>> Windows Vim developer(s) and some Mac Vim developer(s) joined you on
>> this project.
>>
>> I'm cross-posting on the vim_mac group because Mac people might (or
>> might not) be interested; but this thread was started on vim_dev. Mac
>> developers: please refer to vim_dev for the discussion's history.
>
>
> As for Mac-Cocoa, I haven't succeeded in building it with recent OSXs last 6
> years. That build is automatically disabled at configure.

My mistake. The various Mac GUI systems leave me stumped, I even had
to do research before i knew whether Cocoa came before or after
Carbon. That tells you.
>
> As for MacVim, they've already merged a patch which enables ligatures into
> their repo. It was almost a year ago ( Aug 24, 2015).

Ah, OK.
>
> So...it's us who was left out.
>
> In my understanding, they made ligatures possible by tweaking an attribute
> of a class of character strings called NSAttributedString [2] (Actually,
> they are doing that through the Core API, not Cocoa).
>
> FYI, the latest nightly build of iTerm2, which is one of the popular
> terminals on Mac and seen a lot of Vimmer on console using the editor on it,
> starts supporting ligatures by a similar way.
>
> Rendering ligatures is done by using some information from font files.
> Therefore, as can been seen in two instances above, people usually rely on
> an rendering engine in use for that chore.
>
> In other words, since creating a new shaping module for the purpose of
> cross-platform is very tough, there's no feasible solution other than
> relying on GUI's rendering engines.
>
> As for Windows stuff...anyone?

Not me… but I sure wouldn't want users of Windows 15 (or something) to
someday come hollering after Bram, saying "Why were we left out?" ;-)
>
> Best regards,
> Kazunobu
>
> [1] https://github.com/macvim-dev/macvim/pull/56
> [2]
> https://developer.apple.com/library/ios/documentation/Cocoa/Reference/Foundation/Classes/NSAttributedString_Class/index.html#//apple_ref/doc/c_ref/NSLigatureAttributeName
>>
>>
>>
Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui