the Modernization of Emacs
in [Lisp]
|
From: Christian Lynbech on 28 Apr 2006 13:22 >>>>> "Hadron" == Hadron Quark <hadronquark(a)gmail.com> writes: Hadron> Frankly I think the debian directory setup for emacs is Hadron> understandable, but far from trivial. The Debian system is not simple but this is mostly because it solves a complex task, that of having a set of emacs libraries that runs across a range of emacs implementations. The Debian handling of Common Lisp isn't exactly trivial either and has gone through a number of evolutions in order to get the right shape. The important part, however, is that to the casual user, it really is rock&roll from the outset. All of the complexity is for the package maintainer to sort out. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic(a)hal.com (Michael A. Petonic)
From: Thomas A. Russ on 28 Apr 2006 14:52 Hadron Quark <hadronquark(a)gmail.com> writes: > Tim X <timx(a)nospam.dev.null> writes: > > > > > Perhaps true - but then again, emacs obviously isn't the right tool > > for people like this - why have a high performance car which you only > > drive to the shops for milk and bread? > > People like what? people that want easy things to be easy? Please. And what easy things in Emacs are hard to do? There are file and edit menus with the standard sorts of things in them. You can navigate with the arrow keys or the mouse. You use the mouse to select text. The only thing that, out-of-the-box, isn't like other editors is that typing doesn't replace selected text. To get that behavior you have to change a configuration. > > Emacs is complex because it is extremely powerful. If you don't need > > the power, then don't use it. If you do want that power, then you have > > to learn how to use the tool. You cannot get powerful customizable > > Lots of things are powerful. Including your analogy : a performace > car. But there is still a steering wheel, a clutch etc. No need to > reinvent the wheel ... to extend your analogy. OK. And as shown above, all of those standard things are present in Emacs. (Oh, by the way, what is the "clutch" thing of which you speak?) > > tools able to be configured to work how you want and have it do so out > > of the box because there is too much variation in what people do. This > > True. > > > will have to wait until we have really really intelligent mind reading > > software which is able to work out what you need autonomously - until > > then, either use something simple or be prepared to face a learning > > curve while you gain the power available with emacs. > > No one doubts the power of emacs : it doesnt mean that the "simple" > things need to be obfuscated, What simple things are hard? I will grant you that the keyboard shortcuts don't match what have become the Mac and Windows conventions. At least on the Mac, though, you can make the mapping match, because Emacs doesn't use the Command key. The issue with changing those is that it would seriously mess with the minds of the millions of existing Emacs users, who expect the control-... keys to do what they expect. Besides, Emacs was here long before Windows. :-P -- Thomas A. Russ, USC/Information Sciences Institute
From: Tim X on 29 Apr 2006 02:40 Hadron Quark <hadronquark(a)gmail.com> writes: > 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: >>>>> >> >> 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. > Actually, I feel it does make a difference. The way you customize/configure emacs depends on whether your doing it as a site administrator or you are doing it as an individual user. Your reference to the system directories gave me the impression you were customizing/modifying these files for individual configuration needs rather than system (i.e. multi-user) needs. What I was trying to say is that for a system being used by just an individual, don't modify the system files at all. Do all your configuration in your .emacs file. If it is a system wide configuration for multiple users and assuming you are using a Debian system, avoid changing the system config files for debian managed packages unless you have a very very good reason. While deb will handle this fine, the Debian default configs are pretty sane and suitable for most setups. Changing them means each time there is an upgrade, you have to merge in your changes and any changes in the new files. If the add-on is not a Debian package, then install it under /usr/local. You can use any scheme you want, but I prefer to follow the Debian emacs policies - partially because I have multiple machines to look after, so I create a deb package and partly so that other admins only have to know one general approach. I find its good to put any additional software which didn't come as part of the distro in /usr/local, which I also make as its own partition. Then, if necessary, I can do a complete re-install of the linux distro, even low level formatting of partitions (except /usr/local and /home) and can then know I have a truely clean install without having to redo all my hand installed software. >> >> 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. > But this is my point about the Debian policies - all this is explained in them and so you can easily find out and not remain confused. You can follow a basic rule of thumb - 1. If the package configuration does not vary between emacsen versions, then stick it in /etc/emacs/site-start.d. Use an appropriate number in the filename so that it is not loaded until any prerequisites are loaded. 2. If the package requires different configuraiton depending on the emacsen version, then put config files in each of the version dependent directories for which you want this pacakge available e.g. /etc/emacs21/site-start.d, /etc/xemcas21/site-start.d etc. 3. Put the source files in the site-lisp directory corresponding to the version of emacsen you will be running and want to have the package available. Debian would use /usr/share/emacs/site-lisp or /usr/share/emacs21/site-lisp. For non-deb packages, I tend to use /usr/local/share/emacs/site-lisp and /usr/local/share/emacs21/site-lisp. >> 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. > I can understand how it may seem confusing, especially under Debian. However, as I've mentioned, this is due to how Debian has done it and nothing to do with emacs. This was the original point I was trying to make - its not the emacs world or emacs developers that have created what you find to be a confusing configuration environment. If you wanted to, you could just have a single directory and put everything in sub directories below it (you only need the sub dirs to avoid file name conflicts between packages). If you look into the emacs documentation, you will find there is in fact only two configuration files which emacs bothers with. All this other stuff and multiple config files is done by the people putting the linux distro together and not something required by emacs. >> >>>> >>>> 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. > Probably already explained above, but at the risk of reptition.... 1. I've found with emacs backages in deb format, the defaults are fine. 2. For packages not in deb format, I put them under /usr/local and follow the same strategy as debian. This way, all my hand crafted configuration is in one place. >> 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. this was the aspect I was attempting to clarify for you. Hopefully what is above makes it a bit clearer. >>> 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. > I'm not at all trying to be argumentative - I asked for examples because I wasn't clear what you were talking about with reference to debian emacs packages using different paths. It has a clearly defined methodology. I was trying to understand what it is in particular you find confusing to see if I could help. If you didn't read it that way, thats unfortunate, but not worth worrying about. >> 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? > Its funny, I actually get the feeling your trying to be argumentative and not really taking in what I've attempted to express. Debian is different because the whole way emacs is configured under a debian distribution is specific to debian - again, this issue you brought up about emacs configuration being difficult is nothing to do with eamcs - its Debian which has set this up. Other Linux distributions do it differently. If yo want to read about it, go to the Debian site and find the policies for building emacs packages. Its all very clearly laid out there. >> >> 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. > True. However, for a multi-user site, most of the ones you would want are in Debian packages. I covered the ones that are not above. >> 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. > I thought backup wasn't an issue? Again, for non-deb installs, you can do it however you want in whatever way suits your maintenance methodology best. Emacs does not impose any restrictions on this - it just has to be able to find the files through its load path. >> >> 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. > So? Again, you can do it however you want. >> 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. > Well, if you really read what I have written and thought about it you would see that its nothing to do with emacs. It is 100% to do with how you manage your configuration because emacs lets you do it how you want. If you don't like the way Debian does it, then make up your own scheme. > 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. > I thought backup was the issue because of the original statement that you were concerned that after months of configuring your system, you didn't know for sure if all your configuration changes were being backed up - this is purely and simply and configuration management issue and as emacs has next to no requirements on how you do the configuration - it just has to be told to read in the file (and there are numerous ways to do that from writing elsip functions, command line switches and the site init file). >> >>>>> .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. > I don't remember saying any of it was trivial - it is straight forward and simply takes the time to do it. >> >> >>>> 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. > You might have found it bleeding obvious, but from the things you had written it was not at all obvious what knowledge or experience you had. Still, your comment of me being argumentative now seems somewhat ironic. >> >>>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. > I don't disagree - again, your original premise was that emacs was difficult to configure and my response was that its not emacs, it is the way Debian has done it. However, there are a lot of advantages to how they have done it which I think justify the apparent confusion you have experienced. I'd now go further and say that your confusion is easily remedied if you look at the Debian package policy for emacsen. It actually is not complicated once you bother to try and understand what they are trying to achieve and how it works. >> >>>> 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? The tric of knowing when of course! > >> >> >> -- >> 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"? :-) No, I wouldn't have said you were stupid. With no effort and only a cursory glance, it can look complicated. the point is it actually is very straight-forward and easy once you bother to find out what the methodology underlying the Debian design is. -- tcross (at) rapttech dot com dot au
From: Tim X on 30 Apr 2006 19:59 Christian Lynbech <christian(a)defun.dk> writes: >>>>>> "Hadron" == Hadron Quark <hadronquark(a)gmail.com> writes: > > Hadron> Frankly I think the debian directory setup for emacs is > Hadron> understandable, but far from trivial. > > The Debian system is not simple but this is mostly because it solves a > complex task, that of having a set of emacs libraries that runs across > a range of emacs implementations. The Debian handling of Common Lisp > isn't exactly trivial either and has gone through a number of > evolutions in order to get the right shape. > > The important part, however, is that to the casual user, it really is > rock&roll from the outset. All of the complexity is for the package > maintainer to sort out. > Exactly. The trick is not to modify the debian provided config/init scripts for the emacs packages unless you find a really good reason to. If you find one of them doesn't work correctly, its a bug and needs to be reported to the package maintainer. For emacs packages you install yourself, you can either follow debian's approach or, if your users only run one flavor of emacs, a much simpler structure. The issue of configuration then becomes simply configuring the non-debian emacs add ons and your personal .emacs. The whole thing then becomes as simple or as complex as you want. Tim -- tcross (at) rapttech dot com dot au
From: Hadron Quark on 1 May 2006 01:45
Tim X <timx(a)nospam.dev.null> writes: > Christian Lynbech <christian(a)defun.dk> writes: > >>>>>>> "Hadron" == Hadron Quark <hadronquark(a)gmail.com> writes: >> >> Hadron> Frankly I think the debian directory setup for emacs is >> Hadron> understandable, but far from trivial. >> >> The Debian system is not simple but this is mostly because it solves a >> complex task, that of having a set of emacs libraries that runs across >> a range of emacs implementations. The Debian handling of Common Lisp >> isn't exactly trivial either and has gone through a number of >> evolutions in order to get the right shape. >> >> The important part, however, is that to the casual user, it really is >> rock&roll from the outset. All of the complexity is for the package >> maintainer to sort out. >> > Exactly. The trick is not to modify the debian provided config/init > scripts for the emacs packages unless you find a really good reason > to. If you find one of them doesn't work correctly, its a bug and > needs to be reported to the package maintainer. About the last 6 out of 7 things I installed were not in a debian package. > > For emacs packages you install yourself, you can either follow > debian's approach or, if your users only run one flavor of emacs, a > much simpler structure. What dont you understand? There as posters here telling you that its not trivial to do that and you simply ignore that? I love emacs : but how either of you can say "emacs is easy from day one" is beyond me. > > The issue of configuration then becomes simply configuring the > non-debian emacs add ons and your personal .emacs. The whole thing > then becomes as simple or as complex as you want. Yet again you choose to ignore the multiple user scenario, which, while not impossible, can be confusing in debian. *Confusing* not impossible. > > Tim > > > -- > tcross (at) rapttech dot com dot au -- lithp : syntax error |