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

200Re: [SubEthaEdit] Updating the Makefile mode

Expand Messages
  • Martin Pittenauer
    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
    • Show all 6 messages in this topic