Re: Changes to hi-lock before release.

[Alan Mackenzie <acm@muc.de>]

Hi, Richard, Chong and Emacs!

On Fri, Apr 20, 2007 at 02:06:14PM -0500, David Koppelman wrote:
> I believe the following changes should be made to hi-lock before
> release. The problem is that hi-lock can automatically add font-lock
> keywords when a buffer is loaded, allowing for some mischief.  The
> patch sets the loading of patterns from files off by default, but
> by setting a variable the user can be prompted or can provide
> a function to determine safety. The user can still add the patterns
> by using a key sequence.

> If font-lock-pattern safety-checking code becomes available later
> I'll use that instead of these changes.

Sorry to come into this thread so late.  I think there're serious
problems with the patched hi-lock-mode (I've just fired up the latest
pretest, 22.0.99): it treats users with less friendliness than they're
entitled to expect:

1: Start emacs -Q
2: Load the following file into Emacs with C-x C-f hilight-test.txt:
#########################################################################
Hi-lock: (("FIXME!!!" (0 (quote hi-yellow) t)))


This line contains a FIXME!!!
######################################################################### 
3: Do M-x hi-lock-mode

Nothing happens.  Zilch.  Sweet Fanny Adams.  What should happen is that
"FIXME!!!" become yellow.  It worked in Emacs 21.  At the very least,
the user should get something in the message area, such as "Hi-Lock:
auto highlighting of patterns disabled".  Surely?

I don't think it's reasonable to expect a normal user to go hunting
through the new Emacs manual or even the doc string (much less the
source code) to diagnose this absence of an informational message.  Many
of them are going to get angry, some of them are going to vent that
anger on help-gnu-emacs, and a fair number of them may feel like calling
us rude names - I, for one, wouldn't blame them.

The description of C-x w b (on page "Highlight Interactively") doesn't
seem to describe accurately what now happens when a file into which
patterns are written later gets visited.

The way I use hi-lock-mode is by having quite a lot of patterns at the
top of a personal log file which highlight things like dates, particular
filenames, "FIXME!!!", and so on.  I expect this kind of usage is quite
common, and have been used to it just working without hassle.  I think,
by contrast, that David (the writer of the patch) and most other people
here have been assuming that storing hi-lock patterns in a file is a
minor, barely used facility.

Why is the default for the new option `hi-lock-file-patterns-policy' set
to nil?  Surely it should be 'ask - MUST be 'ask, otherwise nobody will
know it's there.  Why isn't the value t effective for the variable?  Why
do I have to write

(defun return-t (arg) t)

, and set the hi-lock-file-patterns-policy to that instead?  Is this
some sort of security by obscurity?  I think that hi-lock-mode is one of
relatively few of Emacs's advanced features that will appeal
particularly to non-programmers, and they're going to be less well
equipped to start writing defuns than a typical hacker.  Why are we
imposing this pain on them?

In the doc string fragment "If 'ask, prompt when patterns found in
buffer", I think that "prompt", used as an intransitive verb, is a bad
way of saying "ask the user"; it seems to be an abbreviation of "prompt
the user to anwer a question", but the essence of this fuller version is
the "answer", not the "prompt".  "prompt" (intr) seems to be
subliminally insulting - "nudge you, because you're too thick to see
this on your own".  So I think that should be changed too.

I also think it imperative that the option be a customization variable -
it will be jarring indeed for this isolated option NOT to be
customisable - it might even look like the variable was thrown in in a
hurry at the last moment.  ;-)  However, I don't feel up to learning how
to write defcustoms so late in the evening, so would somebody else be
willing to do this?

I think this situation urgently needs fixing.  For the other things,
I've started writing a patch.  I hope to be able to post it in
emacs-devel in a little over 12 hours time (I'm not hacker enough to go
24 hours without sleep).

-- 
Alan Mackenzie (Ittersbach, Germany).