3

I'm trying to use a fixed width font when in org-mode's column view (I use variable width font otherwise). Customizing the org-column face attribute doesn't seem to do it. How can I get this to work?

There's some related discussion out there (referenced in Org-mode FAQs), but it doesn't seem to help my situation. I'm thinking this excerpt from the documentation is the key, but I'm not sure how.

Face: org-column (sample) (customize this face)

Documentation: Face for column display of entry properties. This is actually only part of the face definition for the text in column view. The following faces apply, with this priority.

  1. The color of the reference face. This is normally the level fact that is used in the outline. In agenda-mode, it will be the face of the first character in the line. The color is explicitly retained to make sure that the column line still looks a bit like the structure line it is masking.

  2. The `org-column' face.

  3. The remaining properties of the reference face.

Since column view works by putting overlays with a display property over individual characters in the buffer, the face of the underlining character (this might for example be the a TODO keyword) might still shine through in some properties. So when your column view looks funny, with "random" colors, weight, strike-through, try to explicitly set the properties in the `org-column' face. For example, set :underline to nil, or the :slant to `normal'.

Under XEmacs, the rules are simpler, because the XEmacs version of column view defines special faces for each outline level. See the file `org-colview-xemacs.el' in Org's contrib/ directory for details.

Defined in `org-faces.el'.

           Family: Lucida Console
          Foundry: unspecified
            Width: unspecified
           Height: 120
           Weight: normal
            Slant: normal
       Foreground: unspecified
DistantForeground: unspecified
       Background: grey90
        Underline: nil
         Overline: unspecified
   Strike-through: nil
              Box: unspecified
          Inverse: unspecified
          Stipple: unspecified
             Font: unspecified
          Fontset: unspecified
          Inherit: unspecified

If it helps, I'm running Emacs 24.5 windows version on Mac OS X.

EDIT When I call the function that has the default keybinding C-u C-x = (I don't know the function's name) with my point in the org-column view region I get the following (excerpt):

There is an overlay here:

From 24 to 25

display [Show] face ((:foreground unspecified) (:height 120 :family >"Helvetica") org-agenda-column-dateline org-agenda-date-today) keymap [Show] line-prefix "" org-columns-format "%-70.70s | " org-columns-key "ITEM" org-columns-pom nil org-columns-value "Saturday 6 June 2015" org-columns-value-modified "Saturday 6 June 2015" wrap-prefix ""

Where does emacs invoke this overlay? It looks like it's calling the Helvetica font family in the face--this is precisely what I'm trying to prevent. I believe this is what is overruling the Lucida Console family that I defined for the org-column face (above).

kgo
  • 532
  • 3
  • 15
  • In general, if you set a face, it is set globally for every buffer in an Emacs session. I would suggest that you look into using the `org-agenda-mode-hook` with `face-remap-add-relative`: http://emacs.stackexchange.com/a/7283/2287 And, you'll need to add some conditions if you only want it to apply to *certain* org-agenda buffers (but not all). Here is another example using a hook for an unrelated mode: http://stackoverflow.com/a/28008006/2112489 – lawlist Jun 06 '15 at 20:14
  • That's a really good point. I'll go back and revise how I request face modifications. For specific modes I generally use a hook (e.g., `(add-hook 'org-agenda-mode-hook ...)`) to call an interactive function to edit the `buffer-face-mode-face` variable. For specific characteristics of a mode (e.g., `'org-table`), I use `(set-face-attribute 'org-table nil :foreground ...)`. For the issue at hand, I edited my original post to help clarify my question. I think the 'overlay' emacs adds is my problem and I'd like to find out how to edit that. – kgo Jun 07 '15 at 01:03
  • Perhaps you could try placing your cursor at the location of the text you want to change the appearance of and type `C-u C-x =` -- that will to you what faces, text properties and overlays are present. You can then proceed to alter those characteristics as you desire. The aforementioned keyboard shortcut is running the function `what-cursor-position` -- the prefix argument causes additional details to be displayed. You may also want to consider looking at the `'default` face for the entire buffer. – lawlist Jun 07 '15 at 01:08
  • Thanks, @lawlist. I just finished editing my original question that I referenced prematurely in my first comment. How might I go about preventing that face overlay (i.e., "Helvetica" font family)? I think that's what is messing up my font. – kgo Jun 07 '15 at 01:25
  • 1
    If I had to take a semi-researched *guess*, I would *guess* that your `'default` face is being used here and the function responsible for that behavior is `org-columns-display-here`. If you decide that this is the case, then consider creating a new function with the exact same name and modifying it to suit your needs -- you will want to precede your new function with the same name by a `require` statement so that you can redefine it -- i.e., `(require 'org-colview) (defun org-columns-display-here (&optional props dateline) . . .` :) – lawlist Jun 07 '15 at 02:32
  • Note, if the `'default` face is being used by `org-columns-display-here` and *if* you believe that is responsible for the behavior you wish to avoid, then the second link in the first comment may be all that you need -- i.e., `face-remap-add-relative` can change the `'default` face for the current buffer. The reference you mentioned to `buffer-face-mode-face` is likely using the same underlying concept -- i.e., `face-remapping-alist`. – lawlist Jun 07 '15 at 02:37
  • Alright, @lawlist is completely correct. Function `org-columns-display-here` in `org-colview.el` defines the overlay's face properties. By removing that function's explicit definition of the `:family` face attribute my modifications to `org-column` (i.e., `(set-face-attribute 'org-column nil :family ...)`) are now showing through. So I could copy the contents of that function, minus the problematic parts, and create a new function in my .emacs file (in accordance with the above suggestion)? And this fix should persist with future version updates? – kgo Jun 08 '15 at 18:26
  • In general, the require statement (for the library containing the function at issue) *followed by* a newly defined function *with the same name* is the preferred method for altering substantive components of an existing function -- this is not a situation (in my opinion) where advice should be used. I do not have a crystal ball to see whether the authors of this library will change the arguments or contents of the function at issue. In life, situations change and we adapt as needed. :) – lawlist Jun 08 '15 at 19:36
  • Great. Thank you so much for your help and advice, @lawlist! My problem is solved (for now). – kgo Jun 08 '15 at 19:58

1 Answers1

2

The primary function responsible for the behavior described by the original poster is located within the org-colview.el library, and is called org-columns-display-here. The function at issue can be found in the source code by typing M-x find-function RET org-columns-display-here RET after first having loaded the org-colview.el library -- e.g., M-x eval-expression RET (require 'org-colview) RET. The faces and individual attributes at issue are hard coded.

If the original poster decides to modify the function directly, the function can be copied and pasted to the .emacs file with a preceding require statement for the library where the original function is located. Although the internal workings of the function may be modified by the original poster, the original function will maintain its original name -- e.g., (require 'org-colview) (defun org-columns-display-here (prefix-descriptions) . . . ).

Options include, but are not limited to, hard-coding different faces and/or individual attributes defined by the original poster, changing the global settings for the existing faces used by the function (e.g., 'default), or including code to use the existing faces (e.g., 'default) on a buffer-local basis (with different attributes) with something like face-remap-add-relative, the documentation for which is at the following link: http://www.gnu.org/software/emacs/manual/html_node/elisp/Face-Remapping.html

lawlist
  • 18,826
  • 5
  • 37
  • 118