For TextMate, cmd+E, cmd+F then the selection is in the search box. Or, you don't even have to open the search box with cmd+F, just cmd+G to next selection or cmd+opt+F to multi-cursor edit all occurrences.
The regex in TextMate is also very powerful (the unicode support is more powerful). New lines can be matched with \n. Another way is to select new line and repeat the cmd+E trick.
TextMate column selection is even better: you can enter column select mode simply by pressing opt. It is in fact multi-cursor editing, many editing commands like completion / copy / paste can work for each row individually.
Cmd+N or ctrl+cmd+N in TextMate.
The last one, not in TextMate. Though cmd+E then cmd+opt+F can highlight and start multi-edit on all instances of the word.
1. Fast and responsive
2. If you write a plugin, you know TextMate is Unix (forked child process, communicate through shared fd, you invoke a command named dialog2 to let TextMate popup any dialogs or completion menu...). You can add editor commands in any language -- you can even make TextMate display complex UI dialog with bash.
3. File browser is nearly a finder (drag and drop like finder, and most finder shortcuts work)
4. Search (there are some hidden shortcuts, but when you master it you feel very fluent)
There are weakness too: TextMate is losing the market, many bundle developers switched to other editors. You can't find many new bundles nowadays. It still doesn't support vim-like keyboard operation... etc
I think another (important) cause of microservice is politics:
When every department wants the easiest job with max outcome and the boss decides to split the cake equally, then an easy job X can be cut into N services which are usually named "micro", resulting in a huge project of complexity (X/N)^N for each team.
One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.
Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?
> One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.
I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager.
A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.
I suggest you use one repo with sub directories, one directory for API part, one directory for front end part, one for the server part ...
Then, when you change the API, you don't have to create 3 pull requests across 3 repos, just ONE pull request and teams can review all the changes together.
And your problem of searching for issues assigned to one person across multiple repos is not a problem any more.
There are already many good examples of managing multiple modules inside one repo:
I think such cases call for a more professional / serious project management tool. I mean, GitHub projects is just a webapp, one that lets you move some rectangles around with a mouse. I'll be happily using it to manage issues on my small open-source projects (that incidentally are usually self-contained within a single repo), but for anything bigger / more serious, I'd rather use an external tool.
Reusable and reused components span multiple projects and even companies. A quite reasonable scenario is when a project includes a component library that's loosely coupled, open-sourced and used by others (so it pretty much has to be in a separate), but it's not just an included dependency but being actively worked on in a project - e.g. a single small new feature would require commits to both the library and the repository that's using it.
Spinnaker is comprised of a bunch of quasi-independent microservices, designed to work together. I don't think it would necessarily make sense to have them all in the same repo, when they could be swapped out or even used separately in another project.
