Some traits, symbols that appear at some point on the right slider. Сometimes it's one, sometimes five... They don't budge until I close everything.
Recognition of the functions does not work correct. After expressly correction, it remains dedicated. It hinders more than it suggests correctly. еxample: PinMode -> qwewqeqwew
Hi @rockn. The line you noted on the "Overview Ruler" indicates the cursor position. If you don't like that, it can be disabled in the advanced settings:
editor.hideCursorInOverviewRulerPlease provide detailed instructions I can follow to reproduce this.
Opening examples: blink. Change a letter /for the wrong function/.
v1.8.19 - the word is not already highlighted /not a function/.
v2.0.2 - the word is still lit /even with the big one/ ie. highlighting is already harm.
v2.0.2 start for 32 second - super slow starting 
. Please, DO SOMETHING for that!
Arduino IDE 1.x has a system where custom keywords can be defined for special highlighting in the editor:
Arduino IDE 2.x has a general understanding of the C++ language courtesy of the VS Code C++ language extension. So it simply sees that you have written a function call and highlights it accordingly. It doesn't care whether the name of the function is digitalWrite or qweqweqweqwe.
The lack of a custom keyword highlighting system is tracked by the developers here:
Even if the new system has some deficiencies, it is already superior to the crude keywords system of Arduino IDE 1.x. With the old system, all the keywords of all the libraries you have installed were highlighted, regardless of whether the code was actually referencing the library. In addition, many things that should have been highlighted were not because library authors did not define them as keywords. Sometimes that was because the library author didn't bother to do it, but more often it was that they attempted to define the keywords but were not competent enough to get the correct data format that allowed the IDE to recognize their keywords file.
You already have a dedicated forum topic about that. If you have more to say, use that one:
A post was merged into an existing topic: Unacceptable that IDE takes 20 s to start on low spec Win 7 computer
Hang on a second there. I've lived through this for more than 12 years.
It is the Arduino.cc dev team that made a wreck of the format of the keywords file and caused many unnecessary compatibility issues that broke the keywords file and its parsing.
i.e. with a few changes to the parsing code it could have avoided the most common issues for the keywords file not being parsed properly.
IMO, They screwed up from the beginning by not properly parsing the file correctly for white space field separators.
i.e. IMO, the parsing of field separators was and still is kind of brain-dead/stupid. They parsed for a specific delimiter character of and multiple tabs would not work initially.
The problem with that is that when using a single tab, the file looks like crap when you edit it so for those trying to make the file look "pretty" by inserting extra tabs or spaces, the IDE parser will misparse the file.
Even worse they changed the delimiter parsing a few times through the years.
The parsing was so weak that you couldn't even use multiple tabs at first. Then a later format change altered it to work with multiple tabs.
I pleaded for the use of isspace() rather than checking for multiple tabs, but it fell on deaf ears.
Needless to say, supporting 1 or more tabs didn't fully solve the issue as there can be cases where spaces end up in the file which will break the parsing.
If they had simply used isspace() to check for white space and used that to skip over all the white space characters up to the next field, the format would have been more flexible and eliminated the problem by allowing tab, space, or multiple of any combination as a delimiter.
People (including me) asked, advised, and even pleaded for them to use isspace() to look for white space field separators going into the 1.0 release but they outright refused and went on about their simplistic way of parsing.
As it is now, there are multiple formats due to changing of the field delimiters through the years and so there is no way to create a keywords file that looks good and works with all the releases.
Because of all this, I have a keywords.txt file that looks like crap so it will work with any ide all the way back to 1.0
BTW,
In over 40 years of programming, I've only ever encountered 1 other tool that had such a rigid file format (using a single tab character) and puked all over the place if you didn't do it properly.
And that is the makefile used by make.
Most tools use white space rather than such a simplistic method of parsing, as using which space (which means 1 or more whitespace characters) it is much more flexible.
It is a tab separated data format. That is not something that can be made pretty. The same goes for CSV using a tab delimiter.
Use of an arbitrary number of tabs as delimiter is still not supported. Each field is separated by a single tab. So if you use multiple tabs then you are putting the following value into a different field.
Allowing a single space delimiter would not have helped at all because the invalid files always use multiple spaces in place of a tab.
The point is that you change highlighting and arrangement code /comments/ over the years. So the old files should/must reformatted. Just implement the old provision. We are already used to her (and I know his flaws). Do not implement a new one in v2.
You are welcome to submit a pull request to contribute the required code changes to add the feature to this free open source software project. Instructions are provided here:
[quote="ptillisch, post:7, topic:1055809"]
It is a tab separated data format. That is not something that can be made pretty. [/quote]
Correct, and that is the problem. They chose to use a single character for a delimiter instead of white-space. That was broken by design.
Not true. The IDE was updated to support multiple tabs.
I can't remember the revision number but it was added and it could be used to pretty up the way the file looks.
I haven't tried it lately but I assume it still works.
And in version 1.6.9 support for space or multiple spaces was added.
NOTE: The comment above about spaces was incorrect. I misread my notes.
My notes actually stated that as of 1.6.9 there was not support for space or multiple spaces, not that it had been added. - my faux pas here.
But there was support for multiple tabs that was added at some point
I never used these new capabilities because while it worked for newer IDE versions, my library needed to support older versions of the IDE so I was limited to using the ugly single tab delimeter.
With Arduino 2.x no clue what they have done since that seems to be a lets re-invent the world thing that didn't implement things the same way and some things have been lost along the way.
But again, if white-space was used as the delimiter, the file could use
a single space, multiple spaces, a single tab, or multiple tabs, or any combination.
whitespace has been used as a standard delimiter for decades going back to the early unix days in the late 60s, the Arduino.cc team just didn't choose to use it for their delimeter in this file and instead chose to use a single character and then after complaints expanded it to multiple characters.
IDE 2.x is new enough that if it doesn't support white-space as the delimiter, it could be corrected now without too much worry about older versions.
--- bill
You know good and well that reverting to some of the old behavior and/or looks likely cannot be done.
The issue that @rockn has brought up is similar to several other issues that are difficult or impossible to fix in the 2.x IDE given the new design, new code, and new tool sets used.
The same kind of thing is true for some of the ugly things that are on the new "forum".
What is frustrating is that there doesn't seem to be at least an admission and/or an apology from the development team when things like this come up.
Perhaps with something like:
Yeah we know this is a change and/or regression, but due to the way things are done now, we can't really return back to the old behavior / look.
--- bill
OS is kind of old, I suspect your hardware is Win-7 vintage, too. With IDE tools such as Arduino 2.x, the hardware and cpu requirements need peppy systems.
It is often difficult to spend big-buck$ on new computer for a hobby; especially with the global inflation reducing buying power. After I retired, I found it impossible to justify the cost of a new notebook. In my case, I have been fortunate to find multiple sources for second-hand computers donated by businesses to charities for fund raising: this MS Surface Pro 4, 8G RAM, 256G HD was under $300... still a significant investment, but it is running Win-11 Pro 64-bif with no lag on the Intel i5.
On a recycled HP EliteBook 8470p notebook from 2015, the price for an i7 was under $200: I put in another 8G of RAM from eBay for a total of 16G, added a 512G SSD from NewEgg, and installed Linux Mint 64-bit .... unit runs Arduino IDE 2.x without any hiccups. No, not new, but fast enough for the new IDE.
Looks like:
Amazon.com: HP EliteBook 8470p Laptop Core i7 2.90GHz, 8GB DDR3, 180GB SSD Win-10 : Electronics
but purchased from a non-profit a few years back with a spinner-drive that I replaced.
If you want decent software performance, you need to provide a hardware platform with speed and bandwidth to not cap the software performance.
As I already explained, this is incorrect. You are simply pushing the value into the next field by adding more delimiters.
https://arduino.github.io/arduino-cli/dev/library-specification/#keywordstxt-format
You will still get keyword coloration because the default keyword type is used when the field is empty, but the coloration will not be done according to the value you intended to set (unless the default happens to have the same coloration as you intended).
I'll provide a demonstration library:
KeywordsTxtTest.zip (880 Bytes)
Simply install it and then open the KeywordsTxtTest example in any recent version of Arduino IDE 1.x.
The library has a keywords.txt file that contains two keywords
OneTab digitalWrite RESERVED_WORD_2
TwoTabs digitalWrite RESERVED_WORD_2
The OneTab keyword uses the correct single tab delimiter. the TwoTabs uses unsupported double tab delimiters.
Note that for the sake of simplicity I have left the backwards compatibility KEYWORD_TOKENTYPE field (field 2) empty, since it is overridden by the RSYNTAXTEXTAREA_TOKENTYPE field (field 4)
If you were right about multiple tabs being supported, then we would expect both keywords to have the same RESERVED_WORD_2 coloration as defined in the RSYNTAXTEXTAREA_TOKENTYPE field (field 4).
If you were right about multiple tabs being supported, then we would expect both keywords to load the same reference URL as defined in the REFERENCE_LINK field (field 3) when you highlight the keyword, right click, then select "Find in Reference" from the context menu.
You can see that is not the case:
Note that the two keywords have different coloration due to the TwoTabs keyword having an empty RSYNTAXTEXTAREA_TOKENTYPE field.
Note that the "Find in Reference" context menu item is disabled for the TwoTabs keyword due to the keyword having an empty REFERENCE_LINK field.
Looking at it from the context of Arduino IDE 1.x, you could consider it that. But looking at it from the context of the VS Code/Eclipse Theia code Arduino IDE 2.x is built on, no reinvention occurred because Arduino IDE 2.x is leveraging an existing sophisticated C++ keyword highlighting system used by a huge number of developers.
The only way this would work is if you added a placeholder value otherwise the IDE has no way of knowing whether the multiple whitespace characters should be considered a single delimiter, or multiple delimiters containing an empty field. In my opinion, that would just make the system more convoluted. It would be switching from a widely used and well known standard tab delimited data format to something non-standard.
It doesn't support any delimiter because it doesn't support keywords.txt at all.
I know there was support for multiple tabs at one point.
And I know that things went back and forth on this parsing issue for a few IDE versions related to this and it created a mess. I'd have to go back an look at the code and the mailing list to recall when and how that happened.
In terms of parsing, sure there are simplistic parsers that use single character delimiters, but it is far from a standard and was definitely not the norm in unix systems.
If the file format was poorly designed such that it could potentially have empty fields, then use a place holder character or string to represent an empty field.
Something like a dash would be simple and fairly self explanatory.
Rather than having invisible empty fields, which is what happens if using a single white space character as delimiter.
But like I said the keywords.txt file format was bad / broken by design.
Oh well at this point, we have what we have for 1.x
A goofy file format that looks pretty crappy.
It doesn't support any delimiter because it doesn't support
keywords.txtat all.
Touche!
Here is a link to an issue about keyword.txt delimiters that has some discussion about it.
And some more here:
Bottom line, the goofy format used is pretty FUBAR - and while there were some options offered to make it better or even fix it, it never really got any support from the developers.
And now with the 2.x IDE, the library customizable keyword feature no longer exists.
--- bill
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
