Jayakrishnan Nair | 1 May 02:00 2004
Picon

RE: JDE 2.3.4beta2 and jde-import-all

I was able to use 2.3.4beta2 successfully. This is what I have in my
~/.emacs

(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/jde-2.3.4beta2/lisp"))
(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/semantic-1.4.4"))
(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/speedbar-0.14beta4"))
(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/elib-1.0"))
(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/eieio-0.17"))

Now to use cedet I did the following

(load-file
"c:/Applications/Editor/emacs-lib/cedet-1.0beta2a/common/cedet.el")
(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/jde-2.3.4beta2/lisp"))
(add-to-list 'load-path 
	     (expand-file-name
"c:/Applications/Editor/emacs-lib/elib-1.0"))

(Continue reading)

Suraj Acharya | 1 May 02:28 2004
Picon

Re: JDE 2.3.4beta2 and jde-import-all

On Fri, 30 Apr 2004 17:00:14 -0700, Jayakrishnan Nair
<tiptronicus <at> hotmail.com> wrote:
> 
[snip]
> 
> File error: "Cannot open load file", "semantic-loaddefs"
> 
> What am I missing ?

That's a generated file. Did you compile cedet sucessfully?

Suraj

David PONCE | 3 May 13:45 2004
Picon

Avoid JDEE to shadow standard libraries

Hi Paul,

For compatibility reason, the JDEE's distribution can include
"standard" libraries, because they are not provided in certain X?Emacs
distributions.

The last example is the sregex library which is pre-installed in GNU
Emacs but not exist in XEmacs.

I think it is always better to use a standard pre-installed library
when possible to benefit of fixes and improvements.

The problem with including a such library in JDEE, is that it can
shadow the standard library if the JDEE is added in front of the
predefined `load-path' (which is probably the case, at least in most
GNU Emacs installations).

So to use the library from the Emacs distribution, it is necessary
either to append the JDEE lisp directory to `load-path' or to remove
the duplicate library from the JDEE distribution.

IMO, this is neither convenient nor satisfactory.

What I propose is first to rename such third party libraries in the
JDEE distribution, to prefix them with `jde-'.  For example, sregex.el
will become jde-sregex.el.

Then, introduce a new `jde-require' function, equivalent to the
built-in `require' function, which will try first to do a "normal"
require of a feature, then, if it failed, try to require it from an
(Continue reading)

Paul Kinnucan | 3 May 14:23 2004
Picon

Avoid JDEE to shadow standard libraries

David PONCE writes:
 > Hi Paul,
 > 
 > For compatibility reason, the JDEE's distribution can include
 > "standard" libraries, because they are not provided in certain X?Emacs
 > distributions.
 > 
 > The last example is the sregex library which is pre-installed in GNU
 > Emacs but not exist in XEmacs.
 > 
 > I think it is always better to use a standard pre-installed library
 > when possible to benefit of fixes and improvements.
 > 
 > The problem with including a such library in JDEE, is that it can
 > shadow the standard library if the JDEE is added in front of the
 > predefined `load-path' (which is probably the case, at least in most
 > GNU Emacs installations).
 > 
 > So to use the library from the Emacs distribution, it is necessary
 > either to append the JDEE lisp directory to `load-path' or to remove
 > the duplicate library from the JDEE distribution.
 > 
 > IMO, this is neither convenient nor satisfactory.
 > 

Hi David,

I originally considered naming the JDEE copy jde-sregex and requiring
it if sregex was not installed to avoid shadowing the copy in the
Emacs distribution but decided not to as I didn't think such shadowing
(Continue reading)

David PONCE | 3 May 14:47 2004
Picon

Re: Avoid JDEE to shadow standard libraries

> I originally considered naming the JDEE copy jde-sregex and requiring
> it if sregex was not installed to avoid shadowing the copy in the
> Emacs distribution but decided not to as I didn't think such shadowing
> would ever cause a problem in the case of such an obscure, little
> used, and stable library as sregex.

You're right about sregex.  However, unless it is justified, I think
to avoid shadowing standard features is a good general principle,
that can turn out to be useful for more used and less obscure
libraries ;-)

Another example that come to my mind is tree-widget, which is about to
be included in GNU Emacs, with new capabilities like image themes
support to draw nice-looking trees.

> 
> Nevertheless, I will do this now to allay your concern.

Thanks!

David

Jason Rumney | 3 May 16:26 2004
Picon

Re: Avoid JDEE to shadow standard libraries

David PONCE <david.ponce <at> wanadoo.fr> writes:

> +   (condition-case nil
> +       ;; If the library if available, use it.
> +       (require feature)
> +     (error
> +      ;; Try to use the one from the JDEE's distribution.
> +      (require feature (format "jde-%s" feature)))))

It might be cleaner to use:

(if (not (require feature nil t))
    (require feature (format "jde-%s" feature)))

David Ponce | 3 May 19:41 2004
Picon

Re: Avoid JDEE to shadow standard libraries

Jason Rumney wrote:
> David PONCE <david.ponce <at> wanadoo.fr> writes:
> 
> 
>>+   (condition-case nil
>>+       ;; If the library if available, use it.
>>+       (require feature)
>>+     (error
>>+      ;; Try to use the one from the JDEE's distribution.
>>+      (require feature (format "jde-%s" feature)))))
> 
> 
> It might be cleaner to use:
> 
> (if (not (require feature nil t))
>     (require feature (format "jde-%s" feature)))
> 
> 

The problem is that the XEmacs version of `require' doesn't
support the optional NOERROR flag :-(

Latchezar Dimitrov | 4 May 01:26 2004

RE: Avoid JDEE to shadow standard libraries

Hi,

I know you realize it but I could not help making it explicit - you're
suggesting to get rid of "shadowing" a "feature" by doing very much
similar thing to "require"  :-)

Latchezar

> -----Original Message-----
> From: Jason Rumney [mailto:jasonr <at> gnu.org] 
> Sent: Monday, May 03, 2004 10:27 AM
> To: david.ponce <at> wanadoo.fr
> Cc: Paul Kinnucan; jdee
> Subject: Re: Avoid JDEE to shadow standard libraries
> 
> David PONCE <david.ponce <at> wanadoo.fr> writes:
> 
> > +   (condition-case nil
> > +       ;; If the library if available, use it.
> > +       (require feature)
> > +     (error
> > +      ;; Try to use the one from the JDEE's distribution.
> > +      (require feature (format "jde-%s" feature)))))
> 
> It might be cleaner to use:
> 
> (if (not (require feature nil t))
>     (require feature (format "jde-%s" feature)))
> 
> 
(Continue reading)

Schmitt, Christian (ext. | 4 May 08:57 2004

RE: Avoid JDEE to shadow standard libraries

> -----Original Message-----
> From: David Ponce [mailto:david.ponce <at> wanadoo.fr]
> Sent: Monday, May 03, 2004 7:41 PM
> To: Jason Rumney
> Cc: Paul Kinnucan; jdee
> Subject: Re: Avoid JDEE to shadow standard libraries
> 
> 
> Jason Rumney wrote:
> > David PONCE <david.ponce <at> wanadoo.fr> writes:
> > 
> > 
> >>+   (condition-case nil
> >>+       ;; If the library if available, use it.
> >>+       (require feature)
> >>+     (error
> >>+      ;; Try to use the one from the JDEE's distribution.
> >>+      (require feature (format "jde-%s" feature)))))
> > 
> > 
> > It might be cleaner to use:
> > 
> > (if (not (require feature nil t))
> >     (require feature (format "jde-%s" feature)))
> > 
> > 
> 
> The problem is that the XEmacs version of `require' doesn't
> support the optional NOERROR flag :-(
> 
(Continue reading)

David PONCE | 4 May 09:08 2004
Picon

Re: Avoid JDEE to shadow standard libraries

>>The problem is that the XEmacs version of `require' doesn't
>>support the optional NOERROR flag :-(
>>
> 
> XEmacs 21.4.15
> 
> C-h f require RET
> `require' is a compiled Lisp function
> (require FEATURE &optional FILENAME NOERROR)
> 
> Documentation:
> If feature FEATURE is not loaded, load it from FILENAME.
> If FEATURE is not a member of the list `features', then the feature
> is not loaded; so load the file FILENAME.
> If FILENAME is omitted, the printname of FEATURE is used as the file name,
> but in this case `load' insists on adding the suffix `.el' or `.elc'.
> If the optional third argument NOERROR is non-nil,
> then return nil if the file is not found.
> Normally the return value is FEATURE.
> 
> 
> Hth,
> Christian
> 
Weird.  I use:

XEmacs 21.4.15 "Security Through Obscurity" configured for `i686-pc-linux'.

xemacs -q -no-site-file
C-h f require RET
(Continue reading)


Gmane