[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future

From: Thorsten Jolitz
Subject: Re: Emacs Lisp's future
Date: Tue, 30 Sep 2014 09:58:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

address@hidden (Phillip Lord) writes:

> Christopher Allan Webber <address@hidden> 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:

| (key . fun) |             |             |
|             |             |             |
| (key . fun) | (key . fun) | (key . fun) |
| (key . fun) | (key . fun) |             |
|             |             |             |
| (key . fun) | (key . fun) |             |
|             | (key . fun) |             |

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

#+BEGIN_SRC emacs-lisp :results output raw
 (lambda () (print (org-table-to-lisp))))

(("(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)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]