Note that as of Emacs 27, you should probably use the built-in display-fill-column-indicator-mode, as noted by the newer answer from Basil.
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 ...
Are there any better alternatives?
Emacs 27 (officially released 2020-08-11) added support for 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 (see (info "(emacs) Minor Modes")).
For example, you can enable it in most ...
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:
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 ...
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)
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 ...
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, ...
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 ...
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 ...
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 ...
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!
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 is about Ruler Mode, a minor mode that shows a ruler for columns at the top of a window.
It also shows you the current column and the positions of comment-column, fill-column, goal-column, and the tab stops (as in tab-stop-list).
And this EmacsWiki page is about a ruler that pops up on demand, then disappears.
This other EmacsWiki page ...
(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)
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.)
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 ...
Take a look at font-lock-keywords after you have called your function. You will see that it just has the regexp for the first line as the regexp to fontify. All you did was to pick up a given line and put a regexp to match it into font-lock-keywords - so only dups of that line get highlighted. IOW, the regexp for that first line is hard-coded in font-lock-...
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/...
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'"))