[Jed-users-l] calendar command, overwriting basic functions

["R. Stewart Ellis" <ellis@xxxxxxxxxxxxx>]

I am running ubuntu 10.0.4 LTS with their packages of jed, jed-extra, etc..
It shows Jed 0.99.19U on the modeline.

When I try to run the calendar function a couple of odd things happen.  One,
if I type M-ecale<TAB> I am prompted with two instances of calendar.  If I
complete the command and type <RET> I get a message 
"Unable to open /home/stew/calendar: No such file or directory"

Same thing happens if I try to run calendar from the menu.

I believe I am on the track to solve the problem.  The debian packagers do
some magic which ends up with both /usr/share/jed/lib/cal.sl and
/usr/share/jed-extra/drop-in/calendar.sl defining a public function named
calendar.

I would actually like both functions, so I am going to have to figure out
how to name them so they do not clobber each other.  But this does bring up
a larger point: as valuable as some of the extras seem to be, programmers
and packagers need to avoid breaking pieces of the basic distribution of
jed.  It also needs to be easier for a new user, even someone like me with
>25 years of UNIX and C sysadmin with some programming, to put the pieces
together.  I do not know how influential John is, particularly with the
debian packagers, but I would like to see a more modular way of adding
modifications/enhancements to the base rather than the current way which
depends on the order in which modules are loaded.

I haven't been thinking about this long, but have some ideas.

For something that is truly a drop-in replacement for one of the basic
modules, there could be a directory, let's call it "drop-ins" at the same
level as "lib" and "jed-extra", and a directory also at that level called
"distrib-replaced".  It would be the responsibility of a programmer
"improving" a package to clearly document how to uninstall the replaced
package and replace it with the improved package.  For example, the replaced
function would be mv'ed to the distrib-replaced dir and replaced by a
symlink in the libdir to the replacement in the drop-in dir.  Anyone coming
to that system would be able to tell what of the standard files had been put
aside.

For functions that are truly new, they could simply be put into the
jed-extra dir if they did not clobber any of the functions in the basic
distribution.  They could also be symlinked into the lib dir.  If the new
functions also needed enhanced versions of original functions, then the
programmer might have to write a drop-in and an extra with a note at the top
of the code in each that the two depend on each other.

Does anyone have any comments?

-- 
   R.Stewart(Stew) Ellis,Prof.Appl.Socl.Informatics  Kettering University/
   Liberal Studies Dept. ellis@xxxxxxxxxxxxx  ()    ___________________
   Flint, MI 48504 810-762-9765 Free software /\   /   _____  ______
   Webmaster emeritus:  www.kettering.edu         /________/ /  /  / /
_______________________________________________
Jed-users-l mailing list
Jed-users-l@xxxxxxxx
http://mailman.jtan.com/mailman/listinfo/jed-users-l