Here is what I mean:
[paths]
default = some/path/to/something
another_path = [paths.default]/something/else
Can it be done somehow?
Thanks ;)
No, the Mercurial config format has no concept of variables or re-use.
See the hgrc documentation:
The values are either free-form text strings, lists of text strings, or Boolean values. Boolean values can be set to true using any of "1", "yes", "true", or "on" and to false using "0", "no", "false", or "off" (all case insensitive).
Individual settings may support some form of variable parsing, but this does not apply to values in the configuration file in general. Variable support (environment or otherwise) is the exception, not the norm. For example, %include (to include another configuration file) does support environment variables via the Python os.path.expandvars() function, but this does not apply to any other syntax.
Related
I recently started using a 3rd party extension for language supporting robot programming (RoboDK). The extension is pretty good but doesn't include many of the commands I would like to use and doesn't correctly (at least to me) handle optional arguments to commands. I'd like to 'extend' the extension to support additional commands (and potentially provide this feedback to the developer).
I'm specifically using ABB's RAPID robot language.
Example:
MoveL robtarget, speeddata, zonedata, tooldata \WObj:=WObj0;
For MoveL, var1 thru var4 are required but \WObj:=WObj0 is optional. The '\WObj0:=' part of the string is a constant (if supplying the option) and WObj0 would be a variable of the expected type for MoveL (a work object, in this case).
Is there a way to edit the snippets json to not enter the optional part unless I start typing a backslash followed by text? I also would like to keep the optional part in the snippet as a reference so I don't have to remember every optional argument as some commands have many options.
Here's an excerpt from the snippet.abb.json file:
"movel": {
"prefix": "movel",
"body": [
"MoveL ${1:var_robtarget}, ${2:var_speeddata}, ${3:var_zonedata}, ${4:pers_tooldata} \\WObj:=WObj0;"
],
"description": "Linear motion"
},
Which results in the code with var_robtarget, var_speeddata, var_zonedata & pers_tooldata all highlighted and the remainder is plain text:
MoveL var_robtarget, var_speeddata, var_zonedata, pers_tooldata \WObj:=WObj0;
Is there a way to edit the snippets json to not enter the optional
part unless I start typing a backslash followed by text?
No, I don't think there is any way to do that within the same snippet. You could make another snippet with the backslash prefix but that is cumbersome.
Here is a simple way to do what you want but you will have to delete any optional variables you don't want:
"body" [
"MoveL ${1:var_robtarget}, ${2:var_speeddata}, ${3:var_zonedata}, ${4:pers_tooldata}${5: \\WObj:=WObj0}${6: anotherVar};"
]
That last variables are also selected when you get to them. If you don't want any just hit Delete.
In the above demo I am just tabbing and deleting.
In Visual Studio Code (1.22.2) when I add certain words to a YAML file they are syntax highlighted differently to what is expected.
For example both on and y are colored orange here. AFAIK, neither on nor y have any special YAML significance. This occurs for other keys and values also. I note this same color is used on values of true or false but here it is occurring for seemingly arbitrary values and also for keys. The same occurs after a restart with all extensions disabled so it's not some forgotten extension I don't think.
Is this some other file-type syntax-highlighter interfering? Am I missing something about YAML 'keywords'?
In YAML 1.1, there are actually many values recognized as booleans, and on and y belong to them.
See the type specification for !!bool in the YAML 1.1 type repository: http://yaml.org/type/bool.html
I wrote this overview of Types/Schema in YAML 1.1/1.2 a while ago, maybe this is helpful too:
http://blogs.perl.org/users/tinita/2018/01/introduction-to-yaml-schemas-and-tags.html
One of the bigger changes in 1.2 was that less values are recognized as booleans.
I have a questions about Team Foundation Server variables:
Is there a way to update/define TFS variables from a PowerShell script (runs as a custom build step)?
When I define a variable value like "a,b,c" and I want to use it in a build step which wants it as a multiline value (separated by \n) is there a way to split it online, like Projects: $(myVariable).split(',') ?
Can I define multiline-type variable value?
Variables are name-value pairs defined by you or provided by Build or Release Management. You can use variables as inputs and in your scripts. Check:　https://www.visualstudio.com/en-us/docs/build/define/variables
One variable usually has one value. But your requirement should can be achieved with Poswershell script, you need to refer to Powershell documentation to implement how to split values.
No. Never seen such definition.
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.
There are several similar setting functions:
set & setq
set-default
defcustom
custom-set-value
custom-set-variables
customize-set-value
customize-set-variable
so, what's the difference between these functions?
If I want setting my own preferences to an add-on, for these scenario:
If a variable setting by defcustom, which setting-function will be better?
And what about a variable setting by defvar?
The short answer to you question is:
use setq or setq-default for variables defined by defvar.
use setq, setq-default, or the Customize mechanism for variables defined by defcustom
Below is the long answer.
The functions that you are going to use are the following:
set is the main function to set the value of a variable.
setq is another version that automatically quotes its first argument. This is useful since quoting the first argument is what you want to do almost all the time.
Some variables cannot be set globally. Whenever you set the variable it is only set for the current buffer. If you want to simulate setting this variable globally you use set-default or setq-default.
The functions that a package writer uses are:
defvar which allows the package writer to define a variable and to give some documentation. This function is not required but makes the life of users easier.
defcustom builds on defvar. It tells emacs that it is a variable, and it allows the developer to create a custom interface to set the value. The developer can say, things like "this variable can contain only the value 'foo or 'bar".
Setting variables can be done two ways:
if defvar was used, the values can only be set by the user in its .emacs by using the set function (or variants)
if defcustom was used, the values can be set using set (see 1.) OR by using Customize. When using the customize mechanism, emacs will generate some code that it will place in custom-set-variables. The user should not use this function.
They are, largely all paths to the same thing. There are some important differences though. The best way to get to know them is to read the manuals for Emacs and Elisp (see C-h i). Off the top of the head though:
set is a "low-level" variable assignment
(setq foo bar) is shorthand for (set (quote foo) bar)
(set-default foo bar) means "unless there is a more explicitly scoped definition of foo in the current buffer, use the value bar", and applies to all buffers.
defcustom is used to mark a variable as one that the user is expected to be able to safely modify through the customize feature.
custom-set-value and customize-set-value are two names that point to the same function. They're convenience methods for working with the customize system.
custom-set-variables and customize-set-variables are used to make some set of customized-through-customize variables active, IIRC.
In general, it's recommended to use M-x customize to change things around. You're free to set things defined with defcustom using set or setq in your .emacs, the customize system will warn you about it if you later change it via customize though.
defcustom is generally only used by people writing packages meant for distribution, and I don't think I've seen anyone use custom-set-* outside of files internal to customize. setq is very common in people's initialization files for setting things up how they like them, regardless of whether those things are marked for use with customize or not.
I don't have a full understanding of all this, hopefully someone else can shed more light, but I think that that's a fairly good overview :P
set and setq are the lowest level primitives used for assigning any kind of variable.
set-default and setq-default are emacs extensions that go along with buffer-local variables, to allow setting the default values used for new buffers.
3-7. All the "custom" stuff is a later addition that was designed to support a user interface for managing variables that are intended to be used as user preferences.
defcustom is similar to defvar, but allows you to specify a place in the hierarchy of options, as well as data type information so that the UI can display the value as a menu, or automatically convert user input to the appropriate type.
I don't think there is a custom-set-value function.
custom-set-variables is used by the customize UI when saving all the user's options. It lists all the variables that the user has changed from their defaults.
6-7. custom-set-value and custom-set-variable are used by the Customize UI to prompt the user for the current and default values of an option variable, and assign them. You don't normally call this yourself.
Just as addition, the differences between those commands have increased due to the introduction of lexical binding, though those differences will not really be relevant if you just want to customize some variables.
The def... constructs declare global variables. The set... functions set variables, whether global or local. When x is neither a local variable (a formal parameter of the current function or declared by a let form or similiar) nor defined by a def... form and you write (setq x 0) the byte compiler will even show a warning
Warning: assignment to free variable `x'
Variables declared with defvar, defcustom, defconst are dynamically bound, i.e. when you have a construct
(let ((lisp-indent-offset 2))
(pp (some-function)))
the function some-function will see the change of the global variable lisp-indent-offset.
When a variable is not dynamically bound, in something like
(let ((my-local-var 1))
(some-function))
where my-local-var has no global value, then some-function will not see the assigned value, as it is lexically scoped.
On the other hand, dynamically scoped variables will not be captured into lexical closures.
More details can be seen in http://www.gnu.org/software/emacs/manual/html_node/elisp/Lexical-Binding.html