From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thorsten Jolitz Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Tue, 30 Sep 2014 09:58:58 +0200 Message-ID: <87vbo55ykd.fsf@gmail.com> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <877g11c8wh.fsf@gmx.us> <87wq91uhe8.fsf@newcastle.ac.uk> <87k3508oie.fsf@gmx.us> <87mw9mqqb2.fsf@bernoul.li> <874mvufdes.fsf@earlgrey.lan> <87mw9iu8p8.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412063993 7949 80.91.229.3 (30 Sep 2014 07:59:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 07:59:53 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 30 09:59:46 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XYsLY-0006Jq-Ai for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 09:59:44 +0200 Original-Received: from localhost ([::1]:41361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYsLY-0003xW-0s for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 03:59:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYsLG-0003wn-Ji for emacs-devel@gnu.org; Tue, 30 Sep 2014 03:59:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XYsLA-0007xH-HH for emacs-devel@gnu.org; Tue, 30 Sep 2014 03:59:26 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:34749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYsLA-0007wr-AB for emacs-devel@gnu.org; Tue, 30 Sep 2014 03:59:20 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XYsL2-00064r-1F for emacs-devel@gnu.org; Tue, 30 Sep 2014 09:59:12 +0200 Original-Received: from e178063043.adsl.alicedsl.de ([85.178.63.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Sep 2014 09:59:12 +0200 Original-Received: from tjolitz by e178063043.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Sep 2014 09:59:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 71 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e178063043.adsl.alicedsl.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:Bb4kj2jHToahwIzvlBmC1LBcqMA= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174829 Archived-At: phillip.lord@newcastle.ac.uk (Phillip Lord) writes: > Christopher Allan Webber writes: >>> Instead of adding Magit as is, I would rather add certain components of >>> Magit to Emacs itself (after sufficiently abstracting them) and move >>> certain functionality into libraries that are already part of Emacs. >> >> That would be great. There are some features of magit that would be >> really nice to have available for all packages by being bundled with >> emacs. The popup menu system is pretty much the best, for example. > > It is really nice. There is a similar solution in org-mode (the export > dispatcher) and even in auctex (which is simpler but generally works out > the right thing to do for you). > > All of them are text, all of the fast and all of them easy to use (but > slightly different). Having a generic library that could be reused by > different packages would be great. I like these 'dispatcher popup-menus' too, they are a very nice UI feature in cases there are a lot of choices for the user. I once tried to reuse them in a project, but there is generally no separation of UI and logic, its all mixed up, so starting from scratch seemed easier than reusing what is already there. How would a generic UI generator look like in this case? Wouldn't it be very complicated to prompt the user for all the dispatcher-menu-UI properties? Where to put what on the dispatcher UI? May be an Org table would be a good input format: #+BEGIN_ORG | (key . fun) | | | |-------------+-------------+-------------| | | | | | (key . fun) | (key . fun) | (key . fun) | | (key . fun) | (key . fun) | | | | | | | (key . fun) | (key . fun) | | |-------------+-------------+-------------| | | (key . fun) | | #+END_ORG so that the user specifies the dispatcher-grid as an Org table, with hlines and key/function pairs, and a generic dispatcher-ui-generator function or macro then gets the nested-list representation of that Org table as argument: #+BEGIN_SRC emacs-lisp :results output raw (org-table-map-tables (lambda () (print (org-table-to-lisp)))) #+END_SRC #+results: (("(key . fun)" "" "") hline ("" "" "") ("(key . fun)" "(key . fun)" "(key . fun)") ("(key . fun)" "(key . fun)" "") ("" "" "") ("(key . fun)" "(key . fun)" "") hline ("" "(key . fun)" "")) or something like this, using the org-parser (untested): #+BEGIN_SRC emacs-lisp :results pp (org-element-map (org-element-parse-buffer) '(table table-row) 'identity) #+END_SRC -- cheers, Thorsten