> While I'm not sure of it since I don't use the adaptive-fill-mode > normally, I found something like a bug. Try the following:
> (with-temp-buffer > (insert-char ?- 70) > (let ((fill-column 70) > (adaptive-fill-mode t)) > (fill-region (point-min) (point-max)))) > => "fill-prefix too long for specified width" > Is it reasonable that the form causes an error? Similar errors > have occurred when decoding the text/enriched MIME messages which > contain long dash lines. The enriched-decode function which runs > fill-region is performed then. Does the patch below fix your problem? > Though we can solve it for that case by binding adaptive-fill-mode > to nil, I'm hesitating to do so. I appreciate any comment. I agree. Binding adaptive-fill-mode to nil is nothing more than a workaround. Stefan --- fill.el 24 mai 2005 15:01:00 -0400 1.176 +++ fill.el 09 jun 2005 14:04:51 -0400 @@ -1,7 +1,7 @@ ;;; fill.el --- fill commands for Emacs -*- coding: iso-2022-7bit -*- -;; Copyright (C) 1985,86,92,94,95,96,97,1999,2001,02,03,2004 -;; Free Software Foundation, Inc. +;; Copyright (C) 1985, 1986, 1992, 1994, 1995, 1996, 1997, 1999, 2001, 2002, +;; 2003, 2004, 2005 Free Software Foundation, Inc. ;; Maintainer: FSF ;; Keywords: wp @@ -205,6 +205,22 @@ (unless (zerop cmp) (substring s1 0 cmp))))) +(defun fill-match-adaptive-prefix () + (let ((str (cond + ;; We don't need to consider `paragraph-start' here since it + ;; will be explicitly checked later on. Also setting + ;; first-line-prefix to nil prevents second-line-prefix from + ;; being used. + ;; ((looking-at paragraph-start) nil) + ((and adaptive-fill-regexp (looking-at adaptive-fill-regexp)) + (match-string-no-properties 0)) + (adaptive-fill-function + (funcall adaptive-fill-function))))) + (if (>= (+ (current-left-margin) (length str)) (current-fill-column)) + ;; Death to insanely long prefixes. + nil + str))) + (defun fill-context-prefix (from to &optional first-line-regexp) "Compute a fill prefix from the text between FROM and TO. This uses the variables `adaptive-fill-regexp' and `adaptive-fill-function' @@ -224,27 +240,13 @@ second-line-prefix start) (setq start (point)) - (setq first-line-prefix - ;; We don't need to consider `paragraph-start' here since it - ;; will be explicitly checked later on. - ;; Also setting first-line-prefix to nil prevents - ;; second-line-prefix from being used. - (cond ;; ((looking-at paragraph-start) nil) - ((and adaptive-fill-regexp (looking-at adaptive-fill-regexp)) - (match-string-no-properties 0)) - (adaptive-fill-function (funcall adaptive-fill-function)))) + (setq first-line-prefix (fill-match-adaptive-prefix)) (forward-line 1) (if (< (point) to) (progn (move-to-left-margin) (setq start (point)) - (setq second-line-prefix - (cond ((looking-at paragraph-start) nil) ;Can it happen ? -stef - ((and adaptive-fill-regexp - (looking-at adaptive-fill-regexp)) - (buffer-substring-no-properties start (match-end 0))) - (adaptive-fill-function - (funcall adaptive-fill-function)))) + (setq second-line-prefix (fill-match-adaptive-prefix)) ;; If we get a fill prefix from the second line, ;; make sure it or something compatible is on the first line too. (when second-line-prefix _______________________________________________ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug