(I don't know if the title of this question is correct)
When using several minor modes simultaneously changing 'colors', what determines in which order which modes shows what? For example I'm trying to use both highlight-changes-mode and rainbow-mode: http://julien.danjou.info/projects/emacs-packages
The problem I have is that when I enter a new color in my buffer (say #306090), instead of seeing the background color of the #306090 characters as rainbow-mode would want it to be, I see the background color (of the entire line) as changed (because I'm using highlight-changes-mode, which I like a lot).
My question is kinda a generic one: what determines in which "order" conflicts are resolved here? Does it depend on the loading order of the various modes?
It doesn't depend on the loading order of the modes. It depends on the respective mechanisms the modes use to apply the faces.
rainbow-mode uses font-lock to highlight text, which in turn uses so-called text properties. Text properties are intrinsic properties of string objects, and can belong to string objects that are not part of any buffer. (Text properties thus survive cutting and pasting, for example.)
highlight-changes-mode, in contrast, uses "overlays," which can be thought of as virtual text properties: An overlay is a specification of an interval in a buffer together with a specification of one or more properties that that interval should act as if it had; among the properties that an overlay can specify is a face. Overlay properties are not properties of the strings themselves (and so don't survive cutting and pasting).
If incompatible face attributes are specified by the text property of a buffer substring and an overlay covering that substring, then the overlay takes precedence. (If the face attributes aren't incompatible--as when a text property specifies a foreground color but no background color, and an overlay specifies merely a background color--then they're merged in the fashion you'd expect.)
In general the rules for merging faces are complex, because overlays themselves can specify strings to display at a buffer position, which strings in turn can have their own text properties, and different rules govern such cases; also, certain built-in faces like mouse highlights and mode-line faces are governed by their own rules. If you want to know more, see the info nodes "(elisp) Faces" and "(elisp) Overlays". For the complete story you'll need to look at the source code of the display routine (probably starting with handle_face_prop in xdisp.c and face_at_string_position in xfaces.c).
Related
I love Emacs and Org-Mode. But I can only stand to use Org Mode in the clean view (or whatever it's called - with org-indent-mode on).
My problem is that I often want to use headers that don't have a bullet in front of them. I want one asterisk to be the start of the list, not the header.
Example:
List 1
List 2
Header 1
List 3
List 4
But when I try to do this, Header 1 gets indented to the level of List 2.
I know just turning off org-indent-mode and getting used to that is one solution. But is there a way to reset the indentation for Header 1?
The things you are talking about changing are pretty fundamental to org-mode; basically you are trying to change the org-mode syntax. The reason why Header 1 in your example is not being dedented, is that org-mode does not see it as a headline, because headlines by definition start with leading stars. Also, while it is technically supported to use * to identify a plain list item, this is not recommended, and can cause some unexpected behavior (see footnote 1 here).
That being said, you can have some control over the appearance of headlines. For example, you can use the org-bullets package. You can then define the bullets to use in place of * like this:
(setq org-bullets-bullet-list
'("◉" "◎" "⚫" "○" "►" "◇"))
which will define the bullets used for the first six levels of headlines. You can replace the bullets in that list with other utf-8 symbols, and you can even use " " as one of the symbols, so that your Headlines will be preceded by a single space. However, note that this only affects the way headlines are displayed; they will still be preceded by * in the actual file.
I know it is not very helpful, but my overall suggestion would be to stick with the org-mode syntax if you want to use org-mode, i.e., use a structure like this:
- List one
- List two
* Header 1
- List three
- List four
with * starting a headline, and - starting a plain list. Since org-mode files are just plain text, the magic of that mode depends heavily on those files having a set structure. In my own experience, if you try to change that structure (another example is changing timestamp formats), it will cause more headaches than it relieves, and cause a lot of the functionality that makes org-mode so great to break.
Just as a side note: I prefer a cleaner view as well, and one option I like to enable in addition to org-indent-mode is (setq org-hide-leading-stars t), which will display only a single star/bullet per headline (although the leading stars will still be present in the actual text file).
I'm in the process of updating a heap of manuals which for whatever reason have Heading Formats applied to them. The empty lines sometimes appear in the table of contents which is annoying the end recipients somewhat.
The documents have a mix of styles I need to replace, ie the Paragraphs in the boxes below, but I can't work out a way to find an empty line with a specific style that may or may not differ from the previous line.
I'm getting the impression it's not doable but thought I'd ask here before doing it manually. The main effect is on navigation but occasionally TOC, usually when compatibility is maintained.
I'd like to isearch/search-replace/occur only in code (that is not in comments or strings).
This must be a common problem, so what packages do this already?
If no existing packages do this, I'm thinking a minor-mode where strings and comments are hidden based on fontification would do the trick. Is there one?
Icicles search gives you several ways to do this. Here are two:
Search "things" (e.g. defuns, sexps, xml elements, etc.), ignoring comments (option icicle-ignore-comments-flag). That is, use selected code segments as search contexts, but ignore any comments within code or code inside comments.
Search the complement of the comments. E.g., define the search contexts as the complement of the zones of text that are font-locked with either face font-lock-comment-face or face font-lock-comment-delimiter-face (which means search all code outside of comments).
After defining the search contexts, just type text to incrementally filter the contexts. And you can replace any matches on demand.
Check out narrowing.
Yes, you are right. The HideShow minor mode allows you to hide/show block of text, in particular multiline comments.
The hide/show comments is not part of the standard package but on the wiki page you will find the code which does the trick.
Then isearch command does not take into account the hidden comments.
HOWEVER: replace operates on the whole buffer, including hidden blocks.
Isearch+ does what you ask (as does Icicles --- see other answer, above).
You can define the contexts that Isearch searches, using any of the following:
A regexp to be matched.
A given text or overlay property --- The search contexts are the text zones that have the property (e.g. a particular `face' value or combination of values)
A given Emacs THING (sexp, defun, list, string, comment, etc.) --- The search contexts are the text zones of the given THING type.
Having defined the search contexts, you can also search the complement: the non-contexts. You can toggle between searching contexts and non-contexts anytime in Isearch, using C-M-~.
When searching, by default the zones not being searched are dimmed slightly, to make the searchable areas stand out.
For context-searching with Isearch you need these two libraries:
isearch+.el
isearch-prop.el
In emacs, I want a function name get highlighted when it is called, not only defined or declared. I try to do this with a 'color-theme' theme file. But the theme file does not seem to have a variable to work this out, it has a variable 'font-lock-function-name-face', but this one only works for function declaration.
Is there some solution?
Thanks,
Utoah
There are a number of standard font lock faces, such as font-lock-comment-face, font-lock-function-name-face, font-lock-type-face, etc. It's up to each major mode to decide what is highlighted in each face. Programming language modes typically put comments in font-lock-comment-face, function names in definitions in font-lock-function-name-face, and so on. Some modes use font-lock-type-face only for definitions of type names while others use it for type annotations. There is no standard font lock face for function names in function calls, so most modes don't contain code to detect them. You'll probably have to modify the font locking code for the mode you're interested in.
In noweb mode, I would like to make the doc chunks and code chunks easier to distinguish. I'm already using font-lock-mode, but it applies the same face to strings in R and strings in tex, so doesn't distinguish the code and doc chunks very well.
For example, a slightly different background color for the code chunks.
One possibility would be to define a new face for the minor mode of the code chunk, but then that face would also apply when editing a buffer in that mode.
Another possibility would be to create an overlay for the code chunks.
Also, somewhat related, org-mode can be configured to use different background colors for source blocks.
Update: I now use polymode to achive this.
You can use noweb-font-lock-mode from ESS to get syntax highlighting for both code and documentation chunks. I'd recommend you also use noweb-mode from ESS too, because it has some improvements.
One option would be mmm-mode, with which you can define regions that are in a different mode -- it also applies a face to the entire sub-mode region, which you can use to easily distinguish those regions within the parent file.
I personally use this for Ruby within IRB, Javascript and CSS within HTML etc. There's an example for javascript in my emacs config.
The MuMaMo extensions allows different rules for different parts of the file. Getting the nXhtml package will give you the mode and I think you can configure it to do what you want.