From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: hw Newsgroups: gmane.emacs.bugs Subject: bug#17021: 24.3.50; extension to hi-lock.el Date: Sun, 16 Aug 2020 19:49:38 +0200 Message-ID: References: <87mwgp1mq4.fsf@yun.yagibdah.de> <877du2g7jj.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4771"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.4 (3.36.4-1.fc32) Cc: Lars Ingebrigtsen , koppel@ece.lsu.edu, stefankangas@gmail.com To: 17021@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 16 19:50:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k7MnL-00018X-UP for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Aug 2020 19:50:11 +0200 Original-Received: from localhost ([::1]:39002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7MnK-0002Dy-Fb for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Aug 2020 13:50:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7MnC-0002Dd-R6 for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2020 13:50:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46871) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k7MnC-000217-HF for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2020 13:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k7MnC-0007OZ-Fw for bug-gnu-emacs@gnu.org; Sun, 16 Aug 2020 13:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: hw Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Aug 2020 17:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17021 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo patch Original-Received: via spool by 17021-submit@debbugs.gnu.org id=B17021.159760019328408 (code B ref 17021); Sun, 16 Aug 2020 17:50:02 +0000 Original-Received: (at 17021) by debbugs.gnu.org; 16 Aug 2020 17:49:53 +0000 Original-Received: from localhost ([127.0.0.1]:58417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k7Mn3-0007O8-GX for submit@debbugs.gnu.org; Sun, 16 Aug 2020 13:49:53 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.22]:27368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k7Mn1-0007Ny-91 for 17021@debbugs.gnu.org; Sun, 16 Aug 2020 13:49:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1597600189; s=strato-dkim-0002; d=adminart.net; h=References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=i0uCVTP/HbV80cLxy101mSfR0q9WUqZljVmbaTYbPBU=; b=SBWeGRIpgmLFeYSa388r+aaPVWaEciP9B4I05GId+dy45RcuF0vV51dv1JvYb3bYeb H5tBEU05EofnPlnIragTENrK2uuUMyk2wlbFjIJ3xRGf4qgHrCpmoEqSghm69HvU/8/b L+tuCFIIzOOCtXYvgGap9gMfn/gqVzYgY7EK9XrqocRajBCnCDDcMKKZ1UTFSMnh79c+ EnzIaC4KM0l9IBljF6SIC7Qw/lGBOc2BxjdHUR/oRcfmMeOZKKjxW1H2ACYXgcICPBR2 9MbxC57g6V3RW5ueABKm2+kgR0rX07lNTx0RqU1HEPFnMiOMobFBawZo8pSD0lQ1qGNF icvg== X-RZG-AUTH: ":JHskdESlcvGJlcww5P8kEdDfB60eDdbwg2z1BLI60U5wCzf/pgzSaLAuAikn9dDl" X-RZG-CLASS-ID: mo00 Original-Received: from toy.adminart.net by smtp.strato.de (RZmta 46.10.5 DYNA|AUTH) with ESMTPSA id e08936w7GHncaF2 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 16 Aug 2020 19:49:38 +0200 (CEST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:185322 Archived-At: 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 ...