From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fren Zeee Newsgroups: gmane.emacs.help Subject: Emacs Plugin Date: Sun, 27 Jun 2010 21:58:08 -0700 (PDT) Organization: http://groups.google.com Message-ID: <2ad7d91d-3081-4f4a-9961-c8bac5eaf6ef@d37g2000yqm.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1291840280 23548 80.91.229.12 (8 Dec 2010 20:31:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Dec 2010 20:31:20 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 08 21:31:16 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQQfT-0004JD-5D for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 21:31:15 +0100 Original-Received: from localhost ([127.0.0.1]:37416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQQfS-0008PN-1P for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Dec 2010 15:31:14 -0500 Original-Path: usenet.stanford.edu!postnews.google.com!d37g2000yqm.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help,comp.emacs.xemacs,comp.emacs Original-Lines: 68 Original-NNTP-Posting-Host: 75.30.150.100 Original-X-Trace: posting.google.com 1277701088 30031 127.0.0.1 (28 Jun 2010 04:58:08 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Mon, 28 Jun 2010 04:58:08 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d37g2000yqm.googlegroups.com; posting-host=75.30.150.100; posting-account=Xy1x0QoAAAC1_8XWVbTILoO5VL5JMCDm User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6,gzip(gfe) Original-Xref: usenet.stanford.edu gnu.emacs.help:179290 comp.emacs.xemacs:82456 comp.emacs:100119 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:75983 Archived-At: Emacs Plugin An Emacs Plugin is platform dependent code, probably written in c, that is dynamically loaded as an OS =93library=94 through a ForeignFunctionInterface? to accomplish goals that are usually outside the scope of Emacs. Mostly this means buffers could contain the core functionality of a wide variety of applications. Examples include: * Video/Audio player and editor. * Image editor as part of the viewer. Some suggested technologies: http://XaraXtreme.org , InkScape, Gimp, GraphicsMagick? * Browse and mail with the Gecko engine. Never start FireFox or ThunderBird? again. * This might even work for games. Should probably have the option to =91pause=92 the execution and even =91page-out=92 the memory when you switch away from that buffer. >From WishList It would be really cool, if the emacs display engine would support the drawing of circles, lines, boxes. This would allow the creation of vector graphics within emacs. It would be enough to have some graphics only buffers for a start. With such an addition one could write a xfig mode. Well, I am only dreaming. =96 StefanReichoer * You can create images (using =91create-image=92) and insert them into buffers (using =91put-image=92) within Emacs. You could also fix the Emacs redisplay engine such that stuff created via the XlibInterface (see PixelDrawing) do not get erased on the next redisplay. =96 AlexSchroeder * Whatever you do, the Emacs display engine is line-oriented, for editing text. It=92s clearly not suitable as a vector graphics editor, and why should it be? * Rather than asking emacs to become half vector-graphics editor, I=92d like to see emacs support, as modules, buffers of types other than text. =96 TomBreton * So in your vector-graphics example, you would write your circle, box etc drawing code, and you=92d write a data structure and tell emacs that it was a type of buffer and should be displayed via your display code, all without changing emacs itself. * And if your extension was horrendous, nobody else is bothered; if it was a niche thing, others who like it can load it or link it in and still share the rest of emacs with everyone else; and if it=92s nice it=92s easy to include it later in emacs proper. * Some thoughts towards implementation: o Each such module would supply its own data representation (Model) and display engine that would assume it was dealing with an emacs window (View), and data inspection and mutation primitives controlled via elisp (Controller). o Some existing buffer fields would be common to all buffer types (eg buffer name, save_modified, modtime, auto_save_modified, backed_up, etc), some would be heterogeneous but retain a common structure (eg undo_list, markers), and some would become specific to text buffers (eg last_window_start, display_table, syntax_table_v). o Like buffer, window would share some existing fields (most), structurally share some (pointm, last_point, region_showing), and some would become specific to text (start, display_table, base_line_number, base_line_pos). o C functions that now assume a buffer is a text-buffer would check buffer type before proceeding. Fset_window_buffer (I think, looking at window.c) would know to call a non-text buffer=92s own display function. =96 TomBreton * You can make SVG images with lisp and display them in Emacs buffers. See EmacsSvg.See EmacsXembed for work on embedding other applications inside Emacs =96 JoakimVerona