Closed cohler closed 4 years ago
@cohler, thank you for the report. I can't reproduce it with the current master or v1.90. Can you send the string you are searching for as well as a screenshot of the search toolbar to show the selected options and the search location?
Can you also include the version of the IDE you are using and the version of macOS?
For example, a regex search for "_c.\w+ =" turns up nothing, and that's how I find all my functions. Find within a file works fine, same expression.
I've been using the software for about a year now, doing these searches 1000 times per day. Stopped working a few days ago. Reinstalled. Rebooted. Junked prefs etc... Ran Disk Utility on hard drive etc... all the standard stuff. The software is simply broken. Can't imagine how you could cause such a bug. And of course, Find in Files is THE central feature of any IDE, without which the entire IDE is totally useless. Programmers have to be able to quickly find things in dozens of files. So this is a major bug.
[image: image.png]
Version of IDE and macOS really doesn't matter, because NOTHING changed on my end, but FYI... [image: image.png]
[image: image.png]
FYI, people have previously reported the search suddenly not working...For example, https://stackoverflow.com/questions/42323024/zerobrane-isnt-searching-my-current-project-folder
If you get it working again, please let me know.
Best, Jonathan
I don't see the images (as they didn't come through in the email), but if it doesn't work with the same version it worked before with, I suspect you don't have regex search toggle selected. [Re] button should be pressed on the search toolbar.
FYI, people have previously reported the search suddenly not working...For example, https://stackoverflow.com/questions/42323024/zerobrane-isnt-searching-my-current-project-folder
This looks to be a different issue, as it worked in one project directory, but not in another one. Unfortunately, there was no follow-up, so I'm not sure what caused that particular one.
Regex search IS toggle selected.
As I said, I have been using this FOR A YEAR. And I do the searches 1000 of times per day. I AM AN EXPERT with 40 years of systems programming experience. And I know EXACTLY what I am doing.
Since your email doesn't work properly, I will send you the images again as attachments instead of standard embedded images.
Instead of assuming I am wrong, and giving me a glib non-answer, as you would to a neophyte, it would be much wiser of you to assume that I know what I'm talking about, because I do.
Best regards, Jonathan
Since your email doesn't work properly, I will send you the images again as attachments instead of standard embedded images.
That's not my email, it's github's. You can attach the images directly to your comment using github and it will show up correctly.
Instead of assuming I am wrong, and giving me a glib non-answer, as you would to a neophyte,
There is nothing glib about my questions and I'm not sure what you expect me to do.
You said that you've been using it for a while and everything was working. Nothing changed on your side and it stopped working. How do you want me to investigate without asking more questions trying to figure out what changed?
Stopped working a few days ago.
Clearly it worked before. The IDE doesn't have any auto-updates in the background, so nothing has changed in it, that's why I was trying to figure out what may be different.
Do the searches without regex expressions work? Do you always get 0 results in the search output?
it would be much wiser of you to assume that I know what I'm talking about, because I do.
This cuts both ways. I've been doing support for 25+ years and for this project since 2011. I can change the level of the discussion as needed, even when I'm yelled at.
I'm sure something has changed if it was working before and now it's not. I'm also sure we can quickly figure out what it is, but it will be easier to work together.
Your response here is a complete straw-man argument with a false premise. You say "How do you want me to investigate without asking more questions...?" I never said that I didn't want you to ask more questions. My stern response to you was not because you asked questions, all of which I responded to, but rather it was to your highly insulting, glib assumption:
"*I suspect you don't have regex* search toggle selected."
This is obviously wrong, given the context of the conversation in which I had already told you I have been using the product extensively for 1 YEAR doing thousands of such searches EVERY DAY.
In any case, here are the answers to your current questions. Please do not again falsely accuse me of not answering your questions. And please do not give me glib assumptions on the level of "did you reboot your computer etc" as I have already explained that I did all those things many times already:
Do the searches without regex expressions work? No. Find in Files doesn't produce results whether or not regex is selected. But regular Find (within the open file) works fine both with and without regex.
Do you always get 0 results in the search output? Almost always. Here's a case where it finds some references in one html file buried in a subdirectory. But doesn't find the hundreds of references in the lua files. Before you assume that there is some difference in the directory or file protections, I have provided screen shots of those as well. As you can see all the directories are 755 and the files are all 644.
See attached.
P.S. One cannot "yell" in a printed message. There was no audio attached to my message. Accusing me of "yelling" is not productive. Use of boldface, CAPITALIZATION, and underscores are typographic tools used for clarity and immediacy of understanding.
Jonathan Cohler
You didn't answer my question about the versions of macOS and the IDE; you wrote this: "Version of IDE and macOS really doesn't matter, because NOTHING changed on my end, but FYI..." and then attached the screenshots that didn't go through. I already told you that github doesn't transfer images from emails to tickets and yet you continue sending email with images and didn't put in text those answers. You again wrote "I have provided screen shots of those as well.", but as you can see, nothing is included in your comment: https://github.com/pkulchenko/ZeroBraneStudio/issues/1046#issuecomment-611496162.
Let's do this; to make any progress I need the following (everything in text form except a screenshot of the search toolbar):
What do you think has happened? As you described several times, nothing has changed on your side, including the IDE, so why do you think it was working and then stopped? What's your theory?
I see that your emails are not from your own email address, but rather from this system. That was not made clear in your emails to me. I'll attach the images again here for the third time...
Version of macOS you are using. Did it change between the times the search was working and now? See previous message attachments for version info. No macOS did not change.
Version of the IDE. No IDE did not change. Although, I did download latest version after it stopped working and did a fresh install to see if that would fix the problem. Same problem.
An example of a search that was working and doesn't work anymore; include both the string you are searching for and the content of the Search result window. I need the simplest possible example that stopped working from your perspective. If a simple search worked and now doesn't, please include a string from a file (and a filename) that you expected to be found (that was found previously) See attachments above.
An example of a search that "Almost always" works. Does this mean that it works one time and doesn't work some other time? Or does this mean it works on some files, but not others, but works consistently on those? See attachments and previous explanations above.
What do you think has happened? As you described several times, nothing has changed on your side, including the IDE, so why do you think it was working and then stopped? What's your theory? I believe it must have to do with some system wide setting IN YOUR SOFTWARE that somehow got changed internally (by some bug in your software) that is now telling your software not to search in those directories, OR not to search for those particular file types in those directories. But as there is no documentation about those things, it is impossible for me to find the answer.
And thank you for asking especially the last question about what I think. That would be a great first step next time.
I believe it must have to do with some system wide setting IN YOUR SOFTWARE that somehow got changed internally (by some bug in your software) that is now telling your software not to search in those directories, OR not to search for those particular file types in those directories.
There is only one configuration setting that a user can change to affect the search: it is to specify binarylist
with a list of extensions/folders to exclude. There is nothing else in the IDE that would somehow exclude files from the search when they would still be shown in the file tree.
But as there is no documentation about those things, it is impossible for me to find the answer.
Every available option is documented, including exclusion lists: https://studio.zerobrane.com/doc-general-preferences#file-exclusion-lists. Every option specifies default values, possible values, and a version when it was added or updated.
So far I don't see anything that could have caused the behavior you have and can't reproduce it on my Mac. We can try the following:
binarylist
option is not set there. Do you have anything specified in either of these files?$HOME/Library/Preferences/ZeroBraneStudio Preferences
); make sure you close ZeroBrane Studio before removing the file (https://studio.zerobrane.com/doc-general-preferences#session-configuration).(you may want to save a copy of the preference file in case it turned out that it works after removing it; I'd like to be able to take a look to see if I can reproduce the behavior.)
Nothing set in User or System Preferences. I had already checked that previously. I had already removed the Preferences file as I indicated previously. Same behavior.
In the meantime, I installed SlickEdit Pro 2019 and all the multi-file searches in all the same directories and files work perfectly every time.
As I said, I believe the problem is INTERNAL to YOUR SOFTWARE and not in a settings file. It is a bug, clearly.
Here's the current prefs file (I added the .txt extension so that it would upload here)
And pray tell, of what use was the information on MacOS and ZeroBrane version etc? Are there versions where this problem is a known issue? If so, it must have reared its ugly head again. And if not, of what use was the information?
Nothing set in User or System Preferences. I had already checked that previously. I had already removed the Preferences file as I indicated previously. Same behavior. Here's the current prefs file (I added the .txt extension so that it would upload here)
I don't see where you mentioned removing the file. I just want to make sure, did you remove $HOME/Library/Preferences/ZeroBraneStudio Preferences
file and relaunched the IDE?
As I said, I believe the problem is INTERNAL to YOUR SOFTWARE and not in a settings file. It is a bug, clearly.
As I said, I can't reproduce this issue, which makes it difficult to see what may be going on. Also, I don't have any other reports of this issue, and many of the IDE users are on macOS, so this would have already been reported.
Can you try two other things:
\w+
in the same folder. I just want to see if any special regex characters are being searched for._c\.\w+ =
in some other project folder.And pray tell, of what use was the information on MacOS and ZeroBrane version etc? Are there versions where this problem is a known issue? If so, it must have reared its ugly head again. And if not, of what use was the information?
I don't see a reason to be obtuse about this. Even if we are not able to solve the problem, it may be helpful in case someone else runs into the same issue. Also, it would be easier to have it in text (v1.90 and 10.13.6 High Sierra), as having images makes it non-searchable.
Yes as I said twice now (including my first message to you) I removed the preferences file. And in my last message to you I sent you a copy of the current version of that file. It is located at ~/LibraryPreferences/ZeroBraneStudio Preferences
(the ~ on Mac translates to /Users/username
, which the value of the HOME
environment variable).
Your assumption that "this would have been reported" is totally inaccurate and the #1 fallacy oft repeated by arrogant and ignorant customer service people. I have always instructed my customer support employees to NEVER EVER say that to ANY customer, because it is invariably FALSE. The fact that you are unaware of such a report or that most people don't report and waste their time like I am does NOT in any way mean that the report does not exist. They simply move on to something that works. Rather It simply means YOU are not AWARE of it, which is irrelevant to the CUSTOMER and it is insulting to the CUSTOMER, basically saying to them the equivalent of, "the problem must be YOU Mr. Customer".
Back to your questions...
- Search for \w+ in the same folder. I just want to see if any special regex characters are being searched for. Yes this produces results but only in 8 files:
Searched for '\w+'. Found 104533 instances on 8293 lines in 8 files.
And those files are all.ini
,.md
and.html
files but no.lua
files- Search for _c.\w+ = in some other project folder. Searching for
_c\.\w+
produces no results in any project folder
Again, instead of insulting the CUSTOMER (who is generously helping you to debug a MAJOR bug in YOUR SOFTWARE) yet again and calling me "obtuse", could you instead answer my explicit and specific questions. Once again:
@cohler, I think I know what's happening. You have Bootstrap.bin.lua
files in some of your folders, which are probably binary files, so the IDE marks .lua files as binary files and skips them in subsequent searches.
Also, you are searching for _c
in .../Beta 1.192/includes/
folder, but for _c\.\w+ =
in .../Beta 1.192/
folder, which catches Bootstrap.bin.lua
file as well. If you do the first search in .../Beta 1.192/includes/
folder I expect you get the results you were getting before.
Again, instead of insulting the CUSTOMER (who is generously helping you to debug a MAJOR bug in YOUR SOFTWARE) yet again and calling me "obtuse", could you instead answer my explicit and specific questions.
Of what use would my answers to these questions be to you? Do you want me to list the tickets that show (different) issues related to a specific version of macOS? Here is the list of items we asked to provide when a new bug request is submitted. I can't tell you if it's a known issue or not if I don't even know what the issue is. As you can see, if I'm correct in my description in the previous paragraph, the issue is caused by (1) Bootstrap.bin.lua
file being detected as a binary file with .lua extension and (2) the search being started in a directory that includes Bootstrap.bin.lua
file as the first .lua file. If this hypothesis is correct, then the change in the behavior you see was caused by the search being started in a different directory and not by something that has changed in the application.
So this IS a pretty MAJOR BUG in THE IDE as I indicated.
First, the file Bootstrap.bin.lua
is a STANDARD lua file produced from a STANDARD Lua string.dump
function which is loadable through the exact same Lua loadfile
function as ANY OTHER .lua
file. So the inclusion of such a .lua
file with other .lua
files is absolutely STANDARD.
Second, NOWHERE in your documentation does it say: WARNING!!!!! IF YOU INCLUDE ANY FILE THAT OUR SOFTWARE DOESN'T RECOGNIZE, WE WILL DISABLE ALL RECOGNITION OF ANY OTHER FILES OF THE SAME EXTENSION.
This needs to be fixed immediately as it renders your product fundamentally useless for Lua development wherein virtually EVERYONE uses a mixture of Lua text files and Lua string.dump
files both of which are loadable through the exact same loadfile
function.
On a positive note, I was able to verify that the IDE does work now with the following steps to repair the problem:
string.dump
lua files from the Project directoryThis of course is an UNACCEPTABLE solution for ANY Lua developer, virtually all of whom include multiple string.dump
lua files in their projects.
The IDE shouldn't be making internal adhoc decisions to subsequently TOTALLY IGNORE all files of a given extension based upon the IDE's incorrect conclusion that one particular file is "Binary" (whatever that means) and it fails to understand the format of the file.
When do you expect a bug fix will be available?
And please don't give me a silly response telling me that this is how the product is "supposed" to function.
I should add to my previous message. The warning should actually be extended to say:
WARNING!!!!! IF YOU INCLUDE ANY FILE THAT OUR SOFTWARE DOESN'T RECOGNIZE, WE WILL DISABLE ALL RECOGNITION OF ANY OTHER FILES OF THE SAME EXTENSION AND WE WILL NOT NOTIFY YOU OF THIS IN ANY WAY, NOR WILL WE OFFER YOU ANY WAY OF FIXING THIS PROBLEM (OTHER THAN REINSTALLING EVERYTHING FROM SCRATCH AND REMOVING ALL SUCH "OFFENDING" FILES FROM YOUR ENTIRE PROJECT TREE).
Obviously, the CORRECT behavior of the IDE would be to simply ignore files it cannot recognize and continue on without suddenly, silently, and inexplicably, without warning of any kind, DISABLING ITSELF and rendering itself USELESS.
So yes indeed THE IDE DID IN FACT MODIFY ITSELF precisely as I had surmised.
Find in Files produces empty result always now on Mac OS X. So yes indeed THE IDE DID IN FACT MODIFY ITSELF precisely as I had surmised.
No and no; we've already established that Find in Files doesn't always produces empty result on macOS and that the IDE didn't modify itself.
I don't understand what you are so worked up about. You searched in your project directories and everything worked as you expected for a long time (as you said). You then searched in the directory that had binary files with .lua extension, which changed the search behavior to skip the rest of the .lua files. Yes, this behavior is by design, even though in retrospect it wasn't ideal, as you can see, so I've submitted a patch that will change that.
I don't like your attitude and not sure why you feel that I owe you anything. I develop this product as I see fit based on feedback from my other customers and have no obligation to do anything at all to satisfy your demands. It's an open software, so you should be free to make any changes you desire and add any warnings you deem necessary. You are also free to use any other products that better satisfy your needs. I'm sure you can figure out how to apply the fix.
Reload ZeroBrane from your website to make sure it is uncorrupted by the internal BUG
I'm not sure what you mean by that, as you'd be downloading the same software you are already using.
This of course is an UNACCEPTABLE solution for ANY Lua developer, virtually all of whom include multiple string.dump lua files in their projects.
None of the steps you described are necessary, as this only happens when the first .lua file that is found during search is a binary one, so if you first search in includes/
folder after launching the IDE, everything will work as you expect it to. This is not saved in any preferences, so you don't need to remove or modify any files.
which changed the search behavior to skip the rest of the .lua files. Yes, this behavior is by design
As you note your software did EXACTLY what I stated.
THIS IS A BUG. IT IS NOT A DESIGN. IT IS NOT DOCUMENTED ANYWHERE. IT IS INCORRECT. Claiming that it is "by design" does not make it so. Pray tell where is the documentation saying this is the design???? Where is the warning to users????
Stop dissembling. And please FIX THE BUG.
And furthermore, it DID NOT WORK again until I installed fresh.
Simply removing the file from the directory DID NOT fix the problem as the IDE HAD ALREADY MODIFIED ITSELF.
If you refuse to FIX THE BUG, and continue to claim that this is "the design", I will take it on myself to warn all other Lua programmers about this SEVERE LIMITATION in your IDE's "design".
And why do you find it necessary to be so insulting, accusatory, and contrarian to a CUSTOMER who is spending his valuable time helping you to FIX YOUR SOFTWARE?
THIS IS A BUG. IT IS NOT A DESIGN. IT IS NOT DOCUMENTED ANYWHERE. IT IS INCORRECT. Claiming that it is "by design" does not make it so. Pray tell where is the documentation saying this is the design???? Where is the warning to users????
Unfortunately this is not for you to decide what's by design and what's not. I make design decisions, so it's my responsibility to figure out the end result and to decide what to document and what not. If you are interested in the discussion and decisions that led to this implementation, feel free to read comments in #416.
And why do you find it necessary to be so insulting, accusatory, and contrarian to a CUSTOMER who is spending his valuable time helping you to FIX YOUR SOFTWARE?
I think you need to look in the mirror. What did you find insulting or accusatory in my responses? As I wrote in my previous comment, I already applied and pushed the change that does this, but you were so focused on proving me wrong and yourself right, that you might have missed it.
I didn't miss anything in your response in which you also said that it was part of the "design". UNDOCUMENTED "DESIGNS" that do the WRONG thing ARE BUGS!
For you to not be able to admit that and to continue in your unending chain of insults and attacks on the customer really is quite astonishing. Claiming that you have "applied and pushed the change" is meaningless.
You didn't answer the question once again as to when we can expect to see this MAJOR BUG fixed.
At the moment the product is essentially USELESS for editing Lua projects, so given your continued insults and total ARROGANT DISREGARD for the CUSTOMER, I will proceed to warn the community...
Best of luck...
You didn't answer the question once again as to when we can expect to see this MAJOR BUG fixed.
I said twice that it's been updated already; it's in the commit that closed this ticket. I'm not sure what else to say.
I also said that I don't owe you anything and yet you keep insisting that I should do something and promptly.
At the moment the product is essentially USELESS for editing Lua projects, so given your continued insults and total ARROGANT DISREGARD for the CUSTOMER, I will proceed to warn the community...
Anyone can read this discussion and form their own opinion, but you should do whatever you feel is necessary.
And FYI, there is nothing in #471 about this issue.
And FYI, the very line of code that you fixed in your push, does EXACTLY WHAT I HAD PREDICTED AND TOLD YOU ...
if knownBinary[ext] == nil then knownBinary[ext] = IsBinary(content) end
Namely, YOUR SOFTWARE internally MODIFIED ITSELF (not in a settings file), changing knownBinary[ext]
from nil
to IsBinary(content)
causing the entire problem, and which behavior IS DOCUMENTED NOWHERE.
A simple "thank you for your help in identifying this MASSIVE BUG" would be nice, but in your never ending need to be right (it's part of the "design") and smarter than and superior to all your customers, I doubt you will have the basic courtesy to do so, so I won't hold my breath...
If it is or was part of the design as you now insist after the fact, I guess you would have been happy with the following warning to all users?
WARNING!!!!! IF YOU INCLUDE ANY FILE THAT OUR SOFTWARE DOESN'T RECOGNIZE, WE WILL DISABLE ALL RECOGNITION OF ANY OTHER FILES OF THE SAME EXTENSION AND WE WILL NOT NOTIFY YOU OF THIS IN ANY WAY, NOR WILL WE OFFER YOU ANY WAY OF FIXING THIS PROBLEM (OTHER THAN REINSTALLING EVERYTHING FROM SCRATCH AND REMOVING ALL SUCH "OFFENDING" FILES FROM YOUR ENTIRE PROJECT TREE).
Unfortunately, in #416, you didn't pay attention to that customer's admonition to you,
**"It's important to be able to define what a binary file is"**
This is a Lua IDE. And string.dump
is used ALL THE TIME to save functions which are then reloadable using the same loadfile
command that loads all lua files.
You just can't stop, can you? You keep bringing up points that have already been discussed and addressed...
Unfortunately, in #416, you didn't pay attention to that customer's admonition to you, "It's important to be able to define what a binary file is"
That's exactly what I meant by being obtuse. You cut the quote short to support your point: "It's important to be able to define what a binary file is if you can't autodetect it.". The IDE does both: it allows the user to define what a binary file is (using file exclusion lists), and it supports autodetection.
A simple "thank you for your help in identifying this MASSIVE BUG" would be nice, but in your never ending need to be right (it's part of the "design") and smarter than and superior to all your customers, I doubt you will have the basic courtesy to do so, so I won't hold my breath...
thank you for your help in identifying this MASSIVE BUG
Thank you.
Folks, let's keep the discussion civil and on point.
Hopefully, there will be a new version of the Mac executable available soon for download at Zerobrane.com. Without the recently pushed fix, the Find in Files turns up NO RESULTS for ALL .lua
files in your Project directories once it finds one binary .lua
file, such as a standard Lua string.dump
file, for example.
Hopefully, there will be a new version of the Mac executable available soon for download at Zerobrane.com.
You only need to change a couple of lines as shown in the referenced commit (5daf55d). There was a recent release and I don't have a next one scheduled at this time.
Without the recently pushed fix, the Find in Files turns up NO RESULTS for ALL .lua files in your Project directories once it finds one binary .lua file, such as a standard Lua string.dump file, for example.
No, this only happens when a binary file with .lua extension is the very first file found by find-in-files after an IDE launch. If you search first in includes/
folder everything will work as you expect it to (until you restart the IDE).
Just to summarize the options you have:
The choice is yours...
You only need to change a couple of lines as shown in the referenced commit
How can I build an entire new release of the app with many tools etc?
No, this only happens when a binary file with .lua extension is the very first file found by find-in-files after an IDE launch.
Yes. I believe this is true. However, the normal use of the IDE is to set-and-forget the project folder and do searches as one works. People normally don't search individual folders, it's too slow and cumbersome when working rapidly on a project that has many files in many directories under one project tree.
You can save lua dump files with a different extension.
This is an unsatisfactory workaround. Lua files are lua files. People don't want their code doing extra searches for multiple file extensions all the time slowing down ALL loads when it is totally unnecessary in Lua.
You can apply the change in the referenced commit. Should only take a minute or so.
Any advice on the steps to do this in "a minute or so" on a Mac would be greatly appreciated.
How can I build an entire new release of the app with many tools etc?
You don't need to; you can modify some of its source after it's installed in the /Applications
folder.
This is an unsatisfactory workaround.
You keep failing to assume good faith in this discussion. For some reason you think I'm getting defensive when I merely list options that are available (and are reasonable in my opinion despite your objections). You can simply ignore it if it doesn't work for you (as it may well work for someone else).
Any advice on the steps to do this in "a minute or so" on a Mac would be greatly appreciated.
vim /Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/src/editor/findreplace.lua
Thank you! That's fabulous. I didn't realize you could do that! Much appreciated.
Find in Files produces empty result always now on Mac OS X.