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

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

>
> 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

[-- Attachment #2: Type: text/html, Size: 4275 bytes --]