I'm trying to set the default value for the number of spaces that gets used to indent lines in C++ mode. I see a lot of answers and have tried a setting a few things (in my ~/.emacs.d):
(setq c-basic-offset 2)
In a completely separate attempt, I tried the following:
(setq-default c-basic-offset 2)
In both cases, if I use C-h v to test the value of the variable I get
Its value is 4
Original value was set-from-style
Local in buffer file.cc; global value is 2
I interpret this to mean that one of the minor-modes (I suspect the value of c-indentation-style) is overwriting the global value. So instead I set the value as follows:
(setq c-default-style "bsd"
c-basic-offset 2)
When I try to query the value of the variable I still get an output similar to above. I am able to manually set the value of the variable for buffers and it seems to work fine. Does anyone have any ideas about what I should do to make it more "permanent"?
Related
I recently had the need to match against two strings in ColdFusion and ran into this scenario during my loop:
<cfif "0" IS NOT "NO">
Generally during the loop it looks something like this:
<cfif "AM" IS NOT "BA">
Now both of these values were variables (I wasn't just typing it out for fun) and I was using "0" as a default value for the first variable to match against (since the second variables would never be 0) but both of these values changed in the loop I was running. I easily fixed this by setting my default value to -- instead of 0 but I tried researching and found nothing indicating there was a way to get around the falsey nature of strings when evaluating them.
Is there no Operator or trick to match on the strings themselves and ignore their truthyness or falseyness in ColdFusion?
The compare function will help you. This:
writedump(compare("0", "NO"));
returns -1.
This page will tell you what that means.
Sometimes I need to change a variable name in the code from foo to bar. I do it using query-replace-regexp. Then I would do some other stuff and I might regret my decision and want to change it back from bar to foo. If I do query-replace-regexp, it will show by default the last replacement performed (default foo -> bar). My question is, is there a quick way to tell Emacs I want the reverse order of the default? Otherwise one would need to type the whole thing again.
Edit: The default replacement is the last replacement (default foo -> bar). What I want now is the opposite: bar to foo. Basically, I want to undo the replacement. Not always can I use the undo feature since I may have a very long history after many other edits.
When you use query-replace, M-p retrieves the default, which is foo -> bar. That is, it puts foo -> bar in the minibuffer.
You can edit that text in the minibuffer. In particular, you can move backward a word (or a sexp), using M-b (or C-M-b), and then use M-t (or C-M-t) to transpose the two words (sexps) there, giving you bar -> foo. (Then hit RET.)
The point is that once you have retrieved a previously used input, or the default input, you can edit it in the minibuffer.
(Normally, in Emacs, it is M-n that retrieves the default value. In this case it is M-p (which (IMHO) is an aberration).)
Wrt accessing previously entered input: You can cycle, by repeating M-p, but you can also search directly, using M-r. If the input you want to retrieve was not very recent, then M-r can be quicker than cycling.
This is probably a horrible way of doing this, but you could create a function like the following and bind it to another key. It seems to work in this specific case but there are tons of other things that this doesn't handle as is (such as the prefix argument).
(defun so-undo-last-query-replace ()
(interactive)
(let ((query-replace-defaults (list (cons (cdar query-replace-defaults)
(caar query-replace-defaults)))))
(call-interactively 'query-replace)))
Stata does not replace a value, as I am commanding. What is happening?
I have this variable Shutouts, which is a float variable (%9.0g).
One observation has the value = 5.08; that is an error, it should be 5.
I type: replace Shutout= 5 if Shutout==5.08.
And, surprisingly to me, Stata responds:
replace Shutouts=5 if Shutouts==5.08
(0 real changes made)
I have a similar problem for a variable with the same characteristics, with the name Save_perc; one value is 9.2 but should be .92. And, also this time, I receive this response from Stata:
replace Save_perc=.92 if Save_perc==9.2
(0 real changes made)
Why "0 real changes"?
It seems like a very banal problem, but I have been working on it for like 30' and I cannot really figure it out.
it has to do with how floating numbers are stored into memory. You should not use == when comparing two different number formats because some internal storage approximation can make the comparison fail.
In your case, you should just use
Shutouts=5 if Shutouts > 5.07
or
Shutouts=5 if Shutouts == float(5.07)
I am having trouble with Erlang converting listed numbers to characters whenever none of the listed items could not also be representing a character.
I am writing a function to separate all the numbers in a positive integer and put them in a list, for example: digitize(123) should return [1,2,3] and so on.
The following code works fine, except when the list only consist of 8's and/or 9's:
digitize(_N) when _N =:= 0 -> [];
digitize(_N) when _N > 0 -> _H = [_N rem 10], _T = digitize(_N div 10), _T ++ _H.
For example: Instead of digitize(8) returning [8], it gives me the nongraphic character "\b" and digitize(89) returns "\b\t". This is only for numbers 8 and 9 and when they're put alone inside the list. digitize(891) will correctly return [8,9,1] for example.
I am aware of the reason for this but how can I solve it without altering my result? (ex: to contain empty lists inside the result like [[],[8]] for digitize(8)).
If you look at comments you will see that it is more problem of the way shell prints your data, than the data itself. You logic is wright and I would not change it. You could introduce some use of io:format/2 into you code, but I guess that it would make it harder to use this function in other parts of code.
Other way around it is changing the shell settings itself. There is shell:strings/1 functions that disables printing lists as stings, and it should do exactly what you want. Just remember to change it back when you finish with your shell stuff, since it could introduce some confusion when you will start using some "string" returning functions.
So I'm new to emacs lisp, and I've got a long file with walls of text broken up by dates. Sometimes I can't see what date I'm reading under without scrolling up and losing my position, and I decided I wanted to be able to see this at all times.
After skim-reading the manuals, borrowing code examples and making a wild stab in the dark, the following worked beautifully:
(add-hook 'text-mode-hook
(lambda ()
(setq header-line-format
'(:eval
;;(setq temp-point point)
(setq temp-string
(if (re-search-backward "../../.." nil t nil) (match-string 0) '("no date"))
)
;;(goto-char 'temp-point)
`(temp-string)
)
)
)
)
There's only one fly in the ointment: re-search-backward moves the point. I want it to stay put.
First of all, is there a function that can do a regexp search without moving the point and return the match?
Secondly, and whether or not that's true: as you can tell from the commented code I've been trying to work around it by saving the value of point and then resetting the position afterward. The order of the code is on the assumption that the last element of the list is the one that gets returned.
However that assumption doesn't seem to always hold: as soon as I uncomment the first line (which can actually be anything as long as it's valid code) the header gets set to a blank string instead.
If someone could tell me where I'm going wrong, that would be great. Also if I've got any bad habits or less-than-efficient ways of solving a problem, please point them out.
You're looking for the save-excursion macro. Wrap it around your search, and it will undo any movement. To quote the docstring:
(save-excursion &rest BODY)
Save point, mark, and current buffer; execute BODY; restore those things.
So in place of (re-search-backward "../../.." nil t nil) you'd put:
(save-excursion
(re-search-backward "../../.." nil t nil))
As to why uncommenting the first line would change the result, this has to do with the way :eval works in mode/header line format specs. The docstring for mode-line-format says that it's (:eval FORM) - with just one form - and apparently it silently ignores any forms after the first one. (Your intuition is correct: most of the time the last value inside the form is returned, and the behaviour of :eval is indeed surprising.)