unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>
Cc: rgm@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org
Subject: RE: VC filesets
Date: Sun, 19 Oct 2008 23:04:55 -0700	[thread overview]
Message-ID: <006801c93279$c802fb40$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <E1KrnFz-0006ui-67@fencepost.gnu.org>

> The idea was that filesets.el would be a general facility for 
> file sets and that we would make other things work with it.

Yes, I realize that. But it is not that general. And things haven't really
worked out that way. And regardless of what one might think of that particular
example, the general terminology issues that were raised remain.

It doesn't matter, for example, that bookmarks.el *is* quite general and could
be extended to include things that might be found in other "bookmarks" libraries
available here and there. Independent libraries get developed with different or
similar features - or even virtually identical features that are implemented
differently. In many cases they will always remain separate, rather than being
incorporated (into bookmarks.el for example).

The problems I raised are (only) about terminology, not about implementation,
features, or packaging. It's about how to talk about features, not about how to
integrate or assimilate them.

Using more specific names can help avoid some of the problems. Using file names
that are different from general feature names can help too. But I don't see a
general solution to the terminology problems.

In the case Glenn initially raised, VC filesets, presumably a solution could be
found, because VC filesets and filesets.el filesets are both part of Emacs. I
take his observation as a suggestion that VC filesets should be called something
else. That would take care of this particular occurrence of the problem.

Or perhaps, following your remark above, VC filesets should be somehow
integrated with filesets.el filesets, since the latter feature is the intended
"general facility for file sets". I can't speak to that, knowing nothing about
VC filesets.





      reply	other threads:[~2008-10-20  6:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-19  3:07 VC filesets Chong Yidong
2008-10-19  8:08 ` Dan Nicolaescu
2008-10-20 19:55   ` Chong Yidong
2008-10-21  0:30     ` Dan Nicolaescu
2008-10-19 20:43 ` Glenn Morris
2008-10-19 21:35   ` Drew Adams
2008-10-20  5:24     ` Richard M. Stallman
2008-10-20  6:04       ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='006801c93279$c802fb40$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=rgm@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).