Forum Replies Created
- May 24, 2010 at 11:36 pm in reply to: EmEditor Professional v10 RC 7 (9.90.16) – v10 key required #8513
I’ve been using EmEditor v8 for a while. I have just upgraded to a new laptop with Windows 7. So I come back here to check if I should give it a software upgrade. I’m so excited to see EmEditor v10 coming. When is the time frame for the release of v10?November 15, 2007 at 10:18 pm in reply to: [b29] Find in Files very slow to search a large number of files #5000
The procedure is the same as what has been posted in this thread. I see no difference between b29 and b32.
One more data point. I’m using the “exported to USB drive” version. If I just run the version installed in “C:program files” it does not seems to have this problem.November 15, 2007 at 7:33 pm in reply to: [b29] Find in Files very slow to search a large number of files #4998
Upgraded to b32 and found the same issue.November 9, 2007 at 5:53 pm in reply to: [b29] Find in Files very slow to search a large number of files #4977
This surely is a bug isn’t it? There is no explanation why it would take so long for certain combination of encoding setting.
Besides I tried you recommendation. It doesn’t help. Picking “utf-8” or any other encoding in the Find in File dialog however does solve the problem.
Is it true that choosing .ini for configuration slow things down? This is one thing to make me love EmEditor 7.November 8, 2007 at 6:58 pm in reply to: [b29] Find in Files very slow to search a large number of files #4966
In the File tab I have these options selected:
* Prompt if null char found
* Prompt if invalid char
* show file name w/full path
* Detect BOM
* Detect UTF-8
* Prompt at inconsistent returns
* Opening Encoding: UTF-8
The files I have searched should be all Ascii files.
Even if EmEditor is doing more detection, it just doesn’t sound right to me that one program can search all files in 2 seconds but it takes EmEditor 9 minutes. Also if I select any encoding, says UTF-8, the performance goes up dramatically to a few seconds.
Of course now I have a workaround as stated in my previous sentence :-)November 7, 2007 at 9:16 pm in reply to: [b29] Find in Files very slow to search a large number of files #4961
I’ve figured it out. The problem is in the “Encoding” listbox. The default “Configured Encoding” is the slowest. Choosing anything other than “Configured Encoding”, even if you pick something random like Korean, will give you good performance.
The other options I have set is “Look in subfolder” and “Use Escape Sequence”. Unfortunately I cannot post my data file. But this is irrelevant. I repeat the search over 1000 files from an open source project and the result is the same.
Thanks for looking. Find in file is still slow in b29. I have added a new post with more detail.
About danderson’s second suggestion, I actually use it a lot with my previous editor. I have macros that parse a file and extract data into a new, temporary, unnamed buffer and like to have a way to refer to data in the unnamed buffer. Right now EmEditor only support one kind of address, that is filename/lineno. Since the unnamed buffer has no filename, it is not addressable. So one idea is to define a new address format such as
This is only a first suggestion. Of course the format should be carefully designed so that it does not overlap with other usage.
About 1, I have also make a enhancement suggestion that not only applied to the OutputBar but to all document Windows. There is an obscure concept of Tag (filename, linenumber) in EmEditor and it should be a simple enhancement to allow custom Tag format.
Sounds good. My suggestion is to add a command similar to TagJump that activates a URL. Then user can map any key to that command.
* Here is my little peeve. It used to be lightning fast for me to open a file. Now I see a delay of nearly a second. I hope this is not because EmEditor has become bloated. I know my expectation is unreasonably high. But for me this is what distinguish an amazing editor from just a good editor.
This seems to be more than a minor annoyance. It seems to affect “Find In Files” also. Other program can look through 100 files in a breeze. With EmEditor taking 0.5 second to open every file, “Find In Files” becomes really slow.
P.S. It is beta 24 that I am using.
I love this. Right now it is a pain to work in column when some lines are shorter than the others.
Not that I know of. However I have written a collection of macros that does what you want and more. I’m trying to clean it up and post it some time.
How would you like to see the result of ‘find all words’?
What I often do is to close the ‘Find’ dialog box. You will find all matched items highlighted. You can then use ‘Find Next Word’ or ‘Find Previous Word’ to navigate within the document.
Another way is to use the ‘Find in Files’ to see all matched lines. It will search all files in specified directory though. I wish it has a easier way to saerch within the current document only.
1) Display the line text in addition to the line number. Often I just want to see the lines not actually navigate to them. It would also help with finding a pertinent occurrence rather than looking at each line. It would also be helpful to be able to show only the file/buffer name rather than the full path. The full path takes up too much space. Often all of the files are in the same path as well. The current setup requires expanding out the file column to actually see the file.
I’m with you. The file column is mostly useless for me as the directory name would take up most spaces. I’m usually more interest to see the matched lines. Something like the output of grep is would be great.January 18, 2007 at 11:17 pm in reply to: Do not ask to reload files Changed by Another Program? #4107
Thank you for your response. I have somehow missed the notifcation.
Yes, I can turn off the prompting altogether with the property dialog. But usually I don’t want that. Only in certain scenario like reading a constantly changing log file would I be bugged by the prompt.
Ideally I want ‘No’ to mean no for all subsequence file changes. Only if I manually reload the file should it resume checking for file changes.