Macro breaks undo capability

V@no · May 14, 2016#12016-05-14T12:49+00:00

Hello.

I've had this macro since UEStudio v6:

SpacesToTabs
TrimTrailingSpaces

It's assigned to ALT+T

Up to UES v15 it worked perfectly: you select a block of text, hit ALT+T and all spaces turned into tabs instantly in the selection and selection stays selected like nothing happened.
Since v15 it started to select text all the way to the end of the file, showing cancel dialog box and after it's done (a few seconds) it clears the selection, at witch point very often if you have something in undo buffer, it gets corrupted, to the point that if you undo, you can't redo to the proper state, everything is "shifted" a few characters.
Since v16 not only it inherited v15 issues, on top of that UES started crashing every time you try to edit a macro. It was fixed in latest version, but now I'm getting this message after executing this macro:

The application could not allocate enough memory for the undo buffer. The undo chain will be reset for this document.

Note, this issue only happens when text selected, with no selection the macro works with no issues (other then it still much slower then pre-v15).

Is there something I could change in the settings that would fix this, or it's a bug?

Thank you.

Mofi · May 14, 2016#22016-05-14T14:00+00:00

I could reproduce some of the reported issues with 32-bit UE v22.20.0.49 on Windows XP as well. There is definitely nothing in configuration which would avoid wrong behavior. There is definitely something to fix by the developers of UltraEdit. Please report the issues by email to IDM support. I reported 3 weeks ago also a display issue with Spaces to Tabs (All) and Tabs to Spaces.

V@no · May 14, 2016#32016-05-14T14:47+00:00

What display issues do you have?

Mofi · May 15, 2016#42016-05-15T07:52+00:00

I reported following by email 3 weeks ago and the issue could be reproduced by IDM support:

UE - Spaces to Tabs (All) and Tabs to Spaces results in display range change

I'm using at the moment 32-bit UE UVB v23.00.0.60 on Windows 7 SP1 x64 and 32-bit UE v22.20.0.49 on Windows XP SP3 x86 and both show the same display behavior as described below. So this display issue is not new for v23.00. Windows Classic is used on both computers as Windows desktop theme.

When executing the command Spaces to Tabs (All) or Tabs to Spaces the displayed area of the file changes even for small files with line numbering enabled. It looks like UltraEdit uses the current byte offset in file to define position after converting all spaces to tabs respectively all tabs to spaces which of course is not good as the byte offset in file changes.

Example procedure to reproduce this minor display issue:

Start UltraEdit with all settings set to default, i.e. entire directory %APPDATA%\IDMComp\UltraEdit just created new.
Open Settings/Configuration and change the value for Tab stop value from 2 to 8 for Default at Editor - Word Wrap/ Tab Settings.
Extract from attached archive the file SpacesTabsTest.txt and open it in UltraEdit. This file contains lots of trailing spaces on each line. (The file is not attached to this post.)

It is helpful to enable Show Spaces/Tabs for the next steps.
Scroll down with vertical scroll bar until getting displayed the line 500 at top of the document window.

Displayed are now in my UltraEdit the lines 500 to 535.
Execute Spaces to Tabs (All).

Displayed are now in my UltraEdit the lines 1123 to 1158.

Better would be to display still the lines 500 to 535.
Execute Tabs To Spaces.

Displayed are now in my UltraEdit the lines 499 to 534.

It is interesting that the displayed line range changes by 1 line up.
Execute once again Spaces to Tabs (All).

Displayed are now in my UltraEdit the lines 1121 to 1156.
Execute one more Tabs To Spaces.

Displayed are now in my UltraEdit the lines 498 to 533.

If line numbering (counting) is enabled as by default (for small files) it would be much better to make use of the line number information on the 3 Spaces/Tabs conversion commands as the number of lines does not change, just the number of bytes. The displayed line range should not change on running the 3 commands. And the caret should be on same line and if possible also in same column after executing one of those three commands even if caret position is outside of displayed lines range.

Honestly I have executed those commands mainly with caret positioned at top of the file and displayed is also top of the file in the past and therefore have never seen this display issue before.

But even with Ctrl+G to open Go To dialog, entering 500 and jumping to line 500 by pressing RETURN and executing now with caret being also positioned at beginning of line 500 instead of line 1, the displayed range changes on executing the conversion commands, although the caret is still positioned at beginning of line 500.

Of course with line numbers disabled in configuration as recommended on using UltraEdit for editing large files it is necessary to use the byte offset as line number information is not available which must result in a change of displayed lines if the commands are executed on a larger area (entire file or a selection being larger as number of displayed lines).