* arch taglines for emacs @ 2003-08-19 3:55 Miles Bader 2003-08-20 2:42 ` Richard Stallman ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Miles Bader @ 2003-08-19 3:55 UTC (permalink / raw) Would anyone object to me adding an arch `taglines' to the source files in emacs? A tagline is basically a single-line comment near the end (or beginning) of the file that gives the file a unique ID (which persists even if you rename the file); their presence makes using arch easier and more efficient (of course some file formats can't handle comments, so arch has other methods of tagging files, but there various disadvantages to these other methods; in general it seems best to use taglines when possible). Some example taglines: For an elisp file: ;; arch-tag: af05e2b7-12a2-48a1-8af4-0f0cb793b869 For a C file: /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */ If these were placed at the end of source files, I think there would be little or no problem with the change causing conflicts. Thanks, -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.' ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-19 3:55 arch taglines for emacs Miles Bader @ 2003-08-20 2:42 ` Richard Stallman 2003-08-20 2:54 ` Miles Bader [not found] ` <87he4cfkhf.fsf@mail.jurta.org> 2003-08-21 11:29 ` Florian Weimer 2 siblings, 1 reply; 22+ messages in thread From: Richard Stallman @ 2003-08-20 2:42 UTC (permalink / raw) Cc: Tom Lord, emacs-devel Would anyone object to me adding an arch `taglines' to the source files in emacs? It seems ok to me. /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */ It looks ugly to put the */ on the next line. Why do that-- is arch unable to handle putting the */ at the end of the line? If so, Tom, could you fix that? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-20 2:42 ` Richard Stallman @ 2003-08-20 2:54 ` Miles Bader 2003-08-20 3:03 ` Tom Lord 2003-08-23 3:59 ` Richard Stallman 0 siblings, 2 replies; 22+ messages in thread From: Miles Bader @ 2003-08-20 2:54 UTC (permalink / raw) Cc: Tom Lord, emacs-devel Richard Stallman <rms@gnu.org> writes: > Would anyone object to me adding an arch `taglines' to the source files > in emacs? > > It seems ok to me. Thanks; that will make things a bit nicer for me. > /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 > */ > > It looks ugly to put the */ on the next line. Why do that-- > is arch unable to handle putting the */ at the end of the line? > If so, Tom, could you fix that? 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. So if the comment was all one line, the _actual_ tag would be: 53bb84c6-dee0-46c6-a275-2db144993d89_*/ I think this behavior is dangerous because whitespace and comment delimiters can get changed inadvertently, whereas users are more likely to be careful about the actual tag string (which looks `magic'). I've posted a proposed solution to the gnu-arch-users mailing list, so we'll see how that pans out. -Miles -- 80% of success is just showing up. --Woody Allen ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-20 2:54 ` Miles Bader @ 2003-08-20 3:03 ` Tom Lord 2003-08-21 14:11 ` Richard Stallman 2003-08-23 3:59 ` Richard Stallman 1 sibling, 1 reply; 22+ messages in thread From: Tom Lord @ 2003-08-20 3:03 UTC (permalink / raw) Cc: rms, emacs-devel > From: Miles Bader <miles@lsi.nec.co.jp> > I think this behavior is dangerous because whitespace and comment > delimiters can get changed inadvertently, whereas users are more likely > to be careful about the actual tag string (which looks `magic'). That's fine, although no problems have ever been reported in practice. > I've posted a proposed solution to the gnu-arch-users mailing list, so > we'll see how that pans out. Your solution was no good because it wasn't strictly upwards compatible but strictly upwards compatible solutions are certainly possible. (Strict upwards compatibility is more important in revision control than in many software systems, since a large part of the point is to keep around very long-lived archives without having to format-convert them every N weeks. Upward compatibility is even more of a priority for arch since it is a distributed system, but we can't rely on all users publishing archives to upgrade at the same time. Welcome to my own personal hell. :-) -t ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-20 3:03 ` Tom Lord @ 2003-08-21 14:11 ` Richard Stallman 2003-08-21 14:56 ` Tom Lord 0 siblings, 1 reply; 22+ messages in thread From: Richard Stallman @ 2003-08-21 14:11 UTC (permalink / raw) Cc: emacs-devel, miles > From: Miles Bader <miles@lsi.nec.co.jp> > I think this behavior is dangerous because whitespace and comment > delimiters can get changed inadvertently, whereas users are more likely > to be careful about the actual tag string (which looks `magic'). That's fine, although no problems have ever been reported in practice. Could you tell me what is the issue here? I have not received Miles' message that you are replying to. Was it sent to emacs-devel? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-21 14:11 ` Richard Stallman @ 2003-08-21 14:56 ` Tom Lord 0 siblings, 0 replies; 22+ messages in thread From: Tom Lord @ 2003-08-21 14:56 UTC (permalink / raw) Cc: emacs-devel, miles > From: Richard Stallman <rms@gnu.org> > > From: Miles Bader <miles@lsi.nec.co.jp> > > I think this behavior is dangerous because whitespace and comment > > delimiters can get changed inadvertently, whereas users are more likely > > to be careful about the actual tag string (which looks `magic'). > That's fine, although no problems have ever been reported in practice. > Could you tell me what is the issue here? I have not received Miles' > message that you are replying to. Was it sent to emacs-devel? One of the cornerstones of arch are the tools `mkpatch' and `dopatch' which are generalizations of `diff' and `patch'. Rather than comparing two versions of a single file or patching a single file, `mkpatch' and `dopatch' work on an entire source tree. Among the "differences" noted by `mkpatch' are names of files and directories. For example, if I have two versions of the hello world program: version-1 tree: ./Makefile ./hw.c version-2 tree: ./Makefile ./hw.c.~1~ ./hello.c # used to be called hw.c `mkpatch' will produce a changeset that says (in effect): hw.c has been renamed hello.c hello.c has been modified (here are the diffs....) So arch needs _some_ mechanism to recognize that in the two trees, "hw.c" and "hello.c" are the same logical file. Two mechanisms are provided. In one mechanism, extra files are added to the tree (stored in subdirs named `.arch-ids') which describe the logical identities of files. In another mechanism, a specially formatted comment is added _inside_ of each file, and arch searches for those. (In practice a mixture of these is often used, since though the special comments are more convenient, they can't be applied to all types of files.) The special comments method is usually the most convenient. When such comments are used, a user can rename a file in the usual way (e.g., with `mv(1)') and arch recognizes what has happened. When external records are used, moving a file requires an extra step to update the external record (e.g., the arch `move' command). In the case of Emacs, where only a subset of the developers will be using arch, the special comments method is arguably the best choice. Developers not using arch can simply ignore these comments -- they only have to remember not to change them. (External files are still desirable to assign logical names to directories, but because of the way those files are stored, users do _not_ have to use the arch `move' command when renaming a directory.) The issue Miles is raising concerns the syntax of the special comments. Given a comment such as: /* arch-tag: this is the tag i chose for this file. */ arch forms a string which stands for the logical name of the file. To form this string, it takes the entire contents of the string following "arch-tag:", strips surrounding whitespace, and replaces other non-graphical characters with "_". So, the logical name of that file is: this_is_the_tag_i_chose_for_this_file._*/ Miles is concerned that a seemingly harmless change, like adding extra whitespace, will have the undesirable side effect of changing the logical name of the file: modified comment: /* arch-tag: this is the tag i chose for this file. */ new logical file name: this_is_the_tag_i_chose_for_this_file. Such problems have not been observed in practice, but I agree with Miles that it is a legitimate concern. So he proposed a change to the way logical names are formed and I've pointed out (on another list) some design constraints that his first proposal doesn't satisfy. (The primary constraint is that any change in this area should be made in a way that is 100% upward compatible will all already existing mkpatch-generated changesets. Miles' first proposal was based on a solution that in theory might be incomatible with some changesets, but that he guesses will be compatible with all of them in practice.) Meanwhile, there is an easy convention to adopt that will make such problems unlikely to occur in the Emacs source and will make it easy to upgrade to a new syntax if we decide to add one to arch. The convention is to use tags which do not contain spaces: /* arch-tag: d41d8cd98f00b204e9800998ecf8427e */ or /* arch-tag: d41d8cd98f00b204e9800998ecf8427e * Do not Modify this comment. */ or similar. -t ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-20 2:54 ` Miles Bader 2003-08-20 3:03 ` Tom Lord @ 2003-08-23 3:59 ` Richard Stallman 2003-08-23 14:02 ` Tom Lord 1 sibling, 1 reply; 22+ messages in thread From: Richard Stallman @ 2003-08-23 3:59 UTC (permalink / raw) Cc: lord, emacs-devel 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-23 3:59 ` Richard Stallman @ 2003-08-23 14:02 ` Tom Lord 2003-08-24 18:00 ` Richard Stallman 2003-08-24 18:00 ` Richard Stallman 0 siblings, 2 replies; 22+ messages in thread From: Tom Lord @ 2003-08-23 14:02 UTC (permalink / raw) Cc: emacs-devel, miles > From: Richard Stallman <rms@gnu.org> > 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 <miles@gnu.org>!! */ vs. /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader<miles@gnu.org>!! */ 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-23 14:02 ` Tom Lord @ 2003-08-24 18:00 ` Richard Stallman 2003-08-24 18:00 ` Richard Stallman 1 sibling, 0 replies; 22+ messages in thread From: Richard Stallman @ 2003-08-24 18:00 UTC (permalink / raw) Cc: emacs-devel, miles 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 <miles@gnu.org>!! */ vs. /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader<miles@gnu.org>!! */ Deletion of a single space is unlikely--filling won't do that, and humans are likely to think of it as a real change and not do it either. By contrast, what is likely to happen is changes in number of spaces. So if you treat all whitespace groups as equivalent to a single space, you should avoid the problem. Also, if you use string syntax with doublequotes, people are likely to avoid changing anything inside that, even the number of spaces. It would be best, I think, to make the change as a strictly compatible extension. I agree. 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. That is one way to do it. Or else you could use string syntax if the tag begins with doublequote. That is similar to shell syntax and will be easy to understand, and I doubt it will break any tags people are using now (though that is not absolutely guaranteed). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-23 14:02 ` Tom Lord 2003-08-24 18:00 ` Richard Stallman @ 2003-08-24 18:00 ` Richard Stallman 2003-08-24 18:59 ` Tom Lord 1 sibling, 1 reply; 22+ messages in thread From: Richard Stallman @ 2003-08-24 18:00 UTC (permalink / raw) Cc: emacs-devel, miles 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 <miles@gnu.org>!! */ vs. /* arch-tag: tagged on 2003-01-01-12:12:12 by miles bader<miles@gnu.org>!! */ Deletion of a single space is unlikely--filling won't do that, and humans are likely to think of it as a real change and not do it either. By contrast, what is likely to happen is changes in number of spaces. So if you treat all whitespace groups as equivalent to a single space, you should avoid the problem. Also, if you use string syntax with doublequotes, people are likely to avoid changing anything inside that, even the number of spaces. 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*/ That change would be unlikely, so maybe we should just use this form and let the */ be part of the arch tag. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-24 18:00 ` Richard Stallman @ 2003-08-24 18:59 ` Tom Lord 2003-08-24 19:38 ` Jonathan Walther 2003-08-25 1:59 ` Miles Bader 0 siblings, 2 replies; 22+ messages in thread From: Tom Lord @ 2003-08-24 18:59 UTC (permalink / raw) Cc: gnu-arch-users, emacs-devel [Please don't reply without trimming the recipients. This has been CROSS POSTED.] > From: various people [in various messages, on and off list: proposed alternative syntaxes for tags affirmation that multi-line tags are ugly possibility of using the > /*arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89*/ ] I'll leave this pretty much up to you guys ("To:" line). Here's my position and observations: 1) I think everybody now agrees that a strictly upward compatible alternative tagline syntax is desirable. 2) It sure would be smart, imo, to help make emacs developers happy given the size of the project, it's position within the GNU project, and this early effort to try out arch by miles. Basically, I think this is a good thing for the arch project to do. 3) An alternative syntax is pretty easy -- if need be, I'm sure we can nail down what to do in that regard within 2 days of deciding too and implement it within 5. There's no big need to back-and-forth over the details until then or across multiple lists. Most of the suggestions have been just fine -- to an extent, it's an arbitrary choice. 4) I'm willing to do any of the following: a) nothing (for now). You decide to use the current `arch-tag:' syntax as shown above. b) go into a quick design/merge cycle with miles to put in a new syntax sooner rather than later. c) put in a new syntax myself. Obviously (c) is "least desirable" but, in absolute terms, it's not that much work. (a) would be my choice by default but (2) and (3) mean I'm happy to to do (b) or (c), too. In favor of (a): going that route poses the least risk to my degrees of freedom doing other changes to the "inventory" subsystem of arch going forward -- but I'll qualify that by saying that I don't see the risk of not doing (a) as huge. So, tell me what to do to help keep Emacs folks happy. Your call. -t ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Re: arch taglines for emacs 2003-08-24 18:59 ` Tom Lord @ 2003-08-24 19:38 ` Jonathan Walther 2003-08-24 19:44 ` [Gnu-arch-users] " Tom Lord 2003-08-25 1:59 ` Miles Bader 1 sibling, 1 reply; 22+ messages in thread From: Jonathan Walther @ 2003-08-24 19:38 UTC (permalink / raw) [-- Attachment #1.1: Type: text/plain, Size: 1279 bytes --] On Sun, Aug 24, 2003 at 11:59:19AM -0700, Tom Lord wrote: > In favor of (a): going that route poses the least risk to my > degrees of freedom doing other changes to the "inventory" subsystem > of arch going forward -- but I'll qualify that by saying that I > don't see the risk of not doing (a) as huge. > >So, tell me what to do to help keep Emacs folks happy. Your call. I would love to be able to use arch-id: syntax for Xouvert. Did anyone notice that switching to /* arch-id: "old-tag*/" */ won't work? Because of the */ coming too early in the line. C compiler would emit an error about an unterminated string. Jonathan -- It's not true unless it makes you laugh, but you don't understand it until it makes you weep. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw@reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2 [-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --] [-- Attachment #2: Type: text/plain, Size: 214 bytes --] _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://mail.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Gnu-arch-users] Re: arch taglines for emacs 2003-08-24 19:38 ` Jonathan Walther @ 2003-08-24 19:44 ` Tom Lord 0 siblings, 0 replies; 22+ messages in thread From: Tom Lord @ 2003-08-24 19:44 UTC (permalink / raw) Cc: gnu-arch-users, emacs-devel > From: Jonathan Walther <krooger@debian.org> > Did anyone notice that switching to > /* arch-id: "old-tag*/" */ > won't work? Because of the */ coming too early in the line. C compiler > would emit an error about an unterminated string. Doh! (Thanks.) But: /* arch-id: "old-tag*\057" */ would work. -t ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-24 18:59 ` Tom Lord 2003-08-24 19:38 ` Jonathan Walther @ 2003-08-25 1:59 ` Miles Bader 2003-08-25 2:08 ` Tom Lord 2003-08-26 1:38 ` Richard Stallman 1 sibling, 2 replies; 22+ messages in thread From: Miles Bader @ 2003-08-25 1:59 UTC (permalink / raw) Cc: rms, emacs-devel [CC to gnu-arch-users dropped] Tom Lord <lord@emf.net> writes: > So, tell me what to do to help keep Emacs folks happy. Your call. I want to keep the tag-ids clean (no */ as part of the tag). My tentative plan is to do as you've suggested, and use this format for C code: /* arch-tag: ID-CONTENTS (don't change this comment) */ and then later when `arch-id:' is implemented, change to using: /* arch-id: "ID-CONTENTS" */ As long as you (Tom) are pretty sure the proposal for arch-id: will not change in any way significant enough to screw up compatibility, this seems like the most practical method. _However_, if Richard objects to temporarily having the ugly multi-line comments then I'm also willing to do the grunt work for a minimal implementation of arch-id:, and use that instead. Richard? Thanks, -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.' ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-25 1:59 ` Miles Bader @ 2003-08-25 2:08 ` Tom Lord 2003-08-26 1:38 ` Richard Stallman 1 sibling, 0 replies; 22+ messages in thread From: Tom Lord @ 2003-08-25 2:08 UTC (permalink / raw) Cc: rms, emacs-devel > From: Miles Bader <miles@lsi.nec.co.jp> > Tom Lord <lord@emf.net> writes: > > So, tell me what to do to help keep Emacs folks happy. Your call. > I want to keep the tag-ids clean (no */ as part of the tag). > My tentative plan is to do as you've suggested, and use this format for > C code: > /* arch-tag: ID-CONTENTS > (don't change this comment) */ > and then later when `arch-id:' is implemented, change to using: > /* arch-id: "ID-CONTENTS" */ > As long as you (Tom) are pretty sure the proposal for arch-id: will not > change in any way significant enough to screw up compatibility, this > seems like the most practical method. That's a nice conservative approach from the arch perspective. > _However_, if Richard objects to temporarily having the ugly multi-line > comments then I'm also willing to do the grunt work for a minimal > implementation of arch-id:, and use that instead. And I'm willing to pitch in on that to make it minimal but satisfactory for the future. Either way, really. -t ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-25 1:59 ` Miles Bader 2003-08-25 2:08 ` Tom Lord @ 2003-08-26 1:38 ` Richard Stallman 1 sibling, 0 replies; 22+ messages in thread From: Richard Stallman @ 2003-08-26 1:38 UTC (permalink / raw) Cc: lord, emacs-devel My tentative plan is to do as you've suggested, and use this format for C code: /* arch-tag: ID-CONTENTS (don't change this comment) */ and then later when `arch-id:' is implemented, change to using: /* arch-id: "ID-CONTENTS" */ As long as you (Tom) are pretty sure the proposal for arch-id: will not change in any way significant enough to screw up compatibility, this seems like the most practical method. Doing things in two steps like that is ok with me. ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <87he4cfkhf.fsf@mail.jurta.org>]
* Re: arch taglines for emacs [not found] ` <87he4cfkhf.fsf@mail.jurta.org> @ 2003-08-21 4:36 ` Miles Bader 2003-08-22 20:54 ` Juri Linkov 0 siblings, 1 reply; 22+ messages in thread From: Miles Bader @ 2003-08-21 4:36 UTC (permalink / raw) Cc: gnu-arch-users, emacs-devel Juri Linkov <juri@jurta.org> writes: > The better and safer if it had a form of RCS keywords ($Id$, $Header$, etc.) It's a very different concept than RCS keywords. RCS keywords are a form of communication from RCS to the human reader of the source code. Arch taglines, on the other hand, are strictly for the use of arch (though I suppose you could choose to use them for similar purposes in other tools). RCS tags change (which can be a huge source of problems). Arch taglines _never_ -- by definition -- change. Because taglines are meant for arch, not for the user, you also probably don't want them in a very user-visible location; also arch only searches for them in the first and last 1024-byte blocks of the file. For these reasons, the convention is to make them the last line in the source file, or thereabouts. You are right that a less strictly line-oriented syntax would be more convenient (in fact such a syntax is being discussed right now on gnu-arch-users, in case you're reading this on emacs-devel). > If initially the user enters strings of the form $Arch$, then arch > could assign an unique tag to it automatically. Because arch taglines never change, they are assigned only once; as such, I suppose you could create a tool to automatically look for `unfilled' tags and fill them in, if you find such a method of creating taglines convenient. I think there are currently script available which automatically add a tagline to every un-tagged source file they find, for files who's type the script knows. Because of the convention of putting taglines at the end of the file, this probably works pretty well, and is slightly more convenient than requiring the user to add an unfilled-in template somewhere... -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://mail.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-21 4:36 ` Miles Bader @ 2003-08-22 20:54 ` Juri Linkov 0 siblings, 0 replies; 22+ messages in thread From: Juri Linkov @ 2003-08-22 20:54 UTC (permalink / raw) Cc: emacs-devel Miles Bader <miles@lsi.nec.co.jp> writes: > RCS keywords are a form of communication from RCS to the human reader of > the source code. Arch taglines, on the other hand, are strictly for the > use of arch (though I suppose you could choose to use them for similar > purposes in other tools). RCS tags change (which can be a huge source > of problems). Arch taglines _never_ -- by definition -- change. You are right: RCS tags have a different purpose. But what I propose is only to use the same format, i.e. to enclose arch tags in the $ characters. This solves many problems: special comment delimiters are not needed anymore, the $ character delimits the arch tag; whitespace is allowed inside the arch tag: all whitespace until the $ character is considered as part of tag. There is no need in special warning (e.g. "Do not change this comment"), because users already know that everything inside the $ characters shouldn't be changed manually. > Because taglines are meant for arch, not for the user, you also probably > don't want them in a very user-visible location; also arch only searches > for them in the first and last 1024-byte blocks of the file. Limiting the search by some constant value is not a good thing. I have a bad experience with time-stamp Emacs feature. It limits its search for a Time-stamp tag by only first 8 lines. Sometimes, the line with a Time-stamp tag gets accidentally shifted below 8 lines (by adding new comment lines above it) and becomes invisible for time-stamp to update it. So I would also propose to disable default limits for time-stamp by setting the default value of the variable `time-stamp-line-limit' to 0. > You are right that a less strictly line-oriented syntax would be more > convenient (in fact such a syntax is being discussed right now on > gnu-arch-users, in case you're reading this on emacs-devel). OK, I continued this discussion on gnu-arch-users. -- http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-19 3:55 arch taglines for emacs Miles Bader 2003-08-20 2:42 ` Richard Stallman [not found] ` <87he4cfkhf.fsf@mail.jurta.org> @ 2003-08-21 11:29 ` Florian Weimer 2003-08-22 1:47 ` Miles Bader 2 siblings, 1 reply; 22+ messages in thread From: Florian Weimer @ 2003-08-21 11:29 UTC (permalink / raw) Cc: emacs-devel Miles Bader <miles@lsi.nec.co.jp> writes: > For a C file: > > /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 > */ What about the following? #define ARCH_TAG "arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89" This would avoid the problem with placing " */". (It doesn't make sense to compile the string into the binary because it never changes.) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-21 11:29 ` Florian Weimer @ 2003-08-22 1:47 ` Miles Bader 2003-08-22 12:07 ` Andreas Schwab 0 siblings, 1 reply; 22+ messages in thread From: Miles Bader @ 2003-08-22 1:47 UTC (permalink / raw) Cc: Tom Lord, emacs-devel Florian Weimer <fw@deneb.enyo.de> writes: > #define ARCH_TAG "arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89" > > This would avoid the problem with placing " */". Hmmm, using `#define' is also ugly, but it doe avoid the end-delimiter problem. For compatibility with the proposed new embedded-tag format, it should actually not include the quotes: #define ARCH_TAG arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 would be the same as the (proposed) new format: /* arch-id: "53bb84c6-dee0-46c6-a275-2db144993d89" */ Presuming Tom thinks it's likely that the `new format' will eventually come to pass in something like it's current form (or rather with something like the properties Tom's proposal suggests), I'll probably go ahead and add the tags using the old format, either using (1) /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 */ or (2) /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 (do not change this comment, even a little bit) */ or (3) #define ARCH_TAG arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 or even (4) #define DONT_TOUCH arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 Presumably in the time until the `new format' gets implemented, the danger of tags getting inadvertently perturbed is reasonably low, so any of these is basically fine. Personally I'm inclined to go with (2), as it's a little less ugly than the `#define' forms, and hopefully the warning is enough to keep the newline safe -- and it seems like the best form to have in the code base in the case that no new embedded-tag format ever gets implemented. -Miles -- 80% of success is just showing up. --Woody Allen ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-22 1:47 ` Miles Bader @ 2003-08-22 12:07 ` Andreas Schwab 2003-08-22 20:55 ` Miles Bader 0 siblings, 1 reply; 22+ messages in thread From: Andreas Schwab @ 2003-08-22 12:07 UTC (permalink / raw) Cc: Florian Weimer, Tom Lord, emacs-devel Miles Bader <miles@lsi.nec.co.jp> writes: |> Presuming Tom thinks it's likely that the `new format' will eventually |> come to pass in something like it's current form (or rather with |> something like the properties Tom's proposal suggests), I'll probably go |> ahead and add the tags using the old format, either using |> |> (1) /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 |> */ |> |> or |> |> (2) /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 |> (do not change this comment, even a little bit) */ If you are going to put this at the end you should also explain that nothing should be added after this, so that it doesn't inadvertently get moved outside the 1k range. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: arch taglines for emacs 2003-08-22 12:07 ` Andreas Schwab @ 2003-08-22 20:55 ` Miles Bader 0 siblings, 0 replies; 22+ messages in thread From: Miles Bader @ 2003-08-22 20:55 UTC (permalink / raw) Cc: Florian Weimer, emacs-devel, Tom Lord, Miles Bader On Fri, Aug 22, 2003 at 02:07:12PM +0200, Andreas Schwab wrote: > |> (2) /* arch-tag: 53bb84c6-dee0-46c6-a275-2db144993d89 > |> (do not change this comment, even a little bit) */ > > If you are going to put this at the end you should also explain that > nothing should be added after this, so that it doesn't inadvertently get > moved outside the 1k range. And hopefully the explanatory comment won't exceed 1K! -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2003-08-26 1:38 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-08-19 3:55 arch taglines for emacs Miles Bader 2003-08-20 2:42 ` Richard Stallman 2003-08-20 2:54 ` Miles Bader 2003-08-20 3:03 ` Tom Lord 2003-08-21 14:11 ` Richard Stallman 2003-08-21 14:56 ` Tom Lord 2003-08-23 3:59 ` Richard Stallman 2003-08-23 14:02 ` Tom Lord 2003-08-24 18:00 ` Richard Stallman 2003-08-24 18:00 ` Richard Stallman 2003-08-24 18:59 ` Tom Lord 2003-08-24 19:38 ` Jonathan Walther 2003-08-24 19:44 ` [Gnu-arch-users] " Tom Lord 2003-08-25 1:59 ` Miles Bader 2003-08-25 2:08 ` Tom Lord 2003-08-26 1:38 ` Richard Stallman [not found] ` <87he4cfkhf.fsf@mail.jurta.org> 2003-08-21 4:36 ` Miles Bader 2003-08-22 20:54 ` Juri Linkov 2003-08-21 11:29 ` Florian Weimer 2003-08-22 1:47 ` Miles Bader 2003-08-22 12:07 ` Andreas Schwab 2003-08-22 20:55 ` Miles Bader
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).