bug#17021: 24.3.50; extension to hi-lock.el

[hw]

On Thu, 2020-08-13 at 16:46 -0500, David Koppelman wrote:
> I've looked at the patch, but haven't tried to apply it to the current
> hi-lock. There are two things that need to be addressed before I would
> be happy with it landing.
> 
> First, this patch should not include the code for highlighting global
> variables, function-like text, and constants. (Perhaps this code was
> included by accident.) Those situations are best handled by the
> font-lock modes for specific languages.
> 
> Second, I don't feel comfortable reading a pattern file path from
> within the file being visited. Instead, some kind of identifier could
> be read from the file, such as xyz-report-patterns. That identifier
> would then be used to locate patterns from a file in some default
> location, such as ~/.emacs.d/hi-lock-patterns, or it could be used to
> construct a file name (but not a path) that would be expected in some
> directory, such as ~/.emacs.d/hi-lock-patterns/.
> 
> David Koppelman

It's been a long time that I've been using this extension.  Using a default
location may be a nice option, and I definitely wouldn't want to enforce it
and wouldn't suggest it, either:

When you have a (source) file or a number of (source) files in a directory
(structure) highlighting patterns should be applied to, you probably want
to keep the pattern file(s) together with the source file(s) --- or at
least within the same directory structure.  If you somehow distribute the
source files and/or have them under version control, you are facing the
problem of how to distribute the pattern files along with the source files
when you have a bunch of unrelated pattern files together with relevant
pattern files all in the same default location (i. e. some directory
somewhere else).  And if you use the same pattern files for multiple
projects, you don't want the pattern files used by project A altered when
you revert to a previous commit of project B or when you merge changes to
project C just because all the pattern are at the same default location.

Recipients of the files may not even have a default location required for
this to work, especially when the recipients are using operating systems
that would use entirely different paths for the pattern files.  Files at a
default location might be overwritten.  All this could make it difficult to
use a default location for pattern files and to maintain the necessary
assignments between source files and pattern files.

After all this time, the first thing that comes to mind for storing the
patterns is now an SQL database ...