"stephen" == stephen <stephen(a)xemacs.org> writes:
stephen> Nelson Ferreira writes:
> For a long time I have been having a problem with closing some
> buffers. In order to be able to close them I had to manually turn
> off font-lock mode.
stephen> First, let me warn that fast-lock is deprecated and
stephen> unmaintained as far as I know.
Ok. I can live with having my own patched copy.
> - (let* ((bufile (expand-file-name buffer-file-truename))
> + (let* ((bufile (expand-file-name (or buffer-file-truename
> + buffer-file-name)))
stephen> What is the context of this?
This happens for me mostly when using Info and the info file is
compressed. I believe the root cause of this is because the buffer is
not associated with a file name. The issue here seems to be that on
the decompressed bufefr buffer-file-truename is nil and while
buffer-file-name still holds the .gz file name which can be used to
save the font-lock info, but it was not.
This is in the fast-lock-cache-name defun which returns the filename
where the font lock info will be saved. This is _always_ called with a
directory taken of fast-lock-cache-directories, which will be _where_
the cache will be saved.
,----
| `fast-lock-cache-directories' is a variable declared in Lisp.
| -- loaded from "fast-lock"
| | Documentation:
| *Directories in which Font Lock cache files are saved and read.
[...]
`----
stephen> Why does fast-lock need a file name here?
It tries to get the buffer-file-name in order to append a
transformation of it to the directory received as arg and thus
returning a unique filename for that buffer.
stephen> It seems to me that fast-lock is doing something evil in
stephen> depending on the buffer visiting a file; that should be
stephen> checked and fixed, rather than applying a hack that seems
stephen> likely to file up random directories with irrelevant trash.
Well, it is fast-lock's design to use the full path of the file being
visited to lookup and load the font lock info. So changing that is to
fundamentally change the nature of fast-lock.
Still, this hack _will not_ file up random directories because the .flc will
only be saved on one of the directories in fast-lock-cache-directories.
--
Nelson Ferreira
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches