Why do the theme definitions contain structures like (t (:background "black"))? What is the role of t?
The sexp ((t (:foreground ... ))) is a face specification which is described here:
http://www.gnu.org/software/emacs/manual/html_node/elisp/Defining-Faces.html
In short, it is an alist of the form (display . plist) and hence in your code t corresponds to display and (:background... ) is the plist. plist is the property list of face attributes, and I'm not going to talk about it since it's not relevant to the question. However, display can take other values than t. The aforementioned documentation describes display as:
The display part of an element of spec determines which terminals the
element matches.
and the value t means:
This element of spec matches all terminals.
However, you could be more selective and define your face attributes to only apply to certain terminals, for instance only those that support color.
Related
I want to define a customizable variable in Emacs Lisp whose possible values are restricted to a certain list, but the list should be dynamically created by a function each time the user opens the customization buffer. Thus, something similar to
(defcustom my-variable
[...]
:type '(choice [...])
but choice seems to support only a static set of values. What I want is something like
(defcustom my-variable
[...]
:type '(choice my-function)
where my-function is a function that returns the list of possible values, and is evaluated each time the customization buffer is created.
Is that possible?
(defun my-function ()
"..."
'(42 "a" b (x y) "c"))
(defcustom foo 42
"..."
:group 'convenience
:type '(restricted-sexp
:match-alternatives ((lambda (x)
(car (member x (my-function)))))))
Function my-function could provide a different list of possibilities each time (or whenever, based on whatever).
This simple example doesn't provide much in the way of feedback (and no doc strings).
But the idea is this: restricted-sexp is the most general defstruct type-defining construct. This is what the Elisp manual, node Composite Types says:
(restricted-sexp :match-alternatives CRITERIA)
This is the most general composite type construct. The value may
be any Lisp object that satisfies one of CRITERIA. CRITERIA should
be a list, and each element should be one of these possibilities:
A predicate—that is, a function of one argument that returns
either nil or non-nil according to the argument. Using a
predicate in the list says that objects for which the
predicate returns non-nil are acceptable.
A quoted constant—that is, 'OBJECT. This sort of element in
the list says that OBJECT itself is an acceptable value.
For example,
(restricted-sexp :match-alternatives
(integerp 't 'nil))
allows integers, t and nil as legitimate values.
The customization buffer shows all legitimate values using their
read syntax, and the user edits them textually.
In the example I gave, the list of CRITERIA is a singleton, with just this function:
(lambda (x) (car (member x (my-function))))
That function ensures that the value you use for the option is a member of the list that function my-function returns. (And it makes the value be the car of what member returns, i.e., the particular member of the list that the user enters.
When using M-x customize-option you won't be able to set a new value if it isn't one of the values returned by my-function.
Instead of seeing feedback that the value was set to what you entered, you continue to see this help text:
EDITED, shown value does not take effect until you set or save it.
If you provide a valid value then you get confirmation that the value was set.
Admittedly, what you might really want is to provide for completion etc. in the editing field. For that, you would need to use/define an appropriate widget, because Customize, out of the box, provides for completion only for a limited set of defcustom type constructs (files, colors, etc.). You can see which ones by searching for completion starting in node Simple Types.
restricted-sexp is really a wonderful thing. It should be improved by Emacs to be more useful. But even as it is it should be used more, to provide more-specific type checking. Too many users defining defcustoms are a bit lazy, IMO, not bothering to provide a specific type definition even when that might be as simple as using choice. (Too many just use a type of sexp.)
I found a solution: I defined my-variable with type choice and only one default entry, then I wrote a function that updates the choice entries dynamically, and added that function to 'Custom-mode-hook. This hook is called each time Custom mode is entered. Thus, whenever the user is about to customize my-variable, the choice entries are updated before. Here is a sketch of code:
(defcustom my-variable
"None"
:type '(choice (const :tag "None" "None")))
(defun my-function ()
;; Function that provides the possible values of my-variable
)
(defun my-update-variable-allowed-values ()
(let* ( (choices '((const :tag "None" "None"))) )
(dolist (val (my-function))
(setq choices (cons (list 'const ':tag val val) choices)))
(setq choices (cons 'choice choices))
(put 'my-variable 'custom-type choices)))
(add-hook 'Custom-mode-hook 'my-update-variable-allowed-values)
Trying to modify org-mind-map to change the attributes of the nodes and edges. I haven't really learned the internals of emacs and org-mode, and use them "as is" - without making modifications, and therefore not really understanding. So, it would be great if one could explain what custom options means and how to implement them in a org file. This will help me work with other org-mode files also. I do not know how to even call this problem properly, otherwise I would have google-fu'd this.
So, as an example, if I want to change the "shape" of node to "circle" for only a particular heading, where should that property be written within the headline of the org file? So in the example taken from the main project, this works.
* This is an org-mode tree with tags
:PROPERTIES:
:OMM-COLOR: GREEN
:OMM-LEGEND: Legend entry
:END:
To change the shape of the node, the documentation mentions using :OMM-NODE-FMT and something about custom options.
;;; Customizable Options:
;; Below is a list of customizable options:
;; `org-mind-map-default-node-attribs'
;; Alist of default node attributes and values.
;; default = '(("shape" . "plaintext"))
;; You can customize the style of the graph by adding :OMM-NODE-FMT and :OMM-EDGE-FMT properties
;; to the headlines in the tree.
And in the code the documentation tells us,
(defcustom org-mind-map-default-node-attribs '(("shape" . "plaintext"))
"Alist of default node attributes and values.
Each item in the alist should be a cons cell of the form (ATTRIB . VALUE)
where ATTRIB and VALUE are strings.
For a list of value attributes, see here: https://graphviz.gitlab.io/_pages/doc/info/attrs.html"
:type '(alist :key-type (string :tag "Attribute") :value-type (string :tag " Value"))
:group 'org-mind-map)
So, for a headline in org-mode if I want to change the shape of the node, where should I put those options? Should I do something like this
* This is an org-mode tree with tags
:PROPERTIES:
:OMM-NODE-FMT: '(("shape" . "circle"))
:OMM-COLOR: GREEN
:OMM-LEGEND: Legend entry
:END:
This isn't working, of course. Please help!
To use :OMM-NODE-FMT: and :OMM-EDGE-FMT: you actually have to create a
function and add it to org-mind-map-node-formats respectively org-mind-map-node-formats.
Fortunately there are some auxiliary macros predefined to make this as easy as
possible:
for node: (org-mind-map-make-node-fn NAME DOC PROPS &optional SHAPE COLOR OTHER)
for edge: (org-mind-map-make-edge-fn NAME DOC PROPS &optional STYLE COLOR OTHER)
Unfortunately the node one seems to not have been updated after some changes to
org-mind-map and is therefore only useable with a little workaround (see below).
I created a new issue on the github page. The owner of org-mind-map has not been
active on github for a long time, so this will probably not be resolved.
This is how you do it:
:OMM-NODE-FMT:
(require 'ox-org)
(org-mind-map-make-node-fn circle "circle shape" nil "circle" nil nil)
;; until fixed: wrap inside a lambda.
(add-to-list 'org-mind-map-node-formats
'("circle" . (lambda (title tags color hm el &optional content images)
(org-mind-map-circle-node title tags color hm el))))
Check the documentation for org-mind-map-make-node-fn to get more infos about the arguments.
Then use as follows:
* circle
:PROPERTIES:
:OMM-NODE-FMT: circle
:END:
** rectangle
Result:
:OMM-EDGE-FMT:
This would be the way to do it, but it's not working (created another issue on the github page):
(require 'ox-org)
(org-mind-map-make-edge-fn dashed "dashed, red and empty arrowhead"
nil "dashed" "red" "arrowhead=empty")
(add-to-list 'org-mind-map-edge-formats
'("dashed" . org-mind-map-dashed-edge))
Even changing (setq org-mind-map-edge-format-default "[style=dotted]") has no
effect.
Only way to change edge style globally is by modifying (setq
org-mind-map-default-edge-attribs '(("style" . "dotted"))).
I wish to change the appearance of something in a *helm ag* buffer. None of my usual tricks for discovering which face is being used at some point (my favourite being M-x customize-face with the point in the region of interest) work, as there is no (obvious) way of getting control of a cursor in helm buffers.
My questions are:
Teach me to fish, feed me for life: How can I discover the faces used in a buffer in which I cannot place the cursor?
Give me a fish, feed me for a day: Which face is used in the *helm ag* buffer to highlight the pattern match on the currently selected line?
Update
In the case of *helm-ag* buffers created by the helm-ag command, the relevant face is helm-match. However, in *helm ag* buffers (no dash!) created by the helm-do-grep-ag command, the helm-match face seems to have no effect, as described in the further information below.
Further information
Here is a picture of an emacs session in which no custom themes have been enabled.
In the lower left there is a *helm ag* buffer searching for defun. The third line in the buffer is selected. The match (defun) is highlighted in all other lines, but not on the selected one.
On the right are some face customization buffers for likely candidates. helm-match has been set to have a red foreground, but this is not reflected in the *helm-ag* buffer. This seems to suggest that helm-match is not the fish I'm looking for.
A similar approach to #elethan's #3:
Call list-faces-display, which will show you a list of all faces
in alphabetical order.
Search for "helm".
First here is your "fish": I think the face you are referring to is helm-match.
Here are few different strategies that I would personally try if I needed to find a given face and can't place point on the text with that face:
Use M-x describe-face, guess at what the first part of the name is likely to be (in this case helm), and scan through the likely candidates that start with that.
Go to the code where that face is likely defined (in this case helm-ag.el which you can find with M-x describe-function RET helm-ag), and search for face in that file to find a likely match.
Do M-x customize-face and enter and 'all faces', look for helm-* faces and try to find a name and face (since you can see a sample of the face in this buffer) that matches the one you are looking for.
Probably none of these methods is as direct as you are hoping for, and there may be a quicker solution, but this is what I would do (and have done). In this case I found the face with method #2.
Update:
Here is a screenshot from my setup:
Notice that for me the relevant face is helm-match which inherits from match in replace.el. Also, note that the difference between the way the match appears in the highlighted/selected line compared to the other lines is not due to a different face, but caused by how the background color of the line highlighting affects the color, as can be seen when I highlight the sample text here:
Update 2:
It turns out OP was using helm-ag-do-grep which is defined in a different file - helm-grep.el. Here is the face-setting portion of that code:
;;; Faces
;;
;;
(defgroup helm-grep-faces nil
"Customize the appearance of helm-grep."
:prefix "helm-"
:group 'helm-grep
:group 'helm-faces)
(defface helm-grep-match
'((((background light)) :foreground "#b00000")
(((background dark)) :foreground "gold1"))
"Face used to highlight grep matches."
:group 'helm-grep-faces)
(defface helm-grep-file
'((t (:foreground "BlueViolet"
:underline t)))
"Face used to highlight grep results filenames."
:group 'helm-grep-faces)
(defface helm-grep-lineno
'((t (:foreground "Darkorange1")))
"Face used to highlight grep number lines."
:group 'helm-grep-faces)
(defface helm-grep-finish
'((t (:foreground "Green")))
"Face used in mode line when grep is finish."
:group 'helm-grep-faces)
(defface helm-grep-cmd-line
'((t (:inherit diff-added)))
"Face used to highlight grep command line when no results."
:group 'helm-grep-faces)
I think helm-grep-match is what you are looking for. If not, the face in question is likely to be in the above code snippet, and all of those faces should be customizable using customize-face. This code also tracked down using method #2 described above.
ag itself uses colours to highlight matches. Helm uses these colours and ignores helm-grep-match unless helm-grep-ag-command contains the --nocolors option.
There are therefore two approaches:
Set the colours you want with the --color-match option to ag in helm-grep-ag-command.
Disable ag's match highlighting with the --nocolor opiton in helm-grep-ag-command and set Emacs' helm-match or helm-grep-match (not entirely sure which one is the right one here) to specify the match colours. As this second option uses elisp to deal with the colouring, it's likely to be slower than the first.
In both cases, match highlighting will be overriden by helm-selection, so the only way to get any highlighting of the match on the selected line is to have helm-selection not specify either the background or the foreground, thereby leaving the opportuinity for the match highlighting to be seen.
Reference: https://github.com/emacs-helm/helm/issues/1660#
In emacs lisp mode, I want to highlight all function calls one color, and all quoted symbols another color. For example, in (foo 1 2 'bar), foo should be highlighted color 1 and 'bar should be highlighted color 2.
I was able to do this with the code below, however, it is also highlighting the first symbol in a list when the list is quoted. For example, in '(nil a b c), nil should not be highlighted as a function call, and all items in that list should be highlighted as quoted symbols (color 2).
(defface font-lock-func-face
'((nil (:foreground "#6fc2ef"))
(t (:bold t :italic t)))
"Font Lock mode face used for function calls."
:group 'font-lock-highlighting-faces)
(defface font-lock-quoted-face
'((nil (:foreground "#e1a3ee"))
(t (:bold t :italic t)))
"Font Lock mode face used for function calls."
:group 'font-lock-highlighting-faces)
(font-lock-add-keywords
'emacs-lisp-mode
'(("(\\s-*\\(\\_<\\(?:\\sw\\|\\s_\\)+\\)\\_>"
1 'font-lock-func-face)))
(font-lock-add-keywords
'emacs-lisp-mode
'(("'[-a-zA-Z_][-a-zA-Z0-9_]*\\>" 0 'font-lock-quoted-face)))
There's also an image of what I'm looking at here: http://imgur.com/Iluku05
First part of the answer: The package lisp-extra-font-lock highlights, among else, quoted expressions.
It also highlights:
variables in the parameter lists of functions and variables bound by let, pcase etc. It distinguish between normal local variables and global variables defined by a defvar by using different colors.
Back-quoted expressions (and un-highlights all ,- and ,#-escaped subexpressions)
For example:
Second part of the answer:
If you use the lisp-extra-font-lock package, your rule for highlighting functions work as you posted it, if you add it as the last rule, after you have enabled the package. That way it will not overwrite any other highlight:
(font-lock-add-keywords
'emacs-lisp-mode
'(("(\\s-*\\(\\_<\\(?:\\sw\\|\\s_\\)+\\)\\_>"
1 'font-lock-func-face))
'append) ;; <-- Add after all other rules
Is there a way to get ERC to highlight all lines that come in that match a certain regexp? For context, I'm using ERC to connect to a bitlbee server and wish that when I issue a 'blist' command, my friends who are online are highlighted in green and those away are highlighted in red.
With erc come several modules. Customise erc-modules so it contains the match module. Then customise erc-keywords, which can contain regexps and cons cells where the regexp is in the car and the face in the cdr.
Don't know about the regexp to distinguish online and away. Is the output from blist different for both?
Edit:
I can't figure out, how to insert custom faces (I mean not existing symbols like the default face) in the customize buffer. So here it is with setting the variable directly:
(setq erc-keywords '(("online-regexp" (:foreground "green"))
("away-regexp" (:foreground "red"))))
I never used ERC, but highlight regex search in emacs can be actived by M-x highlight-regexp