Scala mode doesn't ignore /* in ``

[jackcviers]

implicit val AssetUploadAndMetadataUnmarshaller = Unmarshaller[AssetUploadAndMetadata](ContentTypeRange(MediaRanges.`multipart/*`)){
  * case(HttpEntity.NonEmpty(contentType, data)) => "aaarg!"
}

Note that multipart/* is inside backticks. scala-mode-2 considers that to be the start of a comment, and C-M inserts a * at the beginning of the new line. Additionally, if I fix that and remove the hanging *, the indentation screws up:

implicit val AssetUploadAndMetadataUnmarshaller = Unmarshaller[AssetUploadAndMetadata](ContentTypeRange(MediaRanges.`multipart/*`)){
    case(HttpEntity.NonEmpty(contentType, data)) =>
    * "aaargh"

I think the culpable regex for the coloring is here: https://github.com/hvesalai/scala-mode2/blob/master/scala-mode2-fontlock.el#L489

But I am not sure. I will try adding a "not `" on the regex and make a pull request if that fixes it. I assume that something similar will be found for indentation.

[hvesalai]

You have nice variable names :)

The culpit is how emacs handles comments. Anything that is not a string is scanned for comment begin mark (/* or //) and since variable names (inside backticks or not) are not considered as strings, you get bitten.

The proper way to fix this would be to modify the syntax-propertize-function so that it marks the /* as "symbol constituent" when the sequence appears inside backticks. The current syntax-propertize-function is here: https://github.com/hvesalai/scala-mode2/blob/master/scala-mode2-syntax.el#L537.

An other option would be to make backticks be string delimiters (i.e. making scala symbols be strings from emacs' point of view) by modifying the syntax table that is here: https://github.com/hvesalai/scala-mode2/blob/master/scala-mode2-syntax.el#L406 and then to modify the function you pointed to to font-lock (i.e. colorise) them as normal code.

The latter would maybe be easyer.

The code line you pointed to just decides how comments and strings are colored, so changing that will not fix this issue.

I think I will not try to fix this issue my self, but I will gladly accept any clean fix for it as a pull request.

[emanresusername]

has there been any movement on this one?

[fommil]

Would you be interested in looking into it? It's the only way it'll get fixed because it's not bothering me or Heikki.

[emanresusername]

Definitely interested But my elisp-fu is very weak at the moment 😅

…

On Sat, Dec 24, 2016 at 01:24 Sam Halliday ***@***.***> wrote: Would you be interested in looking into it? It's the only way it'll get fixed because it's not bothering me or Heikki. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0hN0ReHc00iW_LhU9fLmRfY2f3llsTks5rLOTGgaJpZM4Bqucx> .

[fommil]

We have a contributors page is the Emacs section of ensime.org to get you started with some material.