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

Re: [jasspa] suddenly everything quote highlighted!

Expand Messages
  • Reza Roboubi
    ... that would be useful. ... Okay, the attached file will narrow it down pretty nicely. Line 52 must be scrolled to the top of the page and then the
    Message 1 of 8 , Oct 31, 2011
    • 1 Attachment
    • 127 Bytes
    On 11-10-31 06:11 AM, Jon Green wrote:
    > If you are able to send some code that reproduces the issue then
    that would be useful.
    >

    Okay, the attached file will narrow it down pretty nicely. Line 52 must
    be scrolled to the top of the page and then the highlighting is wrong.
    This is the version information and buffer mode is a standard .c file:
    -------------------------
    MicroEmacs 09 - Date 2009/10/11 - linux

    Global Status:
    # buffers : 3
    Modes on : autosv backup cr fence magic tab undo
    Modes off : binary crypt ctrlz edit exact hide indent justify lf lock
    nact
    narrow over pipe rbin time view wrap

    Current Buffer Status:
    Buffer : ooo.c
    File name : /home/reza/backup/prj/proof.noauto/ooo.c
    Lines : Total 52, Current 0
    Characters: Total 127, Current 0
    Modes on : autosv backup cr fence magic tab time undo
    Modes off : binary crypt ctrlz edit exact hide indent justify lf lock
    nact
    narrow over pipe rbin view wrap

    Copyright (C) 1988-2009 JASSPA (www.jasspa.com)
    ------------------------

    PS: The strange comment which breaks things is for real; it's related
    to how the thing must be compiled.

    Many thanks. :)

    Reza.
  • Jon Green
    ... Hi Reza, The issue is the look-back length in the template file. In the file scenario that you have posted then by scrolling to line 52 then the
    Message 2 of 8 , Oct 31, 2011
    • 0 Attachment
      On 31/10/2011 15:07, Reza Roboubi wrote:
      > On 11-10-31 06:11 AM, Jon Green wrote:
      > > If you are able to send some code that reproduces the issue then
      > that would be useful.
      > >
      >
      > Okay, the attached file will narrow it down pretty nicely. Line 52 must
      > be scrolled to the top of the page and then the highlighting is wrong.
      > This is the version information and buffer mode is a standard .c file:
      Hi Reza,

      The issue is the look-back length in the template file. In the file scenario
      that you have posted then by scrolling to line 52 then the highlighting is
      expected to look back more than 50 lines in order to find an anchor point on
      which to base its highlighting scheme for the current line.

      If you look at hkc.emf which performs the highlighting then the template is
      defined with a 50 line look back at line 110 i.e.

      ; Hi-light C Mode
      0 hilight .hilight.c 2 50

      Parameter 1 (=.hilight.c) is the highlight number.
      Parameter 2 (=2) is the bitmask and sets the highlight look-back
      Parameter 3 (=50) is the "nol" parameter which specifies the number of lines to
      look back.

      50 is a typical value that works for most code. For your code then this is not
      enough and you could change it to perform a longer look-back. The problem in
      the file disappears if you change the look-back size to 150 (say) i.e.

      ; Hi-light C Mode
      0 hilight .hilight.c 2 150

      You can change the look-back to any value, the bigger the value the more
      processing is required so it is best to find a reasonable value. The look-back
      does stop when it finds a token.

      To fix then copy the file hkc.emf to your local .jasspa (or .jasspa/macros)
      directory and then edit it to over-ride the default file (typically in
      /usr/share/jasspa/macros/hkc.emf for linux). Re-start the editor or re-execute
      the macro file and the issue will be resolved.

      Hope that helps.

      Regards
      Jon.
    • Reza Roboubi
      ... Thank you Jon. First, the problem is that the quotes are escaped. Without the escapes everything works. In this simple case, the easy work-around is to
      Message 3 of 8 , Oct 31, 2011
      • 0 Attachment
        On 11-10-31 01:19 PM, Jon Green wrote:
        >
        > On 31/10/2011 15:07, Reza Roboubi wrote:
        > > On 11-10-31 06:11 AM, Jon Green wrote:
        > > > If you are able to send some code that reproduces the issue then
        > > that would be useful.
        > > >
        > >
        > > Okay, the attached file will narrow it down pretty nicely. Line 52 must
        > > be scrolled to the top of the page and then the highlighting is wrong.
        > > This is the version information and buffer mode is a standard .c file:
        > Hi Reza,
        >
        > The issue is the look-back length in the template file. In the file
        > scenario
        > that you have posted then by scrolling to line 52 then the
        > highlighting is
        > expected to look back more than 50 lines in order to find an anchor
        > point on
        > which to base its highlighting scheme for the current line.
        >
        > If you look at hkc.emf which performs the highlighting then the
        > template is
        > defined with a 50 line look back at line 110 i.e.
        >
        > ; Hi-light C Mode
        > 0 hilight .hilight.c 2 50
        >

        Thank you Jon. First, the problem is that the quotes are escaped.
        Without the escapes everything works. In this simple case, the easy
        work-around is to put such comments inside separate "README" files.

        The "hilight 150" look-back feature isn't _really_ for handling this
        problem, but rather, the "50" is the "largest comment size possible" in
        case that you are actually starting _inside_ a comment already.

        Eventually (if not too messy) it would be great to modify hilight to be
        globally precise and complete: hilight only needs to mark, globally and
        persistently, per-buffer, approximately every 40 lines or 400 characters
        or so. The marking says: "This Line Or Character lies outside any
        bracketed region."

        With markings like that we can _completely_ eliminate hilight's
        "look-back" parameter. The user never even needs to know about hilight
        look-backs.

        That way hilight can even scale to ridiculously huge files (for example
        preprocessed output or whatever else.)

        Reza.
      • Jon Green
        ... Hi Reza, I do not quite agree with your analysis because the quotes are fine in the comment when the current position is less than the look-back distance
        Message 4 of 8 , Oct 31, 2011
        • 0 Attachment
          On 31 Oct 2011, at 21:33, Reza Roboubi <reza@...> wrote:

          > On 11-10-31 01:19 PM, Jon Green wrote:
          >>
          >> On 31/10/2011 15:07, Reza Roboubi wrote:
          >>> On 11-10-31 06:11 AM, Jon Green wrote:
          >>>> If you are able to send some code that reproduces the issue then
          >>> that would be useful.
          >>>>
          >>>
          >>> Okay, the attached file will narrow it down pretty nicely. Line 52 must
          >>> be scrolled to the top of the page and then the highlighting is wrong.
          >>> This is the version information and buffer mode is a standard .c file:
          >> Hi Reza,
          >>
          >> The issue is the look-back length in the template file. In the file
          >> scenario
          >> that you have posted then by scrolling to line 52 then the
          >> highlighting is
          >> expected to look back more than 50 lines in order to find an anchor
          >> point on
          >> which to base its highlighting scheme for the current line.
          >>
          >> If you look at hkc.emf which performs the highlighting then the
          >> template is
          >> defined with a 50 line look back at line 110 i.e.
          >>
          >> ; Hi-light C Mode
          >> 0 hilight .hilight.c 2 50
          >>
          >
          > Thank you Jon. First, the problem is that the quotes are escaped.
          > Without the escapes everything works. In this simple case, the easy
          > work-around is to put such comments inside separate "README" files.
          >
          > The "hilight 150" look-back feature isn't _really_ for handling this
          > problem, but rather, the "50" is the "largest comment size possible" in
          > case that you are actually starting _inside_ a comment already.
          >
          > Eventually (if not too messy) it would be great to modify hilight to be
          > globally precise and complete: hilight only needs to mark, globally and
          > persistently, per-buffer, approximately every 40 lines or 400 characters
          > or so. The marking says: "This Line Or Character lies outside any
          > bracketed region."
          >
          > With markings like that we can _completely_ eliminate hilight's
          > "look-back" parameter. The user never even needs to know about hilight
          > look-backs.
          >
          > That way hilight can even scale to ridiculously huge files (for example
          > preprocessed output or whatever else.)
          >
          > Reza.
          >
          >


          Hi Reza,

          I do not quite agree with your analysis because the quotes are fine in the comment when the current position is less than the look-back distance away. If the quotes in the comment were generally a problem then you would expect this to cause a problem irrespective of the actual distance of the offending statement away from the comment.

          You can check out it is the look back length by changing the value to 51 and the bad highlighting is then ok. Then insert a new line into ooo.c before the statement and scroll up the window then the highlight anomaly returns. You can repeat this a few times by changing the look back and then line position.

          So I would not expect that you should be forced to re-organise your codebase by taking some drastic action to separate out some of the code because of the editor you use.

          There are a lot of look back sizes in the template file for the various hilighting schemes, including comments. I think we should parameterise these values so that it is much easier to increase them all in one go rather than using constants. 50 is a little small these days, especially for some of the public domain software with large version histories and licenses contained, with the current processing power available the longer look back does not really become noticeable.

          As for your idea of putting down anchors, this has potential benefits, I am not sure if this completely eradicates look back in its entirety because it must still be performed for brackets in lines.

          Regards
          Jon.



          > ------------------------------------
          >
          > __________________________________________________________________________
          >
          > This is an unmoderated list, but new members are moderated to ensure that there are no spam users. JASSPA is not responsible for the content of
          > any material posted to this list.
          >
          > To un-subscribe, send a mail message to
          >
          > mailto:jasspa-unsubscribe@yahoogroups.com
          >
          > or visit http://groups.yahoo.com/group/jasspa and
          > modify your account settings manually.
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Reza Roboubi
          Hi Jon, ... The question isn t what the problem is. The question is, what s the solution? We both agree that changing the look-back length _only_ solves this
          Message 5 of 8 , Oct 31, 2011
          • 0 Attachment
            Hi Jon,

            On 11-10-31 03:54 PM, Jon Green wrote:
            >
            > I do not quite agree with your analysis because the quotes are fine in
            > the comment when the current position is less than the look-back
            > distance away. If the quotes in the comment were generally a problem
            > then you would expect this to cause a problem irrespective of the
            > actual distance of the offending statement away from the comment.
            >
            The question isn't what the problem is. The question is, what's the
            solution? We both agree that changing the look-back length _only_
            solves this issue if we set look-back >= file-line-number. That's a fact.
            >
            > As for your idea of putting down anchors, this has potential benefits,
            > I am not sure if this completely eradicates look back in its entirety
            > because it must still be performed for brackets in lines.
            >
            Yes, hilight will simply have to look back until it finds the first
            anchor outside of the window's view port. That way, you get global and
            scalable highlighting, for any language or file size. And I suspect
            it's pretty easy to do: Could someone who knows the source code well
            give clear instructions of what needs to change and the potential
            pitfalls to watch for?

            Reza.
          • Reza Roboubi
            I m very sorry for the stupid formatting of my last email. The line spaces were all broken:
            Message 6 of 8 , Oct 31, 2011
            • 0 Attachment
              I'm very sorry for the stupid formatting of my last email. The line
              spaces were all broken:

              On 11-10-31 04:40 PM, Reza Roboubi wrote:
              > Hi Jon,
              >
              > On 11-10-31 03:54 PM, Jon Green wrote:
              >>
              >> I do not quite agree with your analysis because the quotes are fine
              >> in the comment when the current position is less than the look-back
              >> distance away. If the quotes in the comment were generally a problem
              >> then you would expect this to cause a problem irrespective of the
              >> actual distance of the offending statement away from the comment.
              >>

              > The question isn't what the problem is. The question is, what's the
              > solution? We both agree that changing the look-back length _only_
              > solves this issue if we set look-back >= file-line-number. That's a
              > fact.

              >> As for your idea of putting down anchors, this has potential
              >> benefits, I am not sure if this completely eradicates look back in
              >> its entirety because it must still be performed for brackets in lines.
              >>

              > Yes, hilight will simply have to look back until it finds the first
              > anchor outside of the window's view port. That way, you get global
              > and scalable highlighting, for any language or file size. And I
              > suspect it's pretty easy to do: Could someone who knows the source
              > code well give clear instructions of what needs to change and the
              > potential pitfalls to watch for?
              >
              > Reza.
            Your message has been successfully submitted and would be delivered to recipients shortly.