[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:
#+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
- RE: Emacs Lisp's future, (continued)
- RE: Emacs Lisp's future, Drew Adams, 2014/09/19
- Re: Emacs Lisp's future, Richard Stallman, 2014/09/18
- Re: Emacs Lisp's future, Rasmus, 2014/09/18
- Re: Emacs Lisp's future, Eric S. Raymond, 2014/09/19
- Re: Emacs Lisp's future, Emilio Lopes, 2014/09/23
- Re: Emacs Lisp's future, Jonas Bernoulli, 2014/09/26
- Re: Emacs Lisp's future, Christopher Allan Webber, 2014/09/26
- Re: Emacs Lisp's future, Phillip Lord, 2014/09/29
- Re: Emacs Lisp's future, Stefan Monnier, 2014/09/29
- Re: Emacs Lisp's future, Phillip Lord, 2014/09/29
- Re: Emacs Lisp's future,
Thorsten Jolitz <=
- Re: Emacs Lisp's future, Phillip Lord, 2014/09/30
- Re: Emacs Lisp's future, Nic Ferrier, 2014/09/30
- Re: Emacs Lisp's future, Thorsten Jolitz, 2014/09/30
- Re: Emacs Lisp's future, Thorsten Jolitz, 2014/09/30
- Re: Emacs Lisp's future, Nicolas Richard, 2014/09/30
- Re: Emacs Lisp's future, Thorsten Jolitz, 2014/09/30
- RE: Emacs Lisp's future, Drew Adams, 2014/09/30
- Re: Emacs Lisp's future, Stefan Monnier, 2014/09/26
- Re: Emacs Lisp's future, Richard Stallman, 2014/09/18
- Re: Emacs Lisp's future, Rasmus, 2014/09/18