jed extensions and startup file names

[Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx>]

On Fri, 5 Apr 2002 00:48:50 +0200 wrote ks <klaus.schmid@xxxxxx>:

> Not sure what your target is: names of jed config files or a convention
> how to implement jed extensions.

I'd like to kill two birds with one stone (maybe missing both)

Still I believe these two to be related: If I have a nice setup for jed
extensions it is straightforward to put the config files there as well.
(And I need only one name for user, side-wide and standard config. :-)

> The latter seems much more difficult or even impossible to organize. A user
> might install, try and use different extensions, written by different
> authors, different updates, same function names, ... all in parallel -- not
> in time scope but locally. IMO there can be no superseded instance but the
> user to handle this. All we can do is to make the install and remove
> sequence of an extension package as easy and safe as possible.

This is, why I want a default directory for a user-library that is prepended
to the jed library path (if existent).

This would IMHO make the extending/modification of jed far easier. 

(At least, I started to write some small slang scripts and modifications to
existing files long before I was able to gather the concept of
  set_jed_library_path(sprintf("my_library_path,%s", get_jed_library_path());
and (living on DOS at that time) put the stuff in the standard library where
it got overwritten by the next release.)

> Or would you like to collect permanently all new extension packages and
> install a debian-like package management?

No. All I want is:
  + Have ~/.jed/lib prepended to the jed library path.
And then I can  
  + Have some subdirectories there (that are not in the library path)
       contribs/    % for stuff downloaded somewhere
       projects/    % for stuff that still needs debugging or is stalled
  + Use make_ini.sl to create a file ini.sl that has autoload commands for the
    functions defined in my library (but not in the subdirs).
  + evaluate this ini.sl from my .jedrc  

> IMO the most would be done, if an extension package would
> be designed to ease installation and removing:
>
> - unzip a package to a folder of my choice, e.g. gm2

    gm2/ is a subdir of your library, right?

> - insert one line in my jed.rc (or do it at the slang prompt)
>   evalfile( "gm2/gmini.sl");

    + For files that provide one main function, I prefer
        autoload("extract_mini_doc", "gmini.sl");

    + For files that offer basic functionality (and hence should be evaluated
      at startup) I favour
        require("gm2/cuamark.sl")
      so the file will not be evaluated twice if another file needs the
      functionality.

    + For a first time test, I usually load the file into the buffer and do
      M-Return (which is my slang-mode binding for evalbuffer())

> - avoid heavy startup loading,

> % description of commands included in the package...

  for the public ones, preferabely using the tm macros, so a online-help
  can be produced easily. (Dinos tm_make_doc is much of a help here.)

> % proposal to bind some commands to keys...

  As long as this are only proposals, ok. I dislike modules that mess in my
  bindings.

> % proposal to define some custom variables...

  This is, why my make_ini.sl puts comments about custom variables in
  the produced ini.sl (if in verbose mode)

> % ....

  classify the functions by using

  static define  % if only used inside the script (and not bound to a key
                 % or (part of) a hook)
  define         % if intended for use from inside the script but needs
                 % to be accessible from outside (bound to key in a
                 % mode specific keymap, hooks)
  public define  % if intended to be started from outside 
                    % (autoload, bound to Global key, menu)
                 
  This way, make_ini (or Johns recently mailed script) can create the
  relevant autoload commands.

> - removing temporarily just by commenting out in jed.rc:
>   % evalfile( "gm2/gmini.sl");

My scheme is: after a test phase with require("gm2/gmini.sl") I move the
script to the library and do M-x update_ini. Removing can be done by moving
to a subdirectory again and updating the ini.sl.


Guenter


--
G.Milde@xxxxxxxxxxxxxxxxxxxx


--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.