Loading ...
Sorry, an error occurred while loading the content.

1515Re: [jasspa] Search path issue -- CWD, $HOME

Expand Messages
  • Jon Green
    Jul 1, 2005
      Meino Christian Cramer wrote:
      > From: Thomas Hundt <thundt@...>
      > Subject: Re: [jasspa] Search path issue -- CWD, $HOME
      > Date: Fri, 01 Jul 2005 08:35:20 -0700
      > Hihihihi....think of a newbie like me, who tries to create a new file
      > containing macros which "reconfigure" or add new features to the
      > behaviour of ME for editing just this kind of files! What a confusion
      > will rise in my head then !!! This will be a new definition of the
      > word "Recursion", muhahahahaha!
      > Hahahahhahahaha !.....
      > (sorry...this isn't meant negatively in ANY way...just my imagination
      > overruns myself :O)))
      > Meino

      Well after all of that I'm still not convinced of a problem under NORMAL use. Which the
      scenario that we use. For a normal install then the macros are installed in a location that
      is not normally that accessible:-

      c:/Program Files/JASSPA/MicroEmacs/macros - You should not edit in here.
      c:/Program Files/JASSPA/MicroEmacs/company - Yo can edit in here - supposed to be global.
      c:/Document Settings/<user>/Application Data/jasspa/ - You edit in here for local changes.

      /opt/jasspa/macros - You cannot edit in here as it is owned by root
      /opt/jasspa/company - Root may add macros in here for all users.
      $(HOME)/.jasspa - You edit in here for local changes

      You do not create .emf files anywhere else - a simple rule.

      The ./ directory is very useful this allows us to do things like the CD-ROM image where you
      can run ME without installation and it finds all of its macros. It is also used under
      Windows and DOS where there is no burnt in search path and the executable directory is used
      to locate the macros with no configuration information.

      I will admit that you can run into problems, especially with a new release, where a user
      file shadows a macro file and the results are unexpected. Most of the time when we are
      developing new macros then we have to cope with multiple macros issues (as you can imaging
      we typically have more than one set of complete macros and different versions of a binary
      image at the same time). In this instance I think there is something in the help that tells
      you on a new release you are advised to move your macro shadow out of the way to make it in
      accessible and then install your existing macros to make sure that there are not any problems.

      So despite the complaints I am still not convinced that it needs to change.

    • Show all 12 messages in this topic