* Feature Request : autoload-form @ 2008-03-28 20:05 paul r 2008-03-29 4:20 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: paul r @ 2008-03-28 20:05 UTC (permalink / raw) To: Emacs Devel Dear list, autoload is a very convenient feature to pseudo-defun a function until it is called for real for the first time. I have been using it happily until today, when I came accross a need I can not suit with autoload. Here is why : There is a file B that does some (require ...) and some (load ...). In one of the loaded files, function F will be defined. There is a file A that changes the load-path, which is required before loading B. B does not depend on a predefined A file, therefore I can not put a (load A) in B. The only way I have to carry a proper load is to do (load A)(load B). After that, I'm sure F will be defined the way I want. I can really not do that with a single file. Hence my need : I think it would be convenient to have a variant of autoload, let's call it 'autoload-form'. Its look would be : (autoload-form function form &optional docstring interactive type) IOW, exactly the same as autoload, except that FILE becomes FORM. It is a kind a generalization of autoload, in which it is up to FORM to do what is needed to provide a side-effect of having FUNCTION defined. To make sure I am clear, the following two lines have the same effect (autoload foo "bar.el") (autoload-form foo (load-file "bar.el")) With that, I could do a (autoload-form F (load-file "A")(load-file "B")) Without, the only alternative I see is to write (load-file "A")(load-file "B") in a dummy file, then register it with autoload. I really want to do that myself, but autoload belongs to the C part of emacs, and I lack knowledge to change anything in it. I do not know how to do this in emacs lisp, whenever it is possible. I would like to know what you think about that. If you think I can do something clean in lisp, please give me some hints, I do not know where to start. Regards, -- Paul ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-28 20:05 Feature Request : autoload-form paul r @ 2008-03-29 4:20 ` Stefan Monnier 2008-03-29 9:49 ` paul r 2008-03-30 5:49 ` Richard Stallman 0 siblings, 2 replies; 21+ messages in thread From: Stefan Monnier @ 2008-03-29 4:20 UTC (permalink / raw) To: paul r; +Cc: Emacs Devel > (autoload foo "bar.el") > (autoload-form foo (load-file "bar.el")) You could just change autoload to do that. It's a pretty simple change in the C code. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-29 4:20 ` Stefan Monnier @ 2008-03-29 9:49 ` paul r 2008-03-29 19:40 ` Stefan Monnier 2008-03-30 5:49 ` Richard Stallman 1 sibling, 1 reply; 21+ messages in thread From: paul r @ 2008-03-29 9:49 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs Devel 2008/3/29, Stefan Monnier <monnier@iro.umontreal.ca>: > > (autoload foo "bar.el") > > (autoload-form foo (load-file "bar.el")) > > > You could just change autoload to do that. It's a pretty simple change > in the C code. > I'm totally unskilled when it comes to the C code. I admit it is not so-hard, but it will probably take me several hours to get it right. Having a clean solution to my problem is not worth several hours. So I'm willing to spend this time if you think it can bring something useful to emacs. What do you think ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-29 9:49 ` paul r @ 2008-03-29 19:40 ` Stefan Monnier 0 siblings, 0 replies; 21+ messages in thread From: Stefan Monnier @ 2008-03-29 19:40 UTC (permalink / raw) To: paul r; +Cc: Emacs Devel >> > (autoload foo "bar.el") >> > (autoload-form foo (load-file "bar.el")) >> You could just change autoload to do that. It's a pretty simple change >> in the C code. > I'm totally unskilled when it comes to the C code. I admit it is not > so-hard, but it will probably take me several hours to get it right. > Having a clean solution to my problem is not worth several hours. So > I'm willing to spend this time if you think it can bring something > useful to emacs. What do you think ? If it's done well, we could install it in the trunk (you'd probably have to sign copyright paperwork for that, of course). In any case, grep for `do_autoload' in the src/*.c files to see where the autoloading is done. That's probably the main part of the code you'll need to change. But change should be fairly small. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-29 4:20 ` Stefan Monnier 2008-03-29 9:49 ` paul r @ 2008-03-30 5:49 ` Richard Stallman 2008-03-30 11:24 ` paul r 1 sibling, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-03-30 5:49 UTC (permalink / raw) To: Stefan Monnier; +Cc: paul.r.ml, emacs-devel > (autoload foo "bar.el") > (autoload-form foo (load-file "bar.el")) You could just change autoload to do that. It's a pretty simple change in the C code. I don't think we should install this in Emacs, though. Something like autoload should be kept simple and limited. If loading a certain file needs load-path to be set a certain way, the user should simply set load-path that way, perhaps in .emacs. It is a bad idea to have files that only work right if load-path is temporarily changed; rather than adding a new file to Emacs to cope with that situation, it would be better to redesign the Lisp code that appears to need it. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 5:49 ` Richard Stallman @ 2008-03-30 11:24 ` paul r 2008-03-30 15:03 ` Stefan Monnier ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: paul r @ 2008-03-30 11:24 UTC (permalink / raw) To: rms; +Cc: Stefan Monnier, emacs-devel 2008/3/30, Richard Stallman <rms@gnu.org>: > I don't think we should install this in Emacs, though. Something like > autoload should be kept simple and limited. I think of autoload as a particular case of the general need to "eval-on-event-then-call". Therefore, I do not see why evaluating a form is less simple than loading a file. Form evaluation is, indeed, less limited but I don't see why it should be a disadvantage here. > If loading a certain file needs load-path to be set a certain way, > the user should simply set load-path that way, perhaps in .emacs. > It is a bad idea to have files that only work right if load-path > is temporarily changed; rather than adding a new file to Emacs > to cope with that situation, it would be better to redesign the > Lisp code that appears to need it. You are understanding most of the problem I'm facing. I'll try to give you some more information in a manner as concise as possible. I wrote a system called TidyConfig for emacs. It is not a mode, it is a system. Its ultimate goal is to allow people to share effectively what usualy resides in .emacs. Some people want to do that, because they have very similar usage profiles, although not exactly the same. Users copies can be synced using a DVCS. The best example I see is people in my company, who all use TidyConfig and this way avoid duplicated efforts. To achieve that : - I got rid of the monolithic .emacs, so that bits of configuration go into dedicated "modules". There is a module for C-mode, one for Muse-mode etc. One module resides in one file. Modules are shared in your network of friends/colleagues ... anybody syncing with you, so they are "network-specific" but not "user-specific". - To allow fine-tuning, a user can use "module configuration file", which is an other file, with personal tweaking in it. Those conf files are not shared and are usually optional. They are user specific, and private. Exemple : the ERC module does a lot of configuration, but it can not set up username, password etc because this information is user-specific. Any module is optional, this is the whole point of this project. Each user simply choose in a list what modules he wants to use. He can chose to load them at startup time, or "later when needed". In this last case, I obviously use autoload. I could put, at beginning of *every* modules, a (load-file "thisModuleConfigurationFile" t). This is what I did before, but I do not find that elegant, nor fully satisfactory in many ways for the needs, so it now is to the TidyConfig system to carry proper loading of modules. Here we are. I currently have no option to do so, except putting the form I want to eval in a dummy file and registering this file with autoload. This is now what I do, and please believe I don't feel pround of that ugly hack :) If you want to visit my upstream TidyConfig repository, and why not give it a try, you can go to http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary . It is versionned through mercurial, so you can also do a "hg clone" of this url. It could maybe be used as a playground for people here to try and share some lisp before checking in into the trunk, and also to get hands on DVCS. There is an up to date documentation in english. Hope that was not too long ... Thanks. -- Paul ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 11:24 ` paul r @ 2008-03-30 15:03 ` Stefan Monnier 2008-03-30 22:28 ` paul r 2008-03-30 19:55 ` Richard Stallman ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2008-03-30 15:03 UTC (permalink / raw) To: paul r; +Cc: rms, emacs-devel > I think of autoload as a particular case of the general need to > "eval-on-event-then-call". Therefore, I do not see why evaluating a > form is less simple than loading a file. Form evaluation is, indeed, > less limited but I don't see why it should be a disadvantage here. By the way, instead of (autoload <fun> <exp> <doc>) you can do (defun <fun> (&rest args) <doc> <exp> (apply <fun> args)) -- Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 15:03 ` Stefan Monnier @ 2008-03-30 22:28 ` paul r 2008-03-31 7:58 ` Levin Du 0 siblings, 1 reply; 21+ messages in thread From: paul r @ 2008-03-30 22:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, emacs-devel 2008/3/30, Stefan Monnier <monnier@iro.umontreal.ca>: > > I think of autoload as a particular case of the general need to > > "eval-on-event-then-call". Therefore, I do not see why evaluating a > > form is less simple than loading a file. Form evaluation is, indeed, > > less limited but I don't see why it should be a disadvantage here. > > > By the way, instead of > > (autoload <fun> <exp> <doc>) > > you can do > > (defun <fun> (&rest args) > <doc> > <exp> > (apply <fun> args)) > I needed to do a macro for that, because <fun> name is known at runtime, but at the end it works. Thank you. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 22:28 ` paul r @ 2008-03-31 7:58 ` Levin Du 0 siblings, 0 replies; 21+ messages in thread From: Levin Du @ 2008-03-31 7:58 UTC (permalink / raw) To: paul r; +Cc: emacs-devel, Stefan Monnier, rms [-- Attachment #1: Type: text/plain, Size: 829 bytes --] We currenly have (eval-after-load file form), what about: (eval-before-load file form) to make things easier? 2008/3/31, paul r <paul.r.ml@gmail.com>: > > 2008/3/30, Stefan Monnier <monnier@iro.umontreal.ca>: > > > I think of autoload as a particular case of the general need to > > > "eval-on-event-then-call". Therefore, I do not see why evaluating a > > > form is less simple than loading a file. Form evaluation is, indeed, > > > less limited but I don't see why it should be a disadvantage here. > > > > > > By the way, instead of > > > > (autoload <fun> <exp> <doc>) > > > > you can do > > > > (defun <fun> (&rest args) > > <doc> > > <exp> > > (apply <fun> args)) > > > > I needed to do a macro for that, because <fun> name is known at > runtime, but at the end it works. > Thank you. -- Levin [-- Attachment #2: Type: text/html, Size: 1507 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 11:24 ` paul r 2008-03-30 15:03 ` Stefan Monnier @ 2008-03-30 19:55 ` Richard Stallman 2008-03-30 21:35 ` Mike Mattie 2008-03-31 16:24 ` Richard Stallman 3 siblings, 0 replies; 21+ messages in thread From: Richard Stallman @ 2008-03-30 19:55 UTC (permalink / raw) To: paul r; +Cc: monnier, emacs-devel I think of autoload as a particular case of the general need to "eval-on-event-then-call". Looking for the most general way to think of this is not a good practice. Please listen to my experience. Features like autoload should be kept as limited as possible. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 11:24 ` paul r 2008-03-30 15:03 ` Stefan Monnier 2008-03-30 19:55 ` Richard Stallman @ 2008-03-30 21:35 ` Mike Mattie 2008-03-31 16:24 ` Richard Stallman 3 siblings, 0 replies; 21+ messages in thread From: Mike Mattie @ 2008-03-30 21:35 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 4146 bytes --] On Sun, 30 Mar 2008 12:24:19 +0100 "paul r" <paul.r.ml@gmail.com> wrote: > 2008/3/30, Richard Stallman <rms@gnu.org>: > > > I don't think we should install this in Emacs, though. Something > > like autoload should be kept simple and limited. > > I think of autoload as a particular case of the general need to > "eval-on-event-then-call". Therefore, I do not see why evaluating a > form is less simple than loading a file. Form evaluation is, indeed, > less limited but I don't see why it should be a disadvantage here. > > > If loading a certain file needs load-path to be set a certain way, > > the user should simply set load-path that way, perhaps in .emacs. > > It is a bad idea to have files that only work right if load-path > > is temporarily changed; rather than adding a new file to Emacs > > to cope with that situation, it would be better to redesign the > > Lisp code that appears to need it. > > You are understanding most of the problem I'm facing. I'll try to give > you some more information in a manner as concise as possible. > I wrote a system called TidyConfig for emacs. It is not a mode, it is > a system. Its ultimate goal is to allow people to share effectively > what usualy resides in .emacs. Some people want to do that, because > they have very similar usage profiles, although not exactly the same. > Users copies can be synced using a DVCS. The best example I see is > people in my company, who all use TidyConfig and this way avoid > duplicated efforts. To achieve that : > - I got rid of the monolithic .emacs, so that bits of configuration > go into dedicated "modules". There is a module for C-mode, one for > Muse-mode etc. One module resides in one file. Modules are shared in > your network of friends/colleagues ... anybody syncing with you, so > they are "network-specific" but not "user-specific". > - To allow fine-tuning, a user can use "module configuration file", > which is an other file, with personal tweaking in it. Those conf files > are not shared and are usually optional. They are user specific, and > private. Exemple : the ERC module does a lot of configuration, but it > can not set up username, password etc because this information is > user-specific. > > Any module is optional, this is the whole point of this project. Each > user simply choose in a list what modules he wants to use. He can > chose to load them at startup time, or "later when needed". In this > last case, I obviously use autoload. > > I could put, at beginning of *every* modules, a (load-file > "thisModuleConfigurationFile" t). This is what I did before, but I do > not find that elegant, nor fully satisfactory in many ways for the > needs, so it now is to the TidyConfig system to carry proper loading > of modules. > > Here we are. I currently have no option to do so, except putting the > form I want to eval in a dummy file and registering this file with > autoload. This is now what I do, and please believe I don't feel > pround of that ugly hack :) > > If you want to visit my upstream TidyConfig repository, and why not > give it a try, you can go to > http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary . It is > versionned through mercurial, so you can also do a "hg clone" of this > url. It could maybe be used as a playground for people here to try and > share some lisp before checking in into the trunk, and also to get > hands on DVCS. There is an up to date documentation in english. > > Hope that was not too long ... Thanks. I wrote something very similar, but different on some design points. It boiled down to my "modules" having a three part form: [define meta-data & hooks ] [ load w/require ] [ setup ] I would define things like install hooks before the loading part. If anything went wrong with loading needed libraries, my load function could execute the install hooks, and re-evaluate the module. loading would be a bunch of require forms. The setup would configure and integrate the features. If you want to know more drop me a mail off-list. > -- Paul > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-30 11:24 ` paul r ` (2 preceding siblings ...) 2008-03-30 21:35 ` Mike Mattie @ 2008-03-31 16:24 ` Richard Stallman 2008-03-31 17:36 ` paul r 2008-03-31 21:31 ` Mike Mattie 3 siblings, 2 replies; 21+ messages in thread From: Richard Stallman @ 2008-03-31 16:24 UTC (permalink / raw) To: paul r; +Cc: monnier, emacs-devel - I got rid of the monolithic .emacs, so that bits of configuration go into dedicated "modules". There is a module for C-mode, one for Muse-mode etc. One module resides in one file. Modules are shared in your network of friends/colleagues ... anybody syncing with you, so they are "network-specific" but not "user-specific". I think I understand what these do. I'm not completely sure why you want them, though. What job do these do, which you couldn't do by installing some Lisp libraries in the usual way? - To allow fine-tuning, a user can use "module configuration file", which is an other file, with personal tweaking in it. Those conf files are not shared and are usually optional. They are user specific, and private. Exemple : the ERC module does a lot of configuration, but it can not set up username, password etc because this information is user-specific. Why not put this stuff directly in .emacs? I could put, at beginning of *every* modules, a (load-file "thisModuleConfigurationFile" t). I don't see why you want to do that, rather than putting the "module configuration" expressions directly in .emacs. What do you gain? This is what I did before, but I do not find that elegant, nor fully satisfactory in many ways for the needs, so it now is to the TidyConfig system to carry proper loading of modules. I am confused. Are you talking about making a module load its module configuration expressions, or are you talking about how to load the module itself when it is needed? Those are two different issues, right? Some of your words seem to imply one, and some seem to imply the other. Here we are. I currently have no option to do so, except putting the form I want to eval in a dummy file and registering this file with autoload. I have lost you completely here. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-31 16:24 ` Richard Stallman @ 2008-03-31 17:36 ` paul r 2008-03-31 21:31 ` Mike Mattie 1 sibling, 0 replies; 21+ messages in thread From: paul r @ 2008-03-31 17:36 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel 2008/3/31, Richard Stallman <rms@gnu.org>: I'll try to make things more clear below, but before reading the whole message, be warned : - it is long and unlikely to interest you, so you can safely skip it - I solved the original problem of this thread. > I think I understand what these do. I'm not completely sure why you > want them, though. What job do these do, which you couldn't do by > installing some Lisp libraries in the usual way? What usual way ? > > Why not put this stuff directly in .emacs? TidyConfig IS a .emacs splited into many files. Each file has a role. You may want to load some of them, and not some others. As an exemple, the upstream repository provides more than 20 modules, but usualy people use around 10 modules. For exemple, you can load 4 of them at startup time, then the 6 remaining dynamically when needed (thanks to autoload / automode etc). Any configuration should not be read -at all- if not needed yet. > I don't see why you want to do that, rather than putting the > "module configuration" expressions directly in .emacs. > What do you gain? Fine grained, per-feature, configuration "cherry-picking". But you are right that I could. > I am confused. Are you talking about making a module load its module > configuration expressions, or are you talking about how to load the > module itself when it is needed? Those are two different issues, right? > Some of your words seem to imply one, and some seem to imply the other. Sorry for not being clear. This system uses some conventions. Here is an exemple of a use case : - I sometime use latex-mode - I do not want it to be loaded at startup time because it would slow down for nothing - Some of the configuration should be shared with other users To do so : - I have some customization for this mode, that is shared by everybody in my company. This configuration is some lisp written in mod.latex.el. At the beginning of this file, there is (require 'latex) - I have personal preferences that are not shared, it goes to conf.latex.el - I need the actual latex mode librairy, so I download it from Auctex to my "modes" directory and name the directory "latex". - I register "metadata" which is a list of 3 elements '( module autoload-function automode-extension ), with following meaning : "load module on autoload-function call" and "call autoload-function on file matching automode-extension". Is this case, it will be basicaly '(latex latex-mode ".tex") And that's it. Nothing about latex will be loaded at emacs startup time, except "metadata". Then, when autoload-function is called for the first time, is does the "proper loading of module" that confused you, which is detailled below : 1 - load conf.latex.el (again, this is a per-user optional file) 2 - unless tidyconfig-avoid-local-mode has been set to 't in conf.latex.el, look for a directory in modes directory which name is "latex". If found, add it to load-path. 3 - load mod.latex.el. This module does (require 'latex), which in turn will define real latex-mode. 4 - call latex-mode The file mentionned above can be visited from [2]. So why do I have all this system ? Because, as strange as it can look at first glance, it provides strong consistency over how emacs config is managed as a whole, for me and for my "network". As well as easier portability over systems. I did not invente anything, 99% of the goodness is due to emacs clean design. I just did the last 1% to make it easier to access. I think it might be surprising mainly because it uses some conventions for loading process, while conventional lisp librairy explicitly express their dependencies through load-path settings, (require ...) (load ...) etc. Although I think the later is more robust, so is the right choice in most cases, I think the former is easier to maintain, for me, in the particular case of .emacs configuration. > I have lost you completely here. I'm sorry about that. If you have a web browser and want to give it a try, please go to [1], download a snapshot clicking on "zip" or "gz", extract in any directory, cd to this directory, and enter emacs -q -l tidyconfig.start.el Regards, -- Paul [1] http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary [2] http://emacs.kekerekex.net:8008/tidyconfig-vanilla/file ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-31 16:24 ` Richard Stallman 2008-03-31 17:36 ` paul r @ 2008-03-31 21:31 ` Mike Mattie 2008-04-02 2:53 ` Richard Stallman 1 sibling, 1 reply; 21+ messages in thread From: Mike Mattie @ 2008-03-31 21:31 UTC (permalink / raw) To: emacs-devel; +Cc: rms [-- Attachment #1: Type: text/plain, Size: 2849 bytes --] On Mon, 31 Mar 2008 12:24:45 -0400 Richard Stallman <rms@gnu.org> wrote: > - I got rid of the monolithic .emacs, so that bits of > configuration go into dedicated "modules". There is a module for > C-mode, one for Muse-mode etc. One module resides in one file. > Modules are shared in your network of friends/colleagues ... anybody > syncing with you, so they are "network-specific" but not > "user-specific". > > I think I understand what these do. I'm not completely sure why you > want them, though. What job do these do, which you couldn't do by > installing some Lisp libraries in the usual way? There isn't a usual way for installing elisp libraries, just whatever the user has slapped together out of necessity. The closest way to any usual way AFAICT is ELPA. The Emacs developers use trees of elisp source managed by CVS regularly, it is somewhat curious that a single .emacs file is considered adequate the user. In fact I think a single .emacs file discourages sharing emacs elisp because it contradicts directly the kind of modularity and organization essential to sharing. If I had not broken out of a single .emacs file long ago I never would have posted any elisp, because it was always a big hair-ball in a giant file. Something to consider at least. The rest of this line of thought is to off-topic for me to continue, but I will share ideas and code off-list. > - To allow fine-tuning, a user can use "module configuration > file", which is an other file, with personal tweaking in it. Those > conf files are not shared and are usually optional. They are user > specific, and private. Exemple : the ERC module does a lot of > configuration, but it can not set up username, password etc because > this information is user-specific. > > Why not put this stuff directly in .emacs? > > I could put, at beginning of *every* modules, a (load-file > "thisModuleConfigurationFile" t). > > I don't see why you want to do that, rather than putting the > "module configuration" expressions directly in .emacs. > What do you gain? > > This is what I did before, but I do > not find that elegant, nor fully satisfactory in many ways for the > needs, so it now is to the TidyConfig system to carry proper > loading of modules. > > I am confused. Are you talking about making a module load its module > configuration expressions, or are you talking about how to load the > module itself when it is needed? Those are two different issues, > right? Some of your words seem to imply one, and some seem to imply > the other. > > Here we are. I currently have no option to do so, except putting > the form I want to eval in a dummy file and registering this file with > autoload. > > I have lost you completely here. > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-03-31 21:31 ` Mike Mattie @ 2008-04-02 2:53 ` Richard Stallman 2008-04-02 12:44 ` paul r 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-04-02 2:53 UTC (permalink / raw) To: Mike Mattie; +Cc: emacs-devel There isn't a usual way for installing elisp libraries, The standard way is to put them in the directories that Emacs looks in: /usr/local/share/emacs/VERSION/site-lisp and /usr/local/share/emacs/site-lisp. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-04-02 2:53 ` Richard Stallman @ 2008-04-02 12:44 ` paul r 2008-04-02 17:34 ` Richard Stallman 0 siblings, 1 reply; 21+ messages in thread From: paul r @ 2008-04-02 12:44 UTC (permalink / raw) To: rms; +Cc: Mike Mattie, emacs-devel 2008/4/2, Richard Stallman <rms@gnu.org>: > The standard way is to put them in the directories that Emacs looks in: > /usr/local/share/emacs/VERSION/site-lisp and > /usr/local/share/emacs/site-lisp. - It is not writable as a user - it is not user-specific - there is no standard repository where to get librairies from - there is no standard way to fetch them - there is no automatic mean to keep them up to date. Emacs need a packaging system to give satisfactory solution to all theses problems. I know it has already been discussed here, and I do not aim to restart the debate (yet). But the proper, and universal way, to distribute such a large piece of software, is through a packaging system. Be the repositories under full control of the FSF. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-04-02 12:44 ` paul r @ 2008-04-02 17:34 ` Richard Stallman 2008-04-02 19:06 ` paul r 0 siblings, 1 reply; 21+ messages in thread From: Richard Stallman @ 2008-04-02 17:34 UTC (permalink / raw) To: paul r; +Cc: codermattie, emacs-devel - It is not writable as a user - it is not user-specific It would be useful to set up conventional per-user libraries that go in load-path. - there is no standard repository where to get librairies from We do not want one. Anything that WE want to distribute, we put into Emacs. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-04-02 17:34 ` Richard Stallman @ 2008-04-02 19:06 ` paul r 2008-04-02 21:07 ` Don Armstrong 0 siblings, 1 reply; 21+ messages in thread From: paul r @ 2008-04-02 19:06 UTC (permalink / raw) To: rms; +Cc: codermattie, emacs-devel 2008/4/2, Richard Stallman <rms@gnu.org>: > It would be useful to set up conventional per-user libraries > that go in load-path. It could help, yes. > - there is no standard repository where to get librairies from > > We do not want one. Anything that WE want to distribute, > we put into Emacs. Are you planing to impose this ditribution policy for gNewSens / gobuntu as well ? For the whole GNU OS ? I guess you don't. If you think Gnu/Linux distribution requirements differ from Gnu Emacs distribution requirements, could you please explain me how ? At this time, I can only see numerous similarities. Thanks -- Paul ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-04-02 19:06 ` paul r @ 2008-04-02 21:07 ` Don Armstrong 2008-04-03 4:30 ` Stephen J. Turnbull 0 siblings, 1 reply; 21+ messages in thread From: Don Armstrong @ 2008-04-02 21:07 UTC (permalink / raw) To: emacs-devel On Wed, 02 Apr 2008, paul r wrote: > Are you planing to impose this ditribution policy for gNewSens / > gobuntu as well ? For the whole GNU OS ? I guess you don't. If you > think Gnu/Linux distribution requirements differ from Gnu Emacs > distribution requirements, could you please explain me how ? At this > time, I can only see numerous similarities. There are similarities, but the differences is wherein the problems lie. There's pretty much no sane way to handle distribution in something besides a tarball which does not get into the way of what distributions are doing. [And really, packaging for distribution is what the distributions are (or at least should be) best at.] The distribution of emacs and packages which are used for emacs but are not part of emacs have largely been solved by distributions already. See Debian's emacs policy, for example. Don Armstrong -- Mozart tells us what it's like to be human, Beethoven tells us what it's like to be Beethoven, and Bach tells us what it's like to be the universe. -- Douglas Adams http://www.donarmstrong.com http://rzlab.ucr.edu ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-04-02 21:07 ` Don Armstrong @ 2008-04-03 4:30 ` Stephen J. Turnbull 2008-04-03 5:01 ` Don Armstrong 0 siblings, 1 reply; 21+ messages in thread From: Stephen J. Turnbull @ 2008-04-03 4:30 UTC (permalink / raw) To: Don Armstrong; +Cc: emacs-devel Don Armstrong writes: > The distribution of emacs and packages which are used for emacs but > are not part of emacs have largely been solved by distributions > already. See Debian's emacs policy, for example. I have. Debian's emacs policy is a frequent source of annoyance to XEmacs. The policy of trying to use a single package to serve both Emacsen, especially when it's a package we provide but GNU does not, often results in buggy behavior. I don't know that it can be done better from Debian's point of view, but from XEmacs's point of view, "largely solved" is an overstatement. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Feature Request : autoload-form 2008-04-03 4:30 ` Stephen J. Turnbull @ 2008-04-03 5:01 ` Don Armstrong 0 siblings, 0 replies; 21+ messages in thread From: Don Armstrong @ 2008-04-03 5:01 UTC (permalink / raw) To: emacs-devel On Thu, 03 Apr 2008, Stephen J. Turnbull wrote: > Don Armstrong writes: > > The distribution of emacs and packages which are used for emacs > > but are not part of emacs have largely been solved by > > distributions already. See Debian's emacs policy, for example. > > I have. Debian's emacs policy is a frequent source of annoyance to > XEmacs. The policy of trying to use a single package to serve both > Emacsen, First off, we distribute at least four flavors of emacsen, sometimes even 6 or 8. > especially when it's a package we provide but GNU does not, often > results in buggy behavior. In the cases where the addon package should not be loaded in xemacs, this can indeed be done using the existing system. When it's not known that it shouldn't be used in a particular flavor, splitting it out won't help, as the default would still be to have it work on all flavors of emacs (but with 4-8 times as many packages). [Flavor specific code sections can also be done, of course.] > I don't know that it can be done better from Debian's point of view, > but from XEmacs's point of view, "largely solved" is an > overstatement. If there are particular things that are suboptimal, filing bugs is the best way to document them and hopefully get them fixed. [I personally don't use Xemacs, so I'm not in a position to file them.] Don Armstrong -- "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." -- Jeremy S. Anderson http://www.donarmstrong.com http://rzlab.ucr.edu ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-04-03 5:01 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-28 20:05 Feature Request : autoload-form paul r 2008-03-29 4:20 ` Stefan Monnier 2008-03-29 9:49 ` paul r 2008-03-29 19:40 ` Stefan Monnier 2008-03-30 5:49 ` Richard Stallman 2008-03-30 11:24 ` paul r 2008-03-30 15:03 ` Stefan Monnier 2008-03-30 22:28 ` paul r 2008-03-31 7:58 ` Levin Du 2008-03-30 19:55 ` Richard Stallman 2008-03-30 21:35 ` Mike Mattie 2008-03-31 16:24 ` Richard Stallman 2008-03-31 17:36 ` paul r 2008-03-31 21:31 ` Mike Mattie 2008-04-02 2:53 ` Richard Stallman 2008-04-02 12:44 ` paul r 2008-04-02 17:34 ` Richard Stallman 2008-04-02 19:06 ` paul r 2008-04-02 21:07 ` Don Armstrong 2008-04-03 4:30 ` Stephen J. Turnbull 2008-04-03 5:01 ` Don Armstrong
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.