[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


 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. 


 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: