alpaker/fill-column-indicator

An Emacs minor mode that graphically indicates the fill column.

fill-column-indicator's Issues

org-html-export-to-html issues?

Hi,

I'm working with Org mode 8.2.5h and during export to html with fci-mode enabled I get the characters  included in the export which is not expected.

Totally understood that this is not the org-model list, I'm just looking to talk with other fci users who also use org-mode to find out if you faced this and how you resolved it and also wondering where/how we might contribute to tracking down any unexpected behavior.

fci-mode and line-spacing

This may be related to #15, but if line-spacing is non-zero, gaps appear in the FCI between each line of text. (I really like (setq-default line-spacing 2), as it opens up the vertical display of text on the screen.)

Is there either a fix, or another way to specify looser leading that wouldn't clash with FCI?

Display compatibility issue with company-mode

When fci-mode is enabled and a company-mode auto-complete popup shows up, the first completion item is moved beyond the ruler. See screenshot.

incompatibility with yascroll

yascroll together with fci-mode looks like this:

The red bar in the left fringe indicates the portion of the buffer which is visible and is supposed to contain no gaps.

I suspect the reason for the corruption is similar in nature to the problem with linum-mode, see #4.

I don't mind the gaps in the fci that much but hope you can edit fci so that the yascroll bar does not get corrupted.

https://github.com/m2ym/yascroll-el

Visiting tags table in combination with fill column indicator causes Emacs to hang

The following recipe causes Emacs to hang 100%.

1. Start in a mercurial repository directory.
2. Run "emacs -Q -l /path/to/test.el"
3. M-x project-compile-and-visit-tags-table
4. Wait for completion.
5. M-x project-compile-and-visit-tags-table
6. Receive prompt: "Tags file /path/to/TAGS has changed, read new
   contents? (yes or no)"
7. Type "yes"
8. Emacs hangs, must send kill signal to close.

The test.el:

