Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!ox.com!lokkur!scs From: scs@lokkur.dexter.mi.us (Steve Simmons) Newsgroups: comp.mail.elm Subject: Re: I think I might have found a bug Keywords: bug Message-ID: <1990Sep8.020207.913@lokkur.dexter.mi.us> Date: 8 Sep 90 02:02:07 GMT References: <1990Aug30.213125.18159@cs.umn.edu> <1990Aug31.002402.8495@DSI.COM> <41246@mips.mips.COM> Organization: Inland Sea Lines: 38 pmm@mips.COM (Paul M. Moriarty) writes: > It would be a lot > nicer if I could just direct a user to his/her elmrc and tell them to > modify to their heart's content rather than first telling them how to > create a default elmrc. fitz@wang.com (Tom Fitzgerald) writes: >People who want to muck with their elmrc's better have a good understanding >of how it works, or they can badly burn themselves. I'd say let them learn >how the defaults work before letting them modify anything. It's easy >enough to create a default elmrc. pmm@mips.COM (Paul M. Moriarty) writes: > I'd strongly suggest that the default elmrc be written if .elm is being > created or if .elm exists and elmrc doesn't. fitz@wang.com (Tom Fitzgerald) writes: >I'd just as soon keep things the way they are. If elm 2.4 or 3.0 or >whatever renames some option fields, or changes an option default, I >don't want to have to modify the elmrc's of every user on this system. >Any user who _has_ built a new elmrc should change it on his own, but >presumably those people know what they're doing. I disagree with most of the stuff written so far about the elmrc, and these two sum up the suggestions pretty well. My two cents: Admins should be able to configure elm on a site-wide basis with a master elmrc file. Users should be able to override the site stuff with their own elmrcs. The stuff about users being able to handle their own elmrcs isn't so. If the naive user changes one simple thing (such as changing his editor from vi to jove), all of his settings are saved. This is a problem two ways. First, it causes exactly the problem fitz describes. Second, the options displayed in the options are incomplete, so the naive user can't change them. We ought to (a) get *all* the options in there, and (b) when writing an elmrc file, save only those options which are different from the system default file.