Cycle decoration improvements

[grahambates]

• Increase width to handle 3 digit ranges
• Add byte size on hover
• Add horizontal rules between sections in hover
• Prevent misalignment / jumping while editing due to delay updating counts. Every line always has an 'empty' decoration to add horizontal space and the actual counts are positioned in front of this.

[BartmanAbyss]

Nice! This was bothering mee, too, but I never got around to doing something about it :)

[BartmanAbyss]

Btw, is there a way to immediately add that empty space? when cyling through assembly files in the explorer, I still see the text on the left before the space is inserted for about 0.5s or so..

[BartmanAbyss]

Also, I was just testing it with your M68000 assembly extension, and it parses and colorizes correctly, but shows this error:

[{
    "resource": "/c:/Users/Chuck/Documents/Visual_Studio_Code/vscode-amiga-debug/template/support/depacker_doynax_vasm.asm",
    "owner": "_generated_diagnostic_collection_name_#1",
    "code": "14",
    "severity": 8,
    "message": "could not open <C:\\Users\\Chuck\\AppData\\Local\\Temp\\a.out> for output",
    "source": "vasm",
    "startLineNumber": 1,
    "startColumn": 1,
    "endLineNumber": 1,
    "endColumn": 1
}]

This happens only after opening a .asm file, then when I edit it, I no longer get that error.. It seems that error is coming from your M68000 assembly extension, not vscode-amiga-debug, as it still happens when I don't have my extension even enabled.

[grahambates]

Btw, is there a way to immediately add that empty space

The space should be added first. Maybe it's just down to how the rendered view updates. I'll have another look at this though.

[BartmanAbyss]

It appears sooner than the cycle count, but still a delay after the document is shown.

[grahambates]

Thanks for flagging the issue on my extension. It looks like Vasm is failing when trying to assemble to a temporary file, which it does to generate diagnostics. This might be permission related.

[BartmanAbyss]

Maybe it runs too often, even parallel and multiple processes try to access a.out? In my extension I give the output files a unique temp name each run. The path looks correct though

[grahambates]

Setting the empty decorations is the first thing that happens on onDidOpenTextDocument and onDidChangeTextDocument. I'm guessing it's the render update that's slow.

[BartmanAbyss]

Yeah it's a bit strange as the text comes out fully colorized at the same time. Does it look the same for you? (sorry for crappy video quality) https://user-images.githubusercontent.com/19374186/204906280-da742502-f5d5-4ab7-8010-c032693c4ded.mp4

[grahambates]

Yeah that's pretty much what it looks like for me. I'm not sure there's much we can do about it.

On the m68k diagnostics thing, I suspect it might be Windows specific. The thing is though, we really don't need two extensions assembling the same file and generating the same diagnostics! When it does run successfully you just end up with duplicate messages:

I'm going to open a PR to have it disable the provideDiagnostics config setting.

[grahambates]

Looks like the delay is a known issue:

https://github.com/microsoft/vscode/issues/136241

[BartmanAbyss]

Alrighty. No more we can do then.