Loading ...
Sorry, an error occurred while loading the content.

Some TOhtml issues

Expand Messages
  • ZyX
    1. When using concealed characters color that extends past the end of line (i.e. diff color) shows different line end positions:
    Message 1 of 19 , Aug 31, 2013
    • 0 Attachment
      1. When using concealed characters color that extends past the end of line (i.e. diff color) shows different line end positions: http://img-fotki.yandex.ru/get/6704/9151298.3/0_9e202_6394ebc0_orig.png (also attached image 1.png). After inspecting the code it seems that problem is with any multibyte characters, not necessary multibyte character in cchar: script extensively uses things like

      let s:new = s:new . repeat(s:difffillchar, &columns - strlen(s:new) - s:margin)

      for various fillers. Note the `strlen`: it is not correct to use here, strdisplaywidth() is. Note about strchars(): it is not correct because it counts composing characters separately and does not respect fullwidth characters. I also have an emulation of strdisplaywidth() (which though works like if there &ambiwidth is set to single regardless of actual setting) for old vim versions: https://bitbucket.org/ZyX_I/frawor/src/c1683934455928961e93466275cedbcae4ea564c/autoload/frawor/table.vim#cl-4.

      If I set g:html_no_pre it is not better: http://img-fotki.yandex.ru/get/9103/9151298.3/0_9e205_558c48a2_orig.png (1-2.png): highlighting does not extend past the end of line.

      2. With g:html_no_pre=1 empty line does not contain diff highlighting.

      3. Sometimes line does not contain highlighting with g:html_no_pre=0: http://img-fotki.yandex.ru/get/9485/9151298.3/0_9e206_c721f0d3_orig.png (3.png): guess this is because it ends with concealed character.

      4. There is a reason for my formatvim using table with one table row per one line, even though it is very imperfect: too tall characters cause shift: http://img-fotki.yandex.ru/get/9264/9151298.3/0_9e208_cb2ab30c_orig.png (4.png). This is not the first tall character here and diff is thus incorrect. Also note thin black gaps between lines.

      5. When diffing with empty buffer “E749: empty buffer” error is shown: from function tohtml#Convert2HTML, line 15.

      Used 2html.vim: http://code.google.com/r/fritzophrenic-vim-clone/source/browse/runtime/syntax/2html.vim?r=92d11dd5081080db1d9635eb1f88fa2ceb634a53 (with the whole VIMRUNTIME from the same commit of the same repository).

      Used settings: default, unless mentioned otherwise.

      --
      --
      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+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • ZyX
      Also another bug: concealed characters are highligted as regular text if they are not at the start of line and as concealed characters if they are: see 1-2.png
      Message 2 of 19 , Sep 1, 2013
      • 0 Attachment
        Also another bug: concealed characters are highligted as regular text if they are not at the start of line and as concealed characters if they are: see 1-2.png and 3.png or 4.png. In 1-2.png superscripts near x are actually concealed characters.

        --
        --
        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+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Ben Fritz
        ... Thanks, that should be an easy update. That probably never worked right. I wonder if there are other places where strdisplaywidth() needs to be used
        Message 3 of 19 , Sep 3, 2013
        • 0 Attachment
          On Saturday, August 31, 2013 2:24:23 PM UTC-5, ZyX wrote:
          > 1. When using concealed characters color that extends past the end of line (i.e. diff color) shows different line end positions: http://img-fotki.yandex.ru/get/6704/9151298.3/0_9e202_6394ebc0_orig.png (also attached image 1.png). After inspecting the code it seems that problem is with any multibyte characters, not necessary multibyte character in cchar: script extensively uses things like
          >
          >
          >
          > let s:new = s:new . repeat(s:difffillchar, &columns - strlen(s:new) - s:margin)
          >
          >
          >
          > for various fillers. Note the `strlen`: it is not correct to use here, strdisplaywidth() is. Note about strchars(): it is not correct because it counts composing characters separately and does not respect fullwidth characters.

          Thanks, that should be an easy update. That probably never worked right. I wonder if there are other places where strdisplaywidth() needs to be used instead.

          > I also have an emulation of strdisplaywidth() (which though works like if there &ambiwidth is set to single regardless of actual setting) for old vim versions: https://bitbucket.org/ZyX_I/frawor/src/c1683934455928961e93466275cedbcae4ea564c/autoload/frawor/table.vim#cl-4.
          >
          >

          I don't think that's needed in this case because I really don't intend to support really old Vims with the official runtime plugin for the latest Vim; but it should at least fail gracefully I suppose.

          >
          > If I set g:html_no_pre it is not better: http://img-fotki.yandex.ru/get/9103/9151298.3/0_9e205_558c48a2_orig.png (1-2.png): highlighting does not extend past the end of line.
          >
          >
          >
          > 2. With g:html_no_pre=1 empty line does not contain diff highlighting.
          >

          Yes, I'd like to figure out a good way to handle this. I really don't want to resort to using a table, though. At least not if I can avoid it. Tables cause huge performance issues in some browsers if they get to be several thousand rows long; and I do on occasion convert entire files this many lines.

          >
          >
          > 3. Sometimes line does not contain highlighting with g:html_no_pre=0: http://img-fotki.yandex.ru/get/9485/9151298.3/0_9e206_c721f0d3_orig.png (3.png): guess this is because it ends with concealed character.
          >
          >

          I haven't noticed this; I'll need to look into that. Thanks for reporting.

          >
          > 4. There is a reason for my formatvim using table with one table row per one line, even though it is very imperfect: too tall characters cause shift: http://img-fotki.yandex.ru/get/9264/9151298.3/0_9e208_cb2ab30c_orig.png (4.png). This is not the first tall character here and diff is thus incorrect. Also note thin black gaps between lines.
          >
          >

          I struggled with a similar thin gaps problem for a LONG time before I gave up. As mentioned, I *really* don't want to resort to a table. I would love to find a better solution to that. Please anybody let me know if you have any ideas. Design constraint is that TOhtml (mostly) builds one whole line at a time.

          >
          > 5. When diffing with empty buffer “E749: empty buffer” error is shown: from function tohtml#Convert2HTML, line 15.
          >
          >

          That's...interesting. I'm not sure why that ever works. The problem is that line does "windo | if ...." when it should be "windo if ...." (without the |). I guess the default command for windo is :print?

          >
          > Used 2html.vim: http://code.google.com/r/fritzophrenic-vim-clone/source/browse/runtime/syntax/2html.vim?r=92d11dd5081080db1d9635eb1f88fa2ceb634a53 (with the whole VIMRUNTIME from the same commit of the same repository).
          >
          >
          >
          > Used settings: default, unless mentioned otherwise.

          --
          --
          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+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Nikolay Pavlov
          ... line (i.e. diff color) shows different line end positions: http://img-fotki.yandex.ru/get/6704/9151298.3/0_9e202_6394ebc0_orig.png(also attached image
          Message 4 of 19 , Sep 3, 2013
          • 0 Attachment


            On Sep 3, 2013 7:04 PM, "Ben Fritz" <fritzophrenic@...> wrote:
            >
            > On Saturday, August 31, 2013 2:24:23 PM UTC-5, ZyX wrote:
            > > 1. When using concealed characters color that extends past the end of line (i.e. diff color) shows different line end positions: http://img-fotki.yandex.ru/get/6704/9151298.3/0_9e202_6394ebc0_orig.png (also attached image 1.png). After inspecting the code it seems that problem is with any multibyte characters, not necessary multibyte character in cchar: script extensively uses things like
            > >
            > >
            > >
            > >       let s:new = s:new . repeat(s:difffillchar, &columns - strlen(s:new) - s:margin)
            > >
            > >
            > >
            > >    for various fillers. Note the `strlen`: it is not correct to use here, strdisplaywidth() is. Note about strchars(): it is not correct because it counts composing characters separately and does not respect fullwidth characters.
            >
            > Thanks, that should be an easy update. That probably never worked right. I wonder if there are other places where strdisplaywidth() needs to be used instead.
            >
            > > I also have an emulation of strdisplaywidth() (which though works like if there &ambiwidth is set to single regardless of actual setting) for old vim versions: https://bitbucket.org/ZyX_I/frawor/src/c1683934455928961e93466275cedbcae4ea564c/autoload/frawor/table.vim#cl-4.
            > >
            > >
            >
            > I don't think that's needed in this case because I really don't intend to support really old Vims with the official runtime plugin for the latest Vim; but it should at least fail gracefully I suppose.

            It uses strdisplaywidth() if available. Graceful degradation with lesser lines of code would be len(split(str, '\V')).

            > >
            > >     If I set g:html_no_pre it is not better: http://img-fotki.yandex.ru/get/9103/9151298.3/0_9e205_558c48a2_orig.png (1-2.png): highlighting does not extend past the end of line.
            > >
            > >
            > >
            > > 2. With g:html_no_pre=1 empty line does not contain diff highlighting.
            > >
            >
            > Yes, I'd like to figure out a good way to handle this. I really don't want to resort to using a table, though. At least not if I can avoid it. Tables cause huge performance issues in some browsers if they get to be several thousand rows long; and I do on occasion convert entire files this many lines.

            I use p's covering full lines (used to use div's, do not remember why I switched). Table for non-diff is an overkill.

            > >
            > >
            > > 3. Sometimes line does not contain highlighting with g:html_no_pre=0: http://img-fotki.yandex.ru/get/9485/9151298.3/0_9e206_c721f0d3_orig.png (3.png): guess this is because it ends with concealed character.
            > >
            > >
            >
            > I haven't noticed this; I'll need to look into that. Thanks for reporting.
            >
            > >
            > > 4. There is a reason for my formatvim using table with one table row per one line, even though it is very imperfect: too tall characters cause shift: http://img-fotki.yandex.ru/get/9264/9151298.3/0_9e208_cb2ab30c_orig.png (4.png). This is not the first tall character here and diff is thus incorrect. Also note thin black gaps between lines.
            > >
            > >
            >
            > I struggled with a similar thin gaps problem for a LONG time before I gave up. As mentioned, I *really* don't want to resort to a table. I would love to find a better solution to that. Please anybody let me know if you have any ideas. Design constraint is that TOhtml (mostly) builds one whole line at a time.

            My table diff solution is known to hang LTS (AFAIR 17.*) firefox. Others (including latest firefox) are fine; used to check how test with almost four hundred concealed characters (= more then three span's with display property triggered depending on whether line (= container p) is hovered) works in some browsers.

            For this particular case I even format trailing tildas. Though it is not required unless your ultimate goal is to eventually create something like :Format screenshot. Guess it is obvious what should it do.

            > >
            > > 5. When diffing with empty buffer “E749: empty buffer” error is shown: from function tohtml#Convert2HTML, line 15.
            > >
            > >
            >
            > That's...interesting. I'm not sure why that ever works. The problem is that line does "windo | if ...." when it should be "windo if ...." (without the |). I guess the default command for windo is :print?

            :windo accepts bar as its argument. It seems that bar at the start is same no-op as : at the start.

            ---------

            By the way: I found one really crazy optimization technique: the fast cycle determining where region with same highlighting ends may be reduced to exactly two ex commands: :while and :endwhile, this reduced time spend by my formatting function (it normally takes about 90% of total time for large files; the more the greater file is) by almost 30 %:

            As unlike you I use :let's in the cycle it looks like this:

                while curcol<=linelen&&!empty(extend(l:,{'id':synID(clnr,curcol,1),'concealinfo':synconcealed(clnr,curcol),...}))&&!empty(extend(l:,{'nocbreak':f(concealinfo)}))&&id==oldid&&...&&!empty(extend(l:,{'curcol':curcol+1}))
                endwhile

            Even more cryptic if I do not turn off minimizations.

            Will probably once check whether I can automatically transform normal syntax tree into this insanity: seems to be not an impossible task.

            > >
            > > Used 2html.vim: http://code.google.com/r/fritzophrenic-vim-clone/source/browse/runtime/syntax/2html.vim?r=92d11dd5081080db1d9635eb1f88fa2ceb634a53 (with the whole VIMRUNTIME from the same commit of the same repository).
            > >
            > >
            > >
            > > Used settings: default, unless mentioned otherwise.
            >
            > --
            > --
            > 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+unsubscribe@....
            > For more options, visit https://groups.google.com/groups/opt_out.

            --
            --
            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+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Nikolay Pavlov
            ... line (i.e. diff color) shows different line end positions: http://img-fotki.yandex.ru/get/6704/9151298.3/0_9e202_6394ebc0_orig.png(also attached image
            Message 5 of 19 , Sep 3, 2013
            • 0 Attachment


              On Sep 3, 2013 7:04 PM, "Ben Fritz" <fritzophrenic@...> wrote:
              >
              > On Saturday, August 31, 2013 2:24:23 PM UTC-5, ZyX wrote:
              > > 1. When using concealed characters color that extends past the end of line (i.e. diff color) shows different line end positions: http://img-fotki.yandex.ru/get/6704/9151298.3/0_9e202_6394ebc0_orig.png (also attached image 1.png). After inspecting the code it seems that problem is with any multibyte characters, not necessary multibyte character in cchar: script extensively uses things like
              > >
              > >
              > >
              > >       let s:new = s:new . repeat(s:difffillchar, &columns - strlen(s:new) - s:margin)
              > >
              > >
              > >
              > >    for various fillers. Note the `strlen`: it is not correct to use here, strdisplaywidth() is. Note about strchars(): it is not correct because it counts composing characters separately and does not respect fullwidth characters.
              >
              > Thanks, that should be an easy update. That probably never worked right. I wonder if there are other places where strdisplaywidth() needs to be used instead.
              >
              > > I also have an emulation of strdisplaywidth() (which though works like if there &ambiwidth is set to single regardless of actual setting) for old vim versions: https://bitbucket.org/ZyX_I/frawor/src/c1683934455928961e93466275cedbcae4ea564c/autoload/frawor/table.vim#cl-4.
              > >
              > >
              >
              > I don't think that's needed in this case because I really don't intend to support really old Vims with the official runtime plugin for the latest Vim; but it should at least fail gracefully I suppose.
              >
              > >
              > >     If I set g:html_no_pre it is not better: http://img-fotki.yandex.ru/get/9103/9151298.3/0_9e205_558c48a2_orig.png (1-2.png): highlighting does not extend past the end of line.
              > >
              > >
              > >
              > > 2. With g:html_no_pre=1 empty line does not contain diff highlighting.
              > >
              >
              > Yes, I'd like to figure out a good way to handle this. I really don't want to resort to using a table, though. At least not if I can avoid it. Tables cause huge performance issues in some browsers if they get to be several thousand rows long; and I do on occasion convert entire files this many lines.
              >
              > >
              > >
              > > 3. Sometimes line does not contain highlighting with g:html_no_pre=0: http://img-fotki.yandex.ru/get/9485/9151298.3/0_9e206_c721f0d3_orig.png (3.png): guess this is because it ends with concealed character.
              > >
              > >
              >
              > I haven't noticed this; I'll need to look into that. Thanks for reporting.
              >
              > >
              > > 4. There is a reason for my formatvim using table with one table row per one line, even though it is very imperfect: too tall characters cause shift: http://img-fotki.yandex.ru/get/9264/9151298.3/0_9e208_cb2ab30c_orig.png (4.png). This is not the first tall character here and diff is thus incorrect. Also note thin black gaps between lines.
              > >
              > >
              >
              > I struggled with a similar thin gaps problem for a LONG time before I gave up. As mentioned, I *really* don't want to resort to a table. I would love to find a better solution to that. Please anybody let me know if you have any ideas. Design constraint is that TOhtml (mostly) builds one whole line at a time.

              The problem here is not gaps, they are standable. In fact, I have gaps problem with these characters too, though it is different gaps problem (gap between input with sign or line number and adjacent lines). The real problem is incorrect diff, and this is not. Such characters are uncommon (problem should be observed in case font that browser chose does not have required characters), but e.g. powerline has some. In some fonts characters I use for fold markers are absent (I use unicode black triangles: BLACK RIGHT-POINTING TRIANGLE (U+25B6) and BLACK UP-POINTING TRIANGLE (U+25B2)).

              Note the solution I use: record all non-header and non-footer lines into a list: one list for each buffer; and then merge lines adding start, end and separator, adding header and footer only then. This is a workaround for design constraint. It is also a reason I had to add tilde lines I mentioned previously: you MUST have lines with equal lengths if you use this solution.

              I may as well have switched to using container div's or anything else that will allow keeping diff correct under such circumstances, but table is the only solution I know. Well, I can imagine a few based on JS, but I am not up to using it without user request.

              > >
              > > 5. When diffing with empty buffer “E749: empty buffer” error is shown: from function tohtml#Convert2HTML, line 15.
              > >
              > >
              >
              > That's...interesting. I'm not sure why that ever works. The problem is that line does "windo | if ...." when it should be "windo if ...." (without the |). I guess the default command for windo is :print?
              >
              > >
              > > Used 2html.vim: http://code.google.com/r/fritzophrenic-vim-clone/source/browse/runtime/syntax/2html.vim?r=92d11dd5081080db1d9635eb1f88fa2ceb634a53 (with the whole VIMRUNTIME from the same commit of the same repository).
              > >
              > >
              > >
              > > Used settings: default, unless mentioned otherwise.
              >
              > --
              > --
              > 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+unsubscribe@....
              > For more options, visit https://groups.google.com/groups/opt_out.

              --
              --
              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+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Ben Fritz
              ... Ah, so would I be correct to phrase the problem as enough gaps on one side of a diff can make the other side align the incorrect line content ? -- -- You
              Message 6 of 19 , Sep 3, 2013
              • 0 Attachment
                On Tuesday, September 3, 2013 3:30:51 PM UTC-5, ZyX wrote:
                >
                > The problem here is not gaps, they are standable. In fact, I have gaps problem with these characters too, though it is different gaps problem (gap between input with sign or line number and adjacent lines). The real problem is incorrect diff, and this is not.

                Ah, so would I be correct to phrase the problem as "enough gaps on one side of a diff can make the other side align the incorrect line content"?

                --
                --
                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+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Nikolay Pavlov
                ... problem with these characters too, though it is different gaps problem (gap between input with sign or line number and adjacent lines). The real problem is
                Message 7 of 19 , Sep 3, 2013
                • 0 Attachment


                  On Sep 4, 2013 6:16 AM, "Ben Fritz" <fritzophrenic@...> wrote:
                  >
                  > On Tuesday, September 3, 2013 3:30:51 PM UTC-5, ZyX wrote:
                  > >
                  > > The problem here is not gaps, they are standable. In fact, I have gaps problem with these characters too, though it is different gaps problem (gap between input with sign or line number and adjacent lines). The real problem is incorrect diff, and this is not.
                  >
                  > Ah, so would I be correct to phrase the problem as "enough gaps on one side of a diff can make the other side align the incorrect line content"?

                  I guess no. You cannot see this on screenshot, but such tall characters do not cause stairs. That means line height is the same as the tallest character. And that also means diff is incorrect due to too tall lines. And this stacks with gaps... Screenshots were taken from Opera (12.*). But the only thing that differs in firefox is that gaps are a few pixels smaller. Chromium does not have gaps. But lines with some characters are still too tall to cause problems. You can check by yourself: file used to generate diff is http://sourceforge.net/p/formatvim/code/ci/default/tree/test/concealed.tex.

                  > --
                  > --
                  > 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+unsubscribe@....
                  > For more options, visit https://groups.google.com/groups/opt_out.

                  --
                  --
                  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+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • ZyX
                  Yet another problems: now allfolds equivalent (named dynamic_folds in TOhtml) + chromium: 1. Fold column has variable width, including some cases when this
                  Message 8 of 19 , Sep 9, 2013
                  • 0 Attachment
                    Yet another problems: now allfolds equivalent (named dynamic_folds in TOhtml) + chromium:

                    1. Fold column has variable width, including some cases when this seems to be not intentional: http://img-fotki.yandex.ru/get/9152/9151298.3/0_9eb17_5de67bee_orig.png (1.png).
                    2. Different position of fold ends. Seems that problem is with font (does not look like monospace one despite the font-family): http://img-fotki.yandex.ru/get/9349/9151298.3/0_9eb1a_56ac6077_orig.png (2-1.png).

                    Problems are seen in chromium , firefox is not affected, Opera is, but a) not that bad (http://img-fotki.yandex.ru/get/9302/9151298.3/0_9eb19_2ff9a18_orig.png (2-2.png)), b) only if zoom is active and beyond 100% and c) it is Opera 12, versions above this switched to use chromium.

                    Tested on chromium-29.0.1547.57 (Gentoo stable) and chromium-30.0.1599.22 (Gentoo ~amd64).

                    Am not sure there is a way to fix this other then hacking font configuration somewhere or patching the browser: if you search for “chromium monospace” you will get a bunch of reports that monospace font is not monospace. If you search for “firefox monospace” you will get more specific issues.

                    --
                    --
                    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+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Ben Fritz
                    ... Are there actually a variable number of characters shown, or is this also related to font? ... Is this because there is actually a font *named* Monospace
                    Message 9 of 19 , Sep 9, 2013
                    • 0 Attachment
                      On Monday, September 9, 2013 6:39:23 AM UTC-5, ZyX wrote:
                      > Yet another problems: now allfolds equivalent (named dynamic_folds in TOhtml) + chromium:
                      >
                      >
                      >
                      > 1. Fold column has variable width, including some cases when this seems to be not intentional: http://img-fotki.yandex.ru/get/9152/9151298.3/0_9eb17_5de67bee_orig.png (1.png).
                      >

                      Are there actually a variable number of characters shown, or is this also related to font?

                      > 2. Different position of fold ends. Seems that problem is with font (does not look like monospace one despite the font-family): http://img-fotki.yandex.ru/get/9349/9151298.3/0_9eb1a_56ac6077_orig.png (2-1.png).
                      >
                      >

                      Is this because there is actually a font *named* "Monospace" on Linux, which is a proportional font?

                      >
                      > Problems are seen in chromium , firefox is not affected, Opera is, but a) not that bad (http://img-fotki.yandex.ru/get/9302/9151298.3/0_9eb19_2ff9a18_orig.png (2-2.png)), b) only if zoom is active and beyond 100% and c) it is Opera 12, versions above this switched to use chromium.
                      >
                      >
                      >
                      > Tested on chromium-29.0.1547.57 (Gentoo stable) and chromium-30.0.1599.22 (Gentoo ~amd64).
                      >
                      >
                      >
                      > Am not sure there is a way to fix this other then hacking font configuration somewhere or patching the browser: if you search for “chromium monospace” you will get a bunch of reports that monospace font is not monospace. If you search for “firefox monospace” you will get more specific issues.

                      On my TODO list is an item to detect the actual font being used by Vim (falling back to "monospace" as a last resort). There is already an option to specify the font (though it is awkward to use if you want to have a comma-separated list). Maybe I should fix that up to be easier to use and recommend that people actually use it (like the recommendation to specify encoding explicitly)?

                      --
                      --
                      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+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • ZyX
                      ... Only to font. Number of characters is the same. ... ôlö glyph looks differently in chromium (2-1.png) and in kcharselect with Monospace selected
                      Message 10 of 19 , Sep 11, 2013
                      • 0 Attachment
                        > Are there actually a variable number of characters shown, or is this also related to font?

                        Only to font. Number of characters is the same.

                        > Is this because there is actually a font *named* "Monospace" on Linux, which is a proportional font?

                        “l” glyph looks differently in chromium (2-1.png) and in kcharselect with Monospace selected (2-2.png).

                        2-1.png: http://img-fotki.yandex.ru/get/9356/9151298.3/0_9ec11_7f2bc7af_orig.png
                        2-2.png: http://img-fotki.yandex.ru/get/9492/9151298.3/0_9ec12_aef63d40_orig.png

                        . Also “Monospace” is not a proportional font.

                        > >
                        > > Problems are seen in chromium , firefox is not affected, Opera is, but a) not that bad (http://img-fotki.yandex.ru/get/9302/9151298.3/0_9eb19_2ff9a18_orig.png (2-2.png)), b) only if zoom is active and beyond 100% and c) it is Opera 12, versions above this switched to use chromium.
                        > >
                        > > Tested on chromium-29.0.1547.57 (Gentoo stable) and chromium-30.0.1599.22 (Gentoo ~amd64).
                        > >
                        > > Am not sure there is a way to fix this other then hacking font configuration somewhere or patching the browser: if you search for “chromium monospace” you will get a bunch of reports that monospace font is not monospace. If you search for “firefox monospace” you will get more specific issues.
                        >
                        > On my TODO list is an item to detect the actual font being used by Vim (falling back to "monospace" as a last resort). There is already an option to specify the font (though it is awkward to use if you want to have a comma-separated list). Maybe I should fix that up to be easier to use and recommend that people actually use it (like the recommendation to specify encoding explicitly)?

                        Maybe set default to a list of common monospace fonts with an addition of “, monospace” as the very last resort for browser? Chromium has too many users to just ignore this problem.

                        Google code uses the following as font family: “Monaco,'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida Console',monospace”.
                        Github: “Consolas,"Liberation Mono",Courier,monospace”.
                        Bitbucket: “"Bitstream Vera Sans Mono","DejaVu Sans Mono",Monaco,monospace”.

                        --
                        --
                        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+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • Ben Fritz
                        ... Why would the same font look different in different browsers?! ... No? I know people have had trouble using it in Vim before, at least one person decided
                        Message 11 of 19 , Sep 11, 2013
                        • 0 Attachment
                          On Wednesday, September 11, 2013 7:16:29 AM UTC-5, ZyX wrote:
                          > > Are there actually a variable number of characters shown, or is this also related to font?
                          >
                          >
                          >
                          > Only to font. Number of characters is the same.
                          >
                          >
                          >
                          > > Is this because there is actually a font *named* "Monospace" on Linux, which is a proportional font?
                          >
                          >
                          >
                          > “l” glyph looks differently in chromium (2-1.png) and in kcharselect with Monospace selected (2-2.png).
                          >
                          >
                          >
                          > 2-1.png: http://img-fotki.yandex.ru/get/9356/9151298.3/0_9ec11_7f2bc7af_orig.png
                          >
                          > 2-2.png: http://img-fotki.yandex.ru/get/9492/9151298.3/0_9ec12_aef63d40_orig.png
                          >
                          >

                          Why would the same font look different in different browsers?!

                          >
                          > . Also “Monospace” is not a proportional font.
                          >
                          >


                          No? I know people have had trouble using it in Vim before, at least one person decided it was because that font wasn't actually fixed-width:

                          https://groups.google.com/d/msg/vim_use/DxSsvfzVAFI/ZbWBJrmHlsUJ

                          If the 'monospace' font has variable-width characters, isn't it by definition not actually monospace then? I'm a little frustrated to discover there's a font with a name matching a generic family name at all; it prevents any webpage from setting the default user-selected monospace font. But as you say, there are going to be a lot of people using it...

                          >
                          > > On my TODO list is an item to detect the actual font being used by Vim (falling back to "monospace" as a last resort). There is already an option to specify the font (though it is awkward to use if you want to have a comma-separated list). Maybe I should fix that up to be easier to use and recommend that people actually use it (like the recommendation to specify encoding explicitly)?
                          >
                          >
                          >
                          > Maybe set default to a list of common monospace fonts with an addition of “, monospace” as the very last resort for browser? Chromium has too many users to just ignore this problem.
                          >
                          >

                          Yes, that's what i meant by "as a last resort". This sounds like a reasonable alternative, to put a list of common fonts in there. The user could always override that.

                          >
                          > Google code uses the following as font family: “Monaco,'DejaVu Sans Mono','Bitstream Vera Sans Mono','Lucida Console',monospace”.
                          >
                          > Github: “Consolas,"Liberation Mono",Courier,monospace”.
                          >
                          > Bitbucket: “"Bitstream Vera Sans Mono","DejaVu Sans Mono",Monaco,monospace”.

                          Thanks. I'll probably try implementing:

                          1. detect font used by Vim if possible
                          2. fall back to DejaVu/Consolas/Bitstream Vera/Monaco in some order
                          3. Fall back to "monospace" which *intends* to select a generic font family, but apparently on some systems is an actual font name which might not be fixed-width after all

                          Any hints on getting font name from X/Motif fonts? Windows fonts and GTK fonts aren't too bad...

                          --
                          --
                          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+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        • ZyX
                          ... Because it is not the same font. I have font ôMonospaceö, but not ômonospaceö. Also all browsers seem to be fine with this collision: neither firefox,
                          Message 12 of 19 , Sep 11, 2013
                          • 0 Attachment
                            > Why would the same font look different in different browsers?!

                            Because it is not the same font. I have font “Monospace”, but not “monospace”. Also all browsers seem to be fine with this collision: neither firefox, nor opera (12: presto), nor chromium use font named “Monospace”. I can’t say what chromium actually uses because computed style contains “monospace” while Opera shows “DejaVu Sans Mono”. If I read correctly firefox uses “Droid Sans Mono” and “PowerlineSymbols” for the element at a time (due to fontconfig configuration second one is expected; it contains powerline-specific glyphs and nothing more) (computed style again contains only “monospace”, but there is a special tab named “Fonts” in built-in debugger).

                            > No? I know people have had trouble using it in Vim before, at least one person decided it was because that font wasn't actually fixed-width:
                            > https://groups.google.com/d/msg/vim_use/DxSsvfzVAFI/ZbWBJrmHlsUJ
                            > If the 'monospace' font has variable-width characters, isn't it by definition not actually monospace then? I'm a little frustrated to discover there's a font with a name matching a generic family name at all; it prevents any webpage from setting the default user-selected monospace font. But as you say, there are going to be a lot of people using it...

                            Previously I only tried it with terminal. For proportional fonts terminal displays too large gaps, for Monospace it does not. Also it is fine in gvim: I checked now.

                            > > Maybe set default to a list of common monospace fonts with an addition of “, monospace” as the very last resort for browser? Chromium has too many users to just ignore this problem.
                            >
                            > Yes, that's what i meant by "as a last resort". This sounds like a reasonable alternative, to put a list of common fonts in there. The user could always override that.

                            <...>

                            > Thanks. I'll probably try implementing:
                            >
                            > 1. detect font used by Vim if possible
                            > 2. fall back to DejaVu/Consolas/Bitstream Vera/Monaco in some order
                            > 3. Fall back to "monospace" which *intends* to select a generic font family, but apparently on some systems is an actual font name which might not be fixed-width after all

                            3. was not the problem. I just tried creating font named "monospace" (note: lowercase first letter) and it started to be actually used by chromium, firefox and opera. But font named “Monospace” (uppercase first letter) is *not*. It is a different issue which occurs on chromium only.

                            > Any hints on getting font name from X/Motif fonts? Windows fonts and GTK fonts aren't too bad...

                            No idea.

                            --
                            --
                            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+unsubscribe@....
                            For more options, visit https://groups.google.com/groups/opt_out.
                          • LCD 47
                            On 11 September 2013, Ben Fritz wrote: [...] ... [...] There is no collision. Simplifying, you can think of Monospace as an alias
                            Message 13 of 19 , Sep 11, 2013
                            • 0 Attachment
                              On 11 September 2013, Ben Fritz <fritzophrenic@...> wrote:
                              [...]
                              > I'm a little frustrated to discover there's a font with a name
                              > matching a generic family name at all; it prevents any webpage from
                              > setting the default user-selected monospace font.
                              [...]

                              There is no collision. Simplifying, you can think of "Monospace" as
                              an alias to a "real" name, that looks something like this:

                              -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

                              There are standard mechanisms to change these aliases, which allows
                              things like themes and skins to take effect on all programs system-wide.
                              Nothing stops you to alias "Monospace" to a proportional width font, but
                              then you deserve what you get. :)

                              /lcd

                              --
                              --
                              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+unsubscribe@....
                              For more options, visit https://groups.google.com/groups/opt_out.
                            • Nikolay Pavlov
                              ... You are likely true (I failed to find file with font Monospace yet such font can be chosen and fc-list knows nothing about it, neither does KDE
                              Message 14 of 19 , Sep 11, 2013
                              • 0 Attachment


                                On Sep 12, 2013 12:40 AM, "LCD 47" <lcd047@...> wrote:
                                >
                                > On 11 September 2013, Ben Fritz <fritzophrenic@...> wrote:
                                > [...]
                                > > I'm a little frustrated to discover there's a font with a name
                                > > matching a generic family name at all; it prevents any webpage from
                                > > setting the default user-selected monospace font.
                                > [...]
                                >
                                >     There is no collision.  Simplifying, you can think of "Monospace" as
                                > an alias to a "real" name, that looks something like this:
                                >
                                > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
                                >
                                >     There are standard mechanisms to change these aliases, which allows
                                > things like themes and skins to take effect on all programs system-wide.
                                > Nothing stops you to alias "Monospace" to a proportional width font, but
                                > then you deserve what you get. :)
                                >
                                >     /lcd

                                You are likely true (I failed to find file with font "Monospace" yet such font can be chosen and fc-list knows nothing about it, neither does KDE systemsettings), but that is not the case: as indicated earlier browsers choose different fonts for "monospace" that are not equal to "Monospace".

                                By the way, do you know a way to determine what is actually used when I request font "Monospace"? As I said fc-list does not work. In /etc/fonts there are lists for "monospace" (lowercase) family, but "Monospace" string is only present in comments.

                                Also interesting fact: after I added font named "monospace" for testing purposes "Monospace" disappeared. Reappeared again when it was removed.

                                > --
                                > --
                                > 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+unsubscribe@....
                                > For more options, visit https://groups.google.com/groups/opt_out.

                                --
                                --
                                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+unsubscribe@....
                                For more options, visit https://groups.google.com/groups/opt_out.
                              • LCD 47
                                ... As I understand it Monospace is a Pango thing, and Pango is a member of the Gnome tribe. Now, members of the Gnome tribe don t socialize with members of
                                Message 15 of 19 , Sep 12, 2013
                                • 0 Attachment
                                  On 12 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
                                  > On Sep 12, 2013 12:40 AM, "LCD 47" <lcd047@...> wrote:
                                  > >
                                  > > On 11 September 2013, Ben Fritz <fritzophrenic@...> wrote:
                                  > > [...]
                                  > > > I'm a little frustrated to discover there's a font with a name
                                  > > > matching a generic family name at all; it prevents any webpage
                                  > > > from setting the default user-selected monospace font.
                                  > > [...]
                                  > >
                                  > > There is no collision. Simplifying, you can think of
                                  > > "Monospace" as an alias to a "real" name, that looks something like
                                  > > this:
                                  > >
                                  > > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
                                  > >
                                  > > There are standard mechanisms to change these aliases,
                                  > > which allows things like themes and skins to take effect on all
                                  > > programs system-wide. Nothing stops you to alias "Monospace" to a
                                  > > proportional width font, but then you deserve what you get. :)
                                  > >
                                  > > /lcd
                                  >
                                  > You are likely true (I failed to find file with font "Monospace" yet
                                  > such font can be chosen and fc-list knows nothing about it, neither
                                  > does KDE systemsettings), but that is not the case: as indicated
                                  > earlier browsers choose different fonts for "monospace" that are not
                                  > equal to "Monospace".

                                  As I understand it Monospace is a Pango thing, and Pango is a member
                                  of the Gnome tribe. Now, members of the Gnome tribe don't socialize
                                  with members of the KDE tribe; so there you have it. :)

                                  http://xkcd.com/927/

                                  > By the way, do you know a way to determine what is actually used
                                  > when I request font "Monospace"? As I said fc-list does not work. In
                                  > /etc/fonts there are lists for "monospace" (lowercase) family, but
                                  > "Monospace" string is only present in comments.
                                  [...]

                                  I don't know much about that, sorry. I suppose digging through
                                  Pango docs might be a reasonable starting point.

                                  /lcd

                                  --
                                  --
                                  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+unsubscribe@....
                                  For more options, visit https://groups.google.com/groups/opt_out.
                                • Marius Gedminas
                                  ... fc-match Monospace It s a fontconfig thing, nothing to do with Pango. Marius Gedminas -- I may not understand what I m installing, but that s not my job.
                                  Message 16 of 19 , Sep 12, 2013
                                  • 0 Attachment
                                    On Thu, Sep 12, 2013 at 12:39:01PM +0300, LCD 47 wrote:
                                    > On 12 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
                                    > > You are likely true (I failed to find file with font "Monospace" yet
                                    > > such font can be chosen and fc-list knows nothing about it, neither
                                    > > does KDE systemsettings), but that is not the case: as indicated
                                    > > earlier browsers choose different fonts for "monospace" that are not
                                    > > equal to "Monospace".
                                    >
                                    > As I understand it Monospace is a Pango thing, and Pango is a member
                                    > of the Gnome tribe. Now, members of the Gnome tribe don't socialize
                                    > with members of the KDE tribe; so there you have it. :)
                                    >
                                    > http://xkcd.com/927/
                                    >
                                    > > By the way, do you know a way to determine what is actually used
                                    > > when I request font "Monospace"? As I said fc-list does not work. In
                                    > > /etc/fonts there are lists for "monospace" (lowercase) family, but
                                    > > "Monospace" string is only present in comments.

                                    fc-match Monospace

                                    It's a fontconfig thing, nothing to do with Pango.

                                    Marius Gedminas
                                    --
                                    "I may not understand what I'm installing, but that's not my job. I
                                    just need to click Next, Next, Finish here so I can walk to the next
                                    system and repeat the process"
                                    -- Anonymous NT Admin
                                  • LCD 47
                                    ... Sorry, but no. That looks for a font with family Monospace (case insensitive). When Vim is compiled with Gtk, gvim uses Pango. /lcd -- -- You received
                                    Message 17 of 19 , Sep 12, 2013
                                    • 0 Attachment
                                      On 12 September 2013, Marius Gedminas <marius@...> wrote:
                                      > On Thu, Sep 12, 2013 at 12:39:01PM +0300, LCD 47 wrote:
                                      > > On 12 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
                                      > > > You are likely true (I failed to find file with font "Monospace" yet
                                      > > > such font can be chosen and fc-list knows nothing about it, neither
                                      > > > does KDE systemsettings), but that is not the case: as indicated
                                      > > > earlier browsers choose different fonts for "monospace" that are not
                                      > > > equal to "Monospace".
                                      > >
                                      > > As I understand it Monospace is a Pango thing, and Pango is a member
                                      > > of the Gnome tribe. Now, members of the Gnome tribe don't socialize
                                      > > with members of the KDE tribe; so there you have it. :)
                                      > >
                                      > > http://xkcd.com/927/
                                      > >
                                      > > > By the way, do you know a way to determine what is actually used
                                      > > > when I request font "Monospace"? As I said fc-list does not work. In
                                      > > > /etc/fonts there are lists for "monospace" (lowercase) family, but
                                      > > > "Monospace" string is only present in comments.
                                      >
                                      > fc-match Monospace
                                      >
                                      > It's a fontconfig thing, nothing to do with Pango.

                                      Sorry, but no. That looks for a font with family Monospace (case
                                      insensitive). When Vim is compiled with Gtk, gvim uses Pango.

                                      /lcd

                                      --
                                      --
                                      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+unsubscribe@....
                                      For more options, visit https://groups.google.com/groups/opt_out.
                                    • Nikolay Pavlov
                                      ... member ... It is DejaVu Sans Mono on my system. Nothing to do with Pango. Pango is installed. ... vim_dev group. ... email to
                                      Message 18 of 19 , Sep 12, 2013
                                      • 0 Attachment


                                        On Sep 12, 2013 2:19 PM, "LCD 47" <lcd047@...> wrote:
                                        >
                                        > On 12 September 2013, Marius Gedminas <marius@...> wrote:
                                        > > On Thu, Sep 12, 2013 at 12:39:01PM +0300, LCD 47 wrote:
                                        > > > On 12 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
                                        > > > > You are likely true (I failed to find file with font "Monospace" yet
                                        > > > > such font can be chosen and fc-list knows nothing about it, neither
                                        > > > > does KDE systemsettings), but that is not the case: as indicated
                                        > > > > earlier browsers choose different fonts for "monospace" that are not
                                        > > > > equal to "Monospace".
                                        > > >
                                        > > >     As I understand it Monospace is a Pango thing, and Pango is a member
                                        > > > of the Gnome tribe.  Now, members of the Gnome tribe don't socialize
                                        > > > with members of the KDE tribe; so there you have it. :)
                                        > > >
                                        > > >     http://xkcd.com/927/
                                        > > >
                                        > > > > By the way, do you know a way to determine what is actually used
                                        > > > > when I request font "Monospace"? As I said fc-list does not work. In
                                        > > > > /etc/fonts there are lists for "monospace" (lowercase) family, but
                                        > > > > "Monospace" string is only present in comments.
                                        > >
                                        > > fc-match Monospace
                                        > >
                                        > > It's a fontconfig thing, nothing to do with Pango.
                                        >
                                        >     Sorry, but no.  That looks for a font with family Monospace (case
                                        > insensitive).  When Vim is compiled with Gtk, gvim uses Pango.
                                        >
                                        >     /lcd

                                        It is DejaVu Sans Mono on my system. Nothing to do with Pango. Pango is installed.

                                        > --
                                        > --
                                        > 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+unsubscribe@....
                                        > For more options, visit https://groups.google.com/groups/opt_out.

                                        --
                                        --
                                        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+unsubscribe@....
                                        For more options, visit https://groups.google.com/groups/opt_out.
                                      • LCD 47
                                        ... I take that back, you re mostly right: fc-match looks for the closest match, f.i. $ fc-match blahblah DejaVuSans.ttf: DejaVu Sans Book It also works
                                        Message 19 of 19 , Sep 12, 2013
                                        • 0 Attachment
                                          On 12 September 2013, LCD 47 <lcd047@...> wrote:
                                          > On 12 September 2013, Marius Gedminas <marius@...> wrote:
                                          > > On Thu, Sep 12, 2013 at 12:39:01PM +0300, LCD 47 wrote:
                                          > > > On 12 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
                                          > > > > You are likely true (I failed to find file with font "Monospace"
                                          > > > > yet such font can be chosen and fc-list knows nothing about
                                          > > > > it, neither does KDE systemsettings), but that is not the
                                          > > > > case: as indicated earlier browsers choose different fonts for
                                          > > > > "monospace" that are not equal to "Monospace".
                                          > > >
                                          > > > As I understand it Monospace is a Pango thing, and Pango is a
                                          > > > member of the Gnome tribe. Now, members of the Gnome tribe don't
                                          > > > socialize with members of the KDE tribe; so there you have it. :)
                                          > > >
                                          > > > http://xkcd.com/927/
                                          > > >
                                          > > > > By the way, do you know a way to determine what is actually used
                                          > > > > when I request font "Monospace"? As I said fc-list does not
                                          > > > > work. In /etc/fonts there are lists for "monospace" (lowercase)
                                          > > > > family, but "Monospace" string is only present in comments.
                                          > >
                                          > > fc-match Monospace
                                          > >
                                          > > It's a fontconfig thing, nothing to do with Pango.
                                          >
                                          > Sorry, but no. That looks for a font with family Monospace (case
                                          > insensitive). When Vim is compiled with Gtk, gvim uses Pango.

                                          I take that back, you're mostly right: fc-match looks for the
                                          closest match, f.i.

                                          $ fc-match blahblah
                                          DejaVuSans.ttf: "DejaVu Sans" "Book"

                                          It also works from gvim, in the sense that setting guifont to "blahblah"
                                          will actually load the DejaVu Sans font. But the name Monospace itself
                                          comes from Pango.

                                          /lcd

                                          --
                                          --
                                          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+unsubscribe@....
                                          For more options, visit https://groups.google.com/groups/opt_out.
                                        Your message has been successfully submitted and would be delivered to recipients shortly.