Shell syntax highlighting in %post stops at first blank line after "}"

[rgm3]

In the following snippet the second function is not syntax highlighted, but the first one is:

%post
# Make sure pgHome exists and is not empty
function checkDbDirExists {
  if [ ! -e "${pgHome}" ] || [ "$(find ${pgHome} -maxdepth 0 -empty -exec echo 1 \;)" == "1" ]; then
    dbDirExists="N"
  else
    dbDirExists="Y"
  fi
}

# Make sure the DB has been initialized (initdb)
function initializePg {
  checkDbDirExists
  if [ "${dbDirExists}" == "N" ]; then
    service ${pgSvc} initdb
  fi
}

initializePg

[waveclaw]

Anything in the shell script sections (%build, %pre, %post, etc) are handled by shell language high-lighting. That is whatever is providing your 'source.shell' grammar.

I have no control over what you use for this so cannot fix that inside of RPM Spec parsing.

[rgm3]

I suspect that the RPM spec parsing marks the boundaries for "source.shell" grammar use incorrectly though, because when I change the entire file over to use "shell" highlighting there is no problem with the "second function." If you "connect" the functions such that there is no blank line (by inserting a "#" where the blank line would be) then the shell highlighting continues to the next function.

[rgm3]

Here is a more minimal example demonstrating the problem:

Works:

%prerun
#this is correctly shell syntax highlighted
[ "foo" = "bar" ] && echo "yes"

Broke:

%prerun

#this is not shell syntax highlighted, there is a space above
[ "foo" = "bar" ] && echo "yes"

[rgm3]

I think this is because the "foldingStopMarker" is a blank line, but should instead be the start of the next section or the end of the file.

[waveclaw]

foldingStopMarker controls the folding of sections. It is completely optional for a grammar.

The parsing of sections for highlight is handled inside the grammar itself. Any change to parsing highlight of sections requires changing how sections are parsed.

Patches are welcome if you think you have a solution. There are unit tests for validation but they cannot test shell highlighting. They could only test that everything inside a "section" is marked for source.shell highlighting.

[rgm3]

So, it looks like maybe the problem is with the regular expression for "end" in the 'begin': '^(?:preun|prep|pre ... section of rpm-spec.cson Not sure why this issue was closed? It definitely looks like smarter end markers could resolve this, but I currently lack the knowledge to fix this myself. I tried setting 'end': '^(%(?:preun|prep|pre|postun|post|packagepreun|build|install|files|dir|clean|changelog).*)$', which seemed to improve things except for my %pre and %build blocks.

[waveclaw]

This was closed because I do not intend to work on it.

Yes, to fix this will require that the subsection processing be completely changed. Section headers in RPM files take paramters like package names and options. This is currently ignored. Also, some section-like entries such as %patch or %verify_sig are actually entries that should properly nest inside of specific ordered sections. This will require that a nested parse tree be built. Right now the lexer is handling sections. Of course a half-complete solution may solve the direct reported issue.

If you think you have a solution, as I said, patches are welcome.

[rgm3]

Thanks for the clarification and the plugin, cheers.