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

Re: Long lines result in VAX C debugger problems.

Expand Messages
  • Bram Moolenaar
    Walter Briscoe wrote: Since it has taken so long to run into this problem it seems that very few compilers have a problem with long lines. ... Do you mean that
    Message 1 of 7 , Nov 7, 2003
      Walter Briscoe wrote:

      Since it has taken so long to run into this problem it seems that very
      few compilers have a problem with long lines.

      > >For this compiler we could disable the Lisp function, that should work
      > >around the problem.
      > I don't think so. The problem is that a source line is longer than 255
      > bytes. In the dim and distant past, I worked on VaxC symbol display and
      > that is my hazy memory. Can Jim check?

      Do you mean that when you put a long line in between "#ifdef asdf" and
      "#endif" the compiler will still refuse to compile the file?

      > This does not work for the other 2 long strings. We could split the
      > definitions into chunks and load the data in option.c. I don't like
      > doing that as it requires the programmer to do more work. However, it
      > does seem it will work and fit all constraints. What does Bram think?

      I don't like making the code more difficult for a rare compiler. But if
      this code prevents people from using Vim on a specific platform, I could
      include a patch that fixes this (if it's tested).

      --
      Why I like vim:
      > I like VIM because, when I ask a question in this newsgroup, I get a
      > one-line answer. With xemacs, I get a 1Kb lisp script with bugs in it ;-)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
    • Walter Briscoe
      In message of Fri, 7 Nov 2003 16:41:52 in , Bram Moolenaar writes ... The problem is in the
      Message 2 of 7 , Nov 7, 2003
        In message <200311071541.hA7FfqZX007747@...> of Fri, 7 Nov
        2003 16:41:52 in , Bram Moolenaar <Bram@...> writes
        >
        >Walter Briscoe wrote:
        >
        >Since it has taken so long to run into this problem it seems that very
        >few compilers have a problem with long lines.
        The problem is in the debugger rather than the compiler. I doubt if 1 in
        100 vim users run vim through their debugger.

        >
        >> >For this compiler we could disable the Lisp function, that should work
        >> >around the problem.
        >> I don't think so. The problem is that a source line is longer than 255
        >> bytes. In the dim and distant past, I worked on VaxC symbol display and
        >> that is my hazy memory. Can Jim check?
        >
        >Do you mean that when you put a long line in between "#ifdef asdf" and
        >"#endif" the compiler will still refuse to compile the file?
        No! The code compiles happily. The debugger can't handle it.
        It is a long time ago. Jim can confirm or contradict what Bram and I
        expect to happen.

        >
        >> This does not work for the other 2 long strings. We could split the
        >> definitions into chunks and load the data in option.c. I don't like
        >> doing that as it requires the programmer to do more work. However, it
        >> does seem it will work and fit all constraints. What does Bram think?
        >
        >I don't like making the code more difficult for a rare compiler. But if
        >this code prevents people from using Vim on a specific platform, I could
        >include a patch that fixes this (if it's tested).
        >
        I intend to eliminate long lines to deal with the vagaries of a rare
        compiler. Like Bram, I don't have that compiler. I do have others and
        will obviously put any proposed patch through those before submitting
        it. I will check the fix works for me. I will also get Jim to confirm it
        hits his problem. I can do no more. Watch this space ;-)
        --
        Walter Briscoe
      Your message has been successfully submitted and would be delivered to recipients shortly.