HE vs. EditPlus Search & Replace

[GCS]

For over 40 years, I have been "coding" and have used a wide array of text editors. If there is a good promotion on, I will often purchase yet another editor to give it the workout, and see how it compared to all the others I have seen. I purchased HippoEdit sometime back, but I really do not use it very much, and it is all because I use a different editor for most of my work. I am in my text editor often for well over 12 hours a day. Since I have access to quite a few editors, if there is a situation that some other editor can do better, then I will switch to it to handle that need. The sad thing for HippoEdit, is that it is lacking only a few items that would make it my second choice in many cases, but instead, it often loses out to a different editor. Therefore, I would like to see that change, and so I wish to make a suggestion.

In the 1970s/80s, I did most of my work on Linux, some mainframes, and some PC work, so I used a variety of editors, switching often during one day from one editor on one of the OSes to a different editor on another OS. Of course, the human mind would hiccup occasionally, and I would find that I had just typed a command in one editor that would work only in the editor from the previous OS I had just left. How I wished for an editor that would work the same on all three of the OSes I worked on then. One thing that did help was Regular Expressions, and on Linux, I became known as the Guru of Regular Expressions. When someone wanted to know how to do something complex, I often got tapped for how it could be accomplished using Regular Expressions. The first thing that we needed to do was to run a test to ensure that everything would work and that there would be no accidents, because, well, it can happen. After all, we are human, and that human error syndrome can creep in when you least expect it.

For several years, I became a traveling consultant. I had all of my tools (software) packed and ready to go and be as portable as I could. In those days, the iomega Zip drives allowed me to have some portability, and later on still, the iomega Jaz drives. Often though, when I arrived at a client site, they wanted me to look at something right then, and before I had time to set up any of my tools that I preferred to use. I had no choice but to use Notepad or whatever editor they had installed. In one of those incidents, I came across EditPlus on a computer that I had to do some work on. I quickly started to really like the editor, and as soon as that job was done, I had to purchase my own copy.

One of the features I really liked about EditPlus was that it had a multi-line search box, and a multi-line replace box. I often found that in the majority of cases, the search for text was consistent. The regular expressions were only to handle line endings. Rather than having to come up with a regular expression to handle multiple line replacements, all I needed to do was copy the "search-for" text into the search box, then paste the same into the replace box, then modify the replace box text with the changes needed. This turns out to be much quicker in many many cases. My productivity increased as a result of the simple multi-line search and replace capabilities of one editor.

Of course there are many things that one editor has over another, and no exceptions with either HippoEdit or EditPlus, but for productivity, I always prefer EditPlus.

EditPlus is not the only editor to implement multi-line search and replace capability. Another editor I use as my 2nd choice often is Blumentals WeBuilder. Not only does it also have multi-line S&R, but it also has the great feature of "Replace in files" (includes files on disk that are not open in the editor). Recently, EditPlus has added the ability to "Search files on disk" and those can be opened, then the changes applied, but I am hoping they also add the ability to do the search and replace without having to individually open the files. Very often, I have a change that can affect hundreds of files, so it is not feasible to open each one individually just to make the change. Alternatively, I use several different Search and Replace Tools, some that can only handle a single line at a time, so having that multi-line replace-in-files capability right in the editor is a great plus.

If HippoEdit were to implement those two features, I can assure you that it would jump to the number #2 slot, and possibly win me over to use it as the #1 slot in place of EditPlus.

I have spoke to several text editor developers and I find that due to them being coders themselves, they are very experienced with Regular Expressions, and many of their customers are the same. As a result of this, they often are slow to catch on to the usefulness of the multi-line feature. That really boggles my mind, because I was the same way until I accidentally became exposed to the multi-line S&R world. I have no incentive to use a Regular Expression where a simple search and replace will do, and since a lot of my editing often falls into this category, I have little reason to change.

Alex, I hope you will seriously consider this possibility. I think you might be surprised at the response you will start to receive from both the current customer base, but also the new customers, and hopefully it will be an incentive for those new customers.

Regardless, best of luck, and still looking forward to 2.0.

[alex]

Hello Robert,

thank you very much for such a big and detailed feedback!

May I summarize the request you have:
- multi-line search and replace fields in the search dialog, without the need to use regular expressions.

I completely agree with you, that such a feature is useful and may speed up working performance, especially if one needs to do a lot of multi-line replaces.
Such a request is not new for me - I have already evaluated it some time ago, but delayed because did not find a good UI for representing it, without losing features already built in.
For example:
- how to display the history of searches
- how to support autocompletion of the search pattern from the history
- how to keep the size of the dialog in the proper size borders (if the dialog would be too high, it would hide a large portion of the screen and it would be not comfortable to check results in the text). There is a dozen of other options below the search and replace fields, then probably they shall be somehow hidden, to give more space for multi-line boxes
- how to support navigation with a tab between dialog fields (tab shall be then allowed for such a multi-line editing box)

I will once more check EditPlus, to see how it solved there ( I think, I already done it before) and would evaluate once more.

BTW: There is a small feature, that may help to insert multi-line search/replace texts into the search dialog. Just copy and paste multi-line text into one of boxes and editor would suggest you convert the text into regular expression automatically, enabling the regular expression mode. In this case, line breaks characters would be automatically converted into corresponding regular expression escape symbols.

