Re: Regarding Emacs, js.el, template-strings and syntax-tables

[Anders Lindgren]

In my experience, I can read code easier if the delimiters aren't highlighted the same way the content is. (In other words, the current Ruby implementation isn't ideal for me.)

Yes, so in the case of ruby-mode, the delimiters will have some special face (keyword? IDK), and the content will have the default face.

Keyword-face or builtin-face on top of string-face would work well.

While we're on the subject. I've been thinking about highlighting parameters in functions and blocks in Ruby.

Let's maybe make it an optional mode, so ruby-mode doesn't stand out too much (or discuss whether all modes should do that if possible, on emacs-devel). But I've been looking at this too, albeit from a different standpoint (completion of local variable names).

An optional mode would do nicely.

It wouldn't be too difficult, and it would make code easier to read. Unfortunately, it doesn't include all variables as local variables can be created on the fly using a plain assignment in Ruby.

Finding assignments is easy (just a regexp). Tracking variable scopes (defined by their belonging to methods, or blocks, or even class/module bodies) looks harder to me. We can do that by parsing expressions with SMIE, but that's not fast if we have to parse the whole class body (there are some big classes out there).

Limiting ourselves to only methods might be fine, though.

Methods and do-blocks would be straight forward, and make Ruby code a lot easier to read.

As a parallel, my lisp-extra-font-lock package (https://github.com/Lindydancer/lisp-extra-font-lock) do this in Lisp modes for function and lambda parameters and local variables introduces using `let`, `dolist` et.c. Now that I've been using it for a couple of years, I would not dream of going back to the near black-and-white world of the default lisp modes.

I like the idea, but seeing the red on the screenshot is a bit off-putting. red is for errors.

The screenshot demonstrates all features at once, so it might look a bit overwhelming -- in normal code it doesn't highlight that much.

I've opted to define new faces and make them inherit from the predefined. This allows the faces to be customized (e.g. if you don't like red), and they work when a custom theme is used. I settled on the warning face for two constructs, as it was the least bad one available. So far, I've never misinterpreted a highlighted variable name for an error, or vise versa.

Anyway, I understand your concern. I'll revisit this and see if there is another way to do it.

    -- Anders