For the last 3 years, my work required writing and editing configuration files in xml format. The content in the xml tags has evolved so much that now it has become kind of like a programming language. Unfortunately, emacs indents everything inside the tags at the same level. Something like this:
But it'd be wicked if I could get the content indented like the following:
I've read several threads related to custom indentation, but I still don't have any clue how to do it.
I've tried to create a custom major-mode, but doing that killed all the syntax colors and indentation rules. Ideally what I'd like to do is just modify the nxml mayor mode indentation rules? Still, I don't know where about this rules are.
Also it would be a bonus if I could color some key words, like 'if' or 'set'.
I know that what I'm asking is a big job, so I'm not asking for a definitive answer here. I'm just looking for some help to point me to the right direction.
Probably the best way to do it is writing a new major mode for the language inside the tags and then using a multiple major modes package which allows more than one major modes to be active in the same file, so the contained language can have its own major mode.
You might want to have a look at this example.
(defun nxml-extra-space-indent ()
(nxml-indent-line)
(when (zerop (current-indentation))
(indent-line-to 4)))
(setq indent-line-function 'nxml-extra-space-indent)
I indent according to an existing major mode, and then customize the indentation if the line matches certain criteria.
I think this is the easiest way to customize indentation, as you are starting from something existing, and you don't need to know how the indentation logic of a particular mode is implemented.
Related
I've been using Org-mode a few months, and as I customize Emacs, I'm having a lot of difficulty finding documentation on how to specifically customize various variables.
Example: I've successfully set up archiving, but want to customize the org-archive-save-context-info variable to reduce the info that's archived along with the task. I do not want to do this per-file, but in my config file. Despite my best efforts, I don't see documentation on syntax and parameters for customizing this.
I do see some documentation when I customize the variable in the Emacs UI--but I'm looking for documentation so I can see syntax and parameters for customizing this myself via a config file. I can learn it backwards this way (via 'easy customization'): customize a variable, see what Emacs wrote to the config, try tweaking that, etc.
[EDIT] I'm talking about info below the task that appears after archiving, like this:
:PROPERTIES:
:ARCHIVE_TIME: 2018-09-10 Mon 11:24
:ARCHIVE_FILE: ~/Dropbox/logs/capture.org
:ARCHIVE_OLPATH: Tasks
:ARCHIVE_CATEGORY: capture
:ARCHIVE_TODO: DONE
:END:
Is this intentional? Do I just need to 'know ELisp' first? Is the intention that you use the Emacs point-and-click UI to customize things like this? Happy to RTFM if I could find the FM.
Is the intention that you use the Emacs point-and-click UI to customize things like this?
It's certainly intended that you would use the customize interface if you don't know elisp (and you might well choose to use it even if you do).
Do I just need to 'know ELisp' first?
Yes, you'll need at least some familiarity with elisp in order to understand the documentation and be able to write your own config changes. This is because elisp is the configuration language for Emacs, and so the documentation is written in that context. (It wouldn't make sense for basic lisp concepts to be explained and repeated in every piece of documentation which used them.)
That said, many people get by just copying and pasting from config examples -- and you're likely to pick up the basics this way, even if you don't fully understand them. If you're serious about Emacs, though, spending some time to learn about elisp will be hugely beneficial to you in future.
I can learn it backwards this way (via 'easy customization'): customize a variable, see what Emacs wrote to the config, try tweaking that, etc.
That's an entirely reasonable thing to do.
FWIW C-hv org-archive-save-context-info is actually very clear if you have the background understanding.
This variable can be a list of any of the following symbols:
time The time of archiving.
file The file where the entry originates.
ltags The local tags, in the headline of the subtree.
itags The tags the subtree inherits from further up the hierarchy.
todo The pre-archive TODO state.
category The category, taken from file name or #+CATEGORY lines.
olpath The outline path to the item. These are all headlines above
the current item, separated by /, like a file path.
That tells you that you might use the following in your config file:
(setq org-archive-save-context-info '(time file todo))
Happy to RTFM if I could find the FM.
You can start learning about elisp in the "Emacs Lisp Intro" manual, which you should find near the top of the Info directory, or jump to directly with C-hig (eintr) RET. Type h from there if you need to learn how to use the Info reader.
I'm using Emacs 25.1, with the latest stable release of clojure-mode. When clojure-mode (not in other major modes like js2-mode) is turned on, everything is strictly aligned, no extra whitespace is allowed before any forms. For example,
(def
last (fn ^:static last [x]
(if (next x)
(recur (next x))
(first x))))
I can't insert a space (automatically removed after insertion) before the first non-whitespace character on each line. This kind of behavior is just not desirable to me. I tried changing the variables in the Clojure group, but nothing seemed to work. How can I turn this behavior off?
It isn't exactly clear what you mean, but I suspect you are referring to the way
Clojure will align forms in things like let bindings so that all the symbols and
values being bound are aligned i.e.
(let [a-val1 (something-1)
another-val (something-2)
final-col 12]
(do-some-stuff))
rather than
(let [a-val1 (something-1)
another val (something-2)
final-col 12]
(do-some-stuff))
If this is the case, then there are a few things you can try.
Look at the variable clojure-align-forms-automatically
clojure-align-forms-automatically is a variable defined in
‘clojure-mode.el’. Its value is t Original value was nil
This variable is safe as a file local variable if its value
satisfies the predicate ‘booleanp’.
Documentation: If non-nil, vertically align some forms automatically.
Automatically means it is done as part of indenting code. This
applies to binding forms (‘clojure-align-binding-forms’), to cond
forms (‘clojure-align-cond-forms’) and to map literals. For instance,
selecting a map a hitting ‘M-x indent-for-tab-command’ will align the
values like this:
{:some-key 10
:key2 20}
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 5.1 of the clojure-mode package.
The other variable which you might want to look at is clojure-indent-style
clojure-indent-style is a variable defined in ‘clojure-mode.el’. Its
value is ‘:always-align’
This variable is safe as a file local variable if its value
satisfies the predicate ‘keywordp’.
Documentation: Indentation style to use for function forms and macro
forms. There are two cases of interest configured by this variable.
Case (A) is when at least one function argument is on the same line as the function name.
Case (B) is the opposite (no arguments are on the same line as the function name). Note that the body of macros is not affected by
this variable, it is always indented by ‘lisp-body-indent’ (default
2) spaces.
Note that this variable configures the indentation of function forms
(and function-like macros), it does not affect macros that already use
special indentation rules.
The possible values for this variable are keywords indicating how to
indent function forms.
‘:always-align’ - Follow the same rules as ‘lisp-mode’. All
args are vertically aligned with the first arg in case (A),
and vertically aligned with the function name in case (B).
For instance:
(reduce merge
some-coll)
(reduce
merge
some-coll)
‘:always-indent’ - All args are indented like a macro body.
(reduce merge
some-coll)
(reduce
merge
some-coll)
‘:align-arguments’ - Case (A) is indented like ‘lisp’, and
case (B) is indented like a macro body.
(reduce merge
some-coll)
(reduce
merge
some-coll)
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 5.2.0 of the clojure-mode package.
There are some other alignment/indentation variables which you may also want to
check out - try M-x customize-group clojure-mode and M-x customize-group
cider to browse and see if anything is relevant. You might also find
something relevant on the cider documentation site. In particular, look at the
manual section on indentation
UPDATE EDIT: Based on additional information from the OP communicated in comments, I
decided to edit and extend this answer. I've left the original response as I
feel it may be useful to others who search and find the OPs question. However,
with the additional info in the comments, I don't think the answer addresses the
OPs actual issue, so have extended the answer below which I hope will help.
Some Emacs modes are more rigid or enforce code format more strictly than
others. This is particularly the case with vary regular languages like Clojure
(and most lisps generally) whee the syntax is minimal and the rules regarding
code indentation are easier to define and tend to have wide consensus.
The situation for the OP is further complicated because they are using a
pre-defined Emacs configuration - in this case Steve Purcell's emacs.d,
which is one of my favourite pre-defined or canned Emacs configurations. The
one drawback with these pre-defined configurations is that they will turn on and
define many optional features of the Emacs editor which may or may not be
in-line with user personal preferences. Emacs tends to have a vary conservative
position when it comes to new features or enhancements. Often, they are disabled
by default to avoid impacting new users. The cost for this conservative approach
is that over time, Emacs can seem primitive or less feature rich compared to
other editors to new users who expect some of this behaviour to be enabled by
default. By using a canned configuration, you get one person's preferred setup
without having to go through the often long and difficult process of doing it
yourself. The downside is that when it does not match with the user's
expectations, the user does not have the knowledge or understanding to make the
changes and it is difficult to get help because others don't know/understand
what their configuration is already.
As an example how using these pre-defined setups can complicated matters, when I
last looked at the Purcell configuration, it used the ELPA package
aggressive-indent, which enforces more rigid indentation rules and it could
well be this package rather than clojure-mode which is enforcing the rigid
indentation rule.
The OP mentions they are concerned regarding this auto-formatting as it could
cause problems when contributing to other projects and issues with
auto-formatting making the code look like there has been more changes than has
actually occurred due to the version control picking up the whitespace
adjustments. This issue mainly comes up over differences due to the use of tabs
and spaces. to a large extent, such issues are less frequent these days as most
version control systems can be configured to ignore whitespace changes.
In this case, my recommendation is to do nothing for now as there isn't a real
issue yet. Continue to use the canned configuration and continue to ask
questions, but also spend some time trying to learn and understand the
configuration. At some point, once your comfortable with Emacs, you will likely
want to re-configure the system to better meet your own personal taste. By this
time, you will have a better understanding of Emacs, the various options it has
and the way different modes work. When you run into specific real issues which
you cannot solve, then post another question. It is likely at that point, you
will have concrete information and someone will be able to provide specific
help.
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.
I'm wondering if anyone could weigh in on pros and cons of different spelling modes for Emacs. Emacswiki-CategorySpelling mentions three modes for spell checking:
Flyspell mode (default one)
Speck mode (seems to be designed to be faster than flyspell)
Wcheck mode. (designed to be general purpose)
I'm also interested in which of these modes provide a way for the spell checker to skip part of a buffer depending on its syntax (for instance, in order to skip math mode parts in a LaTeX document, which are highlighted as brown in AUCTEX mode). Flyspell doesn't seem to do this
You can do partial flyspell-mode in a number of different ways. One is to use a multi-mode approach, where you define multiple modes in a single buffer, one of which is a mode to edit comments (for example), in which flyspell-mode is enabled. I used to do this for some programming language, but I can't find the config for it any more, so I guess I don't use that language anymore. Anyhow, see mmm-mode for more info there.
A second alternative is to use `flyspell-prog-mode' (which see) which sets up flyspell mode for certain parts of the buffer, defined in this case by the font face (there are specific faces for strings and comments for most programming language major modes). It uses a predicate call-back function, which can be defined however you want it; I maintain TNT, which is an AIM-mode for Emacs, and we use it like so:
(defun tnt-im-mode-flyspell-verify ()
"This function is used for `flyspell-generic-check-word-p' in TNT."
(not (get-text-property (point) 'read-only)))
(put 'tnt-im-mode 'flyspell-mode-predicate 'tnt-im-mode-flyspell-verify)
(put 'tnt-chat-mode 'flyspell-mode-predicate 'tnt-im-mode-flyspell-verify)
Regarding flyspell vs. speck vs. wcheck -- I've only used flyspell mode. speck seems to be very oriented on what is viewable, which can be fine, but generally I want the whole of whatever document I'm working on to be spell-checked, so I wouldn't want that. wcheck seems to be a generic interface to an external program; I'd guess you're going to have to build up its use yourself. flyspell can be used two different ways: as-you-type, which is how I usually use it, and "batch mode", where a whole region or buffer is checked at once. The former is incredibly fast, and I've never found a reason to look for a better tool. The latter can be a tad slow, especially when there are a lot of misspelled words and the document is large, but I really can't remember waiting more than 15 seconds for it to complete. While watching the screen for 15 seconds and doing nothing can seem like a long time, it's not, really. YMMV, of course.
Bottom line: I'd stick with flyspell-mode, assuming it meets your needs, of course.