Skip to content
This repository was archived by the owner on Dec 15, 2022. It is now read-only.

PHP Highlighting incorrectly SQL strings #336

Open
xMarkz opened this issue Sep 16, 2018 · 2 comments
Open

PHP Highlighting incorrectly SQL strings #336

xMarkz opened this issue Sep 16, 2018 · 2 comments
Labels

Comments

@xMarkz
Copy link

xMarkz commented Sep 16, 2018

Description

When I write an SQL string (only if starts with words like SELECT or INSERT) with PHP variables inside the highlight manager uses colors in a wrong way.

Steps to Reproduce

Write:
$a = "SELECT * FROM users WHERE username = '".escape($params["id"])."' AND ban_expire < '".time()."' LIMIT 1";

Expected behavior:

(I used a word different from SELECT because if I don't use SQL words to start the string, the highlight manager behaves correctly.

Actual behavior: [What actually happens]

Instead, as you see, if I start the string with a SQL word (SELECT/INSERT...) the highlight manager does it strange.

Reproduces how often:
Everytime

Versions

Atom 1.30.0 on macOS High Sierra

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

@littlekreen
Copy link

further example:
highlighting in wordpress breaks in link-template.php amid get_adjacent_post() line 1766 as of writing. However, if the line at 1770 is commented out the highlighting resumes properly until the next SQL statement on line 1791 and only 1766 remains broken.

Of particular note:

  • that while 1770 propagates 1766 has the same issue but does not propagate. the difference between them is the use of mixed double and single quotes.
  • If double-quotes are used in the implode function on 1766 syntax colors remain broken and it does not propagate.
  • If empty double or single quotes are concatenated in front of the SQL that is single quoted, it will not propagate but the line will be broken.
  • if uniform quotes are used, 1766 remains broken but does not propagate in either state.
  • if double quotes are used on only the SQL in 1766, the changes now propagate from 1766 onward.

Note: I'm using the line numbers from the official repo as it's slightly ahead of us but the code is identical in this location.
after
before

@thompol
Copy link

thompol commented Feb 25, 2022

Issue still exists. Any idea how/when this could be fixed?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants