At the documentation I saw we could add literal filename (no-extension) support to ctags --langmap but I failed to introduce CMakeLists.txt. How to add CMakeLists.txt as well as .cmake extension?
Please find my definition at: https://github.com/umitkablan/vims/commit/33aaac8312774913b911984158d6a000362c57bb
As I was seeking through other's ctags configurations, I came across https://gist.github.com/romainl/085b4db4a26a06ec7e16#file-ctags-L43 and the line --langmap=vim:+(vimrc) gave me an idea about how to add literal names.
So I applied similar approach:
..
--langdef=cmake
--langmap=cmake:(CMakeLists.txt)
--langmap=cmake:+.cmake
...
Universal-ctags (https://ctags.io) has built-in cmake parser.
If you use it, you don't have to define your own one.
Related
I am trying to print the dependencies associated with a code, such as definitions related to functions or variables in a statement using Emacs, however I am not finding the functions necessary to do it. I have already been able to parse the code, now I just need the printing part, for which I have been looking into the srecode package without success.
It will be a necessary step to translate Java code into C or C++
What "code"? In what programming language? There are packages for different programming languages that could help. You need to be more specific.
to use emacs at this point perharps was a bad idea. I searched for code slicing and found some tools here: slicers. For the translation part I may use code from cogre-srecode.el from the cogre package of cedet and for it the manual of srecode is better
Github highlights the second % in this line as an error:
fscanf(fp, "%d%*[^\n]\n", &ints[i]);
However, the code compiles perfectly and the removing the 'error' will cause the program to function incorrectly.
Is there any way to either disable this error highlighting or make Github recognize it as correct?
Update: pchaigno points out in the comments the section linguist#Overrides, where you can use for instance .gitattributes:
Add a .gitattributes file to your project and use standard git-style path matchers for the files you want to override to set linguist-documentation, linguist-language, linguist-vendored, and linguist-generated. .gitattributes will be used to determine language statistics and will be used to syntax highlight files. You can also manually set syntax highlighting using Vim or Emacs modelines.
$ cat .gitattributes
*.rb linguist-language=Java
Original Answer Jan. 2017
Since you cannot easily remove the GitHub highlight, you can try and use a similar workaround I suggested in "How to fix/ignore syntax error in github"
Try and add on the same line a comment with a '%' in it, in order for the lexer (used by the syntax highlighting engine Rouge and Pygment) to not propagate the "error" to all subsequent lines.
To complete VonC's answer, if you think the highlighting is incorrect, you can actually file a bug report or even fix it; All grammars github.com uses are open source!
How to find the grammar? To find the grammar used for syntax highlighting in your case, you can visit this page on the Linguist project. In front of each language (looks like C in your case), you'll find the repository where the grammar for that language lives (for C, github.com/textmate/c.tmbundle). You can open an issue there with your failing test case, or even better, try and fix it yourself.
I was looking for a method to show a list of filenames in a directory, and then select one of them.
I found this:
https://github.com/lawlist/dired-read-file-name and it seemed promising, so I copied it to my emacs direcory and tried:
(require 'dired-read-file-name)
but I get error
error: Required feature `dired-read-file-name' was not provided
require is not going to work because the source of dired-read-file-name.el does not have a provides expression. You might want to add:
(provide 'dired-read-file-name)
add the end of the file.
Alternatively, you can just load or more low-level load-file.
Also have a look at this.
I'm having trouble getting global to find class/struct definitions.
I can find them with exuberant ctags and with cscope.
All tag files are built from the same source file list.
I configured and built global, et.al., only specifying --prefix.
configure did find exhuberant and is using it.
I've been trying global periodically over the years and it's always had this problem.
Any ideas?
thanks,
davep
I've found out what I did wrong. Maybe this will help someone.
Just because configure finds exuberant ctags does not means that it makes it the default parser. My ex ctags doesn't support --gtags and maybe that's why. The default parser in my case was native/builtin.
The native parser treats .h as C only and does not look for C++ constructs. Oddly, it also does not find structs.
I found 2 fixes:
1) The best, if you have exuberant ctags, is to make it the default. The exuberant default configuration processes .h files properly. If it does not, use method 2. In .globalrc, change
default:\
:tc=native:
to
default:\
:tc=ctags:
2) If you do not have exuberant ctags, edit .globalrc and change the langmap line for the builtin-parser from
builtin-parser:\
:langmap=c\:.c.h,yacc\:.y,asm\:.s.S,java\:.java,cpp\:.c++.cc.hh.cpp.cxx.hxx.hpp.C.H,php\:.php.php3.phtml:
to
builtin-parser:\
:langmap=c\:.c,yacc\:.y,asm\:.s.S,java\:.java,cpp\:.c++.cc.hh.h.cpp.cxx.hxx.hpp.C.H,php\:.php.php3.phtml:
I.e. remove the association of .h with C and associate it with C++.
This may cause problems with C .h files. If so, you may need rename ALL C++ .h files to .hh, .hpp, .hxx, etc, as given in the langmap.
Based on my experience with C++, it looks like most people still use .h for their header files.
Just export this variable and that should pretty much do. From the man page for gtags -
GTAGSFORCECPP
If this variable is set, each file whose suffix is 'h' is treated as a C++ source file.
I am switching to Emacs from TextMate. One feature of TextMate that I would really like to have in Emacs is the "Find in Project" search box that uses fuzzy matching. Emacs sort of has this with ido, but ido does not search recursively through child directories. It searches only within one directory.
Is there a way to give ido a root directory and to search everything under it?
Update:
The questions below pertain to find-file-in-project.el from Michał Marczyk's answer.
If anything in this message sounds obvious it's because I have used Emacs for less than one week. :-)
As I understand it, project-local-variables lets me define things in a .emacs-project file that I keep in my project root.
How do I point find-file-in-project to my project root?
I am not familiar with regex syntax in Emacs Lisp. The default value for ffip-regexp is:
".*\\.\\(rb\\|js\\|css\\|yml\\|yaml\\|rhtml\\|erb\\|html\\|el\\)"
I presume that I can just switch the extensions to the ones appropriate for my project.
Could you explain the ffip-find-options? From the file:
(defvar ffip-find-options
""
"Extra options to pass to `find' when using find-file-in-project.
Use this to exclude portions of your project: \"-not -regex \\".vendor.\\"\"")
What does this mean exactly and how do I use it to exclude files/directories?
Could you share an example .emacs-project file?
I use M-x rgrep for this. It automatically skips a lot of things you don't want, like .svn directories.
(Updated primarily in order to include actual setup instructions for use with the below mentioned find-file-in-project.el from the RINARI distribution. Original answer left intact; the new bits come after the second horizontal rule.)
Have a look at the TextMate page of the EmacsWiki. The most promising thing they mention is probably this Emacs Lisp script, which provides recursive search under a "project directory" guided by some variables. That file begins with an extensive comments section describing how to use it.
What makes it particularly promising is the following bit:
;; If `ido-mode' is enabled, the menu will use `ido-completing-read'
;; instead of `completing-read'.
Note I haven't used it myself... Though I may very well give it a try now that I've found it! :-)
HTH.
(BTW, that script is part of -- to quote the description from GitHub -- "Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)". If you're doing any Rails development, you might want to check out the whole thing.)
Before proceeding any further, configure ido.el. Seriously, it's a must-have on its own and it will improve your experience with find-file-in-project. See this screencast by Stuart Halloway (which I've already mentioned in a comment on this answer) to learn why you need to use it. Also, Stu demonstrates how flexible ido is by emulating TextMate's project-scoped file-finding facility in his own way; if his function suits your needs, read no further.
Ok, so here's how to set up RINARI's find-file-in-project.el:
Obtain find-file-in-project.el and project-local-variables.el from the RINARI distribution and put someplace where Emacs can find them (which means in one of the directories in the load-path variable; you can use (add-to-list 'load-path "/path/to/some/directory") to add new directories to it).
Add (require 'find-file-in-project) to your .emacs file. Also add the following to have the C-x C-M-f sequence bring up the find-file-in-project prompt: (global-set-key (kbd "C-x C-M-f") 'find-file-in-project).
Create a file called .emacs-project in your projects root directory. At a minimum it should contain something like this: (setl ffip-regexp ".*\\.\\(clj\\|py\\)$"). This will make it so that only files whose names and in clj or py will be searched for; please adjust the regex to match your needs. (Note that this regular expression will be passed to the Unix find utility and should use find's preferred regular expression syntax. You still have to double every backslash in regexes as is usual in Emacs; whether you also have to put backslashes before parens / pipes (|) if you want to use their 'magic' regex meaning depends on your find's expectations. The example given above works for me on an Ubuntu box. Look up additional info on regexes in case of doubt.) (Note: this paragraph has been revised in the last edit to fix some confusion w.r.t. regular expression syntax.)
C-x C-M-f away.
There's a number of possible customisations; in particular, you can use (setl ffip-find-options "...") to pass additional options to the Unix find command, which is what find-file-in-project.el calls out to under the hood.
If things appear not to work, please check and double check your spelling -- I did something like (setl ffip-regex ...) once (note the lack of the final 'p' in the variable name) and were initially quite puzzled to discover that no files were being found.
Surprised nobody mentioned https://github.com/defunkt/textmate.el (now gotta make it work on Windows...)
eproject has eproject-grep, which does exactly what you want.
With the right project definition, it will only search project files; it will ignore version control, build artifacts, generated files, whatever. The only downside is that it requires a grep command on your system; this dependency will be eliminated soon.
You can get the effect you want by using GNU Global or IDUtils. They are not Emacs specific, but they has Emacs scripts that integrate that effect. (I don't know too much about them myself.)
You could also opt to use CEDET and the EDE project system. EDE is probably a bit heavy weight, but it has a way to just mark the top of a project. If you also keep GNU Global or IDUtils index files with your project, EDE can use it to find a file by name anywhere, or you can use `semantic-symref' to find references to symbols in your source files. CEDET is at http://cedet.sf.net
For pure, unadulterated speed, I highly recommend a combination of the command-line tool The Silver Searcher (a.k.a. 'ag') with ag.el. The ag-project interactive function will make an educated guess of your project root if you are using git, hg or svn and search the entire project.
FileCache may also be an option. However you would need to add your project directory manually with file-cache-add-directory-recursively.
See these links for info about how Icicles can help here:
find files anywhere, matching any parts of their name (including directory parts)
projects: create, organize, manage, search them
Icicles completion matching can be substring, regexp, fuzzy (various kinds), or combinations of these. You can also combine simple patterns, intersecting the matches or complementing (subtracting) a subset of them