Find-In-Files Results Formatting

LarlaDog · Sep 28, 2005#12005-09-28T18:04+00:00

When you use find-in-files and do NOT specify that results go to edit window, the results come to a new window at the bottom of the editor frame. However, the tab stop value in this new window reverts to a value like 8 even though I have tab stop set to 2.

The result is not good -- lines are spread out so much that you rarely can see all of the line without horiz scrolling.

Is there a way to fix this or should it be sent in as a bug report?

Mofi · Oct 02, 2005#22005-10-02T17:43+00:00

I think, it is not a bug. A tab character (hex 09) is by default interpreted with 8 spaces by ALL programs. UltraEdit lets the user specify by how many spaces a tab should be interpreted based on the file extension. The text in the output window is just something in RAM memory, not a file. So the default is used. UltraEdit cannot know how a human editor has seen the tab during the file creation.

If you get the find output from your source files, you want that UE displays it with two spaces. And what will happen, if you use Find In Files on different files, not created by yourself?

Excuse me, but I personally think, that it is stupid to use a tab character with a width setting of two spaces. Why not simple use 2 spaces instead of a tab? If a tab is interpreted with more than 3 spaces - OK, but 2 spaces? That makes no sense. That's my personal point of view.

However, you can write a feature request by e-mail to IDM for a special tab setting for the output window. But don't write, it is a bug.

Or you run a Replace In Files and replace ^t by 2 spaces and problem is solved.

everseeker · Oct 04, 2005#32005-10-04T17:17+00:00

HA! Don't hold back now... Tell him how ya feel....

Actually, I have had occasion to use "2 space" tabs....
In the past, there have been times when I loaded code, written by others, to review/modify...
Some programmers are QUITE fond of nesting... At the default of 8 spaces, their nesting can force code over so far that it's unreadable without slewing the screen left/right/left/right...
So, in that case, I re-spec to 2 spaces so I can read the code. If I need to make changes, I can do that with the same Tab setting and all "looks" fine...
When done, The code's insane nesting is preserved and everyone's happy.

I too noticed that running finds on such code is....visually problematical... But I too think it's not a "fault", just a quirk.

LarlaDog · Oct 10, 2005#42005-10-10T18:45+00:00

I am using the Default setting for my configuration of tab setting. It would seem that the settings specified under Default would be a better value to use for the output window display than to arbitrarily use 8. Particularly in my case where I have no file extension settings, only Default.

Incidentally, it does use my Default tab setting (2) when I specify the Find output to go to an Edit window. That behavior doesn't seem too consistent compared with what it does for the ouput window. UE knows what my default setting is, there's no reason it couldn't and shouldn't apply it.

I'll assume you just lost your head for a moment when you said that tab setting of 2 is "stupid". The point of using tabs versus spaces is that you don't have to lock yourself into a particular size. And even if I never used anything but 2 for a tab setting, I have cut my keystrokes in half.