External programs and resources

External programs and resources

[Lennart Borgman]

I have not been able to find a common entrypoint for external resources from
Emacs. I would for example appreciate if there was only one place where the
path to a program like Ghostview was entered.

I would suggest that customization of things like this should be in one or
several lisp modules that could be used by other modules.

My apologies if this has already been done or discussed before.

- Lennart

Re: External programs and resources

[Stefan Monnier]

> I have not been able to find a common entrypoint for external resources from
> Emacs. I would for example appreciate if there was only one place where the
> path to a program like Ghostview was entered.

> I would suggest that customization of things like this should be in one or
> several lisp modules that could be used by other modules.

> My apologies if this has already been done or discussed before.

It might be a good idea, but since packages are developed separately by
manny people who don't know each other, it's not always so easy (especially
because you also still want to be able to specify different values
sometimes, because you might sometimes want to use one version of `gv' for
one package and another for some other package).

In the short term, the best we can do is find those redundant customizations
and unify them.  Which ones were you thinking of?


        Stefan

Re: External programs and resources

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>


> > I have not been able to find a common entrypoint for external resources
from
> > Emacs. I would for example appreciate if there was only one place where
the
> > path to a program like Ghostview was entered.
>
> > I would suggest that customization of things like this should be in one
or
> > several lisp modules that could be used by other modules.
>
> It might be a good idea, but since packages are developed separately by
> manny people who don't know each other, it's not always so easy
(especially
> because you also still want to be able to specify different values
> sometimes, because you might sometimes want to use one version of `gv' for
> one package and another for some other package).

Maybe this can be resolved rather easily, at least in principle. The
organisation could perhaps be like this:

- A common elisp module (ext-prog.el?) where for each external program used
by emacs there is a "defcustom" variable for its path. If not set this could
be initialized by executable-find perhaps.

- If a lisp module is using an external program listed in "ext-prog.el" it
can use the corresponding variable.

- If this module however want to give the possibility to use another version
of the program than the one pointed to by the "ext-prog.el" variable it can
define a function that uses a NON-"defcustom" variable defined in this
package
if it is set, otherwise the "ext-prog.el" variable. (I think it would be
confusing to have the second, module-specific variable defcustom too.)

- A customization group, maybe named "external-programs"?

> In the short term, the best we can do is find those redundant
customizations
> and unify them.  Which ones were you thinking of?

At the moment I was only thinking of Ghostview and it relatives.

- Lennart

Re: External programs and resources

[Richard Stallman]

I don't think we should make rearrangements such as this now.
We are trying to move towards making a release.

Re: External programs and resources

[Alex Schroeder]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> - A customization group, maybe named "external-programs"?

Normally developers define a group, and when defining variables, they
assign the group with it.

Custom allows you to do the inverse, too:  Define a group together
with all the variables belonging to it -- the members.  Therefore
somebody could get started working on something like that, and post
his defgroup statement here for others to consider.  Once we are
happy, such a file would be easy to add to Emacs -- no other files are
touched!  And it wouldn't run against the feature freeze.  :)

There is a page on the Emacs Wiki, for example, where people tried to
collect the variables newbies are most likely to customize so that we
can just offer them in a "Most Useful" group or something like that.
Unfortunately, it seems that people lost interest (including me,
ahem).

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: External programs and resources

[Lennart Borgman]

Good point, I will keep it off the list until later.

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>


> I don't think we should make rearrangements such as this now.
> We are trying to move towards making a release.