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

Moving toward a unified Vim...

Expand Messages
  • Linda W
    ... ==== Seeing as how I explained, *in depth*, how you were mistaken, just like every other argument against my case -- (except for one, which informed, me,
    Message 1 of 38 , Oct 30, 2011
    • 0 Attachment
      Linda W wrote:
      > Tony Mechelynck wrote:
      >
      >> On 28/10/11 22:26, Linda W wrote: [...]
      >>> If you put a symlink on linux, windows will see it as a hardlink.
      >>> That means any file copies will go through it.
      >> [...]
      >>
      >> If you set a symlink on a Linux (ext2, ext3, ext4, reiser, etc.)
      >> filesystem, Windows won't see it at all because it cannot read those
      >> filesystems. I was the one who mentioned symlinks, I mentioned them
      >> in the context of double-boot, not of Cygwin, and I explicitly
      >> mentioned ext2, ext3, ext4 and reiser filesystems. So who's
      >> distorting whose words?
      >
      > ---- I'm not distorting anyone's words.
      >
      > I'm replying about things I've tried that don't work.
      ==== Seeing as how I explained, *in depth*, how you were mistaken, just
      like every other argument against my case -- (except for one, which
      informed, me, and I adapted my solution to fit the new
      information...)...

      So I adapted my solution to the only real problem, and no one came
      up with any reason why my solution wouldn't work (or the kept claiming I
      said something OTHER than what I said -- which after the 3-4th time,
      started to get me a bit miffed. And then suddenly I was the bad person
      for having to repeat myself for the 3rd or 4th time to someone who just
      quoted the correct version of what I said but were claiming in their
      response that I said something else.

      But it seems once that became clear, there were no more objections
      or claims of incompatibility. There's always claims that things were
      done some way in the past...but that's true about every piece of
      software that has ever existed. That hasn't stopped new
      versions/standards of C, Perl, shell, linux, Windows...I don't know of
      any software that still is viable to the user community that doesn't
      grow and change.

      So does anyone want to take the unenviable position of why Vim should
      stay stuck with 1980's standards when the rest of the world has moved
      on?

      It wasn't until Vim6, that Vim even realized that HOME had been yanked
      out from underneath them, -- the rest of the world moved on.

      now believe me -- I've been on the other side of these issues often as
      well. Take a look at the bash archives from about a month or two ago
      where the behavior of bash broken longstanding scripts.

      BUT THERE...it did so for NO good reason. No one used the old feature
      cuz they thought it was broken! -- turns out it wasn't so broken, and it
      had been usable, so it was made broken in 4.1. to follow the new POSIX
      spec, which, is incompatible with the old posix spec. Except that the
      feature/mode we are talking about was about bash's NON-POSIX,
      "user-friendly mode"....so there was NO reason, even following a broken
      standard to have changed it. (change was made to "-e" option to exit
      on any non-zero status from any simple or complex command whereas
      before, it was to detect any non-zero exist from specifically, *simple
      commands*, that weren't error checked, but by including complex
      commands, this meant that calculations (let a=b-b), would cause an fatal
      error exist because it calculations return the 'not' of their final
      calculation thus the calculation ((0)) would return '1' (false),

      That and another arbitrary change was made that made all function call
      no longer take the same return params that 'exit' would return (despite
      a functions return is supposed to be equivalent to a program's exist
      code).

      Thy are reversing that decision, and the jury is still out as to whether
      or not he's going to break 14 years of posix compliance to go with the
      new and improved standard that isn't compatible with the old (in an area
      of bash that is an extension and not even covered under posix!)...

      So I'm not someone to just for every change, and fight against stupid
      changes, but you have to be willing to weight the cost of a change
      versus the overall benefit .. not just against the inconvenience of a
      single user. When you see MANY users coming up with hacks and
      workarounds to get around design decisions that once were valid, but now
      be costing people more time and effort to work around than it's worth to
      keep ith those decisions -- at that point, it's time to be
      **practical**, and go with what's going to cause the least effort for
      ongoing maintenance and future people's usage.

      That doesn't mean there might not be a one time conversion 'pain' to
      some new format, but if the payoff is much greater down the line --
      that's what you have to keep your keys on... Not peoples immediate
      gratification or pain levels.

      This isn't an issue I've brought up for the first time. It isn't an
      issue I just started dealing with.

      I've been dealing with cross-platform .vim files and .bash/.profile
      programs since the 80's. Getting Xenix and HP/UX to be compat with
      SunOS/SGI/and dos-unix-shell work-alikes. I've had more than 2 decade
      of experience working around these things. But I recognize when a
      design that might have been right at one point in time, now is well past
      the time of needing to be changed.

      People need to realize. Designs of software are NOT cut in Stone. As
      long as Bran maintains a vi-compat mode, he's doing his bit to
      maintain core compat with required standards. But software was designed
      to be able to be flexibly improved as needs and standards changed.

      But I wish you'd stop arguing against all change.

      There are basic text editing functions I can't do in vim in fixed with
      fonts, that I can do in a web'browser text box because Vim is stuck
      using some old DOS era text boxmodel.

      Simple adopting a new display library would open the new features...but
      I'm sure I've talked this point to death, unless anyone sees any other
      problems with my proposals (other than them coming from me!)... (I know
      that's a fairly negative point that kills alot of my proposals due to my
      scintillating personality... *cough*....*ahem*...I'm only trying to do
      what's best for the most...)... and I'll change my stance on something
      mid-stream given new information that requires change -- just as I did
      in this discussion. I'm not 'stuck in one position. I'll adapt to
      realities brought to my attention that need attention (and did).

      My persuasive style sucks (thanks you mom and dad for rasing me with
      socratic method!)...but I do try to get a pretty wide perspective.








      --
      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
    • Linda W
      ... ==== Seeing as how I explained, *in depth*, how you were mistaken, just like every other argument against my case -- (except for one, which informed, me,
      Message 38 of 38 , Oct 30, 2011
      • 0 Attachment
        Linda W wrote:
        > Tony Mechelynck wrote:
        >
        >> On 28/10/11 22:26, Linda W wrote: [...]
        >>> If you put a symlink on linux, windows will see it as a hardlink.
        >>> That means any file copies will go through it.
        >> [...]
        >>
        >> If you set a symlink on a Linux (ext2, ext3, ext4, reiser, etc.)
        >> filesystem, Windows won't see it at all because it cannot read those
        >> filesystems. I was the one who mentioned symlinks, I mentioned them
        >> in the context of double-boot, not of Cygwin, and I explicitly
        >> mentioned ext2, ext3, ext4 and reiser filesystems. So who's
        >> distorting whose words?
        >
        > ---- I'm not distorting anyone's words.
        >
        > I'm replying about things I've tried that don't work.
        ==== Seeing as how I explained, *in depth*, how you were mistaken, just
        like every other argument against my case -- (except for one, which
        informed, me, and I adapted my solution to fit the new
        information...)...

        So I adapted my solution to the only real problem, and no one came
        up with any reason why my solution wouldn't work (or the kept claiming I
        said something OTHER than what I said -- which after the 3-4th time,
        started to get me a bit miffed. And then suddenly I was the bad person
        for having to repeat myself for the 3rd or 4th time to someone who just
        quoted the correct version of what I said but were claiming in their
        response that I said something else.

        But it seems once that became clear, there were no more objections
        or claims of incompatibility. There's always claims that things were
        done some way in the past...but that's true about every piece of
        software that has ever existed. That hasn't stopped new
        versions/standards of C, Perl, shell, linux, Windows...I don't know of
        any software that still is viable to the user community that doesn't
        grow and change.

        So does anyone want to take the unenviable position of why Vim should
        stay stuck with 1980's standards when the rest of the world has moved
        on?

        It wasn't until Vim6, that Vim even realized that HOME had been yanked
        out from underneath them, -- the rest of the world moved on.

        now believe me -- I've been on the other side of these issues often as
        well. Take a look at the bash archives from about a month or two ago
        where the behavior of bash broken longstanding scripts.

        BUT THERE...it did so for NO good reason. No one used the old feature
        cuz they thought it was broken! -- turns out it wasn't so broken, and it
        had been usable, so it was made broken in 4.1. to follow the new POSIX
        spec, which, is incompatible with the old posix spec. Except that the
        feature/mode we are talking about was about bash's NON-POSIX,
        "user-friendly mode"....so there was NO reason, even following a broken
        standard to have changed it. (change was made to "-e" option to exit
        on any non-zero status from any simple or complex command whereas
        before, it was to detect any non-zero exist from specifically, *simple
        commands*, that weren't error checked, but by including complex
        commands, this meant that calculations (let a=b-b), would cause an fatal
        error exist because it calculations return the 'not' of their final
        calculation thus the calculation ((0)) would return '1' (false),

        That and another arbitrary change was made that made all function call
        no longer take the same return params that 'exit' would return (despite
        a functions return is supposed to be equivalent to a program's exist
        code).

        Thy are reversing that decision, and the jury is still out as to whether
        or not he's going to break 14 years of posix compliance to go with the
        new and improved standard that isn't compatible with the old (in an area
        of bash that is an extension and not even covered under posix!)...

        So I'm not someone to just for every change, and fight against stupid
        changes, but you have to be willing to weight the cost of a change
        versus the overall benefit .. not just against the inconvenience of a
        single user. When you see MANY users coming up with hacks and
        workarounds to get around design decisions that once were valid, but now
        be costing people more time and effort to work around than it's worth to
        keep ith those decisions -- at that point, it's time to be
        **practical**, and go with what's going to cause the least effort for
        ongoing maintenance and future people's usage.

        That doesn't mean there might not be a one time conversion 'pain' to
        some new format, but if the payoff is much greater down the line --
        that's what you have to keep your keys on... Not peoples immediate
        gratification or pain levels.

        This isn't an issue I've brought up for the first time. It isn't an
        issue I just started dealing with.

        I've been dealing with cross-platform .vim files and .bash/.profile
        programs since the 80's. Getting Xenix and HP/UX to be compat with
        SunOS/SGI/and dos-unix-shell work-alikes. I've had more than 2 decade
        of experience working around these things. But I recognize when a
        design that might have been right at one point in time, now is well past
        the time of needing to be changed.

        People need to realize. Designs of software are NOT cut in Stone. As
        long as Bran maintains a vi-compat mode, he's doing his bit to
        maintain core compat with required standards. But software was designed
        to be able to be flexibly improved as needs and standards changed.

        But I wish you'd stop arguing against all change.

        There are basic text editing functions I can't do in vim in fixed with
        fonts, that I can do in a web'browser text box because Vim is stuck
        using some old DOS era text boxmodel.

        Simple adopting a new display library would open the new features...but
        I'm sure I've talked this point to death, unless anyone sees any other
        problems with my proposals (other than them coming from me!)... (I know
        that's a fairly negative point that kills alot of my proposals due to my
        scintillating personality... *cough*....*ahem*...I'm only trying to do
        what's best for the most...)... and I'll change my stance on something
        mid-stream given new information that requires change -- just as I did
        in this discussion. I'm not 'stuck in one position. I'll adapt to
        realities brought to my attention that need attention (and did).

        My persuasive style sucks (thanks you mom and dad for rasing me with
        socratic method!)...but I do try to get a pretty wide perspective.








        --
        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.