[Deipotent]

I mean to go the other way – ie. a button on the Keyboard config dialog to open the Keyboard Properties window.

[Deipotent]

Not sure if this is where you want bug reports for these head-start versions, but I’ve noticed a problem with the FindBar related to following post:

If “Replace >>” button is ON and “In the Selection” is also ON,
the Find Previous, Find Next and Replace Next buttons are always disabled/greyed out.

http://www.emeditor.com/modules/newbb/viewtopic.php?viewmode=flat&topic_id=1895&forum=5

[Deipotent]

Great news about more frequent updates! :-)

I’ll be running these new head-start versions from now on.

[Deipotent]

The editor in question calls this feature a Minimap

[Deipotent]

Yutaka wrote:
1) The spelling checker was analyzed by the spelling engine (Hunspell), so it is separate from EmEditor. Currently, there is no easy way to make an underscore (‘_’) a part of a word unless modifying the Hunspell source code or the spelling data.

Can’t EmEditor scan the text for words and just pass them to Hunspell for checking, and then underline based on the return value from Hunspell?

This way EmEditor has full control over what’s considered a word or not.

[Deipotent]

OK, thanks Yutaka!

[Deipotent]

Yes, “Selection Only” button is checked. This means there is a different problem…

Why is incremental search still highlighting all matches, even though there is no selection?

Even when there is a selection, it still highlights all matches incrementally.

Also, why is the Find Previous button still enabled?

NOTE: I have the following options checked – “Incremental Search, “Use Regular Expressions”, “Move to Start/End Document”

[Deipotent]

Hi Yutaka,

When Replace>> is toggled on in Find Bar in 11.0.3, the Find Next button is always disabled.

[Deipotent]

Had you upgraded from XP to Win 7 when you originally reported the issue ?

Did you originally install EmEditor as a portable app (and to a protected folder – ie. one that requires admin privileges) ?

Both these issues could potentially cause the problems you’re seeing, which seem to be a permissions issue when EmEditor isn’t correctly handling the access denied.

[Deipotent]

Let me know if you can’t reproduce and I’ll create a video demonstrating it.

[Deipotent]

+1

[Deipotent]

+1

[Deipotent]

Thanks for the detailed answer Stefan!

Didn’t know the characters were consumed by default, but lookbehind and lookahead does indeed solve the problem.

Thanks again! :-)

[Deipotent]

Is it possible to increase this character line limit for the 64-bit version ?

[Deipotent]

2) I’ll double check exactly what I see and maybe put together a video.

3) Couldn’t you just re-run the search from the beginning of the current match, so it won’t move unless it no longer matches. It would only do this when incremental search was enabled. I’m assuming that if someone changes the option, it’s because they want to run the search with that option.

[Deipotent]

It’s not so much doing regular major upgrades, but instead of having version 12 with 3-5 new features, why not release each feature as it’s finished as a 11.x update ?

Essentially the point release will include new features AND bug fixes, rather than just bug fixes.

Not sure on what your new upgrade policy will be, but instead of basing it on major version number (ie. free minor upgrades but paid major upgrades), how about offering 1 year free upgrades (major and minor), with the user having to pay for another years upgrades ?

I can understand the translation and support issues, but re. translation, could you not release an English version when ready, and then periodically release translated versions of the latest EmEditor ?

This way, people using English version get new updates ASAP, while the translated versions will still be released as frequently as they are at the moment ?

[Deipotent]

1) As I suggested, can you make it show the character code when more than one character is selected, as the current specification just shows nothing which is not useful.

2) But why does it leave the highlight from the previous search, as well as highlight the new search ?

3) I can understand if incremental highlighting is disabled, but when enabled it would be preferable IMO to immediately redo the search with the new options (ie. Match Case, Regex). At the moment you force the user to perform multiple steps to redo the search with the new option – ie. a user would change an option, delete/add a character in the search pattern, and then re-add/delete the character to perform the search again. Why not just automatically redo the search ?

NOTE: This only applies if one of the options is changed and Incremental search is enabled.

[Deipotent]

The problem with ignoring r is still present – http://www.emeditor.com/modules/newbb/viewtopic.php?topic_id=1813&forum=5

