Re: It's Huntin' Season
>>"Nick" == Nick Phillips <email@example.com> writes:
Nick> On Wed, Feb 06, 2002 at 12:23:06PM -0600, Manoj Srivastava wrote:
>> For what it is worth, I disagree strongly. Start up files
>> change the behaviour of my editor-OS, and I should have a chance to
>> tweak that. Every rationale that lead us to declare that all
>> configuration files need bve under /etc, and that these need to be
>> editable applies to emacs lisp start files as well.
>> And how exactly do emacs lisp start up files not qualify?
Nick> I guess that depends on how you define a "start up
Nick> file". Surely the point here is that emacs deliberately blurs
Nick> the distinction between configuration and code.
We are not waffling abpout this. We are talking about a very
distinct set of files: those that live in /etc/emacs*/site-start.d/
There is absolutely no ambiguity at all.
Nick> Debian policy distinguishes (or tries to) between configuration
Nick> and code.
Nick> Take it to the (ridiculous) limit and you put *everything* in
Nick> /etc, as "you might want to run a hex editor over libc"...
You are the one taking things to such extremes. Not the other
participants in this discussion so far.
Nick> So, it comes to to the Emacs policy or individual maintainers
Nick> to decide what is a config file (and should go in /etc) and
Nick> what is not (and should probably in this case go in /usr/share
If it modifies program behaviour, it is a configuration file,
and goes in /etc. If it does not modify program behaviour, why is it
there in the first place?
Nick> Given the above, surely it's up to the debian-emacsen to go
Nick> away and decide their policy on what constitutes a config file
Nick> as far as Emacs is concerned, and put them in the appropriate
Rubbish. This is where we do development and design work. We
do not tell people to go away and not bother us with the hard
>> When a machine starts up, a number of processes are started,
>> and the behaviour of these processses, or whether they start at all
>> (which changes the behaviour of my machine), is governed by the start
>> up scripts. alsa actually loads and unloads modules from the kernel
>> (changing the behaviour of the kernel in a marked
>> fashion). bootmisc.sh is another nice place to hook things into. Or
>> checkfs.sh. console-screen.sh. I could go on.
Nick> It's also governed by a whole bunch of other *executables*. Just 'cos
Nick> something is human-readable doesn't mean that it can/should be edited
Nick> by admins (and is therefore a config file). How far on would you like
Nick> to go? Hex-editing libc because it affects the bootup of your machine
Nick> in a way that you'd like to tweak? Or just a load of the perl CPAN
Nick> modules that happen to be used by some init script or other?
If you can't exercise a modicum of common sense, there is no
point in wasting the time of the list. Why the hell bring up
executable in the middle of a policy discussion of a specific set of
non binary text files that modify the behaviour of a program?
Are you just trying to be contrary, and enusre no work gets
done in this thread?
Nick> is overly vague; maybe it's deliberately vague, as there are
Nick> grey areas which need to be left to informed discretion.
Nick> Please could the debian-emacsen go away and use their informed
No. If you do not want to participate in development, and
design, go away and unsubscribe. This is not a gossip list.
Nick> When they have a consensus, they can call it "an updated emacs
Nick> policy" ;)
The consensus can just as easily be developed here.
After watching my newly-retired dad spend two weeks learning how to
make a new folder, it became obvious that "intuitive" mostly means
"what the writer or speaker of intuitive likes". (Bruce Ediger,
firstname.lastname@example.org, in comp.os.linux.misc, on X the intuitiveness
of a Mac interface.)
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C