Thomas Smith

Your thoughts parallel my own. In particular, I agree that we have to address the general problem in a general way. I do think that `variable.other` is the correct scope...

I wrote up a rough draft based on the discussion. Comments welcomed. ## `entity.name`: declaring a name. When a name is *declared*, scope it under `entity.name`. Use `entity.name.function` for the...

> I prefer `variable.function` over `variable.other.function`, so we can reserve `variable.other` for stuff we don't know anything about. I've been using the model of `variable.`, where a “vocabulary” is a...

> The support scope must come after `variable.other`, however. Agreed. > So, do we want to pretend they are different vocabulary when used in statically typed languages (or in Python...

> The question arises whether to scope built-in types on top of that (as you'd do `storage` as a meta scope here, more or less), so with the example of...

I think I'm convinced. For one thing, if we didn't scope `new`-like constructs using `variable.*.type`, then in Python we'd scope `Abc(2.3)` as `variable.other.function`, which seems wrong in a very preventable...

I think I get it now: `storage.type` *would* almost always be stacked with a `variable` scope. It may not be completely redundant though. In C#, `dynamic` should probably be `storage.type`...

# Use the Stack Long chains of `set` contexts can be difficult to follow and impossible to understand at a glance. When you have a construction where you expect a...

# Preprocessing with YAML Macros Syntax definitions can have a lot of repetitive elements to them. Sometimes, these elements are simple enough that you can simple `include` a utility context:...

It seems like the easy fix would be replacing the `default\b` pattern in the indent rules with something like `default:\b` (and perhaps something similar for `case`). I'm not that familiar...