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

[Randy Taylor]

On Sunday, February 12th, 2023 at 22:37, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 12/02/2023 04:48, Randy Taylor wrote:
> 
> > > I'm not quite sure what's the best choice here (keeping in mind the
> > > problem with overreaching variable highlights on level 4), but
> > > logically, I think 'module' belongs with 'function' and 'property'
> > > because all three denote some basic syntactic elements which are easy to
> > > understand even without colors, and are harder to make a mistake in.
> > 
> > I am proposing to get rid of the module feature entirely and bring those 
> > queries into the type feature because:
> > - Of how much overlap there is between them
> > - It will make maintaining the queries much easier
> > - It's already a headache dealing with them separately, and I'm not sure 
> > the best way to deal with the issues of them being separate (and the 
> > different levels of highlighting to worry about). It will probably be quite 
> > the hack to deal with it, and no matter what I tried stuff was always 
> > sneaking through.
> > - It also won't introduce that much more highlighting
> 
> 
> Okay, let's try that.
> 
> > > > > Also here's a pre-existing problem mentioned above:
> > > > > 
> > > > > use std::{fmt, fs, usize};
> > > > > 
> > > > > 'fmt' and 'fs' are not types. But they are highlighted with
> > > > > font-lock-type-face.
> > > > 
> > > > This is really weird, I can reproduce it with emacs -Q but not with my 
> > > > normal config...
> > > > Also with emacs -Q this:
> > > > let date = DateTime::chrono::hey::there::Utc::from_utc(date, 
> > > > chrono::cool::this::Utc);
> > > > 
> > > > highlights incorrectly, where "there" is font-lock-variable-name-face. 
> > > > But with my normal config everything is fine.
> > > > 
> > > > I'll look into it tomorrow. Not really sure what in my config could 
> > > > cause this...
> > > 
> > > Thank you.
> > 
> > I did a clean build and wasn't able to reproduce it anymore. Guess it was 
> > stale bytecode or something?
> > At level 4 everything highlights correctly I believe, and with level 3 the 
> > only issues are the module highlighting ones, and to deal with that I think 
> > the module feature should be merged into the type one as I mentioned above. 
> > Then we can call it a day :). I'll post a new patch with those changes if 
> > you agree.
> 
> 
> Please go ahead, and thanks. :-)

Hi Dmitry and Jostein,

Here is the promised patch in all its glory.
I have also attached a screenshot of how things look now.

Changes:
- Attributes are now highlighted with font-lock-preprocessor-face.
- Added import-specific queries to cover all (hopefully...) import highlights, 
and simplified the existing scoped identifier types.
  - Note: I decided that anything at the end of a scoped identifier for imports 
or within a use list that's lowercased should be the default face because we 
don't know if it's a module, function, type, or whatever else. rust-mode also 
does this, and now we match their highlighting almost one for one. neovim and 
the rest do it this way too, and it makes the most sense.

0001-Fix-rust-ts-mode-type-and-module-highlighting-Bug-61.patch
Description: Text Data

2023-02-13-222104.png
Description: PNG image