#30 NEDIT_HOME

development
closed
Program (79)
5
2002-07-09
2001-11-22
Thorsten Haude
No

(I don't know why I always forget this this SF thing.)

This will introduce the environmental variable
$NEDIT_HOME. If set, the names of the three NEdit
config files will be renamed as follows:

$HOME/.nedit -> $NEDIT_HOME/nedit.rc
$HOME/.neditmacro -> $NEDIT_HOME/autoload.nm
$HOME/.neditdb -> $NEDIT_HOME/nedit.history

This is checked on Linux and Solaris, the VMS name
creation algorithm is also checked.

Discussion

<< < 1 2 3 4 > >> (Page 3 of 4)
  • Thorsten Haude
    Thorsten Haude
    2002-01-13

    Logged In: YES
    user_id=119143

    Update

     
  • Thorsten Haude
    Thorsten Haude
    2002-02-09

    Logged In: YES
    user_id=119143

    Update

     
  • Thorsten Haude
    Thorsten Haude
    2002-02-09

    Update

     
    Attachments
  • Eddy De Greef
    Eddy De Greef
    2002-03-16

    common code in a utility function

     
    Attachments
  • Eddy De Greef
    Eddy De Greef
    2002-03-16

    Logged In: YES
    user_id=73597

    It looks good. I just have one remark on the implementation:
    there's a lot of duplicate (or should I say triplicate) code
    for constructing the various file names. It's better to
    isolate this because it's easier to extend and debug.

    I've uploaded a revised version of your patch, in which the
    common code is put in a separate utility function. Can you
    have a look at it ? (It also avoids dynamic allocation of
    the path names.)

    I'm in favour of including this in CVS.

     
  • Eddy De Greef
    Eddy De Greef
    2002-03-17

    Logged In: YES
    user_id=73597

    One more thing: are you sure about the way the VMS path
    names are generated? It looks suspicious to me, but I don't
    know how VMS specifies path names.

     
  • Thorsten Haude
    Thorsten Haude
    2002-03-17

    Logged In: YES
    user_id=119143

    I have separate functions because I want to avoid
    coupling. These are little more than glorified string
    copys, and any one of them could change in the future. If
    the naming system gets more elaborate, chances are that at
    least the autoload file name will be build differently, so
    extension is actually easier this way.
    I basically weighted DRY against KISS, and KISS won for me.

    What do you think?

    Wrt the dynamic allocation: Is that a bad thing?

     
  • Thorsten Haude
    Thorsten Haude
    2002-03-17

    Logged In: YES
    user_id=119143

    Wrt VMS: That's the best I could get out of the
    discussions in the list.

     
  • Eddy De Greef
    Eddy De Greef
    2002-03-18

    Logged In: YES
    user_id=73597

    Saying that it's easier to customize is a poor
    excuse for having duplicate code, especially
    since it's not 1 or two lines we're talking about,
    but a relatively complex piece of code (precondition
    checking, platform dependent, ...)

    If necessary, it's always easy to copy and paste
    shared functionality to customize it later on.

    Dynamic allocation is totally unnecessary here,
    so it should be avoided (it could only confuse
    leak detection tools). Moreover, there's absolutely
    no reason to use an X String iso. a char*, and the
    implicit conversion between the two in your code is
    to be avoided too.

     
  • Thorsten Haude
    Thorsten Haude
    2002-05-09

    Update 2002-05-09

     
    Attachments
<< < 1 2 3 4 > >> (Page 3 of 4)