Re: Updating the Makefile mode
- --- In SubEthaEdit@yahoogroups.com, Martin Pittenauer <map@...> wrote:
>No, it is not. The contents of <charsintokens> is:
> 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?
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.
>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.
> > 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.
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 aThanks for the clarification, that helps a lot.
> > 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.
>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!
> > 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
- On 19.08.2009, at 18:39, michael_j_barber wrote:
> It looks like SHELL should be identified as a separate token inIndeed I identified this as a bug we will fix for 3.5.1. It causes
> either case. Looks like it could be a bug, as Jeff Groth suggests.
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.The default mode has no entry conditions and is the starting point for
> 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 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
All the best,