bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on fi


From: Dmitry Gutov
Subject: bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties
Date: Wed, 8 Feb 2023 17:44:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 08/02/2023 05:38, Randy Taylor wrote:
On Tuesday, February 7th, 2023 at 13:25, Dmitry Gutov <dgutov@yandex.ru> wrote:
rust-ts-mode looks good to me as well except the imports. Stuff like:
use std::fmt::{Display, Formatter};

is highlighted incorrectly. In the above example, std and fmt are highlighted 
as variables.

This is a result of 'variable' being implemented as it is now --
highlighting all (identifier) nodes that no previous rule has matched.

That makes things complicated when we try to support customizable
highlighting level where the user can mix and match the enabled features.

With imports, there was also another problem which I mentioned here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61205#68

If we highlight the imports as constants on level 3, when the 'function'
feature is disabled, the function names will get highlighted with
font-lock-constant-face as well. That seems undesirable.

But -- and this just occurred to me today -- if we create a separate
feature to add to level 4, with rules defined below 'function', that
should satisfy all the constraints.

I think this is a good idea.


We should give them font-lock-constant-face.

I will try to propose a patch later today unless someone beats me to it.

Try the attached patch, please.

Thanks, it looks good to me.

I think the following rule from the type feature:
(scoped_type_identifier path: (identifier) @font-lock-type-face)

Should be changed to font-lock-constant-face and moved to the module feature.

That way, things like the following will be highlighted correctly:
let date = DateTime::<chrono::Utc>::from_utc(date, chrono::Utc);
                       ^^^^^^ this guy

Unless I'm missing something.

Should Utc in the above example be highlighted with font-lock-constant-face too?

What if it looked like this:

  let date = DateTime::<chrono::utc>::from_utc(date, chrono::utc);

If we decide purely based on capitalization, then I guess the rule should be present in both lists (with capitalized? regexp in one, and !capitalized? regexp in another), and a few more rules should be duplicated as well.

This becomes a little more painful semantically, given that the first 'utc' in the example above is parsed into a (type_identifier) node, not just (identifier).

On a distantly related note, we have terms like 'usize' which is
normally a type (and highlighted as such), but can also feature in
expressions like

   let row = usize::from_str_radix(row, 10).map_err(|_| error())?;

where it is now highlighted with font-lock-constant-face. Should we try
to do anything about that? If there is a limited number of built-in
types in that situation (e.g. all of them primitives), we could handle
that with a regexp.

Right. I think it makes sense to handle the primitives with a regex.
I'm not sure if there's anything else beyond those.
There's a list of them here: https://doc.rust-lang.org/reference/types.html
I think it would only apply to the numerical and textual types.

So 'usize' in the above is definitely a "type", not a "module"?

Or vice versa, in

   use std::{fmt, fs, usize};

should 'fmt', 'fs' and 'usize' be highlighted with
font-lock-constant-face rather than font-lock-type-face?

They should indeed be highlighted with font-lock-constant-face because they are 
modules.
We assume the types will be capitalized since that's all we can really do (and 
it's the convention anyway).

If they're modules here, I suppose they should be highlighted the same in

  let row = usize::from_str_radix(...)

as well. The bright side is that will make a more complex regexp (enumerating the lowercase named types) unnecessary.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]