Is there a way to display what the docs call level 2 hidden files in the speedbar? E.g. .emacs
Long Answer
It turns out that the unshown files are controlled by a regular expression
Which is usually "^\\(\\..*\\)\\'", which I think means everything that starts with a dot
Setting that regexp with:
(setq speedbar-directory-unshown-regexp "^$")
does the trick of showing everything.
While looking at this, I discovered that there is a bug in the default value of
speedbar-directory-unshown-regexp causing the problem. It should be redefined like this:
(setq speedbar-directory-unshown-regexp "^\\(CVS\\|RCS\\|SCCS\\|\\.\\.*$\\)\\'")
or to whatever you think makes the most sense.
Related
I am trying to set the comment-column local variable to 70 by default for every buffer I am opening.
I thought that the only thing I had to do is to put the following line in my .emacs file, and to reload Emacs:
(setq-default comment-column 70)
However, when I restart Emacs, it is still to set to 40.
I also tried equivalent like:
(set-default 'comment-column 70)
I am obviously missing something obvious, but I can't find what. I think there is something I don't know about the local variables such as comment-column.
I cite the help on comment-column:
Documentation: Column to indent right-margin comments to. Each mode
may establish a different default value for this variable; you can set
the value for a particular mode using that mode's hook. Comments might
be indented to a different value in order not to go beyond
`comment-fill-column' or in order to align them with surrounding
comments.
Could the bold-faced part be the problem?
I have tried it at my place. There, most programming modes use the global default value whereas modelica-mode uses its own default value.
As the title states, I'm relatively new to Emacs. I tried out several starter kits but went with Prelude and changed a lot of things around.
Anyway, I've been getting a good handle on everything...until this morning I was working and I typed double-quotes. Normally Emacs would insert a second double quotes right after ("") due to the auto-completion, but I must have accidentally changed something with a keystroke and now when I type ", I get \"\".
Thoughts?
Thank you.
This seems to be an issue with smartparens which prelude installs by default (see the file prelude-programming.el. This behavior is described in detail on smartparens wiki. To ensure that smartparens is causing problems you can can do C-h k" this would print about the command acutally run when " is pressed, if the command is sp--self-insert-command then the following should work
Paste this (setq sp-autoescape-string-quote nil) to your *scratch* buffer, go to the closing parenthesis and do C-xC-e, this will disable the behavior for current emacs session.
To disable the behavior for all future emacs session, assuming that you are using prelude, you will need to add the following to your personal config (basically some file inside /path/to/prelude/personal/).
(setq sp-autoescape-string-quote nil)
This will disable the auto-escaping of the string quotes, completely. If you like this behavior and do not want to disable it completely you can do what #steckerhalter suggests C-q" will insert just one parenthesis.
If the above does not solve the issue then try providing following info in your question which may help us debug the issue,
1) The list minor modes active (this can be obtained by doing C-hm).
2) Output of C-hk"
Hope that helps
this sounds a lot like smartparens (https://github.com/Fuco1/smartparens) which is included in Prelude. usually when you are inside "" then it will escape the quotes:
"hahah \"\" bah"
if you want to get a normal " inside quotes you have to use C-q " or disable smartparens with M-x smartparens-mode
If, as you say in a comment, " is bound to self-insert-command, then when you type " what happens is that a (single, unescaped) " character is inserted.
However, I suspect you have some mode turned on that does something additional whenever a " char is inserted. You mention automatic insertion of a second ", for example. That kind of behavior comes from a mode such as is provided by library smart-parens or electric-pair.
And you mention Prelude.
To find out what part of your init file (~/.emacs) is causing the behavior you see, bisect your init file recursively (first comment-out half, to see which half is responsible, then 3/4, to see which quarter is responsible,...). Then, if you still have a question about the responsible code, ask here, providing that info.
When you describe your problem here, it is important to be specific: what Emacs version, what mode(s), what libraries have you loaded,... Whatever might be pertinent. But first narrow down the problem by bisecting your init file to find the culprit.
I'm probably going down the wrong path here, so let me know if I am. I'm trying to build a similar user interface to that which Vim's ctrlp and other plugins use, whereby the user is given a prompt, and as they type, results are shown above the minibuffer prompt line.
I've gotten the minibuffer command handling part working fine with minibuffer-with-setup-hook and a local post-command-hook (easy) and can get the results I want to display (verified by just (message)ing them for now).
If I want to show, say, 10 lines of results above that minibuffer prompt line, should I be somehow prepending text to the minibuffer, or using a separate buffer that I'll close once the command finishes? Any pointers to parts of the manual I should be reading to be on the right track with this?
The "minibuffer" is a normal buffer, so you can modify it by inserting/deleting text into it in the normal way. This said, adding text "before" means basically modifying the prompt which might lead to problems down the line. You'll probably be much better off doing something like
(let ((ol (make-overlay (point-min) (point-min))))
(overlay-put ol 'before-string (format "%s\n" myresults)))
I started to write this as a comment, but it got a bit too long ...
TBH, I feel there is room for a lighter weight version of helm. But the reality is helm is good enough, and someone else has already written it.
Neither I nor anyone else (so far) is motivated enough to rewrite it. What you describe as "God" aspect of it is indeed unappealing. But it is possible to load it (huge as it is, with modern computers, it really isn't an issue), and change settings so it is minimalistic.
ido is a simpler alternative, but the style of UI is not exactly how you described.
I have wrote simple macro to define interactive function and bind it to key at same time
(That what my previous question related)
The only thing, that annoy me, that it looks ugly without highlighting.
It called such way:
(define-and-bind-command foo "C-x £" (message "Hello world"))
I want define-and-bind-command and foo be highlighted.
Well, to get define-and-bind-command highlighted, I can use wrapper around defmacro,
altho is not so pretty, and I have no idea about foo.
I know it is possible, because argument of require is highlighted with const face.
Or, probably, I am inventing wheel, and there is an another lisp mode with more
advanced highlighting?
highlighting the 'define-and-bind-command' can be achieved very easily using 'font-lock-add-keywords', usage would be
(defun my-elisp-mode-keywords()
(font-lock-add-keywords nil
'(
("\\<\\(define-and-bind-command\\)" . 'font-lock-keyword-face)
)
)
)
Of course you could change the 'font-lock-keyword-face' to any face of your liking or create and use your own face. You can find the name for a face already used very easy by moving the point (cursor) over the font-locked part of text and entering 'describe-face' followed by a return.
Edit2: Oh and of course you need to hook that defun to some hook, for elisp mode that would be:
(add-hook 'emacs-lisp-mode-hook 'my-elisp-mode-keywords)
Highlighting the foo part can be done using a regexp.
Unfortunately I can not yet help you with that part because I'm not sure how to match a regexp containing the 'define-and-bind-command' but highlighting only the word after.
Edit: unless you want to highlight both the 'define-and-bind-command' and the foo part in the same face, then it should be very easy. But I guess you want them to have different faces?
Edit3: Corrected my code, stackoverflow ate some braces before...
Edit4: Okay, I have a solution for matching the second part only, I have not tested it extensively but it seems to work. I have allowed for foo to contains any character but a space (and newline I think), I guess one could restrict that event futher to a-zA-z0-9 and "-", so feel free to change that to your liking. The Code responsible for matching only the foo part is
("\\bdefine-and-bind-command\s\\([^\s]*\\)" 1 'font-lock-function-name-face t)
Insert that in the line after the other font-lock keyword in the above function and you're good to go. The regexp matches 'define-and-bind-command' which must begin a word (that's the \b for) followed by a space and then it returns (font-locks) everything followed until a space exists.
Hope this helps!
font-lock-add-keywords can take a symbol, the mode to which to apply the new keywords. So you could do
(font-lock-add-keywords
'emacs-lisp-mode
'(("\\<\\(define-and-bind-command\\)" . 'font-lock-keyword-face)))
The disadvantage compared to using a function and a hook is that this doesn't work for derived modes; that is, if you have a mode which is derived from emacs-lisp-mode, it will not inherit these keywords.
I am trying to diagnose this problem. TAB creates 4 spaces instead of a 4 col TAB like I want. But I don't think it should because C-h v indent-tabs-mode on the buffer in question says it is set to t. When I check my keybindings, TAB is set to c-indent-line-or-region. Does this function ignore my tabs-mode?
Tabs and indentation in Emacs is a considerably more complex subject than most people anticipate. I highly recommend spending some time reading about it -- it will almost certainly save you some confusion in the long run.
The following page at the Emacs Wiki groups together most of the relevant discussion:
http://www.emacswiki.org/emacs/CategoryIndentation
There's quite a lot there, but it's worth looking through.
One or other of the TabsAreEvil and SmartTabs configurations is quite likely to be appealing to you, btw, depending on your personal opinions on the subject!
Make sure you read the page on the tab-stop-list variable. It's tucked away near the bottom of that list of links, but it's critical to understanding the behaviour of tabs in the absence of automated-indentation rules, along with things like 'tabify'.
ruler-mode is useful here as well. I enable it automatically with text-mode:
;; Use ruler in text-mode
(add-hook 'text-mode-hook
(function (lambda ()
(setq ruler-mode-show-tab-stops t)
(ruler-mode 1))))
I figured out the problem. It was inserting a tab character after all. It turns out I thought it wasn't because when I hit backspace that key is bound to c-electric-backspace, which looks at the variable c-backspace-function which was set to backward-delete-char-untabify, which IMO defeats the purpose of having tabs.
Check tab-width variable. If it is 8 (the default), then Emacs of course has to insert four spaces since a tab would be "too much".
Check of the file for Emacs "File Local Variables". These specially formatted lines can override your settings when that file is loaded.
Here is an example from the bottom of a bit of Ruby code, forcing indent to 2 spaces, and tabs converted to spaces:
# Local Variables:
# tab-width: 2
# ruby-indent-level: 2
# indent-tabs-mode: nil
# End:
Be sure to take a look at the first line of the file as well. If you see something like
// -- tab-width: 4; Mode: C++; c-basic-offset: 4; indent-tabs-mode: nil --
This line will override any global or mode settings.