[Deipotent]

Just going through my reported bugs/comments with the latest beta…

1) The character code now is not shown now when more than one character is selected.

Could you make it so that it updates in real-time as the selection changes, and shows either the character to the right of the selection (much like it normally shows the character to the right of the cursor), or the last character in the selection.

This can be useful when you want to select up to a specific character code.

2) There is a minor highlighting problem related to incremental search. To reproduce,
– create a new document with the first line empty, the second with “cf abcde cd” (no quotes) and the third line empty.
– Open up the Find dialog and enable Incremental search
– Click mouse cursor on first line
– Search for “cd” and press Enter
– Search for “abcde” and press Enter
– Now use the drop-down to keep alternating the search between “cd” and “abcde”

— After searching for “abcde”, it will sometimes highlight correctly, but other times will not clear the previous search (so either “cd” will still be highlighted, or the “cd” in “abcde” will be grey rather than the highlight colour)

3) incremental highlighting not updated when Find Dialog option changed. eg. Match case checkbox is enabled/disabled. Using above example, try searching for “ABCDE” and then enable Match Case and it will still match “abcde”

4) Only one match is highlighted when the regex search contains r. eg. If you have multiple lines of the following format “ABCDE: .abc3;.s32”, and have incremental search enabled, all matching lines are highlighted with a regex of “: +([[:alnum:];.]+)”, but only a single match is highlighted with “: +([[:alnum:];.]+)n”

[Deipotent]

I’m posting a link to a bug I’ve just reported related to ignoring r in regexes:

http://www.emeditor.com/modules/newbb/viewtopic.php?topic_id=1813&forum=5

[Deipotent]

After thinking about this again, I re-looked at the regex in my linked post for finding duplicate lines, and realised that there appears to a bug in EmEditor’s regex parser.

My suggestion for ignoring r already appears to be implemented. Let me give some examples to explain:

1) Even if EmEditor didn’t ignore r, the following regex should work as the part, “r?”, is saying match zero or one occurrences of r. So it should match whether there is a r or not. But it doesn’t.

^(.*)(r?n1)+$

2) However, if you remove the ‘?’, so the regex becomes as follows, it works, and matches duplicate lines:

^(.*)(rn1)+$

3) It also works if you have the original regex, but replace “r” with “(r)”:

^(.*)((r)?n1)+$

So, the bug appears to be that EmEditor seems to have a problem applying ‘?’, when it follows a r. It already seems to just remove the “r”, so the original regex ends up being turned into

^(.*)(?n1)+$

which doesn’t work.

[Deipotent]

And i (the user) get the impression that i did it right, what is not the truth.

But you would have done it right, with a valid regex. Currently, EmEditor errors out when some valid regex are used.

I think it’s preferable to make EmEditor adhere to standards, rather than making people who are familiar with regex’s modify them to just to get them to work with EmEditor.

To use your analogy, EmEditor currently does it like IE of old, where people have to put in workarounds to get a regex to work. My proposal is to make EmEditor more like the latest versions of IE which are more standards compliant, and so work with valid regex’s.

[Deipotent]

I don’t mean strip it out of the edit box, I mean just strip it out of the regex that EmEditor will use internally – so the user wouldn’t know any difference, but these valid regex will work.

At the moment, some valid regex are reported as incorrect by EmEditor (see link to my other post for an example of finding duplicates)

[Deipotent]

You also need to change the option below the “Regular Expressions Match New Line Characters” checkbox, “Additional Lines to Search for Regular Expressions”, from 0 to the maximum number of lines a tag could span. For example, if your tag is:

	<td>first line

	second line</td>

	

you need to set it to 1, as the tag is one line later than the

tag. the higher the number you set it, the slower the regex engine will work, as it will be looking at more lines.

You could try setting to 100 or 1000 and see how performance is.

[Deipotent]

Video demonstrating problem on Win 7 SP1 x64 (note: this was not in a fresh Win 7 install – let me know if you still can’t reproduce and I’ll also test that):

http://www.sendspace.com/file/rz0lr6

[Author]

Posts