(require 'package)
(add-to-list 'package-archives
             '("melpa" . "http://melpa.milkbox.net/packages/"))
(package-initialize)
(package-refresh-contents)
(package-install 'fill-column-indicator)

(require 'fill-column-indicator)
(setq-default fci-rule-column 80)
(defun fci-mode-on ()
  "Turn fci-mode on."
  (fci-mode 1))
(define-globalized-minor-mode global-fci-mode
  fci-mode
  fci-mode-on)
(global-fci-mode 1)

(defun project-compile-and-visit-tags-table ()
  "Compile TAGS file at the project ROOT directory."
  (interactive)
  (let ((root (project-root)))
    (when root
      (add-hook 'compilation-finish-functions #'project-visit-tags-table)
      (compile (format "ctags -e -R --languages=PHP -o %s %s"
                       (concat root "TAGS") root)))))

(defun project-visit-tags-table (buffer string)
  "Tell tags commands to use tags table at the project root."
  (when (string= string "finished\n")
    (visit-tags-table (concat (project-root) "TAGS")))
  (remove-hook 'compilation-finish-functions #'project-visit-tags-table))

(defun project-root ()
  "Return the project's root directory."
  (locate-dominating-file default-directory ".hg"))

Clash with theming

While it's possible to set the var fci-rule-color within Emacs 24-style deftheme blocks, switching themes does not update the rule color in active buffers.

Consequently, when restoring buffers upon start-up using, e.g. desktop.el, and then applying a preferred theme, all the fill column rules will be the bold default colors. In order to make the change take effect, one must re-open the buffers or reinitialize them (all) with M-x normal-mode.

A workaround might be to note the last-used color, and then to detect changes when redrawing regions or windows, such that the entire rule is redrawn if the desired color has been changed.

Additionally, any changes that would allow the color to be defined in terms of a regular face would make fci-mode more accessible to theme authors; the face could be used as-is when using the rule character, and the foreground color extracted from it when using the xpm image.

If you've any thoughts, I might be able to prepare a pull request.

FCI hangs on git commit on OS X 10.7

When performing a "git commit" from the shell with FCI globally enabled, emacs will hang. Emacs can then be interrupted with C-g, dropping me back to the shell, the process however stays around and burns 100% cpu. For all other tasks FCI works fine for me.

The symptoms are the same as described here: http://www.emacswiki.org/emacs/MarginMode

Happens with:
GNU Emacs 22.1.1 (mac-apple-darwin)
GNU Emacs 23.4.1 (x86_64-apple-darwin11.3.0)

Feature Request / Suggestion -- set multiple vertical lines (e.g., at tab stops).

As a feature request, please consider adding the ability to set multiple vertical lines -- e.g., at tab stops, or at arbitrary user defined settings.

(setq fci-column tab-stop-list)

fci-mode incompatible w/ linum-mode - missing rule

Starting from emacs23 -Q, eval:
(progn
(linum-mode)
(add-to-list 'load-path "~/apps/elisp/fill-column-indicator/")

(require 'fill-column-indicator)
(fci-mode 1))

Note that the rule is broken/missing on the empty line.
(this is emacs23 in ubuntu lucid, 23.1.1, GTK).
Same happens in a tty window (missing rule on empty lines).
Disabling linum-mode makes the rule appear correctly.

Display doesn't update after long movement commands

If I press G to go to the last line in a file, emacs hangs until I enter some command to put me into insert mode, like o for evil-open-below.

If I disable fci-mode, Emacs doesn't hang when I press G.

The offending line of code seems to the (search-forward "\n" end t) at fill-column-indicator.el#L790. In my tests, it stalled right on the while loop test, meaning the following line was never reached.

I'm not sure why it freezes. One workaround I found was to wrap the whole function in:

(when (<= start end)
  ;; rest of function
)

This has the unfortunate side effect of not filling in the columns, but it doesn't freeze emacs.

fci-rule-column doesn'

hl-line-mode drawing on top of fci

I do not know what this is like when using the gui version of emacs but in the console the hi-line-mode draws its color on top of the fci. This makes it appear as if that line is always overextended on the line currently being highlighted.

Rule horizontal location not adjusted text-scale-adjust has been used

If you use text-scale-adjust to make the text in a buffer larger (C-x C-+) or smaller (C-x C-+), the fci-mode rule stays at the same pixel location, which is no longer the same character location. This is true regardless of whether fci-mode is run before or after text-scale-adjust.

FCI hangs on git commit on OS X

When performing a "git commit" from the shell with FCI globally enabled, emacs will hang. Emacs can then be interrupted with C-g, dropping me back to the shell, the process however stays around and burns 100% cpu.

The symptoms are the same as described here: http://www.emacswiki.org/emacs/MarginMode

Happens with:
GNU Emacs 22.1.1 (mac-apple-darwin)
GNU Emacs 23.4.1 (x86_64-apple-darwin11.3.0)

Compatibility with yasnippet

Hi,

when expanding a yas snippet, the rule is also not updated properly. It looks like the display property needs updating but doesn't. Editing anything in the affected lines fixes the issue. Occurred in various versions of Emacs 22 and 23, with the 0.5.3 version of yasnippet

sheijk

show-trailing-whitespace is incompatible with fci-mode

When I turn on fci-mode the red highlighting of trailing white space characters disappears. I use the following in my .emacs:

(setq-default show-trailing-whitespace t)

You can see the effect by toggling fci-mode on and off while viewing a buffer with trailing white space. Here is a sample of my .emacs with a trailing space.

;; We don't want to ever split a window veritcally if we can help it so 
;; we set this value really high
(setq split-height-threshold 999)

Setting fci-rule-column is broken

Setting fci-rule-column in your emacs.d does not seem to take effect, and attempting to customise the variable instead results in the error "read: Invalid function: 0"

GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2)

Issues with 'truncate-lines nil (Wrap at window edge)

I know the instructions warn that Fill-Column-Indicator doesn't work reliably with 'truncate-lines nil, but 'truncate-lines nil is the default and for long lines, it is a pain to not be able to read all text without horizontal scrolling, so it would be desirable if it worked out-of-the-box.

Here http://www.emacswiki.org/emacs/FillColumnIndicator there is a work-around:

(setq-default fci-rule-column 80)
(setq fci-handle-truncate-lines nil)
(add-hook 'after-change-major-mode-hook 'auto-fci-mode)
(add-hook 'window-size-change-functions 'auto-fci-mode)

(defun auto-fci-mode (&optional unused)
  (if (> (frame-width) 80)
      (fci-mode 1)
    (fci-mode 0))
)

The above hack works fairly well, but it fails if I open two files at the same time: emacs test.c test2.c then, the first buffer will have the fill-column-marker, even if the size of the window is less than 80 columns.

Would you accept patches adding this feature?

Should this mode work in log-edit-mode buffers?

Hi,

Emacs 24.3.1
fill-column-indicator-20140425.1205/

After adding a hook for log-edit-mode, I was hoping to see the line on the right, but it was missing. The other modes that use fci work fine, however.

Calling turn-on-fci-mode or fci-mode alone do not make it happen.

Perhaps I am doing something wrong?

What should I check or dig into on this one to figure it out?

Development Emacs moves cursor past the indicator line on empty lines

When using fci-mode (which is awesome, btw) in a development version of Emacs 24.3.50, point moves past the vertical line of fci-mode when the line is completely empty. Newly entered text in the line is inserted correctly at the beginning of the line, and point moves to the right place. In non-empty lines, all looks correct.

fci-mode throws errors if an overlay's 'face isn't a face

According to http://www.gnu.org/software/emacs/manual/html_node/elisp/Overlay-Properties.html the value of an overlay's 'face property may be a property list or simply a cons cell. If this is done (e.g. I set my 'hl-line face to be just a cons cell) then fc-overlay-fills-background-p will cause an error when it uses face-attribute. fci-mode appeared to still work and the large number of error messages didn't appear to slow down Emacs, but I could see this causing trouble.

Outdated repo version

I installed fill-column-indicator using the Emacs 24 package manager, and got version 0.40, which is horribly outdated. I don't know who is responsible for putting such an old version into the package repository, but maybe you could look into that?

Clash with isearch in certain circumstances

Scenario: editing the following code, with fci enabled (and fill column at 80):

      (funcall (if backward
                   'isearch-backward
                 'isearch-forward)
               nil t))))

Now place the cursor after the final closing paren, then use C-r to isearch-backward for i. The result is that the cursor jumps forward to the column after the fill indicator. The expected behaviour is that the cursor should remain where it was.

Emacs 24.3 previous-line on empty line moves pointer up two lines

With version 1.84 in Emacs 24.3 on Mac OS X 10.8.3 previous-line (via or C-p) on an empty line moves the pointer up twice (to the previous, previous line).

FR: allow automatic enabling globally or per-mode

It should be possible to M-x customize-variable in order to automatically enable the minor mode for all buffers, or for all buffers whose modes are in a given list. This would work similarly to how whitespace-mode provides global-whitespace-mode and whitespace-global-modes.

Makes emacs really slow

Hi, i noticed that when using Fill-Column-Indicator version 1.84 (not sure about prev versions), that my emacs starts to become a bit slower initially, and then really slow as time goes on. For example scrolling 700 lines (even much less) will scroll slowly, forcing for me to wait till it finishes scrolling. When not using this library, my emacs scrolling is near instant.

Here is my code that I use:

(require 'fill-column-indicator)
;;(setq fci-rule-image-format 'pbm) ;;tried this, but made no difference
(setq fci-rule-column 80)
(setq fci-rule-width 1)
(setq fci-rule-color "grey")
(add-hook 'after-change-major-mode-hook 'fci-mode)

This library is really useful, so I hope you can find the problem.

(Btw my computer uses an integrated intel graphics, if that means anything.)

edit:
Seems using fci-always-use-textual-rule only slows it by a small bearable amount.

(fci-mode 0) before (fci-mode 1) errors

First block below shows that running (fci-mode 0) before the first (fci-mode 1) raises an error. Second block shows (fci-mode 1) first raises no error.
(fci-mode 0) ought to be a no-op when fci-mode hasn't been activated in the buffer.
(as a workaround, I just replaced my calls to (fci-mode 0) with
(when (member 'fci-mode minor-mode-list) (fci-mode 0))

$ emacs23 -Q -nw --eval '(progn (toggle-debug-on-error) (load-library "'`pwd`'/fill-column-indicator.el") (fci-mode 0))' --batch
Debug on Error enabled globally
Loading /home/fischman/apps/elisp/fill-column-indicator/fill-column-indicator.el (source)...
Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  aset(nil 10 nil)
  fci-restore-display-table()
  (if fci-mode (condition-case error (progn ... ... ... ... ... ... ... ... ...) (error ... ...)) (fci-restore-display-table) (fci-restore-local-vars) (remove-hook (quote post-command-hook) (function fci-full-update) t) (fci-delete-overlays-buffer) (setq fci-column nil fci-limit nil fci-tab-width nil fci-char-width nil fci-char-height nil fci-buffer-windows nil fci-pre-limit-string nil fci-at-limit-string nil fci-post-limit-string nil))
  (let ((last-message ...)) (setq fci-mode (cond ... ... ...)) (if fci-mode (condition-case error ... ...) (fci-restore-display-table) (fci-restore-local-vars) (remove-hook ... ... t) (fci-delete-overlays-buffer) (setq fci-column nil fci-limit nil fci-tab-width nil fci-char-width nil fci-char-height nil fci-buffer-windows nil fci-pre-limit-string nil fci-at-limit-string nil fci-post-limit-string nil)) (run-hooks (quote fci-mode-hook) (if fci-mode ... ...)) (if (called-interactively-p) (progn nil ...)))
  fci-mode(0)
  (progn (toggle-debug-on-error) (load-library "/home/fischman/apps/elisp/fill-column-indicator/fill-column-indicator.el") (fci-mode 0))
  eval((progn (toggle-debug-on-error) (load-library "/home/fischman/apps/elisp/fill-column-indicator/fill-column-indicator.el") (fci-mode 0)))
  command-line-1(("--eval" "(progn (toggle-debug-on-error) (load-library \"/home/fischman/apps/elisp/fill-column-indicator/fill-column-indicator.el\") (fci-mode 0))"))
  command-line()
  normal-top-level()

$ emacs23 -Q -nw --eval '(progn (toggle-debug-on-error) (load-library "'`pwd`'/fill-column-indicator.el") (fci-mode 1) (fci-mode 0))' --batch
Debug on Error enabled globally
Loading /home/fischman/apps/elisp/fill-column-indicator/fill-column-indicator.el (source)...

reference to free variable `fci-padding-display'

Could you please fix this warning.

fill-column-indicator.el:655:54:Warning: reference to free variable
    `fci-padding-display'

fci-mode incompatible w/ linum-mode - first char of line appears indented

In emacs23 -Q paste the following into the bottom of the scratch buffer (which will cause an empty line between the boilerplate contents of that buffer and this snippet; this is important):
(progn
(column-number-mode)
(linum-mode)
(add-to-list 'load-path "~/apps/elisp/fill-column-indicator/")
(require 'fill-column-indicator)
(fci-mode 1))
Position point at the end of the snippet and eval it (c-x c-e).
Click mouse on the empty line (line 4) between the boilerplate and the snippet.
Notice that point appears to be in column 2 (instead of 0), even though column-number-mode in the modeline confirms it is at logical column 0.

fci-mode allows point to be placed on the rule

Starting from emacs23 -Q eval this snippet:
(progn
(add-to-list 'load-path "~/apps/elisp/fill-column-indicator/")
(require 'fill-column-indicator)
(fci-mode 1))
Position point at the beginning of the last line and hit the left arrow.
Point is placed at the rule instead of on the last character of the (require...) line.
Similarly C-e places point on the rule.

It would be much nicer if the visual presence of the rule didn't interact with point/navigation.

Issues with Wind Move

Using Emacs 24.3.1 (on Fedora 20), and the fill-column-indicator snapshot from 7 August 2013 from Melpa and the following config (tested with emacs -Q --load test.el to make sure no site-settings were interfering):

(add-to-list 'load-path "~/.emacs.d/elpa/fill-column-indicator-20130807.919")
(require 'fill-column-indicator)

(when (fboundp 'windmove-default-keybindings)
  (windmove-default-keybindings))

(split-window-right)

(This only happens with a split-window-right, not a split-window-down).

Load a file (e.g. the init file) into the right-hand window. Position the cursor (e.g. with the mouse) at the end of a line (e.g. at the end of the second line; the first may not cause this issue as it extends past the default line that fill-column-indicator draws). Hitting S-left will cause the cursor to move to the left window (as expected). Hit S-right to go back to the right window.

Now back in the right window, do a M-x turn-on-fci-mode and try doing S-left again: an error comes up:

posn-col-row: Wrong type argument: windowp, #<frame emacs@mycomputer 0x8527bc8>

Turning off fci-mode restores the expected behaviour.

This only seems to occur when the cursor is at the end of a line (including an empty line). There are a few cases where it doesn't (e.g. the last line if the file doesn't end in an empty line, or one of the first two lines in the default scratch buffer) but I haven't managed to work out why yet.

But if the cursor is in the middle of a line then it works as expected.

OSX 23.2: two issues with fci-osx-23-fix.el

This looks like a great package. Thanks for putting it out.

I'm still using 23.2 sometimes on Mac OS X (10.5), so I loaded fill-column-indicator.el and fci-osx-23-fix.el
as instructed. But fci-mode raised an error.

There appear to be too problems, but keep in mind that I only took a quick look, so this diagnosis
should probably be checked.

First, the variable fci-newline-sentinel is not defined; I saw no definition or mention of the variable
in either file except where it is used in fci-nextstep-23-hack.

Second, the form

(add-to-list 'fci-hook-assignments
             '(post-command-hook . fci-nextstep-23-hack))

fails listp at line 497 in fill-column-indicator when (nth 1 ...) is called on the cons.
I think eliminating the . (making the cons-pair a list) will solve the problem.

When I added

(defvar fci-newline-sentinel nil)

and removed the . in the above cons, the mode worked properly,
at least so far.

Thanks again!

Feature req: multiple column indicators and relative offsets

I could use several simultaneous rules: one for the current fill column, one for the 80 character limit (because some people and file formats insist on that) and my preferred 120 character limit.

For reference, vim 7.3 has released a column indicator option that can take an arbitrary number of columns and supports offsets from textwidth (the analog of fill-column):

https://code.google.com/p/vim/source/browse/runtime/doc/options.txt#1547

Thanks!

Broken display when display table customised by another package

I just wrote page-break-lines.el, which modifies the display table entry for the ^L char in order to display a neat horizontal rule -- I borrowed this approach from an emacswiki article.

However, when my display table change is in effect at the same time as fci-mode, all the newline characters are displayed as a random unicode placeholder. I think that somehow either fci-eol-char or fci-blank-char gets displayed literally. Any guesses at what might be causing this?

-Steve

Compatability with hl-line-mode

I am not sure if this is considered a bug exactly, but the behavior isn't what I would expect. When fci-mode and hl-line-mode are both enabled, the indicator is not visible on the currently highlighted line. It appears that the indicator is rendered "behind" the highlighted line.

STR:

1. Start emacs with "emacs -Q some-file.txt"
2. M-x hl-line-mode
3. M-x package-initialize (to get fci-mode in load path)
4. M-x fci-mode
5. Move point up an down lines

This behavior is contrary to other editors (compare to gedit). In other editors the indicator is always visible above the other UI elements even the highlighted line.

Feature Request -- current-column / visual-line-mode

As a feature request, please consider adding support for the current column with visual-line-mode enabled.

fill column indicator causes arrow fringe indicators on every line.

Hello,

This is how it looks without fill-column-indicator:

This is how it looks with fill-column-indicator (every line ending has an arrow fringe indicator)

This is the code I am using to enable fill-column-indicator.
(require 'fill-column-indicator)
(define-globalized-minor-mode global-fci-mode fci-mode fci-mode)
(setq fci-rule-color "darkred")
(global-fci-mode)
;; (fci-mode)

Just wanted to check if this is fixable.

Thanks
Joe

Issues with web-mode

Disclaimer: not sure if a fill-column-indicator bug or a web-mode one.

I have a problem when editing files in web-mode with fci-mode active: there are operations that trigger a strange bug where the cursor goes to the fci-column.
For example:

• C-j at the end of a line creates a newline and positions the cursor to column 80 (or I guess whatever the set column is)
• auto tag closing (e.g. typing < when there is an open tag) closes the tag at column 80
• ...probably others.

Emacs 24.3.1
fill-column-indicator 20140302.1809
web-mode 20140413.1309

relevant configuration in init.el:

(require 'fill-column-indicator)
(setq fci-rule-column 80)
(add-hook 'after-change-major-mode-hook 'fci-mode)

(require 'web-mode)
(add-to-list 'auto-mode-alist '("\\.html$" . web-mode))
(defun my-web-mode-hook ()
  "Hooks for Web mode."
  (setq electric-indent-mode nil)
  (setq web-mode-markup-indent-offset 2)
  (setq web-mode-css-indent-offset 4)
  (setq web-mode-code-indent-offset 4)
  (setq web-mode-script-padding 2)
)
(add-hook 'web-mode-hook 'my-web-mode-hook)

fill-column-indicator causes C-p to skip lines (even when line-move-visual is nil)

This happens with Emacs 24.3 from emacsforosx.com (haven't tested on other platforms) both -nw and windowed.

Repro from emacs -Q:
0. Obtain fill-column-indicator. I'm using version 20130126.1540 from Melpa.

1. (add-to-list 'load-path "/path/to/fill-column-indicator-20130126.1540/")
2. (require 'fill-column-indicator nil t)
3. Create new buffer in fundamental mode
4. M-x turn-on-fci-mode
5. Type the below text until EOF, preserving newlines.
6. Place cursor on "Start here" line, then hit C-p. Behavior will match what
   the text says.
7. verify describe-variable line-move-visual is nil

C-p will skip

C-p will land here
C-p will skip

Start here

EOF

issue with using TeX input-method

I understand that it's not recommended to use fci-mode with non-ascii characters. But I'm wondering whether there can be a quick-fix for the problem that I have.

Symptom

I try to input 'λ' using TeX input-method. When I type "\lambda", it shows the intermediate text after the FCI.

                                                                                 |\lamb

Once it's completed, emacs puts 'λ' back into the point where cursor is at.

λ                                                                                |

How to reproduce

• enable fci-mode
• set-input-method RET TeX
• Type "\lambda"

Interestingly, if I type something in the middle of a line, there is no problem. This problem only happens when I type at the end of a line.

Compatibility with auto-complete

When using auto-complete, the code hints of auto-complete become garbled, like shown in the screenshot below:

When disabling fci-mod, the bug disappears:

fci-mode interacts poorly with longlines-mode

Starting from emacs23 -Q eval'ing this:
(progn
(add-to-list 'load-path "~/apps/elisp/fill-column-indicator/")
(require 'fill-column-indicator)
(switch-to-buffer "test.txt")
(dotimes (i 20) (insert (make-string 10 ?x) " "))
(fci-mode 1)
(longlines-mode 1)
(move-beginning-of-line 1))

results in no fci rule being rendered.
Switching the order of the fci-mode & longlines-mode invocations results in the rule being displayed correctly.
Toggling fci-mode twice with the above snippet, results in the rule being displayed correctly.

Starting from a clean emacs23 -Q and executing a slightly more complex dance:
(progn
(add-to-list 'load-path "~/apps/elisp/fill-column-indicator/")
(require 'fill-column-indicator)
(switch-to-buffer "test.txt")
(dotimes (i 20) (insert (make-string 10 ?x) " "))
(fci-mode 1)
(longlines-mode 1)
(fci-mode 0)
(fci-mode 1)
(longlines-mode 0)
(move-beginning-of-line 1))

results in a single long line (b/c we end up disabling longlines-mode above), but instead of having the strings of x's separated by a single space, and no fci rule being displayed (b/c the line violates fill-column), the first 6 strings of x's are followed by ~6 spaces, an fci rule, a space, and the next string of x's. This repeats (you might need to use a tiny font or a very wide screen/window to see this). Various point motion sequences such as M-> make the fci rule(s) disappear.

incompatibility with emacs-24.3

With emacs-24.3 and enabled fci-mode, the previous-line function (key-up) skips single, non empty lines.

E.g.

$ emacs -nw -Q
M-x load-file fill-column-indicator.el
C-x C-f /tmp/foo
--> fill with the folllowing 5 lines

A

B

C

M-x goto-line 4 (--> cursor is in line between B and C)
M-x fci-mode

--> you are in the line between A and B but not in B as expected.

Things work as expected with emacs-23.1.1

Lint warnings

FYI, The following warnings are displayed for the *.el file

*** Lint Emacs 24.3.1 2013-09-05 00:36:16 file: fill-column-indicator.el
** Lint M-x lm-verify (list-mnt.el)
Missing: ;; Maintainer:
Missing: ;; URL:
Missing: ;;; History:
** Lint M-x checkdoc-current-buffer (checkdoc.el)
fill-column-indicator.el:221: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:230: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:242: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:252: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:273: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:282: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:304: Lisp symbol `truncate-lines' should appear in quotes
fill-column-indicator.el:315: Lisp symbol `line-move-visual' should appear in quotes
fill-column-indicator.el:409: Argument `all-frames' should appear (as ALL-FRAMES) in the doc string
fill-column-indicator.el:516: Argument `blank' should appear (as BLANK) in the doc string
fill-column-indicator.el:516: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:595: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:603: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:630: Argument `body' should appear (as BODY) in the doc string
fill-column-indicator.el:647: Arguments occur in the doc string out of order
fill-column-indicator.el:651: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:672: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:695: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:743: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:748: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:753: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:770: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:782: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:800: Argument `_ignored' should appear (as _IGNORED) in the doc string
fill-column-indicator.el:800: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:810: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:817: Argument `start' should appear (as START) in the doc string
fill-column-indicator.el:817: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:840: Argument `start' should appear (as START) in the doc string
fill-column-indicator.el:840: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:845: Argument `all-frames' should appear (as ALL-FRAMES) in the doc string
fill-column-indicator.el:845: Lisp symbol `fill-column' should appear in quotes
fill-column-indicator.el:850: Lisp symbol `fill-column' should appear in quotes

Make fci-mode coexist better with line-move-visual

I'm interested in isolating and fixing whatever prevents line-move-visual from behaving as expected when fci-mode is on. Do you have more information on what part of the C implementation behaves badly with fci-mode and line-move-visual?

Background:

The README says:

If line-move-visual is t, then vertical navigation can behave oddly in several edge cases while fci-mode is enabled (this is due to a bug in Emacs's C code). Accordingly, fci-mode sets line-move-visual to nil in buffers in which it is enabled and restores it to its previous value when disabled. This can be suppressed by setting fci-handle-line-move-visual to nil. (But you shouldn't want to do this. There's no reason to use line-move-visual if truncate-lines is t, and it doesn't make sense to use something like fci-mode when truncate-lines is nil.)

This is a small test case that shows the unexpected behavior:

$ open -n -a Emacs --args -Q --no-site-file --eval '(progn (load-file "fill-column-indicator.el") (fci-mode) (set-variable (quote line-move-visual) t) (insert "\n\n  \n") (goto-line 2) (move-beginning-of-line nil) (next-line) (what-cursor-position))'

Observe that the point lands in column 2 in the above example, whereas without line-move-visual, it lands in column 0 as expected:

$ open -n -a Emacs --args -Q --no-site-file --eval '(progn (load-file "fill-column-indicator.el") (fci-mode) (insert "\n\n  \n") (goto-line 2) (move-beginning-of-line nil) (next-line) (what-cursor-position))'

Changing tab-size results in rule moving

I have a C++ source file open and the indicator is appearing fine in rule mode. I then adjust the tab-size in my buffer and the rule moves, becoming jagged, in each line that had a tab. Adding and removing a space from each affected line gets the rule to reset.

Before Example:

int add(int a, int b) {           |
  int ret = a + b;                |
  return ret;                     |
}                                 |

After Example:

int add(int a, int b) {           |
    int ret = a + b;                |
    return ret;                     |
}                                 |

Compatibility with whitespace mode (in Emacs 23)

fci-mode does not play nicely with the whitespace mode of Emacs 23:

1. M-x, fci-mode
2. M-x, whitespace-mode
3. M-x, whitespace-toggle-options, S
4. M-x, whitespace-toggle-options, N
   When pressing ? in whitespace-toggle-option the N,B,S options on the bottom should be marked

Now between the last character of a line and the fill-column non-existing spaces are highlighted and all end-of-line-markers appear after the fill-column.

Tried using GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)

remove no-longer-live windows before using them

Starting a week or so ago I started getting lots of errors raised by fci apparently triggered by attempting to delete unneeded rules in no-longer-live windows. The following diff seems to fix it (though I never had a reliable repro case, so not sure).

diff --git a/fill-column-indicator.el b/fill-column-indicator.el
index fa18d69..1b648bc 100644
--- a/fill-column-indicator.el
+++ b/fill-column-indicator.el
@@ -653,7 +653,7 @@ file.  (See the latter for tips on troubleshooting.)"
   (let ((olays (fci-get-overlays-region (point-min) (point-max)))
         (ranges (mapcar #'(lambda (w)
                             (cons (window-start w) (window-end w t)))
-                        fci-buffer-windows))
+                        (remove-if-not 'window-live-p fci-buffer-windows)))
         pos)
     (dolist (o olays)
       (setq pos (overlay-start o))

Underline in commit message becomes a full line

As you can see on http://screencast.com/t/aLC1c1WnFQwA, when fci-mode is enabled, the underline Under the subject of the commit message (Emacs 24.4) becomes a full line.

Minor.

semantic (CEDET) symbol completions appear to right of fci's line

On OS X using 23.2 with the fix (changed as I described in a previously raised issue),
completion suggestions made by semantic (within the CEDET package, version 1.0)
appear to the right side of the fci produced line rather than at the end of the symbol
being completed.

I haven't had a chance yet to test this on emacs 24 to see if it is specific to 23.1-23.2,
but I'll try to do that soon. Thought I'd let you know in any case.

Regards