fill-column-indicator is the most mature solution, and if you find overlay-based code with which it conflicts, you can add code to suspend fci-mode while the conflicting code is active. For example, the following code makes it work with auto-complete:
(defun sanityinc/fci-enabled-p () (symbol-value 'fci-mode))
(defvar sanityinc/fci-mode-suppressed nil)
Here is one option which is more robust, it breaks almost nothing
(occasionally company-mode being a noteworthy exception), but is not as convenient
to mark the 80th column on the header.
Something like the following should suffice:
(list " " (make-string 79 ?-...
Since this writing, it seems that part of the features have been directly implemented in markdown-mode. Check out this comment, and the links therein.
There are two approaches you can take.
You can write a command that compiles the markdown code (using a
shell command) and displays the html in a buffer.
You can make some ...
After much suffering because of various bugs fill-column-indicator introduces, I eliminated it from my config for good.
What I currently use is built-in Emacs functionality to highlight lines that are too long. This even looks better, I wouldn't enable fill-column-indicator now even if it were bug-free.
For a start you may grab my setup:
Are there any better alternatives?
Emacs 27 will support a fill column indicator natively by way of the buffer-local minor mode display-fill-column-indicator-mode and its global counterpart global-display-fill-column-indicator-mode.
Here it is in action:
Quoth (emacs) Displaying Boundaries:
14.15 Displaying Boundaries
The code below use a font-lock rule with a function instead of a regexp, the function search for occurrences of $VAR but only when they are inside a double-quoted string. The function (syntax-ppss) is used to determine this.
The font-lock rule use the prepend flag to add itself on top of the existing string highlighting. (Note that many packages use t for ...
The following elisp snippet should do. The important details are:
Strings are handled by syntax highlighting and not by pattern matching (i.e., keyword highlighting). This has very high priority. So one needs to override it explicitly by the value t for the MATCHER flag OVERRIDE (see doc of font-lock-keywords).
One cannot use a regexp as keyword MATCHER ...
I recently came across similar problem, I basically wanted to fontify code snippets in the documentation which I got some other source. I followed the approach mentioned towards the end of your answer and it worked fine for me. The function I ended up with some thing like the following
(defun my-fontify-yaml (text)
AFAIK the example you give are actually 2-char comment delimiters, except that depending on the 3rd character, these comments are treated in different ways (but always as comments in the sense that the semantics of the code is unaffected).
So, the support offered by Emacs's syntax tables should be sufficient in most cirsumstances. If you want to highlight ...
You can use font-lock-add-keywords to add custom highlights.
In the below example, I am highlighting any string
that begins with _ preceded by a white-space character or beginning of the line
followed by a single alpha-numeric character
followed by anything else
ending with :
The highlight color chosen is font-lock-warning-face; you can choose any other ...
It turns out that the wildly varying performance was related to garbage collection. Each call to the function would get slower until a garbage collection was run. With stock emacs, gc was run every couple of seconds, but I had a line in my init.el to improve startup time that set gc-cons-threshold to 20 MB, and that meant gc was run much more infrequently, ...
Faces are global so changing its attributes anywhere changes it
everywhere, as you've noticed. To change it locally, make a copy of
the face, change the attributes in the copy and then use a mode hook
to locally set the old face to the copy on a per-buffer basis. The
sample below does it for font-lock-comment-face, but the same
incantation will work for ...
There are two ways
(defun lisp--match-hidden-arg (limit) nil)
Remove lisp--match-hidden-arg from lisp-cl-font-lock-keywords-2 and lisp-el-font-lock-keywords-2
(cl-delete 'lisp--match-hidden-arg lisp-el-font-lock-keywords-2
Please Do NOT Do That!
Take a look at the C-hv value of font-lock-type-face the value is just the symbol font-lock-type-face. Now look at the C-hv value of my-mode-foo-face. Oh no! you can't! It's not a variable!
You need a variable to access your face. Declaring the foo-face face does not declare the foo-face variable.
Add (defvar my-mode-foo-face 'my-mode-foo-face) after the ...
There is a built in way to do this with font-lock (thank you sanityinc)
This answer has all the details about how this style of font-lock-keywords work: https://stackoverflow.com/a/14675550
(defun pod-comment-highlighter (limit)
"If looking after __END__ or __END__ is before LIMIT, set match-data to a the location of the pod comment."
This EmacsWiki page has lots of information about different ways to mark a particular column or otherwise let you know when you go past it.
The one I use is Mode Line Position.
But others include showing a vertical line at the column (Column Marker, Fill-Column Indicator) and using whitespace mode to highlight text that goes past the column.
(If you ...
thanks to mutbuerger for the helpful comments. Currently, I use this for this operator to work with ESS only.
(defun then_R_operator ()
"R - %>% operator or 'then' pipe operator"
(define-key ess-mode-map (kbd "C-%") 'then_R_operator)
(override t) is the culprit: that's what tells Emacs to apply the comment face to anything that starts with a # even if part of that thing has already been recognized as something else. Remove it.
However you shouldn't need to define a regex to highlight comments: Emacs understands comments out of the box, based on character syntax, as described by ...
This is really a limitation of Emacs' overlay system, upon which auto-complete and popup rely: the overlays are positioned using text column offsets, not pixels.
So your options are indeed as you outlined. The path of least resistance is to use a fixed-width font with a variety of styles. My personal favourite is Input Mono, FWIW.
Not exactually what you want, but ruler like @Malabarba♦ will waster space, here is better solution:
There is a built-in package in emacs-goodies-el(recommend to install it in terminal) called highlight-beyond-fill-column.el, add this to your .emacs or init.el:
(setq-default fill-column 80)
(add-hook 'prog-mode-hook 'highlight-beyond-fill-column)
Put point (the cursor) on the word fix and do C-u C-x = (what-cursor-position). In the buffer that comes up, look for a section that looks like this:
There are text properties here:
Move point to whatever it says instead of font-lock-comment-face (you can use TAB to navigate there), and ...
One option is to add "auto" to extra types recognized by c++-mode:
(add-to-list 'c++-font-lock-extra-types "auto")
The downside is that now it is not highlighted as a keyword any more. (But "auto" is both a type and a keyword, in a way.)
Sure you can, (see this SO question) although it seems a bit heavy-handed.
(defun nadvice/message-color (old-fun &optional str &rest args)
(if (not str)
(funcall old-fun "%s" (propertize (apply #'format str args)
'face '(:foreground "red")))))
(advice-add 'message :around #'nadvice/...
font-lock-syntactic-face-function is a regular variable from Font Lock, more specifically from the Syntactic Font Lock phase (emphasis mine):
If this variable is non-nil, it should be a function to determine which face to use for a given syntactic element (a string or a comment). The value is normally set through an other-vars element in font-lock-...
For strings and comments it's better to use syntactic fontification. The syntax table for a given major mode has to be defined in variable <major-mode-name>-syntax-table.
This entry from the Emacs manual helps clarifying how Font Lock works: Font Lock mode finds text to highlight in two ways: through syntactic parsing based on the syntax table, and ...
From this in the documentation of font-lock-keywords, it sounds like you could use the PRE-MATCH-FORM to return the limit of the search for "variable", like this:
'(("\\(constant\\):'" (1 font-lock-constant-face t)
(save-excursion (search-forward-regexp "\\(variable,\\)*variable'"))
Instead of the hack of using font-lock-face (which also means no highlighting unless font-lock is turned on), you can just use library Highlight (highlight.el).
It lets you highlight arbitrary text in many ways, using either text properties or overlays, and its highlighting is independent of font-lock highlighting. IOW, it gives you an easy way to keep font ...
A good place to start would be markdown-mode.el which can be downloaded from here.
This mode does not offer org-mode style beautification, but it does offer syntax highlighting and a bevy of customize options.
In order to get this style beautification, someone would need to write an extension to markdown-mode.el implementing font-faces.
Most of org-mode....