Each time I need anything beyond the standard search, I find myself trying several things, searching Google and in the end terribly failing. Apparently, the Hg search syntax is pretty extensive and I would like to use its power, but I don't seem to be able to find a good reference.
For instance, quite often I want to find all changes in the repository related to a partial path match. I know that the following works:
file('path:full/path/file.txt')
But I would like to search for files by partial match, and neither of the following worked:
jquery -- seems to find everything
file(jquery*) -- finds nothing
file('jquery*') -- finds nothing
file('path:jquery.*') -- finds nothing
file('name:jquery.*') -- finds nothing
file('path:jquery.js') -- finds every revision, it seems
From the popup in TortoiseHg I see that there are a gazillion options, but no hint on how to use them (the help link shows a little bit more, but nothing on what a pattern should look like in file(pattern)):
In the end I usually find what I want using other ways of searching, but it would be so nice to be able to use this power of expression, and it's quite a shame that after so many years, I've never found out how to leverage this.
I can very much advise using the hg help system for this. The most useful pages to look at (in my view):
hg help revsets
hg help filesets
hg help patterns
In the page about patterns, you can find about 'path:':
To use a plain path name without any pattern matching, start it with
"path:". These path names must completely match starting at the current
repository root.
In other words: using 'path:' is not suitable for this purpose. Slightly below, 'glob:' is mentioned:
To use an extended glob, start a name with "glob:". Globs are rooted at
the current directory; a glob such as "*.c" will only match files in the
current directory ending with ".c".
The supported glob syntax extensions are "**" to match any string across
path separators and "{a,b}" to mean "a or b".
In other words, it should be possible to use the pattern file('glob:**jquery*').
In fact, the above pattern would also work without the glob prefix, so: file('**jquery*'). See part of the page about revsets:
"file(pattern)"
Changesets affecting files matched by pattern.
For a faster but less accurate result, consider using "filelog()"
instead.
This predicate uses "glob:" as the default kind of pattern.
Related
I've been scratching my head a bit on how to exclude files based on the name of one of the parent directories. I'm not sure if this is something that's not possible or if I'm just missing some real obvious syntax here.
I have a cop that's examining large repositories where I don't control the exact directory structure. I need to skip examining files in any directory named test though no matter where it occurs in the directory structure. For instance my-repo/foo/bar/test/foo/bar/file.rb should not be examined and my-repo/test/another_file.rb should also not be examined. Is there any way to define an exclude that's basically '**/test/**/*.rb?
Yes, your assumption is correct. You can find an example in e.g. in rubocop-rspec extension:
Include:
- "**/spec/**/*"
It would work the same way with Exclude.
It works both for AllCops, and specific cops can be configured as well.
I'm trying to figure out how to search within files containing only a certain extension and within a certain directory. I've tried */app/*,*.jade, but that seems to search for anything within the app directory OR in any other directory given its extension is .jade. I just need a method to filter for files that satisfy both conditions. I feel like the obvious solution would simply be an AND character in place of the comma (which seems to act as an OR), but I'm not sure if the syntax incorporates such a feature. Anyone know if it does, or can offer an alternative solution for my use case? Thanks.
You are indeed correct that the Find in Files functionality allows you to provide a comma separated list of search terms and they are effectively an OR operation.
Note that you can also prefix a term with - to make it mean BUT NOT, which you can use to filter results out.
In order to find only files of a certain extension AND in a certain path, you need to create a search term that includes both of them at the same time:
*/app/*.jade
I want to edit find_under_expand (ctrl+d) to consider hyphenated words, as single words. So when I try to replace all instance of var a, it shouldn't match substrings of "a" in words like a-b, which it currently does.
I'm assuming find_under_expand wraps your current selection in regex boundaries like this: \ba\b
I need it to wrap in something like this: \b(?<!-)a(?!-)\b
Is the find_under_expand command's source available to edit? Or do I have to rewrite the whole thing? I'm not sure where to begin.
Sublime's commands are implemented in one of several ways: as macros, as plugins, and internally as part of the compiled program (probably as C++). The default macros and plugins can be found in the Packages/Default directory in ST2 (where Packages is the directory opened when selecting Preferences -> Browse Packages...), or zipped in the Installed Packages/Default.sublime-package file in ST3, extractable using #skuroda's excellent PackageResourceViewer plugin, available via Package Control. Macros have .sublime-macro extensions, while plugins are written in Python and have .py extensions.
I searched all through the Defaults package in ST3 (things are generally the same as in ST2), and was unable to find a macro or .py file that included the find_under_expand command, or FindUnderExpand, which is the convention when naming command classes in plugins. Therefore, I strongly suspect that this command is internal to Sublime, probably written in C++ and linked into the executable or in a .dll|.dylib|.so library.
So, it doesn't look like there's an existing file that you could easily modify to adjust for your negative lookahead/lookbehind patterns (I assume that's what those are, my regex is a bit rusty...). Instead, you'll have to implement your own plugin from scratch that reads the "word_separators" value in your settings file, which the current implementation of find_under_expand doesn't seem to be doing, judging from your previous question and my own testing. Theoretically, this shouldn't be too terribly difficult - you can just open up a quick panel where the user enters the pattern/regex to be searched for, and you can just iterate through the current view looking for matches and highlighting/selecting them.
Good luck!
When I run some commands, like certain scripts or Makefiles, a number of files and folders are generated along the way to the final output. (For the moment, let's not go into whether or not the script should tidy up after itself. Sometimes this might be a good idea, sometimes not.) What term describes these files?
(I know what I mean when I say "cruft", but I don't think this is necessarily clear, and it could come off as colloquial, which is not what I'm aiming for.)
A common term seems to be "intermediate files"; maybe you could say "intermediate build artefacts" if they are not necessarily just files.
CruiseControl refers to them as Artifacts at least.
I would just refer to them as ~TempFiles generated by your scripts.
Suppose, I have the following pattern in a comment in my code - $REV$. I would like to have a client side hook, which would replace it with something like $REV[$ d3d004be40c5 $]REV$. Any subsequent commits would assume that there is a revision between $REV[$ and $]REV$ and replace it accordingly.
I want to use a client side hook, because I do not want an extra commit for this mangling, hence it must be done on the client as part of the commit.
I reckon a precommit hook in python should be apt for the job, but I've just thought to seek for an advice before delving into it. Maybe there is a better way to do it like using an existing extension, for instance. If anyone has done anything similar - please share.
Thanks.
P.S.
I know this may seem strange to embed the revision within the source code, but please indulge me.
keyword extension does what you want (though usefulness of this is really, really low).