I save the variable in .dir-locals.el like this:
(add-dir-local-variable 'nil 'CurrentProjectStat CurrentProjectStat)
(save-buffer)
(kill-buffer)
When I upload a file with a given project, this variable is loaded only for this buffer, but I need it to be loaded globally. I use this variable in the form of widgets, this is a different buffer, and this variable is no longer there.
I do not know in which direction to look, overriding the variable does not help.
Tell me please how to make such a variable global?
For the sake of answering the question as stated:
You can use the pseudo-variable eval to evaluate arbitrary code, and therefore set a non-local variable (assuming the variable is not already buffer-local), like so:
((nil . ((eval . (setq GLOBALVAR VALUE)))))
I strongly doubt that this is actually what you want to do, however.
Related
The help text for set -a is somewhat cryptic to me, but maybe i just don't understand what bash is doing behind the scenes with variables. Can someone explain why "marking" variables is needed (what are "unmarked" variables)?
My bash man-page uses a slightly different wording for this: Each variable or function that is created or modified is given the export attribute and marked for export to the environment of subsequent commands. This sounds more clear to me. It means:
Each variable you define in your script, is placed in the environment of any child process you create, and each function you define is also available to each bash-child-process you create.
I need to refer to the same variable in several functions in a python script. (The write context of a CGPDFDocument).
I can either write global writeContext in every function;
or add the variable as an argument to every function;
....both of which seem to be excessive duplication.
Other answers to questions about global variables in python suggest that they are "bad".
So what's the better way of handling it?
I'm wondering what benefit discriminating between local and global variables provides. It seems to me that if everything were made a global variable, there would be a lot less confusion.
Wouldn't declaring everything a global variable result in fewer errors because one wouldn't mistakenly call a local variable in a global instance, thereby encountering fewer errors?
Where is my logic wrong on this?
Some of this boils down to good coding practices. Keeping variables local also means it becomes simpler to share code from one application to another without having to worry about code conflicts. While its simpler to make everything global, getting into the habit of only using global variables when you actually have to will force you to code more efficiently and will make your code more structured.
I think your key oversight is thinking that an error telling you a local variable doesn't exist is a bad thing - it isn't. You've made a mistake and ruby is telling you so. This type of mistake is usually easy to fix: you've misspelled something or you're using something that you forgot to create.
Global variables everywhere might remove those errors but they would replace them with a far harder set of errors to reason about: accidentally using a variable that another bit of code is using. Imagine if every time you called a function (one of your own or a standard library one or one from a gem) you had to check which global variables it might change (and which functions it called, since it might also change global variables) If you make a mistake then you might get an error message (if the class of the object in the variable changes enough) but often you would just silently get incorrect results (if the value of a variable you were using changes unexpectedly).
In general global variables are much harder to work with and people avoid them when possible.
If all variables are global, every line of code in every program (including those which haven't been written yet) written by every programmer on the planet (including those who haven't been born yet or are already dead) must universally, uniquely agree on the names of variables. If you use a variable name that someone else on a different continent two years from now will also use, both of your programs will break, when used together.
In the freemarker template language, I can test whether a variable exists by using constructs like variable?exists or variable??. I can also cause a previously non-existent variable to exist by assigning to it, e.g., <#assign variable = "hi" />. But how can I cause a previously existing variable to no longer exist?
I have some other dude's freemarker template, with logic at various points that tests for the (non-)existence of certain variables. In my use case, it would be simplest if I could have a variable that exists at one point, then becomes undefined when including his template, then gets assigned to again later on. The alternative is to restructure things more significantly.
No, there's no directive fort that. Maybe it can be achieved with a custom directive (TemplateDirectiveModel) that can then write null into the variable through the Environment. (Unless the Environment API checks for null-s...)
Is there a parameter to make FMPP fail when it is unable to find a value for a variable in the template? right now it just leaves the text intact with ${} if it cannot resolve a variable.
Something strange is going on there, because it does fail and by default even aborts the whole batch processing if you refer to an undefined variable. Also, it doesn't leave ${}-s in the output, because all the ${ and } are "parsed away" before the template could do anything. So I suspect the value of those variables is indeed the string "${}", or you have some tricky #escape in the border/footer/header settings, or something tricky like that. (If you can provide a minimalistic example to reproduce this, I can certainly spot the reason.)