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

Re: non-interactive vimdiff to stdout

Expand Messages
  • Ben Fritz
    ... Cool, do you have an example of that? I d be interested to see, but it probably won t go into TOhtml any time in the near future unless specifically
    Message 1 of 19 , Jun 4, 2011
    • 0 Attachment
      On Jun 4, 3:40 pm, ZyX <zyx....@...> wrote:
      > Reply to message «Re: non-interactive vimdiff to stdout»,
      > sent 18:14:22 04 June 2011, Saturday
      > by ZyX:
      >
      > Signs are also implemented now, including icons.
      >

      Cool, do you have an example of that? I'd be interested to see, but it
      probably won't go into TOhtml any time in the near future unless
      specifically requested.

      --
      You received this message from the "vim_use" 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
    • ZyX
      Reply to message «Re: non-interactive vimdiff to stdout», sent 06:38:10 05 June 2011, Sunday ... It was removed in rev 232:d5f6156d14e4. Initially it was for
      Message 2 of 19 , Jun 5, 2011
      • 0 Attachment
        Reply to message «Re: non-interactive vimdiff to stdout»,
        sent 06:38:10 05 June 2011, Sunday
        by Ben Fritz:

        > What's the extra span for, with class=over? I could not figure out a
        > purpose for it.
        It was removed in rev 232:d5f6156d14e4. Initially it was for making input
        unselectable in opera, but in original article it was
        <input... /><span ... />
        where constant width is set both for input and for span. I tried replacing it
        with <span ...><input ... /></span>, but this does not work. I can't use initial
        construct as it requires to specify width.

        > By the way, I looked at the specific link you gave...how do you unfold
        > the text? Or is this an example of one which cannot be unfolded? I
        > know I read that your plugin supports this.
        I do not unfold text by default. There is IgnoreFolds option which makes
        formatvim ignore folds and AllFolds option that creates something like
        http://formatvim.sourceforge.net/folded.yaml_C0-D0-a1-n0-o3-r1.html
        (-a1 stands for AllFolds: 1). I guess I will do something with the latter.

        > I'm not sure if you care, but the text is still selectable in Opera,
        > which doesn't seem to support the user-select property.
        I care (I use choose opera as my browser), but I am fine with current partially
        working solution that requires user not to start selecting text from <input>.

        Original message:
        > On Jun 3, 9:14 am, ZyX <zyx....@...> wrote:
        > > Reply to message «Re: non-interactive vimdiff to stdout»,
        > > sent 09:13:30 03 June 2011, Friday
        > > by ZyX:
        > >
        > > If you are interested, <input> hack is now implemented in frawor-port
        > > branch:http://formatvim.hg.sourceforge.net/hgweb/formatvim/formatvim/fil
        > > e/fr.... Lots of examples are in *.ok files in directory «test/» (you
        > > should see those that have -r1, -n1 or -oN where N>=1).
        > > Live examples have urls
        > > likehttp://formatvim.sourceforge.net/concealed.tex_C0-D0-F0-L0-c0-l_q_q-
        > > n... (created using
        > > zmv -C '(*).ok'
        > > 'outs/${${${${${1//_/__}//\%/_}//$/_d}//!/_b}//>/_g}.html' scp
        > > outs/*.html \
        > >
        > > zyxsf,format...@...:/home/groups/f/fo/formatvim/htdocs
        > >
        > > : here following replacement are done:
        > > _ -> __, % -> _, $ -> _d, ! -> _b, > -> _g).
        > > It is not guaranteed that live examples were created using latest
        > > revision.
        >
        > I've actually been playing around with some prototyping for this as
        > well.
        >
        > What's the extra span for, with class=over? I could not figure out a
        > purpose for it.
        >
        > I'm not 100% sure I'm going to implement this fully. The non-copyable
        > area is easy to accomplish with the input with readonly attribute set.
        > But the unselectable quality depends an IE-proprietary attribute
        > (unselectable) or on experimental CSS3 properties which if I am not
        > mistaken have been removed from the latest working draft. If someone
        > can point to a recent CSS3 draft with the user-select property
        > defined, I'd be happy to be proven wrong...
        >
        > I am thinking that I will probably implement the non-copyable bit, but
        > I'm really not sure I can justify to myself the invalid markup
        > required for the unselectable portion. Any thoughts? I would really
        > like to have an unselectable, uncopyable region for the line numbers
        > and fold column.
        >
        > By the way, I looked at the specific link you gave...how do you unfold
        > the text? Or is this an example of one which cannot be unfolded? I
        > know I read that your plugin supports this.
        >
        > I'm not sure if you care, but the text is still selectable in Opera,
        > which doesn't seem to support the user-select property.
      • ZyX
        Reply to message «Re: non-interactive vimdiff to stdout», sent 06:39:25 05 June 2011, Sunday ... http://formatvim.sourceforge.net/signs.yaml_icons.html
        Message 3 of 19 , Jun 5, 2011
        • 0 Attachment
          Reply to message «Re: non-interactive vimdiff to stdout»,
          sent 06:39:25 05 June 2011, Sunday
          by Ben Fritz:

          > Cool, do you have an example of that? I'd be interested to see, but it
          > probably won't go into TOhtml any time in the near future unless
          > specifically requested.
          http://formatvim.sourceforge.net/signs.yaml_icons.html
          http://formatvim.sourceforge.net/signs.yaml_signs__diffformat__diff__numbers.html

          It also does not show a bug with absent signs column on diff filler lines (see
          recent messages in vim-dev for screenshots of this bug).

          Original message:
          > On Jun 4, 3:40 pm, ZyX <zyx....@...> wrote:
          > > Reply to message «Re: non-interactive vimdiff to stdout»,
          > > sent 18:14:22 04 June 2011, Saturday
          > > by ZyX:
          > >
          > > Signs are also implemented now, including icons.
          >
          > Cool, do you have an example of that? I'd be interested to see, but it
          > probably won't go into TOhtml any time in the near future unless
          > specifically requested.
        • Benjamin Fritz
          ... Drat, I think I confirmed that these properties were intentionally removed. So Opera and IE will probably never support user-select (unless it gets
          Message 4 of 19 , Jun 8, 2011
          • 0 Attachment
            On Sat, Jun 4, 2011 at 9:38 PM, Ben Fritz <fritzophrenic@...> wrote:
            > But the unselectable quality depends an IE-proprietary attribute
            > (unselectable) or on experimental CSS3 properties which if I am not
            > mistaken have been removed from the latest working draft. If someone
            > can point to a recent CSS3 draft with the user-select property
            > defined, I'd be happy to be proven wrong...

            Drat, I think I confirmed that these properties were intentionally
            removed. So Opera and IE will probably never support user-select
            (unless it gets re-added), and I wouldn't be surprised if WebKit and
            Gecko drop support sometime too.

            From the change log in http://www.w3.org/TR/2000/WD-css3-userint-20000216 :

            "Reduced scope to focus primarily on presentational features, and
            dropped vast majority of behavior features (e.g. "user-*" properties),
            keeping only those that directly replace dynamic presentational
            features of HTML4."

            So, this particular method won't make it into TOhtml. But I saw a few
            methods using javascript which I will look into.

            --
            You received this message from the "vim_use" 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
          • ZyX
            Reply to message «Re: non-interactive vimdiff to stdout», sent 07:35:06 09 June 2011, Thursday by Benjamin Fritz: Bad, but hack still provides
            Message 5 of 19 , Jun 9, 2011
            • 0 Attachment
              Reply to message «Re: non-interactive vimdiff to stdout»,
              sent 07:35:06 09 June 2011, Thursday
              by Benjamin Fritz:

              Bad, but <input> hack still provides uncopiable content, so I will keep it
              (though now arora shows a strange bug: selected text is not copied if selection
              started with some <input>). Now removed both unselectable attribute and user-
              select property. What about pointer-events?

              // It is strange, but Opera does not report <input type="xxxinvalid"> as an
              // error.

              Original message:
              > On Sat, Jun 4, 2011 at 9:38 PM, Ben Fritz <fritzophrenic@...> wrote:
              > > But the unselectable quality depends an IE-proprietary attribute
              > > (unselectable) or on experimental CSS3 properties which if I am not
              > > mistaken have been removed from the latest working draft. If someone
              > > can point to a recent CSS3 draft with the user-select property
              > > defined, I'd be happy to be proven wrong...
              >
              > Drat, I think I confirmed that these properties were intentionally
              > removed. So Opera and IE will probably never support user-select
              > (unless it gets re-added), and I wouldn't be surprised if WebKit and
              > Gecko drop support sometime too.
              >
              > From the change log in http://www.w3.org/TR/2000/WD-css3-userint-20000216 :
              >
              > "Reduced scope to focus primarily on presentational features, and
              > dropped vast majority of behavior features (e.g. "user-*" properties),
              > keeping only those that directly replace dynamic presentational
              > features of HTML4."
              >
              > So, this particular method won't make it into TOhtml. But I saw a few
              > methods using javascript which I will look into.
            • Benjamin Fritz
              ... Well, it shows up in the latest Editor s Draft ( http://dev.w3.org/csswg/css3-ui/ ) but not in the latest Candidate Recommendation (
              Message 6 of 19 , Jun 10, 2011
              • 0 Attachment
                On Thu, Jun 9, 2011 at 2:34 AM, ZyX <zyx.vim@...> wrote:
                > Reply to message «Re: non-interactive vimdiff to stdout»,
                > sent 07:35:06 09 June 2011, Thursday
                > by Benjamin Fritz:
                >
                > Bad, but <input> hack still provides uncopiable content, so I will keep it
                > (though now arora shows a strange bug: selected text is not copied if selection
                > started with some <input>). Now removed both unselectable attribute and user-
                > select property. What about pointer-events?

                Well, it shows up in the latest Editor's Draft (
                http://dev.w3.org/csswg/css3-ui/ ) but not in the latest Candidate
                Recommendation ( http://www.w3.org/TR/css3-ui/ ). I don't know enough
                about CSS development to know what precisely that means, but it looks
                like pointer-events is on its way back in. user-select and user-focus
                are still not in the Editor's Draft. Pity.

                >
                > // It is strange, but Opera does not report <input type="xxxinvalid"> as an
                > // error.
                >

                That is strange. Where would you see that error? I use Opera as my
                primary browser at home, is that just in an error console somewhere
                that you'd expect to see that?

                --
                You received this message from the "vim_use" 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
              Your message has been successfully submitted and would be delivered to recipients shortly.