Fast lock mode issue

[Nelson Ferreira]

"stephen" == stephen  <stephen at 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