I'm trying to write a new emacs mode for a new template c-like language, which I have to use for some academic research.
I want the code to be colored and indented like in c-mode, with the following exceptions:
The '%' is not used as an operator, but as the first character in some specific keywords (like: "%p", "%action", etc.)
The code lines do not end with a semicolon.
Is it possible to create a derived-mode (from c-mode) and set it to ignore the original purposes of '%' and ';'? Is it possible to make the feature of "automatic-indentation after pressing RET" work without ';'?
Are there similar modes for similar languages (with '{}' brackets, but without semicolons) that I could try to patch?
Should I try to write a major mode from scratch?
I thought about patching the R-mode from http://ess.r-project.org/, but this mode does not support comments of the form "/* comment */".
The most important feature that I'm looking for is the brackets-indentation, i.e. indenting code inside a '{}' block after pressing RET (and without the extra-indentation after lines that do not end with ';'). Partial solutions will help too.
More generally, CC-mode has been extended and generalized over time to accomodate ever more languages, and the latest CC-mode is supposed to be reasonably good at isolating the generic code from the language-specific code. So take a look at some of the major modes that use CC-mode (e.g. awk-mode), and get in touch with CC-mode's maintainer who will be able to help you figure out hwo to do what you want.
If you don't mind something really simple, you can look at Gosu mode. Gosu is a language that has curly braces and no semi-colons, so you should be all set for your minimum. It also uses the same comment syntax as C.
The implementation of the mode for it is really simple and based on generic mode, so modifying it to work the way you want should be easy. It is not based on C-mode.
This is what I used to make a mode for the language I was working on for my compilers class, and it was really easy even with limited elisp experience. On the other hand, the indentation is fairly simple--it works for most code, but is not as complete as C-mode's.
Check out arduino-mode: https://github.com/bookest/arduino-mode/blob/master/arduino-mode.el
It is a C based mode that uses the cc-mode features to quickly create something very useful and unique to arduino programming. Using this as a simple template should help a lot.
Related
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 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.
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.
There are several questions on SO about how to get code folding in emacs, without having to add any special characters like "markers" in the comments for example. Someone said that there was "no perfect solution."
It seems that it could be done by parsing the source of the program being written and look for matching parenthesis or bracket, or to do it based on indentation. You could also use a combination of scripts that use different methods.
So why is it commonly accepted that there is no "perfect" and straightforward way to get code-folding in emac? Is there something in emacs or its architecture that makes it hard to program? If it were easy, after so many years of smart people using emacs you would think that someone would have wrote it.
You should play with Hideshow (hs-minor-mode) combined with fold-dwim.el. It does exactly what you suggested -- looks for matching braces/parens, and can be set up to fall back on the indentation.
There's a robust folding solution out there for most common languages, and if there isn't, all the folding packages are highly customizable. In fact, the only downside is the proliferation of folding methods (fold-dwim helps quite a bit with that); I used to think that because nobody could point me to a definitive solution, folding was hard or impossible — in fact, the opposite is true. You just have to experiment a little to see what works best for you.
I have used folding.el (e.g. to group stuff in my .emacs), outline-minor-mode, and now Hideshow. There's some chance that none of them would work exactly the way you want right out of the box (e.g. you might need to set up an outline regex, or define folding marks for folding.el), but it turns out to be easy. The default keybindings can be somewhat baroque, but this is remedied by fold-dwim and/or hideshow-org (highly recommended for Hideshow, cf the Emacswiki hideshow page; you can also mimic hideshow-org's behavior for other folding modes with some quick-and-dirty elisp and fold-dwim). Once you figure out your preferred setup, just turn it on automatically via hooks or buffer-local variables, and watch your code fold away :)
You should look into CEDET. It does code-folding just fine, and many other fancy features that you're probably looking for if you're switching from an IDE to Emacs.
http://cedet.sourceforge.net/
Specifically, look for `global-semantic-tag-folding-mode'
You don't need anything extra, just enable outline-minor-mode for file types you want to fold.
But in fact, there ARE various solutions for Emacs; I have listed some of them (those I have happened to come across) at http://en.wikipedia.org/w/index.php?title=Code_folding&oldid=375300945#cite_note-2.
Though, there are things I'm missing: in some cases, I'd like to combine several mechanisms: for example, for markdown, I'd like to use outline-based folding (for sections) and indentation-based folding (for quotations, code blocks etc.) -- in order not bother with implementing a complete parser for markdown.
Here they are:
Token-based folding in Emacs
Token-based folding in Emacs is impemented by the folding minor mode.
Indentation-based folding in Emacs
One can use the set-selective-display function in Emacs to hide lines based on the indentation level, as suggested in the Universal code folding note.
Syntax-dependent folding in Emacs
Syntax-dependent folding in Emacs is supported by:
the outline and allout modes
for special dedicated "outline"-syntaxes;
by the hideshow minor mode for some programming languages;
also,
by the semantic-tag-folding minor mode and the
senator-fold-tag command for
syntaxes supported by semantic,
as well as by doc-mode for JavaDoc or Doxygen comments,
by
TeX-fold-mode
sgml-fold-element command,
nxml-outln library
in the corresponding language-specific modes, and possibly in other modes for particular syntaxes.
Several folding mechanisms are unified by the
fold-dwim interface.
See also http://www.emacswiki.org/emacs/CategoryHideStuff.
Folding of user-selected regions in Emacs
Folding of user-selected regions in Emacs is implemented by the hide-region-hide command.
I have been using folding-mode for quite some time. With auto-insert template and abrevs it works quite well for me for for some nice bricks of code.
Being able to produce the buffer folded (for printing/emailing) has always been a desire of mine. Some of my folding tags are for secure / password hiding.
I know this is a bit old but for me origami.el works perfectly well out of the box.
Yes Finally code folding is there in emacs. Try yafolding present at melpa.org package library.
I want to fully-justify latex code on EMACS so that my latex code will look better. For example, I remember my advisor sending me latex in fully justified way like this:
In ~\cite{Hummel2004}, authors described an approach for harvesting
software components from the Web. The basic idea is to use the Web as
the underlying repository, and to utilize standard search engines,
such as Google, as the means of discovering appropriate software
assets. Other researchers have crawled through Internet publicly
available CVS repositories to build their own source code search
engines (e.g., SPARS-J)~\cite{Matsushita2005}.
I suppose that his column-width is set to 70 columns.
Could someone give me a hint?
The standard fill.el package includes the command justify-current-line which is part of what you need. From the function help:
Do some kind of justification on this line.
Normally does full justification: adds spaces to the line to make it end at
the column given by `current-fill-column'.
Optional first argument how specifies alternate type of justification:
it can be `left', `right', `full', `center', or `none'.
If how is t, will justify however the `current-justification' function says to
And other posters have already given you the magicall invokation:
M-x set-justification
As a philosophical side note, the point of fixed-wdith text justification is to fake real typography on a inflexible output device. So applying it to LaTeX source seems a little odd to me. Moreover, I have been using the "one sentence to a line" approach to LaTeX documents for some months now, and find that it really does improves both the editability and the source-control behavior of LaTeX, so I would recommend against doing this.
If you select the region, and then press Ctrl-u M-x fill-region you get "full justification".
M-x set-justification-full
Use Refill mode afterwards to not have to run the command again after typing.
To get line wrap in the file itself (as opposed to something like longlines-mode that does not alter the structure of the file), I use auto-fill-mode, which automatically applies M-q (fill-paragraph) to each paragraph. For example, I use auto-fill-mode in mail-mode. You could do something similar with your LaTeX mode with a hook like this:
(add-hook 'TeX-mode-hook 'turn-on-auto-fill)
Assuming your TeX mode's hook is TeX-mode-hook.