arch taglines for emacs

arch taglines for emacs

[Miles Bader]

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.'

Re: arch taglines for emacs

[Richard Stallman]

    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?

Re: arch taglines for emacs

[Miles Bader]

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

Re: arch taglines for emacs

[Tom Lord]

    > 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

Re: arch taglines for emacs

[Miles Bader]

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/

Re: arch taglines for emacs

[Florian Weimer]

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.)

Re: arch taglines for emacs

[Richard Stallman]

	> 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?

Re: arch taglines for emacs

[Tom Lord]

    > 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

Re: arch taglines for emacs

[Miles Bader]

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

Re: arch taglines for emacs

[Andreas Schwab]

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."

Re: arch taglines for emacs

[Juri Linkov]

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/

Re: arch taglines for emacs

[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_)

Re: arch taglines for emacs

[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?

Re: arch taglines for emacs

[Tom Lord]

    > 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

Re: arch taglines for emacs

[Richard Stallman]

    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).

Re: arch taglines for emacs

[Richard Stallman]

    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.

Re: arch taglines for emacs

[Tom Lord]

[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

Re: Re: arch taglines for emacs

[Jonathan Walther]

[-- 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/

Re: [Gnu-arch-users] Re: arch taglines for emacs

[Tom Lord]

    > 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

Re: arch taglines for emacs

[Miles Bader]

[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.'

Re: arch taglines for emacs

[Tom Lord]

    > 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

Re: arch taglines for emacs

[Richard Stallman]

    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.