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

73022Re: Some TOhtml issues

Expand Messages
  • Nikolay Pavlov
    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.
    • Show all 19 messages in this topic