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.
