Aspell can't currently do that. Adding an option to do so won't be
difficult but it will involve an API change to the C API. Most likely an
additional function. The other alternative would be to add another
config options. In any case it's not likely to appear until the next
I know that checkdoc is not expected to be fool-proof, but perhaps
one of these minor problems could be corrected.
1. Checkdoc does not recognize this footer, for file
foo+.el. Presumably the problem is the plus sign.
;;; foo+.el ends here
It even gives you an error on the footer that it adds
`describe-variable' called on the variable `dired-marker-char'
creates links to unrelated functions `mark' and `do' (when cl-macs
is loaded).
,
| dired-marker-char's value is 42
| Automatically becomes buffer-local when set in any fashion.
|
| In Dired, the current mark character.
| This is w
> 1) Start with emacs -Q
> 2) Put this code in a buffer:
>
> (defun url-dl-callback-save(to-file url)
> (when (= 0 (buffer-size)) (url-dl-do-redir)))
> (goto-char (point-min))
> (let ((redirsts (search-forward-regexp
> "\\(300\\|301\\|302\\|307\\|303\\)" 20 t)))
>))
>
> 3) M-x eval-buffer
>
The docstring of the variable `fringe-mode' mentions the function
`toggle-fringe', but there is no such function in the whole Emacs
source tree. Is it an unimplemented function, or what?
--
Juri Linkov
http://www.jurta.org/emacs/
___
Emacs-pretest-b
> On Sun, 3 Jul 2005 15:40:22 +0100, David Reitter <[EMAIL PROTECTED]> said:
> The following:
> (create-fontset-from-mac-roman-font "-*-bitstream vera sans
> mono*-medium-r-normal-*-14-*-*-*-*-*-mac-roman" nil "test1")
> goes through without complaining, but when the actual font is chos
> The `menu' face does not seem to have any effect at all, in MS
> Windows. For example, set-face-foreground does nothing.
>
> Is this normal? If so, shouldn't it be documented?
Yes it is normal, customization of menu bar colors is a system wide
option on Windows. I beleive
"Drew Adams" <[EMAIL PROTECTED]> writes:
> The `menu' face does not seem to have any effect at all, in MS
> Windows. For example, set-face-foreground does nothing.
>
> Is this normal? If so, shouldn't it be documented?
Yes it is normal, customization of menu bar colors is a system wide
option on
The `menu' face does not seem to have any effect at all, in MS
Windows. For example, set-face-foreground does nothing.
Is this normal? If so, shouldn't it be documented?
In GNU Emacs 22.0.50.2 (i386-mingw-nt5.1.2600)
of 2005-04-16 on LAPTOP
Distributor `Microsoft Corp.', version 5.1.2600
config
Does this fix it right?
*** tpu-edt.el 17 May 2005 17:21:37 -0400 1.38
--- tpu-edt.el 03 Jul 2005 15:20:21 -0400
***
*** 341,347
"Maps the function keys on the VT100 keyboard preceded by GOLD-SS3.")
(defvar tpu-global-map nil "TPU-edt global keymap.")
! (defv
"Chong Yidong" <[EMAIL PROTECTED]> writes:
> I have not tested this on GNU/Linux, but the Windows build silently
> discards some of the text copied onto the clipboard when there are too
> many lines. I think this problem first appeared a couple weeks ago. To
> reproduce:
I cannot reproduce this n
If this is still failing, could you possibly look at the data
that r_alloc_free is operating on, and figure out what is
invalid in that data? That is the necessary first step
for debugging this.
(Please forgive the delay--I got backlogged.)
___
Emacs-
The following:
(create-fontset-from-mac-roman-font "-*-bitstream vera sans
mono*-medium-r-normal-*-14-*-*-*-*-*-mac-roman" nil "test1")
goes through without complaining, but when the actual font is chosen
for a frame (via menu), I get an "Font not found" error.
This, however,
(cr
$B7k:'@83h$KK~B-$7$F$$$k1|MM$,[EMAIL PROTECTED]&$+!#(B
$B2H;v$r$7$F0i;y$r$7$F!"=w$O$=$3$G=*$o$j$J$s$G$7$g$&$+!#(B
$B$=$s$J1|MM$N$?$a$KMQ0U$5$l$?Ev%5%$%H!#(B
$B$7$+$7$J$,[EMAIL PROTECTED],ITB-$.$_$G$9!#(B
$B!Z(B $B1|MM>R2p=j$h$jL5NA>R2p$N$*CN$i$;(B $B