non-alphabetic operator highlights

[c-blake]

For the past year or so I've been using neovim with this plugin, but I patch in these lines:

syntax match   nimOperator        "[-,:{}()\[\]=+*/<>@$~&%|!?^.\\]"

and

highlight default link nimOperator        Operator

I realize that comma(,) colon(:) cannot really be "operators" exactly. I include them since in many fonts, characters like these are harder to distinguish from each other in the same way. Bold facing or bold italic or color shifts can help make them more obvious. There may be better names for the syntax class such as "NonAlphabeticNonQuotingNonUnderscoreASCII" or just "specialChars".. (and the link into Operator could be just up to the user).

I raise this issue just to see if you might be interested in adding a feature like this directly.

[alaviss]

Usually operators in Nim are functions/templates, which will be highlighted via semantic highlighting via nimsuggest. This is why I don't have an operator highlighting group within the plugin. If you're not seeing highlights then this would be a problem (excluding within templates, since semantic highlighting doesn't work for them until they're instantiated).

I realize that comma(,) colon(:) cannot really be "operators" exactly

For highlighting , or :, I think you can use the Delimiter highlighting group. I left those out because no other syntax plugin include them, and at least for my colorscheme they look terrible :P

[c-blake]

Well, things like -+- need stropping/backquotes in Nim, too, unlike most proc names. So, some charset of such things might be useful. As I mentioned, it needn't be linked in to operator. Colorscheme-wise a user could also just "only bold" these things.

[alaviss]

Colorscheme-wise a user could also just "only bold" these things.

That's not possible with how semantic highlighting is working atm, though I can get that working if there's demand for it.

The way semantic highlighting work is by retrieving the semantic information from nimsuggest, and apply nimSug<SymbolKind but without sk prefix> highlighting group onto them (ie. if node is skProc then nimSugProc will be applied). This overrides any prior highlighting applied to them (this includes highlighting from groups such as nimOperators), which will renders this addition redundant since all operators are currently highlighted by nimsuggest.

[c-blake]

I do bold by justing add 2 above mentioned lines & then to after/syntax/syncolor.vim adding:

hi Operator ctermfg=DarkBlue ctermbg=NONE cterm=bold

but we may be talking about two different things. I do see the semantic template calls vs. proc calls sort of highlighting out of nimsuggest, but I also see bold dark blue special chars with the above on neovim 0.4.4 (but it's worked for like a year..).

{ Well, "worked" except for when nimsuggest goes into an infinite memory leaking loop and freezes my system - only for "bad syntax", but the intermediate state of a file often has such. I don't know how easy it would be to do inside a vim plugin, but any kind of programmatic monitor that could kill nimsuggest after it uses N gigabytes of memory would be a pretty big usability win, but I expect that is some other issue... :-) It's becoming a big enough problem that I may add a process table monitor doing exactly that. I run with 2x the swap of RAM and it takes forever for Linux' OOM killer to kill it. }

Anyway, it's not a big deal. I can keep applying my patches for years, but thought others might like the idea. Operators/delimiters are often both more consequential and physically smaller.

[alaviss]

but we may be talking about two different things. I do see the semantic template calls vs. proc calls sort of highlighting out of nimsuggest, but I also see bold dark blue special chars with the above on neovim 0.4.4 (but it's worked for like a year..).

If it works then I'll consider adding it after some experiments (without the colon and comma, though I might add them as nimDelim). Currently I'm working on some more diagnostics for nim.nvim so this will have to wait.

Linux' OOM killer

Linux OOM killer is designed as a last resort :P For interactive use you should have earlyoom or things like nohang as those acts faster (and more customizable) than the oom killer.

I don't know how easy it would be to do inside a vim plugin, but any kind of programmatic monitor that could kill nimsuggest after it uses N gigabytes of memory would be a pretty big usability win, but I expect that is some other issue...

I can't monitor memory usage of a program inside vimscript in a portable way, sadly. On Linux you can use a shim program that monitor nimsuggest and kill it once the memory usage grew too big.

[c-blake]

consider adding it after some experiments

Ok. Cool.

Yeah...I'm aware of my various non-inbuilt options to kill nimsuggest. It just seems like a common and long-lived problem. Hmm. Maybe nimsuggest could kill itself? :-)

[alaviss]

Maybe nimsuggest could kill itself?

It's actually programmed to do that: https://github.com/nim-lang/Nim/blob/devel/nimsuggest/nimsuggest.nim.cfg#L13, but I've never seen this working in practice.

[c-blake]

Yeah. I've seen it go well over 32 GiB myself. It's honestly not even a problem for me until it hits 31 GiB -- far beyond 4. I guess nimMaxHeap is broken. :(