Emacs - syntax highlighting colors


One of my earlier posts included two or three (interconnected) fixes. I’ll submit them as a first PR to your GitHub repo. Do you also check the discussion on GitHub regularly? Where do you prefer?

For example, the operator fix:

const PREC = { CALL: 140, BIN: 20 };

function_call: $ => prec.left(PREC.CALL, seq(
  field('receiver', $._primary),
  repeat1($.method_call)
));

binary_expression: $ => prec.left(PREC.BIN, seq(
  field('left',  $._object),
  field('operator', choice(
    '||','&&','|','^','&','==','!=','<','<=','>','>=',
    '<<','>>','+','-','++','+/+','*','/','%','**'
  )),
  field('right', $._object)
));

This fixes most operators, but it’s still not quite correct. One question is **: in SC it isn’t a special math operator, but a method selector defined on Object. That’s a semantic particular, not a parsing rule, so it shouldn’t get special precedence. The correct solution is to maintain all binary operators in a flat, left-to-right tier, while ensuring that message sends always bind “tighter” than binary expressions.

This also connects to the .midiratio issue. Currently, the grammar lets a postfix method chain attach to any expression—including a complete binary expression. So the parser builds: receiver = the whole \freq.kr(440) * (…) then applies .midiratio to that receiver.

To fix this, postfix chains must be part of the operand (a “term”), not something that can wrap a finished binary expression. That change affects the operator rule too:

const PREC = { CALL: 140, BIN: 20 };


_primary: $ => choice(
  $.number, $.string, $.symbol, $.variable, $.class,
  $.collection, $.code_block, $.group
),

group: $ => seq('(', $._expression, ')'),

_postfix: $ => choice(
  prec.left(PREC.CALL, seq($._primary, repeat1($.method_call))),
  $._primary
),

method_call: $ => seq(
  '.',
  field('name', alias($.identifier, $.method_name)),
  optional(seq('(', optional($.parameter_call_list), ')'))
),

// keep identifier ':' only in named args / associative items
parameter_call_list: $ => sepBy1(',', choice($.named_argument, $._object)),

named_argument: $ => seq(
  field('name',  choice($.symbol, $.identifier)),
  ':',
  field('value', $._object)
),


binary_expression: $ => prec.left(PREC.BIN, seq(
  field('left',  $._postfix),
  field('operator', choice(
    '||','&&','|','^','&','==','!=','<','<=','>','>=',
    '<<','>>','+','-','++','+/+','*','/','%','**'
  )),
  field('right', $._postfix)
));

Alternatively, if you want to keep function_call as the chain node:

function_call: $ => prec.left(PREC.CALL, seq(
  field('receiver', $._primary),
  repeat1($.method_call)
)),

_postfix: $ => choice($.function_call, $._primary),

Let’s put this to the test and see how it goes. I just rewrote my earlier post, did not do any additional testing myself.

EDIT:

Just tested it here. It looks relatively bold and hard and it stays until the bracket is closed.
I prefer an option to have this optional with the old implementation. Maybe without the highlight and with less contrast it will look better integrated.

Or what would be even better: Show the mini preview in the mini buffer, but keep it until the bracket is closed.

1 Like

We can fine-tune it. But it seems to be closer to SCIDE now.

What completion package are you using? Company or corfu?

1 Like

I’m using company. Also getting these messages like other people, e.g. when opening the bracket after SinOsc.ar:

“Company: backend company-capf error “Scan error: “Containing expression ends prematurely”, 1579, 1579” with args (prefix)”

1 Like

Ok, I am using corfu, not company.

Maybe I should put this code in a repo, and we can start fine-tuning it from there?

1 Like

Yes, sounds good. :slight_smile: As I’m quite new would also be good what other more experienced users say.

1 Like

Hey @smoge, your highlighting fix works for me as well.
Thanks!

1 Like

This message is specific to the syntax highlighting bug-fix code only

Ok, so it seems I should submit this fix. It’s simple and it makes a huge difference for every user.

I believe the rule (for the supercollider project as a whole) is always to have more pairs of eyes when making changes, even fixing simple bugs.

Could someone please update me on the situation regarding the maintainers of the supercollider/scel repository on GitHub? Does it have a team or a review process?

Peace

1 Like