errorMatch: option to capture character range

[idleberg]

Alright, this might sound odd. I've come across a compiler that does not report the error in the common <line>:<col> scheme, but the character range in which the error occurred.

Example:

Here is an AppleScript that will break on build

tell application "Finder"
  if condition --then omitted
    -- statements
  end if
end tell

Building would produce the following error

/Users/me/Desktop/broken.applescript:31:40: execution error: The variable condition is not define
d. (-2753)

The number 48 marks the beginning of the range where the error occurs, 57 marks the end.

I'm not sure how many compilers follow this, but it would be nice to have a pattern that allows us to capture this, e.g. ?<from> and ?<to>.

[Cxarli]

Character 48 to 57 is equal to omitted in the comment on line 2. Are you sure that's correct?

[idleberg]

@C-Bouthoorn you're right, i forgot i edited the script but did not update the error message

[noseglid]

This would only have any effect when used with the Atom Linter integration, right?

[idleberg]

If it's the linter integration that highlights the line of the — yes!

[idleberg]

The new version does not close this. The compiler does not output <line> or <col>, only character position. The position is counted from the beginning of the file, line numbers are ignored.

/Users/me/Desktop/broken.applescript:31:40: execution error: The variable condition is not define
d. (-2753)

The above means the error occured between the 31st and 40th character in the file.

[noseglid]

Oh I misunderstood. That is indeed an unusual way of outputting error locations.

To solve this we're gonna need new error matcher categories and translate those to row/col. That'll be really tricky and would involve opening the file and inspecting the content. I can think of a million things that might go wrong while doing this.

Is there no way to get it to output row/col instead?

[idleberg]

Is there no way to get it to output row/col instead?

Unfortunately, there is no way to modify the output.

In theory, the Open Scripting Architecture can be used for other scripting languages, but I think it's only been used for AppleScript and JavaScript (JSOSA) in practice. Since JavaScript OSA was since replaced by JavaScript for Automation (JXA), support for character ranges is probably a very small niche.

Maybe keep it on your list if you ever have plans for a major rewrite. Otherwise, forget about it! 😄

[noseglid]

It feels very niched indeed. I would not be opposed to it, but I don't expect I will prioritize it anytime soon 😄

[noseglid]

I'm closing this. It seems too big of an effort and too little of a gain.