Add RegexLab - Regex pattern library for Sublime Text 4

[KaminoU]

• I'm the package's author and/or maintainer.
• I have have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries.
• My package doesn't add key bindings.
• Any commands are available via the command palette.
• Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view.
• If my package is a syntax it doesn't also add a color scheme.
• I use .gitattributes to exclude files from the package: images, test files, sublime-project/workspace.

Add RegexLab

RegexLab is a comprehensive regex pattern library and testing environment for Sublime Text 4.

Key Features:

• 📚 Portfolio system for organizing regex patterns
• 🔍 Real-time pattern testing with syntax highlighting
• 💾 Export/import capabilities with integrity verification
• 🎨 Built-in demo patterns for learning

Quality Assurance:

• ✅ 533 unit tests with 98% code coverage
• ✅ Cross-platform validation (Windows, Linux, macOS)
• ✅ Production-ready (audit score: 9.8/10)
• ✅ Sublime Text 4+ (requires ST >=4000)

Links:

• Repository: https://github.com/KaminoU/RegexLab
• Documentation: Full README with examples
• License: MIT

---

There are no packages like it in Package Control.

While similar packages exist (RegExLink, RegexExplainTip), RegexLab is unique in offering:

• A portfolio system for organizing and managing collections of regex patterns
• Real-time testing environment with live syntax highlighting
• Export/import with cryptographic integrity verification
• Comprehensive demo patterns for learning

The package follows ST4 best practices and uses "tags": true for automatic version synchronization.

[nk9]

Looks like this could use a previous_names key.

[KaminoU]

Hi Nick ^^

This is a complete rewrite rather than an evolution of RegexPortfolio. I'm wondering if using previous_names is relevant in this case?

Also, since there are no longer any references to RegexPortfolio in the r.json file, I thought it might be better to keep it separate.

From my perspective, since the old project is definitively retired, it might be cleaner to move forward without the migration path.

What do you think?

Otherwise, I can add a previous_names: ["RegexPortfolio"] entry to messages.json.

Cheers

[nk9]

Thanks for the quick reply! I see that RegexPortfolio is still on PackageControl.io, even though it's been removed from the channel. And I expect that there are still users who installed it forever ago and just haven't removed it. That's why I suggested it. I'm not a PC expert, though, and I know that longstanding uses of previous_names have been removed relatively recently, so maybe this is a question for the mods.

I did a spot check of other packages and their use of this key. None of their package names appear in the index anymore either, so I don't think that's a reason not to do this. I don't think messages.json is the right place for this, but perhaps you meant r.json?

[KaminoU]

You're absolutely right!

I'll update the r.json in my Package Control fork to include:

"previous_names": ["RegexPortfolio"]

^^

[nk9]

Checking in on this. Is there anything preventing this from being merged? @braver

[braver]

@nk9 Mostly just availability on my end. A package like this takes a bit more time to review than a color scheme or language syntax.

And I must admit, the OP looks like it's AI generated with the emoji overdose and overwrought statements like "The package follows ST4 best practices and uses "tags": true for automatic version synchronization.". Also, the repo has 2 commits which is suspicious for a package that seems quite ambitious.

Now this conversation here reinsured me that some humans put care and attention into it, so it's fine, but I'm sure you can imagine we see quite a bit of slop these days.

Putting RegexPortfolio into previous names seems like a good move by the way. It's close enough to the new package and it cleans up the registry even though I doubt there are too many actual users out there.

I'll have a look at the package :)

[KaminoU]

Hello,

Thanks for your feedback and for taking the time to look into it.

As I mentioned to @nk9, the documentation parts were indeed AI-generated and then reviewed/edited on my side, including some of the repo metadata. So I totally understand how it might give off that impression.

The coding part isn’t suspicious though: the workflow is simply built around a very “workbench”-style DEV branch, and a cleaned-up main where I squash everything to keep a tidy, readable history. That’s why the visible commit count is so low.

Thanks again for the review ^^

Happy to clarify or adjust anything if needed.

P.S.:

@braver

By the way you also added quite a few CI/CD checks… And I passed them all =þ
So you "Have faith" lol ^^

And for transparency: I also documented my unit test coverage in the Contributing section.

[braver]

a tidy, readable history

Or effectively hardly any history at all depending on your perspective on such things. But thanks for explaining 😄

Remarks on the package:

• Preferably use one consistent command prefix (see test warning)
• "My package doesn't add context menu entries" this is not true.
• "My package doesn't add key bindings" also false, and some bindings are not behind a context, risking conflicts.
• You don't need to put "caption": "-" between every menu item.
• Is "INFO" the right default log level? We prefer packages to be quiet (ie. not pollute the console) during normal usage.
• Your installation message has so much ascii art (not even sure what it's supposed to represent), that users will have to scroll down to read anything, and then too much text once you get to it. Remember that users will see this only once. Use it to direct them to your documentation, so that they know where to find it, but don't put all the documentation in there.
• Go easy on the emoji everywhere. It's an AI-generated fad right now, so I get it, but it doesn't actually make the readme more readable with all that distraction. Similarly, and more importantly, avoid emoji in command and input panel labels. It's really not necessary and does not fit the ecosystem (which leans functional and professional).

Since your package is reading from and writing to files, did you test your package also when packaged (use the Create Package File command and then install that instead)?

[KaminoU]

Thanks for the detailed feedback ; really appreciate you taking the time. ^^

About the “context menu” remark: could you clarify what you mean exactly?
For me, a context menu is strictly the right-click menu, and my package doesn’t add anything there. If I’m misunderstanding what you refer to, I’m happy to adjust.

Regarding the keyboard shortcuts: the first CI run indeed complained, and I updated the bindings accordingly. Let me know if something still looks off.

About emojis and visual cues : fair point. I personally navigate a lot by visual blocks (indentation, colors, small icons, etc.), so some of that comes from my own workflow. But I get where you're coming from; tastes differ =P

I’ll add an option to tone all of that down so users can choose. I just need a bit of time, my schedule is packed at the moment… open source life =D

And yes, I tested everything I could on my side using the packaged version:
RegexLab.sublime-package (f612be1ab83eb70bff9bb4f129603e8bd82f4199b4f2e92a1e2c141018714dd1)

Again, thanks for the thorough review

[braver]

and my package doesn’t add anything there

It does, that’s what the Context.sublime-menu file is for.

[KaminoU]

Ah yes you’re absolutely right!

I had completely forgotten about that. I added this little helper very late one night thinking it might be useful, but if it risks causing menu conflicts, I can remove it or move it somewhere more appropriate.

Thanks for pointing it out!

[braver]

but if it risks causing menu conflicts

Well, it's that it's sometimes hard to make things in there conditional or truly contextual. But if every package adds stuff in there just cause it might be useful, users end up with a very long context menu. So, if you could put your context menu behind a settings that could work. In general though, ST use is more driven by the command palette, keybindings and other menus than right-clicking things a lot.

[KaminoU]

Thanks to both of you! =)

I realized I made a bit of a blunder. 😅 My tests were passing locally, but I completely overlooked the difference between dev mode and the packaged environment. I definitely needed a mutable workspace for the integrity checks.

I've pushed the fixes, and unit tests + CI are all green now.

That's what happens when coding at 3 AM... eyes start crossing! 😵‍💫

Thanks again for the feedback!

@nk9 => KaminoU/RegexLab@b958c1c

cheers