Emacs as platform for the application

Emacs as platform for the application

[Artist]

Hi,
 I would like to deploy emacs based application.
 We have several users and I would like to put together the basic
application and then add the functionalities as per need base.
 This is what I have thought:
 To put emacs on the server and have the users running that program
with functions written let's say in perl accessed by keybinding.
 Now my users are not emacs aware and I would like to suppress all the
key binding  (except of course, something like self-insert-command)
other than what's absolutely required plus binding which can provide
functions written by me.
 Yuor suggestions would be valuable in dertermining the phases of
these application.

Thanks,
Artist

Re: Emacs as platform for the application

[Thomas F. Burdick]

googleartist@yahoo.com (Artist) writes:

> Hi,
>  I would like to deploy emacs based application.
>  We have several users and I would like to put together the basic
> application and then add the functionalities as per need base.
>  This is what I have thought:
>  To put emacs on the server and have the users running that program
> with functions written let's say in perl accessed by keybinding.
>  Now my users are not emacs aware and I would like to suppress all the
> key binding  (except of course, something like self-insert-command)
> other than what's absolutely required plus binding which can provide
> functions written by me.

I'm not positive I understand your question, but I think I do, and
I've done this before: you want to use Emacs as a programming
environment for making a somewhat-editor-like application that's not
actually an editor, and you don't want your end users to need to know
that it's Emacs underneath.

To do this, you want to build your own Emacs; the elisp manual
contains an introduction to this.  What you have temacs, load in the
ordinary parts of elisp that your application is going to use (or all
of it, to be safe), and your application code.  When dumping the full
emacs, you can ctonrol what happens at startup.  Have startup start up
your application, and then you control all the keybindings, menu
items, etc., in the initial buffer.  If you don't bind ordinary
functions like execute-extended-command, find-file, etc., then your
users can't call them.  You get the normal Emacs event loop, the mode
line, minibuffer, and menu bar, but apart from that, you can control
things to the extent that your users don't have to have any idea
they're using Emacs[*].  If you're going to distribute this
application (internal "distribution" in an organization doesn't
count), you should look into the licensing issues, as I think it would
fall under the GPL (whereas if you just used a standard Emacs as your
environment, you could distribute your application seperately under
whatever terms you wanted).

[*] Of course, you should still credit Emacs somewhere, like an About
box that says "this application is built on GNU Emacs" -- but you can
control the application to the extent that your users won't need to
realize this.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

Re: Emacs as platform for the application

[Kai Großjohann]

tfb@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> To do this, you want to build your own Emacs; the elisp manual
> contains an introduction to this.  What you have temacs, load in the
> ordinary parts of elisp that your application is going to use (or all
> of it, to be safe), and your application code.  When dumping the full
> emacs, you can ctonrol what happens at startup.  Have startup start up
> your application, and then you control all the keybindings, menu
> items, etc., in the initial buffer.

Is it really better than "emacs -l foo.el -f foo-init"?  It seems
like a lot of work for little gain.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Emacs as platform for the application

[Artist]

tfb@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<xcvlm5xsu7r.fsf@hurricane.OCF.Berkeley.EDU>...
> googleartist@yahoo.com (Artist) writes:

First of all thanks for such a good answer.
> 
> 
> I'm not positive I understand your question, but I think I do, and
> I've done this before: you want to use Emacs as a programming
> environment for making a somewhat-editor-like application that's not
> actually an editor, and you don't want your end users to need to know
> that it's Emacs underneath.

Yep, I would like to have it a reading application, where people can
search the stuff in big file in a variety of ways.

I also want to build a

> 
> To do this, you want to build your own Emacs;   You get the normal Emacs event loop, the mode
> line, minibuffer, and menu bar, but apart from that, you can control
> things to the extent that your users don't have to have any idea
> they're using Emacs[*].  

The idea
If you're going to distribute this
> application (internal "distribution" in an organization doesn't
> count), you should look into the licensing issues, as I think it would
> fall under the GPL (whereas if you just used a standard Emacs as your
> environment, you could distribute your application seperately under
> whatever terms you wanted).
> 
> [*] Of course, you should still credit Emacs somewhere, like an About
> box that says "this application is built on GNU Emacs" -- but you can
> control the application to the extent that your users won't need to
> realize this.
>

Re: Emacs as platform for the application

[Thomas F. Burdick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> tfb@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> > To do this, you want to build your own Emacs; the elisp manual
> > contains an introduction to this.  What you have temacs, load in the
> > ordinary parts of elisp that your application is going to use (or all
> > of it, to be safe), and your application code.  When dumping the full
> > emacs, you can ctonrol what happens at startup.  Have startup start up
> > your application, and then you control all the keybindings, menu
> > items, etc., in the initial buffer.
> 
> Is it really better than "emacs -l foo.el -f foo-init"?  It seems
> like a lot of work for little gain.

Well, it depends on your goal.  I've only done this for one
application, but in that case it was worth it.  I didn't want to
deliver a full emacs, and it simplified things for the end user.  Most
of the time, though, you're right -- if you know the exact platform
(which you need to for my suggestion), you can distribute something
that puts files in the right places, and a shell script to start up
the application.

As for the "a lot of work" part, it's only a lot of work if you don't
know how to build Emacs.  And even still, relative to the amount of
work you'd put into an application you'd want to deliver this way,
it's probably trivial.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'