Re: It's Huntin' Season
>>"Nick" == Nick Phillips <nwp@lemon-computing.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.
Where?
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
Nick> somewhere).
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
Nick> places.
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
technical stuff,
>> 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
Nick> discretion.
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.
manoj
--
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,
bediger@teal.csn.org, in comp.os.linux.misc, on X the intuitiveness
of a Mac interface.)
Manoj Srivastava <srivasta@debian.org> <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
Reply to: