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

Re: 6.0aa compile error (Linux)

Expand Messages
  • Chase Tingley
    ... I m not sure if Bram s going to put up a new source tarball, but this should fix it in the meantime... ct ... +++ move.c Wed Apr 4 16:12:25 2001 @@ -32,13
    Message 1 of 19 , Apr 4, 2001
    • 0 Attachment
      On Wed, 4 Apr 2001, Bram Moolenaar wrote:

      > Perhaps "lineoff_t". It's a bit longer, but also clearer.

      I'm not sure if Bram's going to put up a new source tarball, but this
      should fix it in the meantime...

      ct

      --- move.c.orig Wed Apr 4 16:12:15 2001
      +++ move.c Wed Apr 4 16:12:25 2001
      @@ -32,13 +32,13 @@
      int fill; /* filler lines */
      #endif
      int height; /* height of added line */
      -} loff_t;
      +} lineoff_t;

      -static void topline_back __ARGS((loff_t *lp));
      -static void botline_forw __ARGS((loff_t *lp));
      +static void topline_back __ARGS((lineoff_t *lp));
      +static void botline_forw __ARGS((lineoff_t *lp));
      #ifdef FEAT_DIFF
      -static void botline_topline __ARGS((loff_t *lp));
      -static void topline_botline __ARGS((loff_t *lp));
      +static void botline_topline __ARGS((lineoff_t *lp));
      +static void topline_botline __ARGS((lineoff_t *lp));
      static void check_topfill __ARGS((int down));
      #endif

      @@ -281,7 +281,7 @@
      #endif
      ))
      {
      - loff_t loff;
      + lineoff_t loff;

      /* Cursor is above botline, check if there are 'scrolloff'
      * window lines below the cursor. If not, need to scroll. */
      @@ -372,7 +372,7 @@
      static int
      check_top_offset()
      {
      - loff_t loff;
      + lineoff_t loff;
      int n;

      if (curwin->w_cursor.lnum < curwin->w_topline + p_so
      @@ -1541,7 +1541,7 @@
      */
      static void
      topline_back(lp)
      - loff_t *lp;
      + lineoff_t *lp;
      {
      #ifdef FEAT_DIFF
      if (lp->fill < diff_check_fill(curwin, lp->lnum))
      @@ -1584,7 +1584,7 @@
      */
      static void
      botline_forw(lp)
      - loff_t *lp;
      + lineoff_t *lp;
      {
      #ifdef FEAT_DIFF
      if (lp->fill < diff_check_fill(curwin, lp->lnum + 1))
      @@ -1627,7 +1627,7 @@
      */
      static void
      botline_topline(lp)
      - loff_t *lp;
      + lineoff_t *lp;
      {
      if (lp->fill > 0)
      {
      @@ -1643,7 +1643,7 @@
      */
      static void
      topline_botline(lp)
      - loff_t *lp;
      + lineoff_t *lp;
      {
      if (lp->fill > 0)
      {
      @@ -1841,8 +1841,8 @@
      int i;
      linenr_t line_count;
      linenr_t old_topline = curwin->w_topline;
      - loff_t loff;
      - loff_t boff;
      + lineoff_t loff;
      + lineoff_t boff;
      #ifdef FEAT_DIFF
      int old_topfill = curwin->w_topfill;
      int fill_below_window;
      @@ -2058,8 +2058,8 @@
      linenr_t topline;
      int below = 0;
      int used;
      - loff_t loff;
      - loff_t boff;
      + lineoff_t loff;
      + lineoff_t boff;

      loff.lnum = boff.lnum = curwin->w_cursor.lnum;
      #ifdef FEAT_DIFF
      @@ -2240,7 +2240,7 @@
      curwin->w_valid |= VALID_TOPLINE;
      }

      -static void get_scroll_overlap __ARGS((loff_t *lp, int dir));
      +static void get_scroll_overlap __ARGS((lineoff_t *lp, int dir));
      #ifdef FEAT_DIFF
      static void max_topfill __ARGS((void));
      #endif
      @@ -2257,7 +2257,7 @@
      {
      long n;
      int retval = OK;
      - loff_t loff;
      + lineoff_t loff;

      if (curbuf->b_ml.ml_line_count == 1) /* nothing to do */
      {
      @@ -2450,12 +2450,12 @@
      */
      static void
      get_scroll_overlap(lp, dir)
      - loff_t *lp;
      + lineoff_t *lp;
      int dir;
      {
      int h1, h2, h3, h4;
      int min_height = curwin->w_height - 2;
      - loff_t loff0, loff1, loff2;
      + lineoff_t loff0, loff1, loff2;

      #ifdef FEAT_DIFF
      if (lp->fill > 0)
    • Ron Aaron
      ... I did :%s/loff_t/loff_vim_t/g and it compiled fine... ... Sounds ok to me. Ron
      Message 2 of 19 , Apr 4, 2001
      • 0 Attachment
        Bram Moolenaar <Bram@...> writes:
        >Ron Aaron wrote:
        >
        >> One problem:
        >>
        >> configure --with-features=big --without-gnome
        >> make
        >>
        >> ...
        >> move.c:35: conflicting types for 'loff_t'
        >> /usr/include/sys/types.h:42: previous declaration of 'loff_t'
        >
        >Hmm, what else could we use then? lino_t? :-)

        I did :%s/loff_t/loff_vim_t/g

        and it compiled fine...

        >
        >Perhaps "lineoff_t". It's a bit longer, but also clearer.
        >
        Sounds ok to me.

        Ron
      • Vince Negri
        Is this available on cvs yet - or has the aa confused matters? (Off to dl the tarball just in case...) -- Vince Negri (vnegri@aslnet.co.uk) Application
        Message 3 of 19 , Apr 5, 2001
        • 0 Attachment
          Is this available on cvs yet - or has the 'aa' confused matters?

          (Off to dl the tarball just in case...)

          --
          Vince Negri (vnegri@...)
          Application Solutions Ltd. Tel:+44(0)1273-476608 Fax:+44(0)1273-478888

          Legal Disclaimer: Any views expressed by the sender of this message are
          not necessarily those of Application Solutions Ltd. Information in this
          e-mail may be confidential and is for the use of the intended recipient
          only, no mistake in transmission is intended to waive or compromise such
          privilege. Please advise the sender if you receive this e-mail by mistake.
        • Vince Negri
          ... that ... compare ... Woah! :-D Somebody buy this man a beer! The integration of folding is a neat touch - one of the reasons I ve tended to shy away from
          Message 4 of 19 , Apr 5, 2001
          • 0 Attachment
            On 04 Apr 2001, 20:20 Bram Moolenaar wrote:
            >
            > It's.... vimdiff!
            >
            > This is a nice way to edit two or three different versions of a file.
            > Changed lines are highlighted. A change within a line is highlighted
            > differently, so that you can spot an inserted word, for example. Deleted
            > lines are highlighted in one window and filled up in the other window, so
            that
            > scroll-binding makes it possible to put the windows side-by-side and
            compare
            > the text. Folding is used to hide the text that has no changes.
            >


            Woah! :-D

            Somebody buy this man a beer!

            The integration of folding is a neat touch - one of the reasons I've
            tended to shy away from integrated diffs in editors before is that you
            didn't the compact view you got with (say) "diff -c5" Now I can have
            the best of both worlds!

            Thanks again,

            Vince


            --
            Vince Negri (vnegri@...) The Man with no Mouse
            God is not dead, he is alive and autographing Bibles at W.H.Smith in
            Worthing
            Legal Disclaimer: Any views expressed by the sender of this message are
            not necessarily those of Application Solutions Ltd. Information in this
            e-mail may be confidential and is for the use of the intended recipient
            only, no mistake in transmission is intended to waive or compromise such
            privilege. Please advise the sender if you receive this e-mail by mistake.
          • Moore, Paul
            From: Bram Moolenaar [mailto:Bram@moolenaar.net] ... That s nice. (Although I wonder, if someone else had suggested this, you d have probably said that it
            Message 5 of 19 , Apr 5, 2001
            • 0 Attachment
              From: Bram Moolenaar [mailto:Bram@...]
              > It's.... vimdiff!
              >
              > This is a nice way to edit two or three different versions of a file.
              > Changed lines are highlighted. A change within a line is highlighted
              > differently, so that you can spot an inserted word, for example.
              > Deleted lines are highlighted in one window and filled up in the
              > other window, so that scroll-binding makes it possible to put the
              > windows side-by-side and compare the text. Folding is used to
              > hide the text that has no changes.

              That's nice. (Although I wonder, if someone else had suggested this, you'd
              have probably said that it should be implemented as a script :-)

              One thing - when 'diff' is run on the files on Windows, it shows a console
              window with a "Press enter" prompt. This is presumably the equivalent of :!
              (but in C). Would it be possible to hide the window (which has no useful
              info in it) by doing the equivalent of :call system() instead (like the gzip
              plugin does)?

              Paul.
            • Bram Moolenaar
              ... True. It s on the border of what should still be added to Vim 6.0. It can t be implemented with a script though, especially the handling of filler lines
              Message 6 of 19 , Apr 5, 2001
              • 0 Attachment
                Paul Moore wrote:

                > That's nice. (Although I wonder, if someone else had suggested this, you'd
                > have probably said that it should be implemented as a script :-)

                True. It's on the border of what should still be added to Vim 6.0. It can't
                be implemented with a script though, especially the handling of filler lines
                and scroll-binding.

                I do intend to cut down on adding new features and get 6.0 ready for a beta
                test. The todo list is getting shorter, thus we are getting closer.

                > One thing - when 'diff' is run on the files on Windows, it shows a console
                > window with a "Press enter" prompt. This is presumably the equivalent of :!
                > (but in C). Would it be possible to hide the window (which has no useful
                > info in it) by doing the equivalent of :call system() instead (like the gzip
                > plugin does)?

                Yes, it can work like ":silent !diff". Hopefully "diff" doesn't produce any
                error messages you would like to see. If it would fail to run, you end up
                with no changes (the diff output is empty). The return value of the shell
                can't be used, because "diff" returns non-zero when there are differences.

                Note that calling "patch" often produces output you need to check, thus it's
                better not to silence it.

                --
                hundred-and-one symptoms of being an internet addict:
                33. You name your children Eudora, Mozilla and Dotcom.

                /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
              • Walter Briscoe
                In article of Wed, 4 Apr 2001 21:20:47 in !vim-dev, Bram Moolenaar writes ... tis wonderful. I
                Message 7 of 19 , Apr 5, 2001
                • 0 Attachment
                  In article <200104041920.f34JKlb68785@...> of Wed, 4 Apr 2001
                  21:20:47 in !vim-dev, Bram Moolenaar <Bram@...> writes
                  >
                  >It's.... vimdiff!

                  'tis wonderful.
                  I should no longer have to use my ancient MSDOS shareware editor MR-ED
                  to do buffer comparisons.
                  I found one glitch. I resized the screen of my telnet session from 80 to
                  132 columns. The appropriate interrupt was generated but all the extra
                  columns went to the right hand window rather than being evenly spread on
                  the two open windows.
                  You're right - the colours (and colors) are horrible. I DON'T CARE!
                  This is fantastic. I put it on DOS and liked it. I put it on UNIX where
                  it replaced my 6.0t. I must learn to use folding!
                  --
                  Walter Briscoe
                • Bram Moolenaar
                  ... This was an intentional change. It s not related to the diff mode. Previously, when making the Vim window smaller, and the equalalways option was on,
                  Message 8 of 19 , Apr 5, 2001
                  • 0 Attachment
                    Walter Briscoe wrote:

                    > I found one glitch. I resized the screen of my telnet session from 80 to
                    > 132 columns. The appropriate interrupt was generated but all the extra
                    > columns went to the right hand window rather than being evenly spread on
                    > the two open windows.

                    This was an intentional change. It's not related to the diff mode.
                    Previously, when making the Vim window smaller, and the 'equalalways' option
                    was on, small windows could get bigger. Since it's very complicated to avoid
                    this, I decided that only resizing the right and bottom window would be the
                    best solution. It's not perfect.

                    Enjoy Diffing!

                    --
                    Change is inevitable, except from a vending machine.

                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                    ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                    \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                  • Zdenek Sekera
                    ... Why not also the extra files in bzip2?
                    Message 9 of 19 , Apr 5, 2001
                    • 0 Attachment
                      Bram Moolenaar wrote:
                      > ...
                      > The source archive was over the 1.4M floppy limit. Now also provide bzip2
                      > compressed versions of the sources and runtime archives.

                      Why not also the 'extra' files in bzip2?

                      ---Zdenek
                    • Ron Aaron
                      ... Yes, Bram, you ve outdone yourself this time! ... Nor I windiff ! And it works on unix and Windows too! ... I ve already changed the colors to my own
                      Message 10 of 19 , Apr 5, 2001
                      • 0 Attachment
                        Walter Briscoe <wbriscoe@...> writes:
                        >In article <200104041920.f34JKlb68785@...> of Wed, 4 Apr 2001
                        >21:20:47 in !vim-dev, Bram Moolenaar <Bram@...> writes
                        >>
                        >>It's.... vimdiff!
                        >
                        >'tis wonderful.

                        Yes, Bram, you've outdone yourself this time!

                        >I should no longer have to use my ancient MSDOS shareware editor MR-ED
                        >to do buffer comparisons.

                        Nor I 'windiff'! And it works on unix and Windows too!

                        >You're right - the colours (and colors) are horrible. I DON'T CARE!

                        I've already changed the colors to my own ugly choices. Thanks again, Bram!

                        Ron
                      • Bram Moolenaar
                        ... Two extra files. Why would I bzip2 files that are not too big? Just to save a few Kbyte? -- A fine is a tax for doing wrong. A tax is a fine for doing
                        Message 11 of 19 , Apr 5, 2001
                        • 0 Attachment
                          Zdenek Sekera wrote:

                          > Bram Moolenaar wrote:
                          > > ...
                          > > The source archive was over the 1.4M floppy limit. Now also provide bzip2
                          > > compressed versions of the sources and runtime archives.
                          >
                          > Why not also the 'extra' files in bzip2?

                          Two extra files. Why would I bzip2 files that are not too big? Just to save
                          a few Kbyte?

                          --
                          A fine is a tax for doing wrong. A tax is a fine for doing well.

                          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                          ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                        • Thomas Köhler
                          On Thu, Apr 05, 2001 at 07:41:10PM +0200, ... for i in vim-6.0aa* ; do tar xjvf $i ; done vs for i in vim-6.0aa*bz2 ; do tar xjvf $i ; done ; for i in
                          Message 12 of 19 , Apr 5, 2001
                          • 0 Attachment
                            On Thu, Apr 05, 2001 at 07:41:10PM +0200,
                            Bram Moolenaar <Bram@...> wrote:
                            >
                            > Zdenek Sekera wrote:
                            >
                            > > Bram Moolenaar wrote:
                            > > > ...
                            > > > The source archive was over the 1.4M floppy limit. Now also provide bzip2
                            > > > compressed versions of the sources and runtime archives.
                            > >
                            > > Why not also the 'extra' files in bzip2?
                            >
                            > Two extra files. Why would I bzip2 files that are not too big? Just to save
                            > a few Kbyte?

                            for i in vim-6.0aa* ; do tar xjvf $i ; done

                            vs

                            for i in vim-6.0aa*bz2 ; do tar xjvf $i ; done ; for i in vim-6.0aa*gz ; do tar xzvf $i ; done

                            ;-)

                            CU,
                            Thomas

                            --
                            Thomas Köhler Email: jean-luc@... | LCARS - Linux
                            <>< WWW: http://jeanluc-picard.de | for Computers
                            IRC: jeanluc | on All Real
                            PGP public key available from Homepage! | Starships
                          • Zdenek Sekera
                            ... No, to let people have either/or bzip2/gzip.
                            Message 13 of 19 , Apr 5, 2001
                            • 0 Attachment
                              Bram Moolenaar wrote:
                              >
                              > Zdenek Sekera wrote:
                              >
                              > > Bram Moolenaar wrote:
                              > > > ...
                              > > > The source archive was over the 1.4M floppy limit. Now also provide bzip2
                              > > > compressed versions of the sources and runtime archives.
                              > >
                              > > Why not also the 'extra' files in bzip2?
                              >
                              > Two extra files. Why would I bzip2 files that are not too big? Just to save
                              > a few Kbyte?

                              No, to let people have either/or bzip2/gzip.

                              ---Zdenek
                            • Walter Briscoe
                              In article of Thu, 5 Apr 2001 15:59:44 in !vim-dev, Bram Moolenaar writes ... I am! Now, as a
                              Message 14 of 19 , Apr 6, 2001
                              • 0 Attachment
                                In article <200104051359.f35Dxi606615@...> of Thu, 5 Apr 2001
                                15:59:44 in !vim-dev, Bram Moolenaar <Bram@...> writes
                                >
                                >Walter Briscoe wrote:
                                >
                                >> I found one glitch. I resized the screen of my telnet session from 80 to
                                >> 132 columns. The appropriate interrupt was generated but all the extra
                                >> columns went to the right hand window rather than being evenly spread on
                                >> the two open windows.
                                >
                                >This was an intentional change. It's not related to the diff mode.
                                >Previously, when making the Vim window smaller, and the 'equalalways' option
                                >was on, small windows could get bigger. Since it's very complicated to avoid
                                >this, I decided that only resizing the right and bottom window would be the
                                >best solution. It's not perfect.
                                >
                                >Enjoy Diffing!
                                >
                                I am! Now, as a typical user (PITA), I want a change.
                                I often have to deal with repeated code in a file produced by the
                                "cut-and-paste" brigade. I would like the diff to be relative to my
                                current position in the open windows rather than to be of the current
                                files. I read the help file and see no way of doing this.
                                i.e. The focus in the first window is on line 200 of mirage.c;
                                the focus in the second window is on line 325 of mirage.c.
                                I want the differences to be reported so that line 200 is matched
                                against line 325.
                                This behaviour would probably require a controlling option as it imposes
                                extra work on the implementation.
                                --
                                Walter Briscoe
                              • Bram Moolenaar
                                ... You can already do it: Create a new empty buffer Copy the relevant text from the current buffer to the new one Insert or delete enough lines to line up the
                                Message 15 of 19 , Apr 6, 2001
                                • 0 Attachment
                                  Walter Briscoe wrote:

                                  > I often have to deal with repeated code in a file produced by the
                                  > "cut-and-paste" brigade. I would like the diff to be relative to my
                                  > current position in the open windows rather than to be of the current
                                  > files. I read the help file and see no way of doing this.
                                  > i.e. The focus in the first window is on line 200 of mirage.c;
                                  > the focus in the second window is on line 325 of mirage.c.
                                  > I want the differences to be reported so that line 200 is matched
                                  > against line 325.
                                  > This behaviour would probably require a controlling option as it imposes
                                  > extra work on the implementation.

                                  You can already do it:

                                  Create a new empty buffer
                                  Copy the relevant text from the current buffer to the new one
                                  Insert or delete enough lines to line up the text as you want
                                  Set 'diff' in both buffers.

                                  You can hide the new buffer and reset 'modified', so that you can get rid of
                                  it anytime.

                                  There is one problem: convince "diff" not to line up the wrong text. It might
                                  try to insert lines to make the identical text line up instead.

                                  Including this functionality inside Vim? This would require an option to say
                                  "diff with the same buffer" and an option to specify the offset. It's
                                  probably a bit compicated to find out what offset you need. And finding a way
                                  to avoid the above mentioned "diff" problem would be complicated.

                                  --
                                  hundred-and-one symptoms of being an internet addict:
                                  62. If your doorbell rings, you think hat new mail has arrived. And then
                                  you're disappointed that it's only someone at the door.

                                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                  ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                  \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                • Bram Moolenaar
                                  ... Vim uses several types that end in _t. So far this didn t cause much problems. Renaming them all to _type or similar make all the names a lot longer.
                                  Message 16 of 19 , Apr 14, 2001
                                  • 0 Attachment
                                    Jens M. Felderhoff wrote:

                                    > > Perhaps "lineoff_t". It's a bit longer, but also clearer.
                                    >
                                    > As I already pointed out in a message to Aschwin Marsman (Subject
                                    > "move.c:35: conflicting types for `loff_t'"), identifiers with the
                                    > suffix "_t" are reserved for the X/Open namespace (source: XSH section
                                    > of the Single Unix Specification Version 2).
                                    >
                                    > In order to stay on the safe side I would recommend to rename loff_t
                                    > to loff_type or loff_t_vim.

                                    Vim uses several types that end in _t. So far this didn't cause much
                                    problems. Renaming them all to _type or similar make all the names a lot
                                    longer. How about using _T instead? Or does that conflict with another
                                    standard?

                                    --
                                    hundred-and-one symptoms of being an internet addict:
                                    157. You fum through a magazine, you first check to see if it has a web
                                    address.

                                    /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                    ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
                                    \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                  Your message has been successfully submitted and would be delivered to recipients shortly.