You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 15, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 15, 2022. It is now read-only.
Local variables aren't parsed, or are parsed as kernel functions. #207
No local variables seem to be parsed as such, and those that have the same name as a Ruby Kernel method are parsed as kernel functions. The latter problem seems to be a consequence of the former, in that the parser assumes that they are kernel methods because they have the same name and haven't been parsed as local variables.
Steps to Reproduce
Create the following Ruby code in Atom editor:
p = 'Hello World'
p1 = p
test = p1
puts test
Open Atom's dev tools and inspect the HTML.
Expected behavior:
All local variables should be enclosed in HTML elements indicating what they are. e.g.: <span class="syntax--variable syntax--other syntax--readwrite syntax--local syntax--ruby">p</span>
Actual behavior:
The variablesp and test have the following <span> element, wherever they are used: <span class="syntax--support syntax--function syntax--kernel syntax--ruby">
The variable p1 is just bare text wherever it is used, so cannot easily be formatted by CSS.
Reproduces how often:
Every time.
All the local variables I have tested that have the same names as Kernel methods are parsed as kernel functions.
All others, including those with the names of methods of Object (e.g.clone) are not parsed.
Versions
Atom : 1.18.0
Electron: 1.3.15
Chrome : 52.0.2743.82
Node : 6.5.0
apm 1.18.1
npm 3.10.10
node 6.9.5 x64
python
git
visual studio
language-ruby : 0.71.0
Windows 7 Pro x64
It may be possible to highlight these correctly on the left side of the equals sign using a lookbehind. In all other cases, though, it is not possible to know when p is a local variable or a call to Kernel#p, because syntax highlighting packages are not interpreters or even parsers—they're lexers. Just a collection of naive regexes.
I ask you this: does overshadowing Kernel methods with local variables seem like a good idea? I would argue that, in general, this "bug" is useful behavior: it warns the user that they are treading dangerous waters.
I think that dubious practices such as using the names of Kernel methods as variables should be detected and highlighted by a linter, but the syntax colouring should just reflect how the language is actually parsed. Appending the line p p to the script above does cause it to print "Hello World" as expected, so the different uses of p are being parsed correctly and Kernel#p isn't actually being shadowed by the variable p.
The example I gave is obviously contrived and unusual, but it does illustrate the underlying problem that local variables aren't being recognised as such at all. If they have the same name as a Kernel method then they are displayed as syntax--kernel elements, but usually they are just bare text in the enclosing <div>.
If Atom's syntax highlighting packages are limited to just using regexes you have an interesting challenge! If you could obtain or write a Ruby parser as a finite state machine/automaton you might then be able to convert that to regexes, as described on Stack Exchange and elsewhere. Just writing a parser to recognise local variables would be good enough for this particular problem.
It's a pity that Atom doesn't allow you to use existing parsers, such as the one that must be built into linter-ruby, rather than having to attempt to parse it yourself just using regexes. If it could accept a parse tree in some specified form all you would have to do would be to convert the output from a Ruby parser into that form if necessary.
I must also add that I am now using Visual Studio Code as my main code editor, mostly for it's IntelliSense, but it does also recognise and colour Ruby local variables in most contexts. So it's no longer urgent for me that this or the other problems I reported are fixed.
We are working on an experimental new parser system at tree-sitter. But for the most part, Atom, GitHub, and VSCode all use TextMate-compatible grammars (with the latter two using many of Atom's languages), which are by definition only regexes.
tree-sitter looks to be a good way forwards.
In the meantime perhaps Atom could use VSCode's regexes for Ruby local variables, if both editors use the same TextMate based mechanism.
changed the title [-]Instance variables aren't parsed, or are parsed as kernel functions.[/-][+]Local variables aren't parsed, or are parsed as kernel functions.[/+]on Jul 12, 2019
Activity
stevenpetryk commentedon Sep 25, 2017
It may be possible to highlight these correctly on the left side of the equals sign using a lookbehind. In all other cases, though, it is not possible to know when
pis a local variable or a call toKernel#p, because syntax highlighting packages are not interpreters or even parsers—they're lexers. Just a collection of naive regexes.I ask you this: does overshadowing
Kernelmethods with local variables seem like a good idea? I would argue that, in general, this "bug" is useful behavior: it warns the user that they are treading dangerous waters.Wonderer0 commentedon Sep 26, 2017
I think that dubious practices such as using the names of
Kernelmethods as variables should be detected and highlighted by a linter, but the syntax colouring should just reflect how the language is actually parsed. Appending the linep pto the script above does cause it to print"Hello World"as expected, so the different uses ofpare being parsed correctly andKernel#pisn't actually being shadowed by the variablep.The example I gave is obviously contrived and unusual, but it does illustrate the underlying problem that local variables aren't being recognised as such at all. If they have the same name as a Kernel method then they are displayed as
syntax--kernelelements, but usually they are just bare text in the enclosing<div>.If Atom's syntax highlighting packages are limited to just using regexes you have an interesting challenge! If you could obtain or write a Ruby parser as a finite state machine/automaton you might then be able to convert that to regexes, as described on Stack Exchange and elsewhere. Just writing a parser to recognise local variables would be good enough for this particular problem.
It's a pity that Atom doesn't allow you to use existing parsers, such as the one that must be built into
linter-ruby, rather than having to attempt to parse it yourself just using regexes. If it could accept a parse tree in some specified form all you would have to do would be to convert the output from a Ruby parser into that form if necessary.I must also add that I am now using Visual Studio Code as my main code editor, mostly for it's IntelliSense, but it does also recognise and colour Ruby local variables in most contexts. So it's no longer urgent for me that this or the other problems I reported are fixed.
winstliu commentedon Sep 26, 2017
We are working on an experimental new parser system at tree-sitter. But for the most part, Atom, GitHub, and VSCode all use TextMate-compatible grammars (with the latter two using many of Atom's languages), which are by definition only regexes.
Wonderer0 commentedon Sep 27, 2017
tree-sitter looks to be a good way forwards.
In the meantime perhaps Atom could use VSCode's regexes for Ruby local variables, if both editors use the same TextMate based mechanism.
FranklinYu commentedon Jul 12, 2019
Please change the title. Local variable is different from instance variable. This issue has nothing to do with instance variable (like
@foobar).[-]Instance variables aren't parsed, or are parsed as kernel functions.[/-][+]Local variables aren't parsed, or are parsed as kernel functions.[/+]