From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.emacs.devel Subject: Re: arch taglines for emacs Date: Sat, 23 Aug 2003 07:02:31 -0700 (PDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200308231402.HAA00501@morrowfield.regexps.com> References: NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1061650804 8809 80.91.224.253 (23 Aug 2003 15:00:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2003 15:00:04 +0000 (UTC) Cc: emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Aug 23 17:00:01 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19qZs1-0006oZ-00 for ; Sat, 23 Aug 2003 17:00:01 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19qZwh-0005Qd-00 for ; Sat, 23 Aug 2003 17:04:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19qZq6-0005DZ-0i for emacs-devel@quimby.gnus.org; Sat, 23 Aug 2003 10:58:02 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19qZ6U-0001dQ-2F for emacs-devel@gnu.org; Sat, 23 Aug 2003 10:10:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19qZ44-0007cx-9F for emacs-devel@gnu.org; Sat, 23 Aug 2003 10:08:55 -0400 Original-Received: from [65.234.195.45] (helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19qYy6-0002d9-To; Sat, 23 Aug 2003 10:02:15 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id HAA00501; Sat, 23 Aug 2003 07:02:31 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Fri, 22 Aug 2003 23:59:59 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16105 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:16105 > From: Richard Stallman > I agree that it's ugly; arch currently treats everything on the line > following `arch-tag:' as part of the tag-- and that includes whitespace. > Yes, I gathered that. What I'm suggesting is that this should be changed. > I suggest defining a tag-end sequence for arch. Suppose it is !!. > Then the line could look like > /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89!! */ > This way, arch does not need to know about the specific comment syntax > rules of various languages. > Tom, what do you think? That is a specific variation on the general idea we've been kicking around for what to do. It's likely we'll do something like that. The specific proposal doesn't answer the question of changes to spaces _within_ the tag: /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader !! */ vs. /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader!! */ It would probably also be a good idea to use string-delimiters and string-quoting for the tag contents so that it can safely contain character sequences (e.g. "*/") that might otherwise confuse language modes or compilers. I realize that, from most perspectives, a change of this sort seems trivial. In terms of code changes it is trivial. Two factors make me want to take my time before making the change: 1) A reasonable number of users already have arch archives in place. Those archives contain changesets. Those changesets contain inventory tags. If the computation that derives the actual tag from the comment changes in such a way that it produces a different result, then those older changesets will become broken. It would be best, I think, to make the change as a strictly compatible extension. For example, tags using `arch-tag' comments will continue to work as is, and tags using `arch-id' comments (or some new string) will work in a new way that is delimited and not so sensative to whitespace. (Miles' first idea was to make a change that would be probabilistically upward compatible but I think we've agreed now it's worth the extra effort to be strictly upward compatible.) 2) There are some other, more complicated features that have been oft requested and which I plan to implement. These features require, in part, changes to the same code. I'd strongly prefer to do these all at once. Part of the reason to combine these efforts is because the part of the code concerned with computing file inventories is among the most critical in arch: a) errors in this code can corrupt archives -- any change to this code, even a seemingly trivial change, deserves a lot of testing and review before its release. b) misfeatures (as you can see) create a backwards-compatability constraint. It's therefore best to think through the kinds of changes we can think of to make to the tag comments rather than just make each change as the idea occurs. Finally, again, the particular problem that Miles asked to be solved has never been reported s a problem in practice. It came up as an issue for Emacs because of a desire to keep the tag comments to a single line, e.g.: /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */ but that would produce the inventory tag: i_53bb84c6-dee0-46c6-a275-2db144993d89_*/ which "seems wrong". (It would work fine -- it just looks odd.) If the comment changed to: /*arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89*/ that would (undesirably) change the inventory tag: i_53bb84c6-dee0-46c6-a275-2db144993d89*/ I doubt that any of this will represent a real problem in practice. I would tag the Emacs source with any of: /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */ /*arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89*/ /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */ /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 (do not change this comment) */ and, when a new syntax comes along, switch to something like whichever of these is appropriate: /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89" */ /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89_*/" */ /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89*/" */ -t