I am trying to use Racket to "require" a file whose name is in Chinese. The compiler gives an error that test.rkt:2:3: require: bad module-path string at: "./lib/算数.rkt" in: (require "./lib/算数.rkt") #(13 14), but it does work when I rename 算数.rkt into math.rkt. So I am sure that the error occurs because the filename is not in English. Any method I can use to solve the problem?
I was able to replicate this, and while I didn't dig deep into the documentation to see if there's some listed restriction about what codepoints can be in a module path, I did find a workaround:
(require (file "./lib/算数.rkt"))
From the documentation for (file ...):
Similar to the plain rel-string case, but string is a path—possibly absolute—using the current platform’s path conventions and expand-user-path.
Other documentation says
This form is not portable, and it should not be used when a plain, portable rel-string suffices.
Since the normal way doesn't suffice, I guess this is one of the situations where it's okay to use.
Related
I'm sorta lost because I'm not sure where to place, or exactly how to create the flymake makefile. I saw the emacswiki article on it, but (and maybe I just overlooked it) I didn't find where to place the file, or how to specify where it is.
The exact place of the Makefile does not matter.
Flymake searches for a Makefile in the directory containing the file being checked, and any ancestor directory thereof. Suppose, you edit foo/bar/test.c, then Flymake would first try foo/bar/Makefile, then foo/Makefile, and so on, until the root directory is reached.
The Makefile must provide special support for Flymake, however: It must provide a check-syntax target, and should look at CHK_SOURCES for the file being checked. How to write such a target depends on the language and compiler you are using. If your Makefile does not provide this target, syntax checking will fail!
Flymake uses Makefiles for C and C++ files with common extensions (e.g. .c, .cpp, etc.). Note that Flymake looks at the file name of the buffer, not at its mode. As such, the buffer must have a backing file, and it must have an extension known to Flymake. If your files have unusual extensions, customize flymake-allowed-file-name-masks accordingly, to add regular expressions matching your file names, e.g.:
(require 'flymake)
(add-to-list 'flymake-allowed-file-name-masks
'("\\.an-exotic-c-extension\\'" flymake-simple-make-init))
If you set up the Makefile and customized Flymake accordingly, M-x flymake-mode should then be sufficient to enable syntax checking.
You may also want to look at Flycheck as recommended in the comments. Flycheck is an alternative implementation for syntax checking, that works out of the box for many languages. It does not support Makefiles, but provides support for many languages. If the language you are using is supported, changes are good that you don't even need a Makefile.
Disclaimer: I'm the author and maintainer of Flycheck.
When I type 'f' in a C source file, my emacs with semantic installed and working
will show 25 completion matches, for functions like fclose, fread, and so on (only stdio.h
included)... but not fopen! Why?
Plus, same problem with opendir and readdir, with sys/types.h and dirent.h included.
P.S. semantic has all my sympathy, as upon my personal reading glibc header files showed
as a horrible mess of #ifnded and alikes.
'fopen' is turning up fine for me. Are you by any chance working on OS X? I remember that there were some preprocessor macros there which confused Semantic. Otherwise, your best chance for help is posting to the CEDET-devel mailing list, stating the CEDET version you're using and posting the exact definition of the 'fopen' function which apparently cannot be parsed.
I would like to know the best way to customize auto-formatting/auto-indenting in vim for Common Lisp.
Auto-formatting (I usually do this by typing '==' in command mode per line) works very well for the base lisp language in vim (e.g., defmacro, defun, lambda, if, with-output-to-string), but any time that new language constructs are defined (e.g., using macros), I find that the formatting for the new construct is often not what I'd like it to be.
For example, here's how vim formats 'when (standard lisp construct) and 'awhen (commonly-used anaphoric version of 'when; not part of lisp standard)
(when 'this
(process 'this))
(awhen 'this
(process it))
I would like 'awhen to auto-format like 'when. Any ideas how I can do this?
Edit: Thanks Gilligan and Tamas for the Slimv recommendation. As a test, I downloaded MacVim (will need this working with terminal vim, but that's a different problem) and slimv, rsynched the slimv download into ~/.vim, launched MacVim, and loaded a .lisp file.
I then started up the lisp server (done through a GUI with MacVim), which loaded up my default lisp executable and core file.
And* since my core file is already loaded with the language extensions that I commonly use (awhen being one of them), awhen formatted correctly right out of the box.
I really like this solution. Instead of [1] having to learn how to tell vim to indent particular functions properly, and [2] writing the code that does this explicitly for each language extension that I define, and [3] updating that code every time I add a new language construct. Instead I leverage slimv to do the formatting for me. And slimv can 'learn' new language extensions, as long as those macros are already loaded into the lisp core that the server session is using. Pretty slick!
I have found that this works well for a particular class of language extensions. Usually ones defined as a macro, using the &body keyword. This seems to 'do the right thing' most of the time, but there are macros I use that still don't properly auto-format. Although I'd say that this is more likely to be an issue with how the macro is written (non-standard language extension) than anything else.
So, this solution works well for me for most cases, and I didn't have to code (and maintain) anything. Great stuff!
This might not be a direct answer to your question but I strongly suggest that you install
the slimv plugin: http://www.vim.org/scripts/script.php?script_id=2531
Its a great plugin which integrates SLIME functionality into vim and besides many other things it also comes with an improved indentation for clisp&clojure. It won't indent awhen the way you want though.
For those who are looking for this topic and don't want to run Slimv, because they aren't working with Common Lisp or other reasons, here is the scoop.
Vim's Lisp indentation is not like that for other languages; it has a special "Lisp mode". This mode is turned on by
:set lisp
which is done automatically for .lisp files. Lisp mode isn't a Vim invention; classic Vi implementations have a Lisp mode turned on with :set lisp. (It's not described by POSIX, unfortunately).
Vim's Lisp mode has a simple mechanism for recognizing forms that require operator-style indentation: namely, there is a parameter called lispwords which holds a comma-separated list of identifiers.
You can prove to yourself that this is the identifier list which is used, even when you're editing a Common Lisp .lisp file with syntax highlighting and all. Simply do :set listwords[TAB] and edit the list to remove something from it, such as defun. Then try to reindent a defun: you will see the function-style indentation now instead of the operator-style.
The syntax highlighting support for Common Lisp is separate from Lisp mode's lispwords parameter; it has its own list of identifiers. For example, in Vim 7.3 if you enter this:
(symbol-macrolet ((foo bar))
you get indented out to here!)
This is in spite of the fact that symbol-macrolet is recognized and colored. Why? It's because symbol-macrolet does not appear in the rather scanty lispwords list, whereas it does appear in the lisp.vim syntax highlighting definition file.
The upshot is that you can cob together some script which scans your directory of .lisp files for macros and generates a set lispwords=... command that is placed into a directory .vimrc.
Or if you are working on a custom Lisp dialect, you can just make its Vim syntax highlighting file customize lispwords when it loads.
Here is an implementation oversight: the lispwords option has no local value; you cannot use setlocal lispwords ... to give it a buffer-specific value. In other words, it appears that (at least in the Vim 7.3 I'm using under Ubuntu) you can't have two or more buffers open holding different dialects of Lisp with different identifiers for indentation. The default contents of lispwords contains a smattering of Lisp and Scheme symbols to try to be a kind of "one size almost fits all" solution.
If you filetype is 'lisp' then I think you need to add indenting rules for your special case in the 'lisp.vim' file in the '/vim7x/indent' directory. You can find a bit more info in help at :h indent-expr and :h indentexpr.
Someone may be able to tell you better, but I believe the default lisp.vim indent file basically does nothing because the built-in function lispindent() is used to get indent values. You will want to:
(1) set function used to get indent values (i.e., indentexpr) to a function in your own indent/lisp.vim file, e.g., GetLispIndent().
(2) in your your GetLispIndent() function you will use lispindent() to get indent values to return for all lines except your special case. See other languages' indent files and read the docs to get an idea for how indentexpr works, e.g, java.vim.
#Kaz's answer is completely correct, but they don't go all the way to answering the original question. Vim's lispwords config string is a comma-delimited list of words; when any of the words in lispwords is found at the beginning of an S-expression, Vim will change the way that S-expression is indented. In other words, it defines the "standard lisp constructs" to which the OP refers. If you view your current lispwords config with :set lispwords, you'll see "when" is included, but "awhen" is not, resulting in the following indentation:
(when 'this
(process 'this))
(awhen 'this
(process it))
To fix this, simply add "awhen" to the config string somewhere in your config, like so:
set lispwords+=awhen,
The trailing comma isn't strictly necessary, but the default value includes it, and is probably wise in case you or a plugin modifier elsewhere. That would turn the original formatting into this:
(when 'this
(process 'this))
(awhen 'this
(process it))
(Tested on my current installation of Vim 9.0)
Note that, as #Kaz points out, this config string is universal, so if you have different dialects of lisp their indentation will all be controlled by this setting. Vim is pretty good about auto-detecting lisps, but you may need so :set lisp if it doesn't recognize your filetype or dialect.
My emacs version is 23.2.1
Although I used the following to change the backend to use GTAGS.
(require 'semantic/db-global)
(semanticdb-enable-gnu-global-databases 'c-mode)
(semanticdb-enable-gnu-global-databases 'c++-mode)
I tried to generate a GTAGS file to be used as a backend of semantic.
However, everytime when I open a C file, Semantic is still parsing files without using the GTAGS file.
Is it possible to use the GTAGS file instead of the built-in parser of semantic? I found that the built-in parser is not very accurate.
Is it possible to use the GTAGS file without specifying the project scope? In my case, I tried to put GTAGS file in /usr/include which should be the standard include path of emacs. But Semantics is not using it.
Semantic doesn't use the GTAGS file for generating tags that it will use directly for features such as jumping or smart completion. The GNU Global backend to semantic db will use GTAGS instead as a giant name table. Thus if you need to find a symbol by name, GTAGS will tell semantic where it is, and Semantic will then parse those files itself more directly to get the details.
The reason GTAGS is not used directly as a replacement parser is because the information in GTAGS is insufficient for the kinds of operations Semantic needs, as it excludes datatype info, argument parsing, and local context parsing.
Using gtags in /usr/include is an interesting idea, but would probably not get used much. Semantic will only search header files actually used in your code instead of searching all include files. The GNU Global backend is specifically for scanning an entire project for a symbol, or symbol references. If you wanted to search all your includes for a symbol, then it would be useful, but there is no such feature in Semantic at this time.
It is possible to use ebrowse to do what you want, but I found that for C++, the parser was insufficient in subtle ways, and caused some problems.
If you think the Semantic parser is inaccurate, then you should post that as a bug on the cedet-devel mailing list.
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