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

Updating the Makefile mode

Expand Messages
  • michael_j_barber
    I ve begun adding folding support to the Makefile mode, specifically by adding a Command state to indicate the blocks of build commands for a target. I have a
    Message 1 of 6 , Aug 15, 2009
    • 0 Attachment
      I've begun adding folding support to the Makefile mode, specifically by adding a Command state to indicate the blocks of build commands for a target. I have a few questions and observations.

      First, the keywords are not colored as I would expect. As a specific example of the issue, consider the following two lines:
      SHELL=/bin/sh
      SHELL = /bin/sh
      The SHELL in the first line is colored as a keyword, the SHELL in the second is not. Some keywords don't ever seem to be colored. This happens with the unmodified Makefile mode as downloaded from the codingmonkeys.de website, before I make any changes. I really don't have any idea why this is. The definitions seem consistent with how keywords are given in other modes, so I suspect it may have something to do with the state definitions.

      Second, where should states actually be defined? The C mode has all states as substates of the default state. The current Makefile mode has a default mode and two other modes (SingleComment and String) at the same level. What makes more sense, here?

      I relatively arbitrarily decided that I'd put the new state at the same level as the other three, and not as a substate of the default state. After some experimentation, I've arrived at this:
      <state id="Command" type="block" foldable="yes">
      <begin><regex>(?:^\t)</regex></begin>
      <end><regex>[\n\r](?=[^\t])</regex></end>
      <import keywords-only="yes" />
      <state-link state="SingleComment" />
      <state-link state="String" />
      </state>
      That is, a command block starts with a tab at the beginning of a line and ends with a linefeed or carriage return that is not followed by a tab. The keywords are imported from the default state, and the SingleComment and String states are linked. Note that a single <import /> wouldn't work, as it would lead to nested blocks instead of keeping consecutive tab-indented lines in the same block.

      As I understand the file format, as described at <http://codingmonkeys.de/subethaedit/mode.html>, it should have been possible to use imports instead of the state links, but it did not work. Why is this?

      The end regex for the Command state is quite similar to that for the SingleComment state, which ends with [\n\r]. The similarity produces an edge case where a command block cannot end with a comment line; in such a case, the following line is taken as part of the command block. It seems clear enough why this is: the final linefeed of the command block is taken to close the comment, so another one is needed to close the command block. That makes sense; otherwise, it would not be possible to, e.g., nest curly braces. Should I just accept this edge case, or is there a solution?

      Incidentally, I think the definition is wrong. I don't think a carriage return \r is a valid line ending for a makefile. It is not in GNU Make, at least. I just followed what was already in the SingleComment state. Can anyone provide an authoritative answer to this?
    • jtgroth007
      ... I noticed similar behavior in the PHP-HTML mode and I filed a bug for it (SEE-3865). As excited as I am for the code folding, I had to downgrade to 3.2.1,
      Message 2 of 6 , Aug 19, 2009
      • 0 Attachment
        --- In SubEthaEdit@yahoogroups.com, "michael_j_barber" <michael_j_barber@...> wrote:
        > First, the keywords are not colored as I would expect. As a specific example of the issue, consider the following two lines:
        > SHELL=/bin/sh
        > SHELL = /bin/sh
        > The SHELL in the first line is colored as a keyword, the SHELL in the second is not. Some keywords don't ever seem to be colored. This happens with the unmodified Makefile mode as downloaded from the codingmonkeys.de website, before I make any changes. I really don't have any idea why this is. The definitions seem consistent with how keywords are given in other modes, so I suspect it may have something to do with the state definitions.
        >

        I noticed similar behavior in the PHP-HTML mode and I filed a bug for it (SEE-3865). As excited as I am for the code folding, I had to downgrade to 3.2.1, because the inconsistent and erratic syntax coloring was proving to be a distraction and decreasing my productivity.

        Jeff Groth
      • Martin Pittenauer
        ... Is = part of in your case? ... Usually the default state is a parent to all other states. ... imports the contents of a state into
        Message 3 of 6 , Aug 19, 2009
        • 0 Attachment
          On 15.08.2009, at 15:16, michael_j_barber wrote:

          > I've begun adding folding support to the Makefile mode, specifically
          > by adding a Command state to indicate the blocks of build commands
          > for a target. I have a few questions and observations.
          >
          > First, the keywords are not colored as I would expect. As a specific
          > example of the issue, consider the following two lines:
          > SHELL=/bin/sh
          > SHELL = /bin/sh
          > The SHELL in the first line is colored as a keyword, the SHELL in
          > the second is not. Some keywords don't ever seem to be colored. This
          > happens with the unmodified Makefile mode as downloaded from the codingmonkeys.de
          > website, before I make any changes. I really don't have any idea
          > why this is. The definitions seem consistent with how keywords are
          > given in other modes, so I suspect it may have something to do with
          > the state definitions.

          Is = part of <charsintokens> in your case?


          > Second, where should states actually be defined? The C mode has all
          > states as substates of the default state. The current Makefile mode
          > has a default mode and two other modes (SingleComment and String) at
          > the same level. What makes more sense, here?

          Usually the default state is a parent to all other states.

          > That is, a command block starts with a tab at the beginning of a
          > line and ends with a linefeed or carriage return that is not
          > followed by a tab. The keywords are imported from the default state,
          > and the SingleComment and String states are linked. Note that a
          > single <import /> wouldn't work, as it would lead to nested blocks
          > instead of keeping consecutive tab-indented lines in the same block.

          <import> imports the contents of a state into another. I.e. if you
          want to create a state that behave like the default, but with
          additional state, import is the way to go. You have to provide a frame
          (state/begin/end) to import into.

          <state-link> places an existing state as a child into another state.
          I.e. if you want to have the string state in another state, with begin/
          end conditions intact.


          > Should I just accept this edge case, or is there a solution?

          I tend to use .(?=[\n\r]) in these cases to have proper state
          termination.

          Allt the best,
          Martin
        • Martin Pittenauer
          ... Not sure these issues are related. I m sorry for the bug however. We will try to address it for 3.5.1 which should be due in about 2 weeks. All the best,
          Message 4 of 6 , Aug 19, 2009
          • 0 Attachment
            On 19.08.2009, at 16:49, jtgroth007 wrote:

            > I noticed similar behavior in the PHP-HTML mode and I filed a bug
            > for it (SEE-3865). As excited as I am for the code folding, I had to
            > downgrade to 3.2.1, because the inconsistent and erratic syntax
            > coloring was proving to be a distraction and decreasing my
            > productivity.

            Not sure these issues are related.
            I'm sorry for the bug however. We will try to address it for 3.5.1
            which should be due in about 2 weeks.

            All the best,
            Martin
          • michael_j_barber
            ... No, it is not. The contents of is: It looks like SHELL
            Message 5 of 6 , Aug 19, 2009
            • 0 Attachment
              --- In SubEthaEdit@yahoogroups.com, Martin Pittenauer <map@...> wrote:
              >
              >
              > On 15.08.2009, at 15:16, michael_j_barber wrote:
              >
              > > First, the keywords are not colored as I would expect. As a specific
              > > example of the issue, consider the following two lines:
              > > SHELL=/bin/sh
              > > SHELL = /bin/sh
              > > The SHELL in the first line is colored as a keyword, the SHELL in
              > > the second is not. Some keywords don't ever seem to be colored. This
              > > happens with the unmodified Makefile mode as downloaded from the codingmonkeys.de
              > > website, before I make any changes. I really don't have any idea
              > > why this is. The definitions seem consistent with how keywords are
              > > given in other modes, so I suspect it may have something to do with
              > > the state definitions.
              >
              > Is = part of <charsintokens> in your case?
              >
              No, it is not. The contents of <charsintokens> is:
              <![CDATA[_0987654321abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@-.]]>

              It looks like SHELL should be identified as a separate token in either case. Looks like it could be a bug, as Jeff Groth suggests.

              >
              > > Second, where should states actually be defined? The C mode has all
              > > states as substates of the default state. The current Makefile mode
              > > has a default mode and two other modes (SingleComment and String) at
              > > the same level. What makes more sense, here?
              >
              > Usually the default state is a parent to all other states.
              >
              Why, though? The makefile mode has them separate, and it doesn't seem to cause any harm. I'm looking for understanding of the options.

              I suppose I should make clear at this point that, even though I'm listed on the modes page as a contributor for the Makefile mode, I had nothing to do with the definition of the syntax -- all I did was add the script and triggers for files with the standard names for makefiles.

              > > That is, a command block starts with a tab at the beginning of a
              > > line and ends with a linefeed or carriage return that is not
              > > followed by a tab. The keywords are imported from the default state,
              > > and the SingleComment and String states are linked. Note that a
              > > single <import /> wouldn't work, as it would lead to nested blocks
              > > instead of keeping consecutive tab-indented lines in the same block.
              >
              > <import> imports the contents of a state into another. I.e. if you
              > want to create a state that behave like the default, but with
              > additional state, import is the way to go. You have to provide a frame
              > (state/begin/end) to import into.
              >
              > <state-link> places an existing state as a child into another state.
              > I.e. if you want to have the string state in another state, with begin/
              > end conditions intact.
              >
              Thanks for the clarification, that helps a lot.

              >
              > > Should I just accept this edge case, or is there a solution?
              >
              > I tend to use .(?=[\n\r]) in these cases to have proper state
              > termination.
              >
              Ah, that does it. I had not properly understood how SEE handles the states. For others who might have had the same confusion, colorization of the state includes the begin and end text, while the folding excludes it. Rather a nice solution for just this case!
            • Martin Pittenauer
              ... Indeed I identified this as a bug we will fix for 3.5.1. It causes some keyword groups to not highlight consistently currently. Sorry for that. Took me a
              Message 6 of 6 , Aug 25, 2009
              • 0 Attachment
                On 19.08.2009, at 18:39, michael_j_barber wrote:

                > It looks like SHELL should be identified as a separate token in
                > either case. Looks like it could be a bug, as Jeff Groth suggests.

                Indeed I identified this as a bug we will fix for 3.5.1. It causes
                some keyword groups to not highlight consistently currently. Sorry for
                that. Took me a while to catch it.

                > > Usually the default state is a parent to all other states.
                > >
                > Why, though? The makefile mode has them separate, and it doesn't
                > seem to cause any harm. I'm looking for understanding of the options.

                The default mode has no entry conditions and is the starting point for
                the parser. Any state with starting conditions that is neither
                referenced nor included is only handled correctly because the syntax
                definition parser is very liberal to maintain backwards compatibility
                with definitions made before we had nested states.

                So, in short, not having states as childs of default works, but should
                be avoided.

                All the best,
                Martin
              Your message has been successfully submitted and would be delivered to recipients shortly.