I would like to tell emacs to treat some keywords (or regular expressions even better) as syntactic whitespace, or, in other words, to ignore them.
For example: emacs highlighting and cedet misinterpret the code
void function() some_compiler_specific_modifier(){
...
}
as some_compiler_specific_modifier being the function name.
I have a list of the modifiers so I would love it if emacs could just ignore them whenever it finds them.
EDIT: the most important part is to make the cedet parser ignore these keywords...
To do this, you can modify semantic-lex-c-preprocessor-symbol-map to include the symbols you want to have disappear. Since you have lots of macros, and some of those macros apparently take an argument, you are probably better off create some new header, such as:
goofy.h:
#define some_compiler_specific_modifier(A)
#define some_other_compiler_modifier(B)
// ...
and then add that to semantic-lex-c-preprocessor-symbol-file.
After modifying those variables, you may need to then call semantic-c-reset-preprocessor-symbol-map to get the changes to take effect.
Alternately, use the ede-cpp-root-project type and specify the above info via the configuration in that project style. (See the doc for more on that.)
Related
I am new to Emacs Lisp and the feeling is like it lacks strictness (and namespaces, and more...).
To be more comfortable with it I need a
way to make interpreter/byte compiler complain a lot if I use deprecated or obsolete function or variable (even better - hide them). Why this is not looks so simple and removing corresponding .el packages will not work is obvious - they may be needed by some legacy code.
Also, if it is possible, turning off all aliases would be nice. In my opinion they are there only for backwards compatibility, which I do not need. Because of setting this one globally can ruin something, I hope there is something like use strict in JavaScript, which can be applied to the inner body, so the effect is neatly localized.
Do not get me wrong, I think that global namespace of the Elisp is like a dump and if it could be any cleaner, why not?
To put in one sentence: how to make Elisp global namespace obsoleteless and deprecateless, as slim as possible?
I don't know of an Emacs Lisp linter that is built in to Emacs.
I do two things for my own code to try to ensure some level of cleanliness.
First, I make sure that byte-compiling the code doesn't give any errors or warnings. The byte compiler does a certain amount of checking.
Second, I enable lexical binding. This lets the byte compiler detect a few more possible warnings.
This is about the best you can do with the built-in tools. If you want to go further you could write your own tree walker to perform whatever other tests you like.
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
As described here, emacs-lisp-mode provides for special handling of s-expressions in docstrings that start in the first column. This requires them to be escaped with a backslash to avoid mucking up font-lock later on in the file.
This may be a feature for elisp, but is unfortunate in other lisp modes that reuse emacs-lisp-mode for convenience that don't have special handling of expressions in docstrings, as described/shown here.
My question is, is there any way for such "descendant" modes to configure emacs-lisp-mode to disregard "calling convention expressions" in docstrings?
The short answer is no.
The longer answer is that those other modes are simply broken. They should adapt to Emacs Lisp in this regard. There is no reason not to, is there? It is simply a bad idea to use workarounds (e.g. indent all doc-string lines), such are suggested in the link you provided (and its linked duplicate post).
Emacs doc string are not trivial strings. They have several special properties, including the handling of \\[...], \\{...}, and \\<...>, as well as the property you mention here.
If some mode cannot adjust to Emacs doc strings then it should use macros that define the things it needs without creating Emacs doc strings for them but by handling a different string argument in the special way desired. IOW, create pseudo doc strings that correspond to what the mode wants instead of what Emacs wants.
Of course, that means that you cannot directly take advantage of the Emacs documentation features. You would need to also define mode-specific doc commands that would, for example, wrap the existing doc functions such as describe-function with code that picks up the mode's pseudo-doc string and DTRT, following the mode's conventions instead of the Emacs doc-string conventions.
But I would think that the easiest approach would be to just adapt the mode to the existing Emacs behavior, so that it DTRT.
Many Emacs programming modes, and various Lisp modes are no exception, have been implemented based on parsers with regular expressions. This, unfortunately, gives the editor little idea of the document being edited. Eclipse, for example, has a very different idea of how to edit code, which is more structured, and JetBrain MPS editors are even more rigid and structured in this sense (almost like spreadsheets).
This makes Emacs modes faster and easier to implement, but it also means the code that supports the proper indentation, syntactic validation and highlighting has to re-parse more text every time it is being edited. CEDET, afaik, is trying to address this issue.
Thus, historically, there had been conventions designed to reduce the amount of code to parse on each edit. Parenthesis in the first column is one such convention. However, it also has been known to be an annoyance some times, that's why there's a open-paren-in-column-0-is-defun-start variable one can set to nil to inhibit this behaviour.
But It's hard to say what exactly the performance issues you may face when changing this setting. Lisp grammar is very regular, unless you are using many reader macros, so, perhaps, that won't be a problem.
If beginning-of-defun-function is set accordingly, i.e. checking if inside a comment or string, should be no need for such escaping.
I wanted to find the following function with etags:
dt()
but as I go through the tag table, I keep hitting functions with dt in their names, like
widthThing1()
widthThing2()
...
making the definition of dt() extremely difficult to find.
Is there some way to search only for the exact function that I'm searching for with etags?
Open up your TAGS file and see what it is actually indexing (which will vary by language, of course).
For instance, if the relevant entry looked like this:
function ds(^?6140,232332
Then you could use function ds( (or potentially just ds( ) as your search term, to ensure that you weren't matching other functions.
You could omit the "function" part of that, except that typing SPC at the find-tag prompt will invoke TAG completion. You could avoid that by typing C-qSPC instead, or alternatively utilise find-tag-regexp bound to C-M-. which does not have the completion binding.
So C-M-.SPC ds( RET might be convenient.
You may also want to look at the etags-select library and binding M-. to etags-select-find-tag, which I find provides a much better interface.
You can get that from the EmacsWiki, or Marmalade:
http://www.emacswiki.org/emacs/EtagsSelect
http://marmalade-repo.org/packages/etags-select
Packages like Icicles and Helm also provide alternative interfaces. You can start reading at http://emacswiki.org/emacs/EmacsTags
I am not a very good at using Emacs, but the feature I would like the most would be some integration with help/documentation for a particular language/API I use at the moment. I would imagine that there would be help displayed in another buffer depending on where I put my cursor while editing.
I wonder if there is a package that does that, even if it would be very simple, just displaying some file based on the keyword. I think there is, but I cannot find it ("help" is a too generic word).
(In particular, I would like to have this help for Common Lisp, but other languages, such as Java or C, could be useful.)
ILISP and SLIME provide several methods for looking up a function; see the Emacs wiki and the SLIME documentation. Or just built into Emacs itself, there are functions like C-h f to get function help or M-x man; both use the text at the point by default. You could pretty easily adapt them to work for another language of your choice.
Assuming you are using SLIME for common-lisp, you can take a look at slime-autodoc-mode.
Sorry, can't help with a generic solution for this.
You can set up the CLHS root for SLIME in your .emacs file:
(setq common-lisp-hyperspec-root "/usr/share/doc/hyperspec/HyperSpec/")
Adjust the path to where you put your HyperSpec.
Then, C-c C-d h with point at a symbol will look it up there in your browser.
One thing you might like to enable is eldoc-mode, by adding (turn-on-eldoc-mode) to your mode hook functions for the appropriate programming modes.
In ElDoc mode, the echo area displays information about a
function or variable in the text where point is. If point is
on a documented variable, it displays the first line of that
variable's doc string. Otherwise it displays the argument list
of the function called in the expression point is on.
This is probably less than you were after, but it still makes a good companion to a fuller-featured contextual help system, and there are a number of programming modes that support it.