Visual Studio Find And Replace; Would the community like to be able to use other Text Engines?

Question

The Regex syntax of Visual Studio is not the same as .Net Regex or even close to ECMA complaint. Historically it was based off of old editors of the time's regex syntax and frankly is not used anymore.

Would the community benefit by exposing an unfinished interface to Visual Studio to allow for other text engines to be used. Engines such as created not by Microsoft but by the community at large?

I have posted this Microsoft Connect issue on that :

Modify Visual Studio Find And Replace To Accept other Non MS Text Matching Engines

Thoughts?

---

William Wegerson (www.OmegaCoder.Com)

Answer 1

Hi Omega,

Thanks for posting. I can see some same discussions on the net, and understand the requirement. I rate your feedback link. But from another perspective, the PG may have some historical reasons and difficulties to replace a brand new regex syntax in the find/replace function. I will try to contact to see if PG members would like to share some comments here.


Regards,
Ji Zhou

---

We have published a VSTO FAQ recently, you can view them from the entry thread http://social.msdn.microsoft.com/Forums/en/vsto/thread/31b1ffbf-117b-4e8f-ad38-71614437df59. If you have any feedbacks or suggestions on this FAQ, please feel free to write us emails to [e-mail].

Answer 2

Personally I would rather they invest the time and money into something I use more frequently than search.  I mean search is pretty standard.  I would definitely like to see them switch over to the .NET regex syntax though.  The old legacy one is hard for anybody but a compiler writer to love.

The issue I think they might have is that the IDE itself doesn't just do simple searching.  The IDE has separate interfaces for searching for symbols (Find Symbol) and Find/Replace.  The IDE handles symbol searching itself but Find/Replace can be implemented by a language service or the IDE depending upon the service.  This would complicate trying to replace the search engine.  In order to make this feature meaningfully separate the IDE would need to combine search functionality into a single interface (or two) and then force language services to "publish" searchable text.  If they didn't do this then a search engine would boil down to simplying calling the language services and caching the results.  I don't think there is much room for innovation there.  IMHO.

Michael Taylor - 5/27/09
http://p3net.mvps.org

Answer 3

I would definitely like to see them switch over to the .NET regex syntax though.  The old legacy one is hard for anybody but a compiler writer to love.

Frankly that is where we all would love to go...we had the MS employee who worked on the Find/Replace and he gave us the background to the reason why Regex syntax is funky on this thread in the Regex forum:

Does VS have a customized RegEx

---

William Wegerson (www.OmegaCoder.Com)

Answer 4

Michael, I think you have it somewhat backawards. Text Find/Replace is not implemented by the language service: it's built into the core IDE and closely related to the text editor. Currently, the language service has no participation in text find. The language support is closely involved with symbol search.

If extending the re syntaxes supported were to be done, I don't think it would make sense to replace the existing RE syntax. Instead, .NET regex should be choosable from the Use dropdown, and made the default when you're using one of the managed development profiles.

The job of the Find subsystem would be to offer a place to plug in another implementation of a 'Finder' (there's currently a C++ class interface for this that would need to be exposed through COM, then tested and documented). Finder handles the matching logic, and it uses the underlying IVsTextLines as the source for text to scan, returning TextSpans for matches. Exposing the interfaces would be a modest amount of work. Implementing the Finder for .NET regex would be a bit more work.

As I said on the other thread, it's a perennial item that always makes it to the consider list, but always gets cut for higher-value work.

It is an interesting twist to consider simply expose the extension point. That would at least provide an opportunity for third parties. Exposing an extension point in and of itself doesn't add a tremendous amount of value until someone takes advanatage of it. Nice for the community, but many customers would never see it, so the value of the work is diminished.

Caveat on all this: I haven't worked on this part of VS since 1999, but I think it's pretty much where I left it. I'd personally love to see my work built upon. Good luck on your campaign!

Answer 5

I'll take your word for it then.  My understanding comes from the terse documentation about it in the VS SDK.  It indicated the other way around but did point out that a language service could defer to the IDE for defactor F/R functionality or provide its own view of the data for searching.  Maybe somebody from MS should update the SDK to document how search works because the existing documentation is mostly meaningless. 

Still my original opinion that simply switching to .NET REs would be sufficient for me.  I currently don't even bother with the existing RE support in find.  It's hard enough remembering the .NET vs. non-.NET Re grammars without adding VS to the list.

Thanks.

Michael Taylor - 5/27/09
http://p3net.mvps.org