Sublime Forum

Scoping Best Practices

#1

I was playing around with the expand selection to scope and realized that the way I’ve constructed my scopes permits some weird behavior.

So, in the language I’m working on, there are lot of constructs of the type where there is a declaration/prologue section, and then a body section. For instance:

architecture rtl of my_thing is
    <declarative items>
begin
    <body statements>
end architecture rtl;

This is probably the simplest example, though with subprograms it can get a little messier still as there’s usually also an argument section.

So, in scoping, here’s the stack I’ve created and that you would see as the point moves through the sections.

source.vhdl
source.vhdl meta.block.architecture-declarations.vhdl
source.vhdl meta.block.architecture-body.vhdl
source.vhdl

Now, expand selection to scope seems to work more on scope stack levels than anything. If I place the cursor in the body of the statement, and I expand selection to scope, it’ll grab everything in the body. However if I hit it again, it’ll grab the ENTIRE DOCUMENT. It does not expand to everything in the architecture because the next scope stack level is the base source.vhdl line.

So, I am wondering, am I violating a good practice in scoping? I could create the following in traversing the same structure:

source.vhdl
source.vhdl meta.block.architecture.vhdl meta.section.architecture-declarations.vhdl
source.vhdl meta.block.architecture.vhdl meta.section.architecture-body.vhdl
source.vhdl.

So, I think in this case, expand selection to scope would behave more predictably. Using the same example as before, I THINK the scope would expand to the body, then the entire architecture, then the entire document.

Here’s the kicker though. The Scope Naming document does state in the meta section that “For example, meta.function.php meta.function.parameters.php should never occur, but instead the scopes should alternate between meta.function.php and meta.function.parameters.php and back to meta.function.php.” That’s what I’ve done, however again… it messes up expand selection to scope.

Anyone else attempt to go for this level of granularity and did they side with making the editor work properly or adhering to the scope naming document?

2 Likes
#2

Why not:

source.vhdl
source.vhdl meta.block.architecture.declarations.vhdl
source.vhdl meta.block.architecture.body.vhdl
source.vhdl

I’m not sure that will work like you want with Expand to Scope, but I’m pretty sure Expand to Scope is bugged anyway, so I wrote my own implementation that does what I expect (What exactly does “Expand Selection to Scope” do?).

2 Likes
#3

Yeah, the question is the usage of expand to scope. I haven’t tried your Python replacement yet. I should do so. The way the current one works, you’d want to have one meta.block for the entire structure and then meta.section for subsections of the block. The quirky behavior with expand selection to scope wasn’t wholly limited to the scope stack though. It did some funny things when you had an non-point region selected as well.

So if we think expand selection to scope is truly bugged, then it would seem like the Scope Naming document would still be the preferred method and I’ve named things correctly. The block you wrote there would not work with the current expand to scope. If the point or region was in the meta.block.architecture.body.vhdl location, it would select all of meta.block.architecture.body.vhdl and then it would select all of source.vhdl which is the entire document. It would not select all of what is meta.block.architecture.*

As for exactly how the dot usage goes, I guess I have mainly stuck to the 4-word style. Most color schemes I’ve surveyed only pay attention to the first two (though it seems it’s katy-bar-the-door on the entity.name tree in many schemes). So when it came to creating distinctions between zones I used a dash between words in the 3rd position. However there’s really no particular reason why I couldn’t go to a 5 word scope name so I’ll look into that to see if it makes sense in the context of the language.

0 Likes