Skip to content

difference between KEYWORD1 and KEYWORD2 when parsing keywords.txt [imported] #546

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cmaglie opened this issue Nov 15, 2012 · 2 comments
Closed
Labels
Type: Works For Me We are unable to reproduce the reported bug
Milestone

Comments

@cmaglie
Copy link
Member

cmaglie commented Nov 15, 2012

This is Issue 546 moved from a Google Code project.
Added by 2011-05-20T10:15:37.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

  1. Create a library, and create keywords.txt
  2. Create keywords of type KEYWORD1 and KEYWORD2
  3. for keyword of type KEYWORD1, use more than one tab between the keyword and KEYWORD1
  4. do the same (use more than one tab) for keywords of type KEYWORD2
  5. Load the IDE, import the library, and test the highlighting functionality for your library
  6. notice that KEYWORD2 keywords get highlighted, but KEYWORD1 keyword doesn't
  7. modify keywords.txt so that the KEYWORD1 keyword only has a single tab, leave the KEYWORD2 keywords with multiple tabs
  8. Restart IDE, and test highlighting, now KEYWORD1 keyword is highlighted

What is the expected output? What do you see instead?

Because KEYWORD2 keywords allow an arbitrary number of tabs (which is useful for making the file look clean), I would expect the same to apply to KEYWORD1 keywords. The IDE doesn't agree. The rules between the two types of keywords are inconsistent.


What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

  1. 64-bit Ubuntu 10.04. Board not relevant, but Duemillanove.

Please provide any additional information below.

I think the issue is likely to lie in /app/src/processing/app/syntax/PdeKeywords.java, specifically the function getKeywords. This was the only code I could find dealing with parsing out tabs looking for the "KEYWORDx" token.

Unfortunately I'm not familiar with Java or the codebase, so I'm hoping this is an easy fix for someone. I've attached examples of a working and non-working keywords.txt to clarify my report.

Additionally, I'm wondering if there's a formal spec for keywords.txt posted somewhere.

I also appologize for having to use the word "keyword" so many times, but I couldn't think of a better way to express the bug. :P

@ffissore ffissore self-assigned this Jul 1, 2015
@ffissore ffissore added the Type: Works For Me We are unable to reproduce the reported bug label Jul 8, 2015
@ffissore ffissore added this to the Release 1.6.6 milestone Jul 8, 2015
@ffissore ffissore closed this as completed Jul 8, 2015
@DonnyCraft1
Copy link

I just got this bug in IDE v/1.8.7.

@per1234
Copy link
Collaborator

per1234 commented Nov 3, 2018

@DonnyCraft1 are you sure it's the same bug? I just did a test keywords.txt with Arduino 1.8.7 and got this highlighting behavior:
clipboard01
As you can see, unlike what is reported here, the KEYWORD1WithTwoTabs keyword is indeed highlighted. You might notice that it's highlighted as KEYWORD2 rather than the intended KEYWORD1 highlighting like the KEYWORD1WithOneTab keyword. The reason is that each field of keywords.txt is separated by a single true tab. So when you use multiple tabs as a separator the field is considered empty. This causes the default highlighting to be used, which is the same as that used for KEYWORD2. If you're seeing something different, then please provide the problematic keywords.txt file.

The lack of support for arbitrary whitespace separators in keywords.txt is a separate issue, which some work was done on in #7245.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Works For Me We are unable to reproduce the reported bug
Projects
None yet
Development

No branches or pull requests

5 participants