BTW2: You can already test HippoEDIT 2.0, it is stable enough. It does not have a multi-line search/replace boxes, but have a lot of other interesting new features . You can get it here on the forum.

Best regards,
Alex.

[GCS]

Thanks Alex;

The multi-line fields do not have to be any wider than the original fields. Likewise, their growth vertically adds just a few more lines each. Here is how the Search and Replace dialogs work. The Search only works the same, only without the Replace fields.

EditPlus by default starts out with the single line fields at the top of the dialog. Near the bottom of the dialog is a button labeled "More," which when clicked, extends the bottom of the dialog to show two new multi-line fields to enter text into (each one is 5 lines tall and the same width as was in the original single-line mode). When the entered text goes beyond the edges of the displayed area, scroll bars automatically show up. The button that was labeled "More" now is labeled "Less." Clicking it removes the multi-line fields that shows up at the bottom of the dialog. While the multi-line fields are shown at the bottom, the single-line fields at the top become grayed-out (not accessible). One very important recent improvement was to retain the field's text when switching from one mode to the other (previously, when I switched modes, I had to re-enter the text again).

Blumental's WeBuilder starts out very similar to EditPlus, except the button to get to the multi-line fields is in the middle at the right (labeled "Multi Line"). Clicking it, turns the two one-line fields at the top into multi-line fields. The button is now labeled "Single Line" to return the user to the single line mode. I like the idea that it uses the same area rather than adding two new fields (as EditPlus does).

So, basically, for each field, the dialog grows vertically for three lines each.

From your comment, I know you have considered this idea at some point in the past, but also saw some difficulties working it into the existing design. It may take some thought, and re-examination of how the software works now, but as programmers, we do know that it is possible if we set our minds to it. I remember during college, we learned in class, then were given assignments. We knew the assignment was possible, because we had just studied that area of programing. In my first job out of college, I joined an aggressive software development company, but they did have some stiff competition. I learned the basics of their product, but knew there was a lot more to be learned. There was no more learning before given an assignment to come up with a solution. Even though this was a lot harder, I think I loved  the challenge even more.

Their non-technical Sales Team would go out to Enterprise-level companies to convince them to go with our product. Afterward, they returned and told us what the customer wanted and that they had agreed to provide it. The programmers that had been there the longest would be irate because they had sold something that the product does not do, and that it was not possible to make it do due to "how things worked".

In anger, they were talking about how stupid their non-technical Sales Team had been; they were certain that the sales meeting would have been much better if someone technical had been present to ensure that what was agreed on was possible; that made sense to me to ... at first. These discussion got everyone to thinking though, and soon, one of the newer programmers (not so set in their ways and the program) would say something like, "What if we did this thing first before we do this other thing that we have been doing first in the past" and so on with different ideas being tossed about. At first, the older programmers shot these ideas down, but those suggestions had got others to thinking of alternatives too. Soon, after some paper sketching/white board diagrams, and after a lot of intense discussion, we had an idea that just might work. With some refinements, we always ended up producing exactly what the Sales Team had sold to the customer. This "stupid" non-technical Sales Team had turned out to be the ones that caused us to advance our product to the level that we soon outdistanced all of our competition.

It was probably one of the most important lessons I ever learned in my career.

As programmers, we love a challenge, ... because it IS possible!

If you implement the multi-line Search/Search-Replace, you will be one of the few that has the bragging rights to offer this feature. Knowing how much more productive it can be to use this feature, I think it would be a major step for the product.

Since you already have the "paste multi-line text" into one of the boxes that automates the Regular Expression, you are already familiar with idea, and I think it would fairly simple to implement. Multi-lines can be thought of as a single line, only having carriage returns/line feed as extra characters. If those cause a problem, they could be encoded in a way that would allow them to become part of the string. they would be decoded for use when multi-lines need to be displayed. I think the same automatic handling of the multi-line text into an automated regular expression may also help to solve the 4 bullet items you mentioned. As long as the location that you store the data for those could also handle multi-lines, they may not be much different than they are now.

Regardless, I hope you look forward to the challenge.

Oh yes, I have had the 2.0 Alpha for over a year now, and that is why I am looking forward to seeing it be the new HippoEdit. It will get good media coverage, and if it has multi-line support, it will stand out even more as a dominant editor in the ever increasing field of decent coding editors.

[alex]

Hi Robert,

I agree, that everything is doable, it is just a matter of time how much it would take

The idea with optional, in-place multi-line dialog is not bad... In the case of multi-line, the history, autocompletion etc just would not be supported.
I would evaluate it. Maybe would come in 2.0.

Currently, I am just stuck in localization support for 2.0 I have promised to add. That is only left before a release.
Maybe I would convince myself to add such a feature before

BR, Alex.

[GCS]

Thanks Alex:

>Maybe I would convince myself to add such a feature before

I support that idea because it would give your 2.0 beta users some time to test things out. I hope that it would include the Search and Replace in Files as well (at some starting folder). The multi-line really becomes helpful in this case due to the lack of alternatives on the market that can handle multi-line search/replace. I use WeBuilder currently for that function, but when there are lots of files with the search text, it misses some (at least in my version). Other multi-line search and replace utilities will find the missing ones, but then they sometimes miss some as well. That is why someone needs to solve this problem with accurate results. Best of luck to you and hoping to test this out in the near future.