http://www.postgresql.org/docs/9.3/static/textsearch-controls.html often refers to an optional regconfig parameter, but I can't find its possible values and their meanings. Where is it documented? If this can't be answered (e.g. because it depends on my installed database-components or like), how can I determine it myself?
I'd like a "plain text" regconfig, without any human-language transformation. What is the argument for it?
A text search configuration is a grouping of configuration objects: parsers, templates, and dictionaries. As far as I can tell the only configuration choices built-in are the language-specific ones like 'english' or 'finnish'.
You can see a list of configurations in your database via the \dF command in the psql command line tool, or via a query:
select * from pg_catalog.pg_ts_config;
Regarding a "plain text" configuration (#2), I'm not sure what you need but look at creating a custom dictionary. Perhaps start with the built-in "simple" dictionary and remove the stop words?
COMMENT ON TEXT SEARCH DICTIONARY simple IS 'simple dictionary: just lower case and check for stopword';
Reference: Configurations
The blog article Mastering PostgreSQL Tools: Full-Text Search and Phrase Search answers your question in full.
To summarize:
The regconfig is the Search Configuration object which is, itself, a collection of templates, parser dictionaries and stopwords. You can find it using the command \dF. To find out more about a particular regconfig, such as english/dutch use the command \dF+ dutch
For setting up own regconfig, you'll need access to the postgres.conf file, which isn't always allowed.
Related
I want to write a vscode extension and use vscode.commands.executeCommands(), but I don't know what parameters the command I want to use takes.
For example, when I want to use the "actions.find" command, how do I find out what parameters this specific API accepts?
I don't think there's any comprehensive documentation on commands and their arguments at this time. This page does list some of the most important ones though.
For some commands, there's also args auto-completion in keybindings.json:
Note that a lot of the built-in commands aren't much of an "API" at all. Looking at its implementation, "actions.find" in particular does not seem to support any arguments that would be useful to extensions. Compare this to the implementation of "workbench.action.findInFiles", which supports a well-defined set of arguments such as search query etc.
I'm trying to figure out how to modify an XML file with NSIS. So I'm trying to learn how to use the XML plugin. The examples on the forum page often use the format ${plugin::command} like:
${xml::LoadFile}
The documentation gives no indication that you need the dollar sign and curly braces. As I understand it, just plugin::command will do. So I've been trying to figure out what that syntax means.
The documentation says a $ is for variables and the {} are for code blocks, but I can't find anything about what it means when they're used together. My Internet searches have revealed that it's used for something called template literals in JavaScript. But what does it mean in NSIS?
EDIT: I should mention that the NSIS documentation does show examples of this syntax, especially in the Predefines section, but it still doesn't explain what the syntax means in general.
EDIT: Okay, now I see that the syntax is for the compiler to replace things using !define and !macro. But... what about this specific case? Is it valid to use colons in such a symbol? Why are some people writing ${xml::LoadFile}and some people just writing xml::LoadFile?
It's a !define. There is a header file for this plugin that defines it. The plugin probably needs to do more than one thing, so they wrapped a few lines together with a define that inserts a macro. Either that or it has some default parameters for the plugin call. Either way, it's trying to save you some typing with this syntax.
According to http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL
queries can use regular expressions on both the values and the keys. While I have no trouble using regex on the values, I'm having a problem with the keys.
The example on the wiki referenced above says (among other examples):
/* finds addr:* tags with value exactly "Foo" */
node[~"^addr:.*$"~"^Foo$"];
So, that's an example of using regex on the keys and the values.
What I am interested in is the name key. Specifically the name:en key. There are a couple problems with searching by name. Not all names are in English, and for those nodes/way/relations whose names are not in English, there is no guarantee there will be a name:en tag with an English version of the name.
In general, there is no way to know in advance if the name will be in English or that there is a name:en tag. If you only ask for name or name:en, you run the risk of finding no hit. (Of course, searching for both is no guarantee of success, either.)
I have a case where I know name fails, but name:en succeeds. That is my test case. I can query the overpass-api.de/api/interpreter using this:
[out:json][timeout:25][bbox:33.465530,36.156006,33.608615,36.574516];
(
node[name~"duma",i][place];
way[name~"duma",i][place];
>;
relation[name~"duma",i][place];
node["name:en"~"duma",i][place];
way["name:en"~"duma",i][place];
>;relation["name:en"~"duma",i][place];
);
out center;
see it on overpass
and it works fine ("duma" is not found through name, but it is found with name:en), but I find it lengthy and somewhat repetitive.
I would like to use a regular expression involving the name and name:en tags, but either the server does not understand the query or I simply am using an incorrect regex.
Using the example shown in the wiki: node[~"^addr:.*$"~"^Foo$"]
I have tried:
[~"name|name:en"~"duma",i]
[~"name.*"~"duma",i]
[~"^name.*$"~"duma",i]
and several others. I even mimicked the example with [~"^name:.*"~"duma",i] just to see if anything would be returned.
Does overpass-api.de recognize regular expressions on the keys or do I just have the regex wrong? I don't get an error from overpass-api.de, just the coordinates of the bbox and an empty result. It's usually very strict about reacting to a poortly formatted query. Thanks in advance.
That's really a bug in the Overpass API implementation concerning case-insensitive key regex matching, see this Github ticket for details.
For the time being, you can already test the patch on the development box:
http://overpass-turbo.eu/s/b1l
BTW: If you don't need case-insensitive regexp matching, this should already work on overpass-api.de as of today.
Geany(IDE) supports Autocompletion or IntelliSense as you program, but this is done based on the words you've used in the code so far.
Is there any way so I could have Autocompletion for my language keywords?
You can achieve this by writing your own tag file. It should be name like <somename>.<filetype>.tags and can be stored e.g. inside .geany-folder or inside global folders. You can import it via Tools-menu.
The tag file contains of a list of your methods, functions etc of your language as well as optimally some options for these commands used a tooltip. You can find some details inside manual
Of course, you could also check the wiki whether there might be already some tag file available for your language.
I'd like to have links with the syntax [[foo bar]] go to files with the name foo bar.org. This would make using org-mode much more like using a personal local wiki.
Is this possible without breaking existing link functionality? I'd also ideally still be able to export to html, etc. with standard org-mode tools.
The best I've been able to do is something like: (setq org-link-abbrev-alist '(("o" . "file:%s.org")))
This lets me use the syntax [[o:foo bar]], but that is more verbose, and looks distractingly ugly inline. For example: The quick brown o:fox jumps over the o:lazy_dog. And [[o:foo bar][foo bar]] is even more verbose to type and edit (though it reads fine in org mode).
I don't have a ready made solution and am not a programmer, but this part is self-documenting in org.el, you can write a dedicated link search function. I cite:
"List of functions to execute a file search triggered by a link.
Functions added to this hook must accept a single argument, the search
string that was part of the file link, the part after the double
colon. The function must first check if it would like to handle this
search, for example by checking the `major-mode' or the file
extension. If it decides not to handle this search, it should just
return nil to give other functions a chance. If it does handle the
search, it must return a non-nil value to keep other functions from
trying.
Each function can access the current prefix argument through the
variable `current-prefix-arg'. Note that a single prefix is used to
force opening a link in Emacs, so it may be good to only use a numeric
or double prefix to guide the search function.
In case this is needed, a function in this hook can also restore the
window configuration before `org-open-at-point' was called using:
(set-window-configuration org-window-config-before-follow-link)")
See also Hyperlinks :: Custom Searches # gnu.org