the Modernization of Emacs
in [Lisp]
|
From: Tim X on 1 May 2006 09:44 Hadron Quark <hadronquark(a)gmail.com> writes: > 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? > No, I have not ignored it. You continue not to comprehend what I have said because you simply don't want to. I'll restate things again. This is my last post on the issue as I cannot be bothered trying to assist you by clarifying your misunderstanding on the difference between a distribution imposed methodology and that of emacs. 1. The Debian way of configuring emacs does appear to be complex, but in fact is quite straight forward if you bother to read the available documentation in the emacs policies on how emacsen packages are to be installed. 2. 99% of the time, you do not need to modify the Debian config scripts for emacs add-on packages 3. If you have to install an emacs add-on which is not in a debian package, you DO NOT HAVE TO FOLLOW THE DEBIAN DEFINED CONFIGURATION POLICY. You can do it using any methodology you want. 4. If you do not run multiple different versions of emacs, the way you install an emacs add-on is greatly simplified and involves three basic steps 1. Unpack the *.el files into a directory that is either already in the emacs load-path or add the directory to the load-path. This can be added in either the emacs site-init.el file or left for users to add into the personal .emacs file - the choice depends on how you want to manage your system. 2. Depending on the package, it may be worth compiling the *.el files into .elc files. This can be tricky if there are lots of dependencies and it may be necessary to compile things in a certain order. However, in 15 years of managing emacs add-on packages, I have not seen a single emacs add-on which was complex to build that didn't have a makefile which did all the work for you. All you need to do is type make (sometimes you make need to do run configure for larger emacs add-ons which use autoconf etc). 3. Create a init/config file. Many emacs add-ons don't even need one of these and the defaults are fine. This file is usually very simple. Now, the important bit which you continually refuse to take in... The init file for your package can be called by either the standard emacs sit-init.el file or you can tell users who want to start/run that package to source the file from their personal .emacs. Thats TWO possible points you need to worry about, not the nightmare of configuration directories you keep refering to. That seems pretty straight forward to me. I guess our measure of difficulty is different. > I love emacs : but how either of you can say "emacs is easy from day > one" is beyond me. > Never ever said it was. In fact, if you go through emacs newsgroup archives, you will find posts from me going back many years talking to new users and attempting to assist them to deal with the tough learning curve. There is a paradigm shift which many users find difficult, but once the penny drops, its very straight forward. I got involved in this thread when you made the statement, which I assumed was informed and realise now was based on ignorance, that emacs was difficult to configure because of a confusing hierarchy of configuration directories and paths. I merely pointed out that this was not emacs, but due to Debian and have pointed out in a couple of posts that emacs actually only knows about a couple of configuration files which are clearly documented in the manual. I went further to point out that Debian's approach is clearly laid out in their package policy which is available on their web site and that for non-deb packages, you do NOT have to follow the complex debian way of things, especially if you don't run multiple different versions of emacs. In these situations, things are a lot simpler and very straight forward (regardless of whether you are talking a multi-user or single user system). >> 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. > I should have said above as I've said in other posts responding to this topic) that you can put the configuration in either the site-init.el file or have it called by that file or you can just let users put it in the .emacs file. In fact, you are often better off letting people put it in their .emacs file even on a multi-user system because not everyone wants to run all the same packages and why would they want a slower load time loading packages they are not interrested in just because some over zelous sys admin has set things up badly. Given that initially in this thread, you didn't even know what emacs you were running and given you didn't understand the difference between emacs and xemacs and the fact despite numerous requests for examples you have not given any example of emacs packages which are difficult and complex to configure (except for a vague referenced to cedet, which has no significant installation issue apart from requiring other emacs add-ons, which can be a pain due to the time needed to do all the add-ons, but is trivial otherwise), I now suspect that all you really want to do is moan and are not actually interested in assistance or help to understand how easy it actually all is. -- tcross (at) rapttech dot com dot au
From: Hadron Quark on 2 May 2006 06:58 Tim X <timx(a)nospam.dev.null> writes: > Hadron Quark <hadronquark(a)gmail.com> writes: > >> 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? >> > > No, I have not ignored it. You continue not to comprehend what I have > said because you simply don't want to. I'll restate things again. This > is my last post on the issue as I cannot be bothered trying to assist > you by clarifying your misunderstanding on the difference between a > distribution imposed methodology and that of emacs. > > 1. The Debian way of configuring emacs does appear to be complex, but This is not what you said earlier if I recall correctly. > in fact is quite straight forward if you bother to read the > available documentation in the emacs policies on how emacsen > packages are to be installed. Sigh. All relative to how much work is required to get a result I suppose. > > 2. 99% of the time, you do not need to modify the Debian config > scripts for emacs add-on packages I never said you did : you said that. I was referring to EL files. And the debian package installation varies between packages too in how it installs modules. It is NOT easy and obvious to anyone without a degree in emacs as you appear to have. Other posters have concurred. > > 3. If you have to install an emacs add-on which is not in a debian > package, you DO NOT HAVE TO FOLLOW THE DEBIAN DEFINED CONFIGURATION > POLICY. You can do it using any methodology you want. > > 4. If you do not run multiple different versions of emacs, the way you > install an emacs add-on is greatly simplified and involves three > basic steps > > 1. Unpack the *.el files into a directory that is either already in > the emacs load-path or add the directory to the load-path. This > can be added in either the emacs site-init.el file or left for > users to add into the personal .emacs file - the choice depends > on how you want to manage your system. Sigh. I know. I mentioned these as two of the options : there are also debian specific ways - that is what I said was complicated. There is no apparent common concensus. How can you not see that this can lead to confusion? I know why, but I will refrain from saying it. As for cross dependencies : its might not be emacs itself, per se, but the plethora of hacked el files on the web can make it very difficult to align versions. > > 2. Depending on the package, it may be worth compiling the *.el > files into .elc files. This can be tricky if there are lots of > dependencies and it may be necessary to compile things in a > certain order. However, in 15 years of managing emacs add-on 15 years again ... I'm so impressed. > packages, I have not seen a single emacs add-on which was > complex to build that didn't have a makefile which did all the > work for you. All you need to do is type make (sometimes you > make need to do run configure for larger emacs add-ons which use > autoconf etc). On your system. Would you like to comment on how easy it is or isnt under debian? But at least we get there : you think it is perfectly simple and error free to determine compilation order and to "make" things. A lot of new users might disagree. But we are agreed that good things might take time to learn. > > 3. Create a init/config file. Many emacs add-ons don't even need > one of these and the defaults are fine. This file is usually > very simple. Now, the important bit which you continually refuse > to take in... > > The init file for your package can be called by either the > standard emacs sit-init.el file or you can tell users who want > to start/run that package to source the file from their personal > .emacs. Thats TWO possible points you need to worry about, not > the nightmare of configuration directories you keep refering to. > > That seems pretty straight forward to me. I guess our measure of > difficulty is different. You clearly fail to see how the "flexibility" leads to problems in knowing how best to do things. > > >> I love emacs : but how either of you can say "emacs is easy from day >> one" is beyond me. >> > Never ever said it was. In fact, if you go through emacs newsgroup > archives, you will find posts from me going back many years talking to > new users and attempting to assist them to deal with the tough > learning curve. There is a paradigm shift which many users find > difficult, but once the penny drops, its very straight forward. Aha, so people do find things difficult? There is a reason for that. And its not so much a paradigm shift as an accumulation of a lot of knowledge. A small shift maybe. > > I got involved in this thread when you made the statement, which I > assumed was informed and realise now was based on ignorance, that Aha. Natural order rearing its ugly head ... > emacs was difficult to configure because of a confusing hierarchy of > configuration directories and paths. I merely pointed out that this > was not emacs, but due to Debian and have pointed out in a couple of > posts that emacs actually only knows about a couple of configuration It was emacs under debian. And clearly debian have done this to address something in a multi user, multi version OS. And if you reread it again : you will see that I was right. because of the debian directories, emacs is difficult to configure in a concistent and clear manner IMO. difficult : not impossible. > files which are clearly documented in the manual. I went further to > point out that Debian's approach is clearly laid out in their package > policy which is available on their web site and that for non-deb > packages, you do NOT have to follow the complex debian way of things, I guess that anything that is "on a web" or "in a book" is immediately trivial for you. For me and posisbly others, it is not. > especially if you don't run multiple different versions of emacs. In > these situations, things are a lot simpler and very straight forward > (regardless of whether you are talking a multi-user or single user > system). I know about the debian hierarchy, I know how I can reference el files. But is NOT TRIVIAL and it can be difficult. Primarily because the different packages put things in different places. Different el files need to go in different places and have special ordering. You think it is *easy* because of your "15 years of being an emacs admin" : does it not cross your mind that for others it is not so? Can you not see that? I think not. > >>> 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. >> > > I should have said above as I've said in other posts responding to > this topic) that you can put the configuration in either the > site-init.el file or have it called by that file or you can just let > users put it in the .emacs file. In fact, you are often better off > letting people put it in their .emacs file even on a multi-user system > because not everyone wants to run all the same packages and why would > they want a slower load time loading packages they are not interrested > in just because some over zelous sys admin has set things up badly. Thats fair enough. > > Given that initially in this thread, you didn't even know what emacs > you were running and given you didn't understand the difference > between emacs and xemacs and the fact despite numerous requests for Who said I didnt understand the difference? I never installed "xemacs" specifically , but run an x-windows desktop, is it not reasonable to consider that "xemacs" is run as a proxy for emacs? I dont know : its all a bit confusing - especially when my emacs-version included references to "X-Toolkits" etc. You make the same mistake as a lot of clever clog gurus : you refuse to accept that not everyone has the time or the desire to accumulate peripheral knowledge not directly required to do a job of work. > examples you have not given any example of emacs packages which are > difficult and complex to configure (except for a vague referenced to > cedet, which has no significant installation issue apart from > requiring other emacs add-ons, which can be a pain due to the time > needed to do all the add-ons, but is trivial otherwise), I now suspect You even back me up. Now my examples are "vague". LOL. And "trivial" again. It must be this 15 years again eh? Trivial for me is "install", not sudo'ing to root and wondering where the hell the files should go. > that all you really want to do is moan and are not actually interested > in assistance or help to understand how easy it actually all is. > Arrogance overload. No where did you try and help (until last post) : only to belittle and blow your own trumpet. So we are in agreement : no more on this subject - and for me, no more at all from you. As a footnote, with help from other posters, I have acquired a wonderful working development environment. I used emacs on Convex systems years ago and its great to be using it again. This is not a rant against emacs: far from it. > > > -- > tcross (at) rapttech dot com dot au -- lithp : syntax error
From: David Kastrup on 2 May 2006 07:09 Hadron Quark <hadronquark(a)gmail.com> writes: > Tim X <timx(a)nospam.dev.null> writes: > >> 2. 99% of the time, you do not need to modify the Debian config >> scripts for emacs add-on packages > > I never said you did : you said that. I was referring to EL > files. And the debian package installation varies between packages > too in how it installs modules. It is NOT easy and obvious to anyone > without a degree in emacs as you appear to have. Other posters have > concurred. A degree in Emacs does not help: there is sort of a consensus between core developers of Emacs and XEmacs that they compile their own Emacsen because they don't understand the Debian Emacs policy. In fact, a degree in Emacs is downright detrimental: Emacs' load-path search order and arrangement and the byte-compilation commands are _based_ on the premise that .el-files and .elc-files are in the same directory. All of this is completely broken in Debian's Emacs layouts. If you use the diagnostics like M-x list-load-path-shadows RET, you get gazillions of conflicts displayed. Emacs does not understand what Debian is doing with it, and the Emacs developers and users don't understand it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: Hadron Quark on 2 May 2006 09:38 David Kastrup <dak(a)gnu.org> writes: > Hadron Quark <hadronquark(a)gmail.com> writes: > >> Tim X <timx(a)nospam.dev.null> writes: >> >>> 2. 99% of the time, you do not need to modify the Debian config >>> scripts for emacs add-on packages >> >> I never said you did : you said that. I was referring to EL >> files. And the debian package installation varies between packages >> too in how it installs modules. It is NOT easy and obvious to anyone >> without a degree in emacs as you appear to have. Other posters have >> concurred. > > A degree in Emacs does not help: there is sort of a consensus between > core developers of Emacs and XEmacs that they compile their own > Emacsen because they don't understand the Debian Emacs policy. > > In fact, a degree in Emacs is downright detrimental: Emacs' load-path > search order and arrangement and the byte-compilation commands are > _based_ on the premise that .el-files and .elc-files are in the same > directory. All of this is completely broken in Debian's Emacs > layouts. If you use the diagnostics like M-x list-load-path-shadows > RET, you get gazillions of conflicts displayed. > > Emacs does not understand what Debian is doing with it, and the Emacs > developers and users don't understand it. This I can believe. Unfortunately, in the real world "emacs not configuring well in debian" is for me (using debian) the same as "emacs is hard to configure". I should really replace "hard" with "confusing at times". > > -- > David Kastrup, Kriemhildstr. 15, 44793 Bochum -- lithp : syntax error
From: Christian Lynbech on 4 May 2006 15:44
>>>>> "Hadron" == Hadron Quark <hadronquark(a)gmail.com> writes: Hadron> About the last 6 out of 7 things I installed were not in a debian Hadron> package. I am getting confused. In what way is the Debian emacs add-on package strategy complicating installation of non-Debian packaged emacs add-ons? Hadron> I love emacs : but how either of you can say "emacs is easy from day Hadron> one" is beyond me. Emacs is a rather complex application. Getting to know all of the parts takes a very lomng time. Even more so, some add-on packages such as GNUS carries huge amounts of functionality which also can demand a lot of energy and time to set up and use. But, again, I fail to see that this is futher complicated by Debian. I would greatly appreciate an example as I am really curious. If I am included in the "either of you" referred to above, let me just say that what I was driving at was that IMHO installing (say) the Debian GNUS package is easy (at least no more difficult than Debian package in general). You point to "gnus" and press `install' and in a short while you have access to a recent and common version of "gnus" that will work across the handfull of emacs variations supported by Debian. Now configuring and utilising is quite another matter but you face that no matter how you install it. ------------------------+----------------------------------------------------- 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) |