Forum Replies Created
- Posts
I found that by changing the Search line to:
n]*>s*)(([^>n]*>[^n]+?
s*)+)
EM doesn’t lose any text, but only places the replacement ### at the first line …
Any ideas, please?
UPDATE:
I began to change my scripts and I must say that the results now are more accurate! :-D
But, there’s a severe speed penalization, too :-(
Not the biggest problem in Earth… but If you can optimize this issue, I’ll thank you very much!Thanks again for make this marvelous app better and better with each version!
Un abrazo!OK, thank you!
If there are more “hidden” escape sequences ;-) (i.e, not included at the current Help), please, inform here.
The additions are always welcome to improve scripting proficiency.In order to stop the “Escape sequence” auto trigerring in F&R dialog, you can now uncheck both “Use Selected Text in Find/Replace dialog box” and “Use Word at Cursor in Find/Replace dialog box” in the “Search” tab of the Customize dialog box.
BTW, I didn’t find the first option, only the latest… It changed of dialog box? (v8.05)
Un abrazo desde Perú!
Thank you for your answers!
“Search Only Word” will not work well with Regular Expressions. Instead, you should use Word Boundaries:
Please, clarify if this behavior is only at the current version or will be permanent… to begin editing my macros now… :-o
Cheers,
jugaorYutaka wrote:
Hi, you might want to clear Use Word at Cursor in Find/Replace Dialog Box check box in the Search tab of the Customize dialog box.Yes, it’s always cleared here: the issue is when I select the desired letters/words and trigger the dialog (the usual behavior, I think).
Bang! ‘Use Escape Sequence’ strikes back! :-?
(the only workaround is select/copy/trigger/paste/clearUES… please, fix it!)Yutaka wrote:
I will make this check box disabled when you Replace in Files without checking “Keep Modified Files Open” check box. Thank you!Bravo for that!
But it won’t only aesthetic, no? The promised gain of speed must be effective ;-)Thanks again for your kind answers!
jugaorBy the way, I know that EM tries to anticipate the user desires…
but what about stopping the automatic choosing of “Use Escape Sequence” at Find/Replace dialog opening??? (it occurs if any selected char is /). Besides this, it duplicates that chars every time at Find line…
Sorry but this behavior is very annoying :-(
Why not remembering the previous selected options? (current session)Thanks!
jugaorHi, my friend Yutaka. Sorry for the long delay since my last post (very busy time).
I haven’t no time to test the new features of EM…Just a humble question:
It makes sense the “Accelerate by Discarding Undo Information” with Replace In Files (manual or scripted)? Since it’s already impossible undoing this operation… what about deactivating by default at this to gain the speed? Or, at least, giving that option to the user…Thank you very much for your attention.
jugaorPS: Happy Holidays! :-D
“The Problem # 1” is that Em7 isn’t running certain VBscripts for me. But I found the responsible: the tiny emedshl.dll.
All the details at your mail.
jugaorBTW, my friend, what about Problem # 1?
I’m tied with 7b41 by now…Thanks you very much for your patience!
jugaorThe files are ANSI (Western European), the same as System Default Encoding (I use Spanish Windows XP, but my tests were also in the English version).
I need to work with subtitles (*.srt), many downloaded from Internet or directly generated by me. For testing purposes, I changed their extension to .txt, with the same result.I tried your suggestion (thanks!) but it only correctly works if I first re-save ALL the files as UTF-8.
Sadly, it isn’t a chance for me, because the subtitler applications don’t recognize the Unicode special chars (with or without BOM signature: they only read ANSI). And saving & re-saving are impossible with the bunch of files of my daily job :-(If you can to find a way to recognize the ANSI special chars too, PLEASE PLEASE, write me!
TIA;
jugaor–I think that I isolated the problem #1.
When customizing the Macros menu, b41 doesn’t recognize the added macros until it’s restarted (if I immediately invoke them after customizing the menu, Em apparently ‘runs’ them but it only flickers a “Replacing” macro window, without touching the target text files. Closing and reopening Em is mandatory).
But all the subsequent betas and RC never recognize them (even after restarting, they always show the flickering window) :-(
I also tested the betas in a fresh XP install in MS Virtual PC (the official XP SP2 English from its site) with the same result.
Please, make sure that the VBEE support is enabled in the new releases.–Confirmed: the new ISO codes are only working in manual Searches & Replaces, not in VBEE scripts (b41, since I can’t test them with the others). Please, let me write examples (with several fake Spanish words, only for testing):
editor.ReplaceInFiles “ó”, “o”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”
editor.ReplaceInFiles “Ó”, “O”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”ORIGINAL: Ó ó Óñonoy Ñóño diseñó diseüó.
FINAL: O o Oñonoy Ñoño diseño diseüo.editor.ReplaceInFiles “a por”, “por”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”
editor.ReplaceInFiles “A por”, “Por”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”ORIGINAL: A por, a por. Cabaña por ahí. CÜA por eso. A poría.
FINAL: Por, por. Cabañpor ahí. CÜPor eso. Poría.editor.ReplaceInFiles “asi”, “así”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”
editor.ReplaceInFiles “Asi”, “Así”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”ORIGINAL: Asi, asi. Asiático, Ñasi, Éasi.
FINAL: Así, así. Asíático, Ñasí, Éasí.editor.ReplaceInFiles “comun”, “común”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”
editor.ReplaceInFiles “Comun”, “Común”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”ORIGINAL: Comun, comun. Comunícate, nécomun.
FINAL: Común, común. Comúnícate, nécomún.I also tried to change “eeEncodingSystemDefault” to others without luck (several ones don’t make replaces, “EncodingUTF8” erases not replaces).
Besides this, changing the last ones:editor.ReplaceInFiles “(A|a)si”, “1sí”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceRegExp Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”
editor.ReplaceInFiles “(C|c)omun”, “1omún”, “*.txt”, eeFindReplaceOnlyWord Or eeFindReplaceRegExp Or eeFindReplaceCase, eeEncodingSystemDefault, “”, “”ORIGINAL: Asi, asi. Asiático, Ñasi, Éasi. Comun, comun. Comunícate, nécomun.
FINAL: Así, así. Asiático, Ñasi, Éasi. Común, común. Comunícate, nécomun.The expected behavior! :-o Very strange! (but this ‘solution’ isn’t applicable to other chases, as the first two ones).
Excuse me the long post, but I tried to be the clearer possible. I hope that you can test these issues and make the excellent Em even better! :-)
jugaorTHANK YOU VERY MUCH! I tried the 41 beta and the ‘special chars’ issue is gone! :D
Also, I saw that I misunderstood the “look ahead” expression :-?
I needed to use the “look behind” one (?<!pattern). Excuse me!Congratulations for your excellent job!
jugaorHi, thank you very much for your response.
1. In Spanish, the ‘special’ letters are ÁÉÍÓÚÜ, áéíóúü, Ñ, ñ. I presume that these Unicode chars cover them :)
2. The spaces are needed, since they’re two whole words:
“esta” = “this” / “estas” = “these”, both feminine.
“es” = “is” (singular, verb to be)
“son” = “are” (plural, verb to be)
The strange thing is that EmEditor rightly works with the same subexpression after, not before (i.e. “(¡|¿)esta(s?)(?! es| son)” is correct).I have been trying to use EmEditor to automatically correct words with bad orthography in subtitles files (Spanish). I wrote some complex VBEE scripts for that, and I found these issues above.
Thanks for your attention,
jugaorPS: please, write me when the new beta is ready :)
