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

Re: non-interactive vimdiff to stdout

Expand Messages
  • Ben Fritz
    ... 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
    Message 1 of 19 , Jun 4, 2011
    • 0 Attachment
      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/file/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.

      --
      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
    • 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 2 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 3 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 4 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 5 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 6 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 7 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.