Forum Replies Created
- AuthorPosts
Yutaka Emura
Keymasteryongfa365 wrote:
win2003+sp2long line
ctrl+1
ctrl+2no scroll
This should be fixed on beta 36. Thanks!
Yutaka Emura
Keymasteryongfa365 wrote:
Tray Icon right-clicking does not work on Windows 2003This was fixed on beta 35. Make sure you installed beta 35 correctly, and you might need to restart Windows.
Yutaka Emura
KeymasterThis has been fixed on beta 35. Thanks!
Yutaka Emura
KeymasterAussieDan wrote:
I frequently work with shell scripts that do not have an extension, so I need to select the correct configuration every time I open the file.It would be great if the Association settings allowed the user to specify a regular expression to be applied against the content of the file.
For example, to match php shell scripts:
^#![/a-z]+php
This would be a fallback, and only applied if the file could not be matched by the current extension system.
What do you think?
Dan
That is a great idea, but it might be too late for the version 7 release. I will add that feature request to the wish list next time we begin another poll. Thanks!
November 19, 2007 at 6:01 am in reply to: annoying behavior after file selection in explorer window #5012Yutaka Emura
Keymastervha wrote:
I’m using Windows XP SP2and have the option ‘single click to open an item’ switched on for the explorer plugin.
To reproduce, this is what I do:
– in the explorer window of the plugin, click on a file
– the file opens up in the editor window
BUT the explorer window of the plugin remains the active windowresult is that most of the shortcut keys don’t work (CTRL-G, CTRL-F, …)
But i guess the misunderstanding was that I meant the explorer plugin window, not Window’s explorer window…
vha
I see. I don’t remember why I didn’t program that way, but on the next version clicking an item in the Exploer plug-in will set focus in the editor view. Thanks!
November 18, 2007 at 7:47 pm in reply to: annoying behavior after file selection in explorer window #5010Yutaka Emura
Keymastervha wrote:
If you select a file in the explorer window using the mouse, the explorer remains the active window.This means you first have to click inside the editor window before you can for example do a CTRL-G (go to line…) or CTRL-F (find…)
More logical behavior should be that the newly opened window become the active window in the editor
tx, vha
You didn’t describe exactly what your OS is and how you can reproduce your problem. I don’t have a problem with Windows Vista or Windows XP when I double-click a file in Explorer.
I know there might be a problem with a certain OS, due to a bug in that OS.Yutaka Emura
Keymasteryongfa365 wrote:
replace
n
to
nnwrong
win 2003 +sp2
This will be fixed on beta 34. Thanks!
Yutaka Emura
Keymasterenvisage wrote:
execute the installer on windows server 2008(rc0)
it claims
“””
EmEditor Professional(English) Files in Use
The following applications are using files which the installer must update. You can either close the applications and click “Try Again”, or click “Continue” so that the installer continues the installation, and replaces these files when your system restarts.
the application(s) is windows explorer.
“””
every beta version on windows server 2008(rc0) claims this.I realized this error message, but this claim shouldn’t happen again after installing beta 23. It has been already fixed on beta 23 by not using “emedshl.dll” file, but uninstalling beta 22 or earlier caused this message. Thanks!
November 15, 2007 at 11:35 pm in reply to: [b29] Find in Files very slow to search a large number of files #5001Yutaka Emura
KeymasterEmEditor is optimized for the Registry usage, and the USB install will slow down. If the speed is a top priority, please consider using the Registry (without INI files). I will optimize a little more for INI files, but it won’t become as fast as the Registry version.
November 15, 2007 at 10:01 pm in reply to: [b29] Find in Files very slow to search a large number of files #4999Yutaka Emura
KeymasterYou should have seen at least some improbements. Can you please describe more details that might help me to reproduce your issue? Without descriptions, I won’t be able to reproduce your issue. Thanks!
Yutaka Emura
KeymasterI don’t know why this happens, but did you completely uninstall the previous versions of EmEditor? When you uninstall, try to unintall from the user account that you used to install the previous version with.
Yutaka Emura
KeymasterIt will be fixed on next beta version. Thanks!
Yutaka Emura
Keymasterxxx_pic wrote:
How about give user an option to turn the “Save” command always enabled ?Currently, EmEditor cannot “Save” a document while the document is “Empty” and without any changed (Just used the “New” command or just clicked EmEditor’s shortcut from Start Menu) .
However , The Windows NotePad can “Save” anytime I want !
You can always enable saving from Configuration Properties – File tab – Saving button – “Always Enable Saving” check box.
Yutaka Emura
Keymastergarret wrote:
Notepad uses Lucida Console and doesn’t have a problem showing U+2045.Eclipse uses Courier New and doesn’t have a problem showing U+2045.
Why does EmEditor have a problem with this character?
I confirmed and reproduced this issue with those fonts, and I will look into this issue. Thanks!
Yutaka Emura
KeymasterMost monospace fonts do not support special unicode characters like this. However, in recent Windows, you can select monospace font and still you should see those special characters. Does Notepad use the same font?
I might make Insert Special Character dialog better in future. Thanks!
Yutaka Emura
Keymastergarret wrote:
I’m actively looking for a new editor—a simple editor that handles Unicode. (Unipad does, but is *too* simple.) EmEditor looked promising, but 7.00 beta 32 doesn’t even handle the character U+2045, when notepad.exe handles just fine.Disappointing.
I didn’t have a problem displaying U+2045. The font you use to display must cover that character code. Which font do you use? I used “MS UI Gothic” font in Windows Vista.
Yutaka Emura
KeymasterIt is probably the Find dialog box was resized a little big larger than normal. You can drag the right bottom corner of the Find dialog box to fix this issue.
November 9, 2007 at 6:10 pm in reply to: [b29] Find in Files very slow to search a large number of files #4978Yutaka Emura
KeymasterPlease try beta 32, and you should find better performance. Thanks!
Yutaka Emura
KeymasterFlint wrote:
I have the following text:ALTER TABLE asd ADD xxx TINYINT(1) DEFAULT ‘1’ NOT NULL;
UPDATE asd SET temp=0 WHERE id=-1;
INSERT INTO dsa (col1, col2) VALUES (‘test’, ‘0’);
INSERT INTO dsa (col1, col2) VALUES (‘test_with_something’, ‘0’);I select it all, then open the Replace dialog and set the following parameters:
Find: (.*);
Replace with: ‘1’,
[X] Use Regular Expressions
[X] In the Selection Only
Then I press Replace All. Only first two lines are replaced, the 3rd and the 4th remain unchanged.If I untick the In the Selection Only checkbox, all 4 lines are replaced.
This bug will be fixed on beta 33. Thanks!
Yutaka Emura
KeymasterAussieDan wrote:
After resetting the highlight configuration the wordcomplete seems to be working properly, thanks!I did notice a couple of spelling/typo errors on the Options tab for WordComplete configuration:
Display Icons in the Cadidate List
Automatically Hide the List when No Candiate is MatchedKeep up the great work!
I fixed those spelling mistakes. Thanks for your report!
Yutaka Emura
KeymasterThere is a bug in Find when Match Case option is turned off. This will be fixed on beta 31 soon.
November 8, 2007 at 7:27 pm in reply to: [b29] Find in Files very slow to search a large number of files #4967Yutaka Emura
KeymasterYou should change the Opening Encoding in the File tab of the configuration properties from “UTF-8” to “System Default Encoding”. That should solve this issue.
November 8, 2007 at 5:27 pm in reply to: [b29] Find in Files very slow to search a large number of files #4965Yutaka Emura
KeymasterWhen “Configured Encoding” is selected in “Find in Files” dialog box, EmEditor uses the encoding configured in the File tab of the configuration properties assiciated with the file extension you are searching. In default, Text configuration uses “System Default” encoding with UTF-8 and Unicode signature detection. The UTF-8 detection can make search slower. If the “Detect All” is also checked in the File tab of the configuration properties, it may become even more slower. Please let me know which options are checked in the File tab of associated Configuration Properties.
Also, in what encoding do those files you search are encoded? UTF-8 or Western European (CP:1252) or any other?
November 7, 2007 at 8:33 pm in reply to: [b29] Find in Files very slow to search a large number of files #4960Yutaka Emura
KeymasterAlso, make sure you write which options (such as Regular Expressions, Match Catch, etc.) you checked in the Find in Files dialog box. Using different options can make significant difference in search speed. Thanks!
November 7, 2007 at 8:27 pm in reply to: [b29] Find in Files very slow to search a large number of files #4959Yutaka Emura
KeymasterThanks for descriptions, but it might be more helpful if you can write which encodings those files are written with, and whether you use regular expressions, or escape sequences including new lines. A possible reason for the delay is that EmEditor internally works in Unicode, and it support Unicode-aware regular expressions. You can write exactly what you search for, and what the files are like, and you can email me sample files and more descriptions at [email protected]
Thanks!- AuthorPosts