the Modernization of Emacs
in [Lisp]
|
From: Greg Menke on 26 Apr 2006 19:08 Hadron Quark <hadronquark(a)gmail.com> writes: > Tim X <timx(a)nospam.dev.null> writes: > > > Hadron Quark <hadronquark(a)gmail.com> writes: > > > >> "Greg"posted on 2006-04-25: > > > > Note that Greg is correct in that any problems you are having with > > backing up your emacs configuration is about how you are managing it > > and not due to complexities in emacs itself. A few rules of thumb > > which will possibly help - > > > > 1. Don't change/edit anything in /etc/emacs, /etc/emacs21, > > site-start.el etc. Only make changes to your own .emacs file. > > You dont have a multi user installation : it is easy if you are a one > man show. > Nope, config management done reasonably well handles multiuser just fine. Not that its rocket science either but you have to choose your tools and use them. This may require forming your own emacs distro so you can cm the whole thing and handle merges from the official source trees. This is the non-fun PITA aspect of managing systems that is so often ignored. Again, if backup is the problem, then your cm and backup procedures need enhancement. OTOH there are perhaps other aspects of the deploying additional packages into emacs that are not cm issues. Gregm
From: Hadron Quark on 27 Apr 2006 05:16 Greg Menke <gregm-xyzpdq3(a)toadmail.com> writes: > Hadron Quark <hadronquark(a)gmail.com> writes: > >> Tim X <timx(a)nospam.dev.null> writes: >> >> > Hadron Quark <hadronquark(a)gmail.com> writes: >> > >> >> "Greg"posted on 2006-04-25: >> > >> > Note that Greg is correct in that any problems you are having with >> > backing up your emacs configuration is about how you are managing it >> > and not due to complexities in emacs itself. A few rules of thumb >> > which will possibly help - >> > >> > 1. Don't change/edit anything in /etc/emacs, /etc/emacs21, >> > site-start.el etc. Only make changes to your own .emacs file. >> >> You dont have a multi user installation : it is easy if you are a one >> man show. >> > > Nope, config management done reasonably well handles multiuser just > fine. Not that its rocket science either but you have to choose your What do you mane "nope"? Are you serisouly telling me its as easy for multi-user as it is just to hack one huge .emacs without resorting to root? I must disagree. > tools and use them. This may require forming your own emacs distro so and forming ones own emacs distro isn't tricky? > you can cm the whole thing and handle merges from the official source > trees. This is the non-fun PITA aspect of managing systems that is so > often ignored. Lets get this right : I am a user of an editor/programming environment (eg emacs) - and you are suggesting that I should "cm" the whole thing and take care of merging source trees? All well and good if willing to learn all this : and this is the crux of the matter. It is *not* trivially easy no matter what some people say - if you think that managing and merging elisp source trees is easy then fair play. > > Again, if backup is the problem, then your cm and backup procedures need > enhancement. OTOH there are perhaps other aspects of the deploying > additional packages into emacs that are not cm issues. I'm not sure what you mean. Clearly if there are "issues" then one needs "enhancements" - thats hardly rocket science. Just what do you mean by "cm" here : do you mean a supported, distributed config management application or the more woolly "configuration management" which translates as "remembering where things are"? > > Gregm -- lithp : syntax error
From: Tim X on 27 Apr 2006 05:53 Hadron Quark <hadronquark(a)gmail.com> writes: > Tim X <timx(a)nospam.dev.null> writes: > >> Hadron Quark <hadronquark(a)gmail.com> writes: >> >>> "Greg"posted on 2006-04-25: >>> >>>> As far as customizing the emacs installation itself, I agree with you. >>>> I have a couple customized .el's banging around myself, CM'ed outside >>>> the emacs tree. I find Emacs a contrived interface for some things, >>>> so >>> >>> Mine is in the emacs tree. But the emacs tree is not for the faint >>> hearted IMO. >>> >>>> I just use better suited (and faster) apps for those things, and skip >>>> the installation hacking to gain portability. I also stick with FSF >>>> emacs, xemacs having pissed me off once too often. >>> >>> To this day I dont know if this is xemacs or not : it seems to run in >>> a shell. >>> >>> GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian >>> >>> Synaptic says emacs21 is installed and xemacs21 isnt : so I guess >>> not. Yet M-x emacs version gives the string above which indicates X is >>> in use - so I suppose its normal emacs with just enough for it to "run >>> under X" as opposed to it being XEmacs? is this right? >>> >>>> >>>> I think your backing up issue is probably a symptom of insufficient >>>> configuration management. >>>> >>>> Gregm >>> >>> >>> -- >>> % >> >> Just some clarification - emacs and xemacs are completely different >> and as each year goes by, seem to resemble each other less and less. >> From what you have posted, you are running emacs 21.4, not xemacs. >> >> This issues you have raised regarding emacs and emacs 'apps' being >> scattered all over the place is definitely an issue with your >> configuration management. Emacs has very very few requirements on >> where things are installed - all that stuff with /etc/emacs, >> /etc/emacs21 site-start etc is something done by your Linux >> distribution and absolutely *nothing* to do with emacs. In fact, you >> can (and I use to) run all my emacs stuff out of my ome directory. > > Fine : in a one person installation. > >> >> In fact, it wasn't so long ago that installing emacs under Linux did >> pretty much nothing with respect to configuration - it just installed >> the basic emacs software. Most distributions didn't have all the add >> on bits, you had to chase those down and install them yourself. > > I dont understand your point. It has nothing to do with the issue at > hand : installing lisp files in a linux multi user environment. > firstly, I don't remember seeing anything about a multi-user environment in the original post. The complaint was centered around the concern that it was near impossible to ensure all the emacs configuration information was adequately backed up and a strong impression was given (if not explicitly stated) that it was an individuals emacs configuration that was being referred to. I seem to even remember a mention to an explicit reference to Something like "I'm concerned my emacs configuration which I've been tuning/developing for months/years (I cannot remember the exact wording) may not be fully backed up. If we are talking about system configuration issues, then thats another league and a completely different issue. Linux has configuration stuff in many places - most of it under /etc, but not all of it. If your talking system configuration, then the argument that emacs is worse than anything else has no basis either and if your a sys admin and you do not have a clear idea of exactly what is being backed up and when, then you would be a pretty bloody poor sys admin. >> >> Note that Greg is correct in that any problems you are having with >> backing up your emacs configuration is about how you are managing it >> and not due to complexities in emacs itself. A few rules of thumb >> which will possibly help - >> >> 1. Don't change/edit anything in /etc/emacs, /etc/emacs21, >> site-start.el etc. Only make changes to your own .emacs file. > > You dont have a multi user installation : it is easy if you are a one > man show. > I've been administering multi-user emacs installations for over 15 years. Currently, I'm administering a Debian system. In the last 5 years, I cannot think of a single instance where I have had to modify the default system wide Debian emacs configuration scripts (those which are in /etc/emacs, /etc/emacs21, /etc/emacs-snapshot etc. If I did need to make a global change which wold affect all users, then I would modify one of the global setup files, but all of that is automatically backed up each night and backups are on a three month rotation with a full backup once per week and an incremental backup on the other nights. I can therefore retrieve any version of any global configuration/setup file going back three months. >> >> 2. If you install an emacs add-on by hand (ie not a Deb package), then >> decide on a scheme and stick to it. The only thing emacs needs to >> know about add ons is where to find them (i.e. add the directory to >> your .emacs file load-path setting). > > See above. Also note that the things we install (through debian > packages) also take different paths to installing : this was my point in > how it can be confusing to know the *best* way to do it. Give some examples. I don't understand what you mean about different paths. Debian's installation and policies make all of this extremely clear. All I can assume about the paths is in reference to the mechanism Debian uses to allow you to run multiple versions of emacs on the same system at the same time - its very simple and straight forward and works well if you take the time to understand how Debian does it. It is a bit more complicaed, but being able to run multiple versions of emacs and xemacs on the same box can be complex and Debian solves the problem in a nice and quite elegant way. Again, the main point is this is not due to anything specific to emacs and in fact proves how flexible emacs is with respect to how it is configured. >> >> 3. There are some minor exceptions - vm uses .vm and possibly > > hmm. Minor exceptions? Most emacs extensions that you want "latest > versions for are not in debian packages. They are are .el files. Well, firstly that depends on what version of Debian your running. I do have a couple of emacs packages which are not in deb format and which I've installed from tar balls, but thats not an issue. Installing emacs packages from tar files with just .el files in them is pretty straight forward, but again, this has nothing to do with the original argument that emacs configurations were difficult to backup and the response that if you have problems backing up emacs configuration, the problem is with your configuration management and not with emacs. Nothing you have responded with has changed this. >>> .vm-windows. w3m uses .w3m etc. However, all your configuration >> should be done in your home directory - think about Linux as a >> multi-user environment - thats how it is designed. In such > > Linus is a multiuser environment : hence the difficulty in knowing hos > *best* to install extensions you want open to all logins. There are a > myriad of ways of doing it. and a *lot* of emacs addons are hacks from > lisp experts who dont really offer suported ways of how to install it > for the best. > Examples? My experience with emacs add-ons has been that if the add-on is worth using, it has had a reasonable default for its configuration. In 15 years, I can only think of a couple of minor instances in which a package was difficult to configure and in each case, this was because it was a very old package which had not been actively maintained, so some work was required to get it working with newer versions. >> environments, you don't want personal configuration options being >> set on a global level that can affect all users. Such >> configurations should be put in your home directory. >> >> 4. Never run as root unless you have no choice (i.e. installing new >> packages, shutting down (though there are workarounds for that as > > eh? Where did this come from? You must sudo to root to install things > for multi-user access. Hence my comment on the complexity of the emacs > linux tree. Which part of "...unless you have no choice (i.e. installing new packages,..." did you have trouble understanding? >And it is complicated : for someone who wants to use a "more > powerful editor". I use emacs as a C and an ADA development environment. > This came from the fact it seemed from your original comments that you have very limited system administration experience and running as root when not necessary is a common mistake of those who don't have much experience - it was meant as a cautionary note. My original point is that this is still nothing to do with emacs. The complexities you are referring to are solely due to how Debian has decided to layout the emacs installation - nothing within emacs requires this structure. Given what you get as a result, Debian has done an excellent job - the fact you are not familiar with the advantages of there approach doesn't automatically mean it is too complex. >> well), doing low level system configuration etc). When you do have >> to use root, use things like sudo - this will ensure you don't > > I know. > >> shoot yourself in the foot - plenty of sys admins (including myself >> once) learn this the hard way. I once did a rm -rf * from the root >> partition when cleaning up a system, after a very long day and >> forgetting I was logged in as root! However, I know a lot of very >> experienced and smarter people who have done as bad and worse, so >> feel I'm in pretty good company! > > Personally I always use sudo. > Good. However, sometimes, su - is also needed, the trick is knowing when. -- tcross (at) rapttech dot com dot au
From: Hadron Quark on 27 Apr 2006 06:35 Tim X <timx(a)nospam.dev.null> writes: > Hadron Quark <hadronquark(a)gmail.com> writes: > >> Tim X <timx(a)nospam.dev.null> writes: >> >>> Hadron Quark <hadronquark(a)gmail.com> writes: >>> >>>> "Greg"posted on 2006-04-25: >>>> >>>>> As far as customizing the emacs installation itself, I agree with you. >>>>> I have a couple customized .el's banging around myself, CM'ed outside >>>>> the emacs tree. I find Emacs a contrived interface for some things, >>>>> so >>>> >>>> Mine is in the emacs tree. But the emacs tree is not for the faint >>>> hearted IMO. >>>> >>>>> I just use better suited (and faster) apps for those things, and skip >>>>> the installation hacking to gain portability. I also stick with FSF >>>>> emacs, xemacs having pissed me off once too often. >>>> >>>> To this day I dont know if this is xemacs or not : it seems to run in >>>> a shell. >>>> >>>> GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-05-03 on rothera, modified by Debian >>>> >>>> Synaptic says emacs21 is installed and xemacs21 isnt : so I guess >>>> not. Yet M-x emacs version gives the string above which indicates X is >>>> in use - so I suppose its normal emacs with just enough for it to "run >>>> under X" as opposed to it being XEmacs? is this right? >>>> >>>>> >>>>> I think your backing up issue is probably a symptom of insufficient >>>>> configuration management. >>>>> >>>>> Gregm >>>> >>>> >>>> -- >>>> % >>> >>> Just some clarification - emacs and xemacs are completely different >>> and as each year goes by, seem to resemble each other less and less. >>> From what you have posted, you are running emacs 21.4, not xemacs. >>> >>> This issues you have raised regarding emacs and emacs 'apps' being >>> scattered all over the place is definitely an issue with your >>> configuration management. Emacs has very very few requirements on >>> where things are installed - all that stuff with /etc/emacs, >>> /etc/emacs21 site-start etc is something done by your Linux >>> distribution and absolutely *nothing* to do with emacs. In fact, you >>> can (and I use to) run all my emacs stuff out of my ome directory. >> >> Fine : in a one person installation. >> >>> >>> In fact, it wasn't so long ago that installing emacs under Linux did >>> pretty much nothing with respect to configuration - it just installed >>> the basic emacs software. Most distributions didn't have all the add >>> on bits, you had to chase those down and install them yourself. >> >> I dont understand your point. It has nothing to do with the issue at >> hand : installing lisp files in a linux multi user environment. >> > > firstly, I don't remember seeing anything about a multi-user > environment in the original post. The complaint was centered around > the concern that it was near impossible to ensure all the emacs > configuration information was adequately backed up and a strong > impression was given (if not explicitly stated) that it was an > individuals emacs configuration that was being referred to. I seem to Sorry if you got that impression. > even remember a mention to an explicit reference to Something like > "I'm concerned my emacs configuration which I've been > tuning/developing for months/years (I cannot remember the exact > wording) may not be fully backed up. Well, that doesnt alter anything really since I did mention the system directories. > > If we are talking about system configuration issues, then thats > another league and a completely different issue. Linux has I'm not : im talking about emacs configuration. But admittedly under debian. There are a lot of potential places to add/tweak - this is all I am saying. It can be confusing to know where best and how best to configure things. e.g add 55xyz.el into site-start.d? Where this automatzically appends loadpaths and require's? or in site-start.el? or in all individual .emacs files? It is tricky IMO. > configuration stuff in many places - most of it under /etc, but not > all of it. If your talking system configuration, then the argument > that emacs is worse than anything else has no basis either and if your > a sys admin and you do not have a clear idea of exactly what is being > backed up and when, then you would be a pretty bloody poor sys admin. Possibly I over laboured the backup point. Clearly any idiot can ensure a full system backup - I probably more meant to make the point that the plethora of potential customisation points in the emacs world can and does make it tricky to know where best to customise and how best to keep track of those customisations. > >>> >>> Note that Greg is correct in that any problems you are having with >>> backing up your emacs configuration is about how you are managing it >>> and not due to complexities in emacs itself. A few rules of thumb >>> which will possibly help - >>> >>> 1. Don't change/edit anything in /etc/emacs, /etc/emacs21, >>> site-start.el etc. Only make changes to your own .emacs file. >> >> You dont have a multi user installation : it is easy if you are a one >> man show. >> > > I've been administering multi-user emacs installations for over 15 > years. Currently, I'm administering a Debian system. In the last 5 > years, I cannot think of a single instance where I have had to modify > the default system wide Debian emacs configuration scripts (those > which are in /etc/emacs, /etc/emacs21, /etc/emacs-snapshot etc. Then how did you customise emacs for all users? Please tell me : maybe I hav missed something. I dont see how you can customise a system of any kind for multi-user without rooting around in the system directories such as /usr and /etc. > > If I did need to make a global change which wold affect all users, > then I would modify one of the global setup files, but all of that is > automatically backed up each night and backups are on a three month I dont wish to discuss the backup : the system wide changes are not different to the HOME changes. Its more developing a concistent methodology for emacs changes - maybe I will learn amore about this as the days go on. As it is, there are loads of potential customization points - and I'm never quite sure which one to use. > rotation with a full backup once per week and an incremental backup on > the other nights. I can therefore retrieve any version of any global > configuration/setup file going back three months. > >>> >>> 2. If you install an emacs add-on by hand (ie not a Deb package), then >>> decide on a scheme and stick to it. The only thing emacs needs to >>> know about add ons is where to find them (i.e. add the directory to >>> your .emacs file load-path setting). >> >> See above. Also note that the things we install (through debian >> packages) also take different paths to installing : this was my point in >> how it can be confusing to know the *best* way to do it. > > Give some examples. I don't understand what you mean about different > paths. Debian's installation and policies make all of this extremely > clear. All I can assume about the paths is in reference to the I think you're being purposely argumentative. If it was "perfectly clear" then this and similar threads wouldnt occur. I suspect that the fact you have been an emacs administrator for 15 years makes you impervious to any potential faults or complications. > mechanism Debian uses to allow you to run multiple versions of emacs > on the same system at the same time - its very simple and straight > forward and works well if you take the time to understand how Debian > does it. It is a bit more complicaed, but being able to run multiple > versions of emacs and xemacs on the same box can be complex and Debian > solves the problem in a nice and quite elegant way How is debian special from other linuxes? Do you have a pointer/url please? > > Again, the main point is this is not due to anything specific to emacs > and in fact proves how flexible emacs is with respect to how it is > configured. > >>> >>> 3. There are some minor exceptions - vm uses .vm and possibly >> >> hmm. Minor exceptions? Most emacs extensions that you want "latest >> versions for are not in debian packages. They are are .el files. > > Well, firstly that depends on what version of Debian your running. I There are loads of el changes out there which are not in debian packages. Regardless of the debian version. > do have a couple of emacs packages which are not in deb format and > which I've installed from tar balls, but thats not an issue. Yes it is. Its the MAIN issue. e.g where best to put things and keep track of them for (e.g) backup purpose. > > Installing emacs packages from tar files with just .el files in them > is pretty straight forward, but again, this has nothing to do with the > original argument that emacs configurations were difficult to backup Yes it does. Since the last things I installed (el files) werent in instabble packages - they were just a bunch of files. > and the response that if you have problems backing up emacs > configuration, the problem is with your configuration management and > not with emacs. Nothing you have responded with has changed this. Possibly we are at crossing paths here : you seem determined to concentrate on the "backing up part". Whereas the "backing up" part I meant as a potential issue because of the plethora of possibilities in configuring an emacs system which is built of a hotch potch of debian packages and straghtforward .el files. > >>>> .vm-windows. w3m uses .w3m etc. However, all your configuration >>> should be done in your home directory - think about Linux as a >>> multi-user environment - thats how it is designed. In such >> >> Linus is a multiuser environment : hence the difficulty in knowing hos >> *best* to install extensions you want open to all logins. There are a >> myriad of ways of doing it. and a *lot* of emacs addons are hacks from >> lisp experts who dont really offer suported ways of how to install it >> for the best. >> > > Examples? My experience with emacs add-ons has been that if the add-on > is worth using, it has had a reasonable default for its configuration. > In 15 years, I can only think of a couple of minor instances in which > a package was difficult to configure and in each case, this was > because it was a very old package which had not been actively > maintained, so some work was required to get it working with newer > versions. Most emacs stuff is stable : there is a lot being developed too. There is a lot of stuff requiring cross app compatability which then clashes with the debian packages. I'm not making this up you know. Go and install, say cedet. Latest version. Not rocket science, but not trivial either. > > >>> environments, you don't want personal configuration options being >>> set on a global level that can affect all users. Such >>> configurations should be put in your home directory. >>> >>> 4. Never run as root unless you have no choice (i.e. installing new >>> packages, shutting down (though there are workarounds for that as >> >> eh? Where did this come from? You must sudo to root to install things >> for multi-user access. Hence my comment on the complexity of the emacs >> linux tree. > > Which part of "...unless you have no choice (i.e. installing new > packages,..." did you have trouble understanding? None of it: I just wondered why you felt the need to state the bleeding obvious. This thread wasnt about sudo issues : it was about best ways of configuring emacs on debian in a concistent and reproducible manner. > >>And it is complicated : for someone who wants to use a "more >> powerful editor". I use emacs as a C and an ADA development environment. >> > > This came from the fact it seemed from your original comments that you > have very limited system administration experience and running as root > when not necessary is a common mistake of those who don't have much > experience - it was meant as a cautionary note. > > My original point is that this is still nothing to do with emacs. The Fair enough. > complexities you are referring to are solely due to how Debian has > decided to layout the emacs installation - nothing within emacs > requires this structure. Given what you get as a result, Debian has > done an excellent job - the fact you are not familiar with the > advantages of there approach doesn't automatically mean it is too > complex. I am very aware of the advantages : I also am aware of the disadvantages. As a not too naive user of systems for many years, I stand by the fact that the debian emacs directory hierarchies are confusing - possibly due to the flexibility they provide. But confusing nonetheless. > >>> well), doing low level system configuration etc). When you do have >>> to use root, use things like sudo - this will ensure you don't >> >> I know. >> >>> shoot yourself in the foot - plenty of sys admins (including myself >>> once) learn this the hard way. I once did a rm -rf * from the root >>> partition when cleaning up a system, after a very long day and >>> forgetting I was logged in as root! However, I know a lot of very >>> experienced and smarter people who have done as bad and worse, so >>> feel I'm in pretty good company! >> >> Personally I always use sudo. >> > > Good. However, sometimes, su - is also needed, the trick is knowing > when. What trick? > > > -- > tcross (at) rapttech dot com dot au I guess there isnt really much more to say : you think its easy and I disagree. Maybe I'm, what was the phrase from the other poster, "stupid"? :-)
From: Galen Boyer on 27 Apr 2006 07:43
On Thu, 27 Apr 2006, hadronquark(a)gmail.com wrote: > You seem to confuse user friendliness with reduced functionality : > this is only the case when "stupid" people implement the user > friendliness. So, is your point that the Emacs developers are stupid people? -- Galen Boyer |