Is it possible to make flymake-mode be aware of syntax (or other) errors in racket files like it done for example for erlang or python? I'm using geiser-mode for racket, if it is matters.
It's probably very easy, since Racket spits out warning messages in a standard line:column format.
You don't even need to invoke the compiler -- it's enough to just run the code via racket the-file. But as a semi-side-note, an even better command-line to use is racket -qf the-file. The thing about running the code as above is that it will actually ... run it. More specifically, it loads the module definition and then invokes it. Using -f it will just load the definition but not invoke it and therefore the runtime is not executed. Note that this assumes that the file is one that has just a module, which is what you get for all files that start with a #lang.
Update: I tried it, and indeed it was easy to set things up. I've posted this code on the mailing list:
(defun flymake-racket-init ()
(let* ((temp-file (flymake-init-create-temp-buffer-copy
'flymake-create-temp-inplace))
(local-file (file-relative-name
temp-file
(file-name-directory buffer-file-name))))
(list "racket" (list "-qf" local-file))))
(push '("\\.rkt\\'" flymake-racket-init)
flymake-allowed-file-name-masks)
Related
How can I determine where the load point is for an emacs library? For example, I'm trying to track down and remove any runtime requires of subr-x during initialization, so I'd like to know which library loaded it.
The load-history lists loaded files along with the requires they made when they were loaded, but doesn't seem to provide information about any requires that weren't evaluated initially, but may have been later.
As a simple example, if I M-xload-file "/path/to/the/following/test.el"
(defun my-f ()
(require 'misc))
(provide 'my-test)
I see the first entry in load-history is
("/path/to/test.el"
(defun . my-f)
(provide . my-test))
Then, evaluating (my-f), adds an entry for "misc.el", but there is no indication where it was loaded from (neither is the above entry updated).
How can I find that out?
How can I determine where the load point is for an emacs library?
You can't. There are many reasons an Emacs library will be loaded, for example,
autoload
C-x C-e some lisp code
M-: some lisp code
M-x load-library
For example, I'm trying to track down and remove any runtime requires of subr-x during initialization, so I'd like to know which library loaded it.
Use C-h v load-history, the order is meaningful, for example, your init file loads foo.el, and foo.el requires bar.el, then bar.el requires subr-x.el, load-history should looks like
(foo.el bar.el subr-x.el)
It's not an elegant solution, but worked for me.
As a starting point, that seems works fine for my purposes, I ended up "watching" for an initial call by load or require to a specific library. It's easy to get the name of the file where the require/load took place when an actual load is in progress and load-file-name is defined.
I was less interested in other cases, eg. interactive evaluation, but the following still works -- at least after very minimal testing, it just dumps a backtrace instead of the filename. From the backtrace, it's not hard to find the calling function, and if desired, the calling function's file could presumably be found with symbol-file.
Running the following locates loads/requires of subr-x, reporting in the message buffer the filenames of packages where it was loaded and dumping backtraces around deferred loading locations.
emacs -q -l /path/to/this.el -f find-initial-load
(require 'cl-lib)
(defvar path-to-init-file "~/.emacs.d/init.elc")
(defun find-load-point (lib &optional continue)
"During the first `require' or `load', print `load-file-name' when defined.
Otherwise, dump a backtrace around the loading call.
If CONTINUE is non-nil, don't stop after first load."
(let* ((lib-sym (intern lib))
(lib-path (or (locate-library lib) lib))
(load-syms (mapcar
(lambda (s)
(cons s (intern (format "%s#watch-%s" s lib-sym))))
'(require load)))
(cleanup (unless continue
(cl-loop for (ls . n) in load-syms
collect `(advice-remove ',ls ',n)))))
(pcase-dolist (`(,load-sym . ,name) load-syms)
(advice-add
load-sym :around
(defalias `,name
`(lambda (f sym &rest args)
(when (or (equal sym ',lib-sym)
(and (stringp sym)
(or (string= sym ,lib)
(file-equal-p sym ',lib-path))))
,#cleanup
(prin1 (or (and load-in-progress
(format "%s => %s" ',lib-sym load-file-name))
(backtrace))))
(apply f sym args)))))))
(defun find-initial-load ()
"Call with 'emacs -q -l /this/file.el -f find-initial-load'."
(find-load-point "subr-x" 'continue)
(load path-to-init-file))
;; test that deferred requires still get reported
(defun my-f () (require 'subr-x))
(add-hook 'emacs-startup-hook #'my-f)
A large project may have directory with several level depth. Emacs's default compile command is "make -k", if I modified a certain source code, then typed "M-x compile RET RET", it will execute "make -k" under the directory which the source code lies.
I think I can write a function to determine if the Makefile exist under current directory, if yes, keep searching under the parent directory until find the top level directory, then execute the building command, it would be right like my expectation.
However, I'm not very clearly how to start, could anyone give me some hints to start? Like the function or variable I may encounter. Thanks.
You can try to use something like:
(setq compile-command
'(let ((mf (locate-dominating-file default-directory "Makefile")))
(if mf (setq mf (file-name-directory mf)))
(concat (if (and mf (not (equal mf default-directory)))
(format "cd %s; "
(shell-quote-argument
(file-relative-name
(directory-file-name mf)))))
"make -k ")))
There is a smarter-compile in marmalade.
From the documentation....When you require it, you can specify a list of cons cells, each one like (TEST . COMMAND).
COMMAND is used for the compile-command when
the TEST succeeds.
TEST can be:
a string. In this case it is used as a regex,
and matched against the filename associated to the
buffer. The TEST succeeds when the regex matches.
a symbol, representing the major-mode. In this case
if the buffer uses that major mode, the TEST
succeeds.
a symbol, representing any function with a name not
ending in \"-mode\". In this case, the function is
called and if it returns non-nil, the TEST
succeeds.
a list of forms. In this case the forms are eval'd,
and if the return value is non-nil, the TEST
succeeds.
So you could produce a function that does the scan for makefile in parent directories,
and use that as your TEST.
According to the documentation, if the COMMAND is nil, then the package uses the result of the TEST as the compile command. Which means you would need only one function, returning a make command referencing the makefile in the appropriate directory.
Take a look at: http://emacswiki.org/emacs/CompileCommand
"C-h v compile-command" directly from emacs.
Here's a solution for people who prefer bash scripting over Emacs Lisp. In my .emacs I define a command which saves all buffers and runs a bash script which compiles the project.
(defun save-all-and-compile () (interactive)
(save-some-buffers 1)
(shell-command "make-and-run.sh &"))
(add-hook 'c-mode-common-hook (lambda ()
(local-set-key (kbd "<f5>") 'save-all-and-compile)))
For small projects the script could be as simple as
#!/bin/bash
make -j && ./<main>
where 'main' is the name of your executable. For larger projects one would first need to locate the root directory. Similarly, you could have different scripts (bound for different keys) for building and running the program. And then some more scripts for testing different parts of the project. But these are just details one can figure out for themselves.
Make sure the script is run asynchronously using '&'. This way the Async Shell Command buffer will open with the output from make and your project and will stay open.
EDIT
Based on the discussion below it appears I have initially overthought it and the solution is quite simple. Instead of passing the usual 'make' or 'make -k' to compile-command one could use a shell script which first navigates to the project's root directory and the builds.
(setq compile-command "script.sh")
I want to customize environment while the specific package is installed properly. How to check whether some package is installed in elisp?
Something like this?:
(if (require 'ecb)
(progn (setq ....))
(message "ECB not installed!"))
tripleee's answer is a handy example of error handling, but unnecessary in this instance.
(when (require 'some-library nil 'noerror)
do-things)
That 'noerror can be any non-nil value, but of course it's more descriptive this way. I often see :noerror used as well, but I've no idea if there's any particular advantage to using a keyword argument over a symbol (comments, anyone? I'm quite interested to know).
require is a built-in function in C source code.
(require FEATURE &optional FILENAME NOERROR)
If feature FEATURE is not loaded, load it from FILENAME.
If FEATURE is not a member of the list features, then the feature
is not loaded; so load the file FILENAME.
If FILENAME is omitted, the printname of FEATURE is used as the file name,
and load will try to load this name appended with the suffix .elc or
.el, in that order. The name without appended suffix will not be used.
See get-load-suffixes for the complete list of suffixes.
If the optional third argument NOERROR is non-nil,
then return nil if the file is not found instead of signaling an error.
Normally the return value is FEATURE.
The normal messages at start and end of loading FILENAME are suppressed.
The (require) will throw an error if it fails. That should really be all you need.
If you want to configure ECB's behavior only when it is available, look primarily into adding stuff to ecb-hook -- this is the normal way to configure an Emacs package conditionally.
If no hook is available, or you want to roll it by hand for some reason, try something like
(eval-after-load 'ecb '(setq ecb-be-more-like-better-yes-p t))
If you really really want to roll this by hand, you can trap the error from a failed require like this:
(condition-case nil
(progn
(require 'ecb)
(setq ecb-be-more-like-better-yes-p t) )
(file-error (message "ECB not available; not configuring") ))
Note that the condition-case will catch any file-error from inside the progn so you want to make sure you don't do any other file operations inside. Ultimately you may want to put just the require inside a condition-case and use that as the condition for your original if form, but this is already getting out of hand ...
(if (condition-case nil (require 'ecb) (error nil))
(setq ecb-be-more-like-better-yes-p t)
(message "ECB not available; not configuring") )
Why not using "featurep"?
(featurep FEATURE &optional SUBFEATURE)
Return t if FEATURE is present in this Emacs.
(if (featurep 'ecb)
(message "ECB is there!"))
For people wondering how to check if a package.el package is installed, use package-installed-p.
Four years late on this question, but... here's a simple macro that will do this for you.
(defmacro when-feature-loaded (feature &rest body)
"Executes BODY if and only if FEATURE is loaded."
(declare (indent defun))
`(when (featurep ,module)
#,body))
For example:
(when-feature-loaded 'foo
(message "foo is loaded!"))
Here's another version with an "else" case, in case you need to handle that as well.
(defmacro if-feature-loaded (module then-form else-form)
"Executes THEN-FORM if and only if MODULE is already loaded, otherwise executes ELSE-FORM."
(declare (indent 2))
`(if (featurep ,module)
,then-form
,else-form))
The simplest answer is to use require and eval-after-load as stated in other answers.
However that is not always convenient, such as in a function called by a mode hook that wants to activate another minor mode but only if the package for it is installed. In this case featurep is relevant.
Emacs packages increasingly use autoload to improve startup time. If you test for the presence of a package by using require then you are wearing the cost of loading the file(s). If using ELPA/MELPA/Marmalade packages (available by default since version 24) then many packages may be available in an as-yet unloaded state, but a package foo with autoloads will provide a feature foo-autoloads. I wrote a function that is useful for testing whether a package is available in terms of already being loaded or set to autoload.
(defun autofeaturep (feature)
"For a feature symbol 'foo, return a result equivalent to:
(or (featurep 'foo-autoloads) (featurep 'foo))
Does not support subfeatures."
(catch 'result
(let ((feature-name (symbol-name feature)))
(unless (string-match "-autoloads$" feature-name)
(let ((feature-autoloads (intern-soft (concat feature-name "-autoloads"))))
(when (and feature-autoloads (featurep feature-autoloads))
(throw 'result t))))
(featurep feature))))
N.B.: Using (require ..) will load the package, which defeats the benefit of autoloads (deferred loading).
I use this in my code to configure functions which are autoloaded:
(when (fboundp 'some-function)
...)
Example
I have this in my init.el:
(when (fboundp 'ace-select-window)
(keymap-global-set "M-s-u" 'ace-select-window))
If you have ace-window installed, you can test this yourself by copying it into your own init file, restarting Emacs, and running:
(autoloadp (symbol-function 'ace-select-window))
It should return T. Then run the command, and execute that snippet again; it should return nil.
(newbie tip: Hit altshift:, then enter that, and press enter)
This avoids loading your package just to configure it (which is the point of autoloading).
(newbie tip nr 2: using fbound is for functions; use boundp for values)
I'm learning LISP for a class. I have a basic workflow setup in Ubuntu with my LISP file in VIM and an interactive LISP prompt in a terminal that I'm using to test code as I write it. Is there a way to get LISP to load a specific file every time I type a command? It's getting a bit tiring having to constantly input (load 'initial-code.cl) (yes, even when I am using the terminal's history).
Can always try:
(let (fn)
(defun l (&optional filename)
(if filename
(setf fn filename))
(load fn)))
Works like this:
[2]> (l "x.lisp")
;; Loading file x.lisp ...
;; Loaded file x.lisp
T
[3]> (l)
;; Loading file x.lisp ...
;; Loaded file x.lisp
T
[4]>
Pretty simple.
You can also do something like:
(defun go ()
(load "project.lisp")
(yourfunc 'your 'parameters))
Then you just type (go) and it reloads your file and calls your main entry point.
Or even combine them:
(defun gogo (&rest args)
(l) ;; call (l "file.lisp") first to initialize it
(apply #'yourfunc args))
then you can change your parameters easily
(gogo 1 2)
(gogo 2 4)
Ya know, it's lisp. Don't like something, change it.
With more time, you can write a simple wrapper that can build these on the fly. But you get the idea.
Most Lisp programmers would encourage you to use SLIME.
If you like Eclipse, there is also a Lisp plugin.
I know this doesn't really answer your question, but at least you can be aware of some alternatives.
You can try slimv, it is like slime for vim.
I am upgrading to emacs23. I find that my emacs.el loads much more slowly.
It's my own fault really... I have a lot of stuff in there.
So I am also trying to autoload everything possible that is currently "required" by my emacs.el.
I have a module that exposes 12 entry points - interactive functions I can call.
Is the correct approach to have 12 calls to autoload in order to insure that the module is loaded regardless of which function I call? Are there any problems with this approach? Will it present performance issues?
If not that approach, then what?
What you really want is to get the autoloads generated for you automatically, so that your .emacs file remains pristine. Most packages have the ;;;###autoload lines in them already, and if not, you can easily add them.
To manage this, you can put all the packages in a directory, say ~/emacs/lisp, and in there have a file named update-auto-loads.el which contains:
;; put this path into the load-path automatically
;;;###autoload
(progn
(setq load-path (cons (file-name-directory load-file-name) load-path)))
;;;###autoload
(defun update-autoloads-in-package-area (&optional file)
"Update autoloads for files in the diretory containing this file."
(interactive)
(let ((base (file-truename
(file-name-directory
(symbol-file 'update-autoloads-in-package-area 'defun)))))
(require 'autoload) ;ironic, i know
(let ((generated-autoload-file (concat base "loaddefs.el")))
(when (not (file-exists-p generated-autoload-file))
(with-current-buffer (find-file-noselect generated-autoload-file)
(insert ";;") ;; create the file with non-zero size to appease autoload
(save-buffer)))
(cd base)
(if file
(update-file-autoloads file)
(update-autoloads-from-directories base)))))
;;;###autoload
(defun update-autoloads-for-file-in-package-area (file)
(interactive "f")
(update-autoloads-in-package-area file))
If you add 'update-autoloads-in-package-area to your kill-emacs-hook, then the loaddefs.el will automatically be updated every time you exit Emacs.
And, to tie it all together, add this to your .emacs:
(load-file "~/emacs/lisp/loaddefs.el")
Now, when you download a new package, just save it in the ~/emacs/lisp directory, update the loaddefs via M-x update-autoloads-in-package-area (or exit emacs), and it'll be available the next time you run Emacs. No more changes to your .emacs to load things.
See this question for other alternatives to speeding up Emacs startup: How can I make Emacs start-up faster?
Well, who cares how slowly it starts?
Fire it up via emacs --daemon & and then connect using either one of
emacsclient -c /some/file.ext, or
emacsclient -nw
I created aliases for both these as emx and emt, respectively. Continuing once editing session is so much saner...
Ideally you shouldn't have any load or require in your .emacs file.
You should be using autoload instead...
e.g.
(autoload 'slime-selector "slime" t)
You will need to use eval-after-load to do any library specific config, but the upshot is that you won't need to wait for all this to load up front, or cause errors on versions of Emacs that don't have the same functionality. (e.g. Terminal based, or a different platform etc.)
While this may not affect you right now, chances are, in future you will want to use the same config on all machines / environments where you use Emacs, so it's a very good thing to have your config ready to fly.
Also use (start-server) and open external files into Emacs using emacsclient - So you avoid restarting Emacs.