* Overlays and elisp code
@ 2011-01-31 10:04 Andrea Crotti
2011-01-31 20:04 ` Jeff Horn
0 siblings, 1 reply; 9+ messages in thread
From: Andrea Crotti @ 2011-01-31 10:04 UTC (permalink / raw)
To: emacs-orgmode
I found a strange behaviour which might be a bug, but maybe of my
configuration.
This is org mode version:
Org-mode version 7.4 (release_7.4.199.g8be1.dirty)
and emacs:
"GNU Emacs 23.2.1 (x86_64-apple-darwin10.3.0, NS apple-appkit-1038.29)
of 2010-05-09 on linc"
To reproduce the bug I do
- go over an elisp code block
- C-c ' to edit in the overlay
- C-c ' to go back when done
And it works perfectly, BUT if for example I remove a parenthesis before
pressing C-c ', I can't go back.
C-c ' becomes undefined and I have to kill both the overlay and the
original buffer.
While I was writing I also found the cause of the problem, Paredit!
Removing the hook from emacs-lisp-mode-hook fixes this, but paredit is
really useful with elisp, maybe someone has an idea of why this happens?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-01-31 10:04 Overlays and elisp code Andrea Crotti
@ 2011-01-31 20:04 ` Jeff Horn
2011-02-01 8:08 ` Andrea Crotti
2011-02-01 10:51 ` Dan Davison
0 siblings, 2 replies; 9+ messages in thread
From: Jeff Horn @ 2011-01-31 20:04 UTC (permalink / raw)
To: Andrea Crotti; +Cc: emacs-orgmode
I can reproduce this. emacs 23.1 and org 7.4
On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti
<andrea.crotti.0@gmail.com> wrote:
> I found a strange behaviour which might be a bug, but maybe of my
> configuration.
>
> This is org mode version:
> Org-mode version 7.4 (release_7.4.199.g8be1.dirty)
> and emacs:
> "GNU Emacs 23.2.1 (x86_64-apple-darwin10.3.0, NS apple-appkit-1038.29)
> of 2010-05-09 on linc"
>
> To reproduce the bug I do
> - go over an elisp code block
> - C-c ' to edit in the overlay
> - C-c ' to go back when done
>
> And it works perfectly, BUT if for example I remove a parenthesis before
> pressing C-c ', I can't go back.
>
> C-c ' becomes undefined and I have to kill both the overlay and the
> original buffer.
>
> While I was writing I also found the cause of the problem, Paredit!
> Removing the hook from emacs-lisp-mode-hook fixes this, but paredit is
> really useful with elisp, maybe someone has an idea of why this happens?
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
--
Jeffrey Horn
http://www.failuretorefrain.com/jeff/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-01-31 20:04 ` Jeff Horn
@ 2011-02-01 8:08 ` Andrea Crotti
2011-02-01 10:51 ` Dan Davison
1 sibling, 0 replies; 9+ messages in thread
From: Andrea Crotti @ 2011-02-01 8:08 UTC (permalink / raw)
To: emacs-orgmode
Jeff Horn <jrhorn424@gmail.com> writes:
> I can reproduce this. emacs 23.1 and org 7.4
>
Good that I'm not alone :)
Another thing is that also changing mode in the overlay messes things
up, but that's not an orgmode fault I think, it's just how they work...
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-01-31 20:04 ` Jeff Horn
2011-02-01 8:08 ` Andrea Crotti
@ 2011-02-01 10:51 ` Dan Davison
2011-02-01 11:01 ` Dan Davison
1 sibling, 1 reply; 9+ messages in thread
From: Dan Davison @ 2011-02-01 10:51 UTC (permalink / raw)
To: Jeff Horn; +Cc: emacs-orgmode, Andrea Crotti
Jeff Horn <jrhorn424@gmail.com> writes:
> I can reproduce this. emacs 23.1 and org 7.4
>
> On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti
> <andrea.crotti.0@gmail.com> wrote:
>> I found a strange behaviour which might be a bug, but maybe of my
>> configuration.
>>
>> This is org mode version:
>> Org-mode version 7.4 (release_7.4.199.g8be1.dirty)
>> and emacs:
>> "GNU Emacs 23.2.1 (x86_64-apple-darwin10.3.0, NS apple-appkit-1038.29)
>> of 2010-05-09 on linc"
>>
>> To reproduce the bug I do
>> - go over an elisp code block
>> - C-c ' to edit in the overlay
>> - C-c ' to go back when done
>>
>> And it works perfectly, BUT if for example I remove a parenthesis before
>> pressing C-c ', I can't go back.
>>
>> C-c ' becomes undefined and I have to kill both the overlay and the
>> original buffer.
>>
>> While I was writing I also found the cause of the problem, Paredit!
>> Removing the hook from emacs-lisp-mode-hook fixes this, but paredit is
>> really useful with elisp, maybe someone has an idea of why this happens?
Hi Andrea,
So it looks like paredit-mode refuses to start up (throws an error) if
the parentheses are unbalanced. So how about we use
#+begin_src emacs-lisp
(add-hook 'emacs-lisp-mode-hook
(lambda ()
(condition-case nil
(paredit-mode)
(error (message "Failed to activate paredit mode")))))
#+end_src
At the moment this message gets stamped on by a message which
org-edit-src always issues in the echo-area. I'm going to submit a patch
to control that in a subsequent email.
Oh no. You got me editing elisp with paredit mode turned on. Maybe it
will last more than 5 minutes this time :)
Dan
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-02-01 10:51 ` Dan Davison
@ 2011-02-01 11:01 ` Dan Davison
2011-02-01 11:08 ` Carsten Dominik
0 siblings, 1 reply; 9+ messages in thread
From: Dan Davison @ 2011-02-01 11:01 UTC (permalink / raw)
To: Jeff Horn; +Cc: emacs-orgmode, Andrea Crotti
>> On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti
>> <andrea.crotti.0@gmail.com> wrote:
>>> I found a strange behaviour which might be a bug, but maybe of my
>>> configuration.
[...]
>>> - go over an elisp code block
>>> - C-c ' to edit in the overlay
>>> - C-c ' to go back when done
>>>
>>> And it works perfectly, BUT if for example I remove a parenthesis before
>>> pressing C-c ', I can't go back.
>>>
>>> C-c ' becomes undefined and I have to kill both the overlay and the
>>> original buffer.
[...]
> So it looks like paredit-mode refuses to start up (throws an error) if
> the parentheses are unbalanced. So how about we use
>
> #+begin_src emacs-lisp
> (add-hook 'emacs-lisp-mode-hook
> (lambda ()
> (condition-case nil
> (paredit-mode)
> (error (message "Failed to activate paredit mode")))))
> #+end_src
>
> At the moment this message gets stamped on by a message which
> org-edit-src always issues in the echo-area.
When using C-c ', currently we can turn off the persistent message at
the top of the screen by setting `org-edit-src-persistent-message' to
nil, but we can't prevent the echo-area message without more code. The
echo area message may be useful for new users, but for experienced users
it is unnecessary and risks obscuring more useful messages.
This patch provides control over both messages. The relevant
customizable variable has a different name: `org-edit-src-messages'.
Dan
~~~~~~~~~~~~~~~~~~~~~~~~
Change user option for controlling edit buffer messages
* lisp/org-src.el (org-edit-src-messages): Change UI for controlling
educational messages when src-code generating edit buffer.
(org-edit-src-code): Implement control over persistent header message
and echo-area message.
#+begin_src diff
diff --git a/lisp/org-src.el b/lisp/org-src.el
index f55e292..ea9be6c 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -113,13 +113,16 @@ editing it with \\[org-edit-src-code]. Has no effect if
"If non-nil, blank lines are removed when exiting the code edit
buffer.")
-(defcustom org-edit-src-persistent-message t
- "Non-nil means show persistent exit help message while editing src examples.
-The message is shown in the header-line, which will be created in the
-first line of the window showing the editing buffer.
-When nil, the message will only be shown intermittently in the echo area."
+(defcustom org-edit-src-messages '(message header)
+ "Which messages to show when editing src examples.
+If 'header is a member of this list, then a message is shown in
+the header-line, which will be created in the first line of the
+window showing the editing buffer. If 'message is in the list,
+then a message will be displayed in the echo area."
:group 'org-edit-structure
- :type 'boolean)
+ :type '(set :greedy t
+ (const message)
+ (const header)))
(defcustom org-src-window-setup 'reorganize-frame
"How the source code edit buffer should be displayed.
@@ -320,9 +323,10 @@ buffer."
(org-set-local 'org-edit-src-block-indentation block-nindent)
(org-src-mode)
(set-buffer-modified-p nil)
- (and org-edit-src-persistent-message
+ (and (memq 'header org-edit-src-messages)
(org-set-local 'header-line-format msg)))
- (unless quietp (message "%s" msg))
+ (unless (or quietp (not (memq 'message org-edit-src-messages)))
+ (message "%s" msg))
t)))
(defun org-edit-src-continue (e)
#+end_src
> I'm going to submit a patch
> to control that in a subsequent email.
>
> Oh no. You got me editing elisp with paredit mode turned on. Maybe it
> will last more than 5 minutes this time :)
>
> Dan
>
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Re: Overlays and elisp code
2011-02-01 11:01 ` Dan Davison
@ 2011-02-01 11:08 ` Carsten Dominik
2011-02-01 11:22 ` Dan Davison
0 siblings, 1 reply; 9+ messages in thread
From: Carsten Dominik @ 2011-02-01 11:08 UTC (permalink / raw)
To: Dan Davison; +Cc: Jeff Horn, emacs-orgmode, Andrea Crotti
Hi Dan,
maybe just header in the default value to keep the echo area open for
error messages?
Cheers
- Carsten
On Feb 1, 2011, at 12:01 PM, Dan Davison wrote:
>>> On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti
>>> <andrea.crotti.0@gmail.com> wrote:
>>>> I found a strange behaviour which might be a bug, but maybe of my
>>>> configuration.
> [...]
>>>> - go over an elisp code block
>>>> - C-c ' to edit in the overlay
>>>> - C-c ' to go back when done
>>>>
>>>> And it works perfectly, BUT if for example I remove a parenthesis
>>>> before
>>>> pressing C-c ', I can't go back.
>>>>
>>>> C-c ' becomes undefined and I have to kill both the overlay and the
>>>> original buffer.
>
> [...]
>> So it looks like paredit-mode refuses to start up (throws an error)
>> if
>> the parentheses are unbalanced. So how about we use
>>
>> #+begin_src emacs-lisp
>> (add-hook 'emacs-lisp-mode-hook
>> (lambda ()
>> (condition-case nil
>> (paredit-mode)
>> (error (message "Failed to activate paredit mode")))))
>> #+end_src
>>
>> At the moment this message gets stamped on by a message which
>> org-edit-src always issues in the echo-area.
>
> When using C-c ', currently we can turn off the persistent message at
> the top of the screen by setting `org-edit-src-persistent-message' to
> nil, but we can't prevent the echo-area message without more code. The
> echo area message may be useful for new users, but for experienced
> users
> it is unnecessary and risks obscuring more useful messages.
>
> This patch provides control over both messages. The relevant
> customizable variable has a different name: `org-edit-src-messages'.
>
> Dan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
> Change user option for controlling edit buffer messages
>
> * lisp/org-src.el (org-edit-src-messages): Change UI for
> controlling
> educational messages when src-code generating edit buffer.
> (org-edit-src-code): Implement control over persistent header
> message
> and echo-area message.
>
> #+begin_src diff
> diff --git a/lisp/org-src.el b/lisp/org-src.el
> index f55e292..ea9be6c 100644
> --- a/lisp/org-src.el
> +++ b/lisp/org-src.el
> @@ -113,13 +113,16 @@ editing it with \\[org-edit-src-code]. Has no
> effect if
> "If non-nil, blank lines are removed when exiting the code edit
> buffer.")
>
> -(defcustom org-edit-src-persistent-message t
> - "Non-nil means show persistent exit help message while editing
> src examples.
> -The message is shown in the header-line, which will be created in the
> -first line of the window showing the editing buffer.
> -When nil, the message will only be shown intermittently in the echo
> area."
> +(defcustom org-edit-src-messages '(message header)
> + "Which messages to show when editing src examples.
> +If 'header is a member of this list, then a message is shown in
> +the header-line, which will be created in the first line of the
> +window showing the editing buffer. If 'message is in the list,
> +then a message will be displayed in the echo area."
> :group 'org-edit-structure
> - :type 'boolean)
> + :type '(set :greedy t
> + (const message)
> + (const header)))
>
> (defcustom org-src-window-setup 'reorganize-frame
> "How the source code edit buffer should be displayed.
> @@ -320,9 +323,10 @@ buffer."
> (org-set-local 'org-edit-src-block-indentation block-nindent)
> (org-src-mode)
> (set-buffer-modified-p nil)
> - (and org-edit-src-persistent-message
> + (and (memq 'header org-edit-src-messages)
> (org-set-local 'header-line-format msg)))
> - (unless quietp (message "%s" msg))
> + (unless (or quietp (not (memq 'message org-edit-src-messages)))
> + (message "%s" msg))
> t)))
>
> (defun org-edit-src-continue (e)
> #+end_src
>
>
>
>
>
>> I'm going to submit a patch
>> to control that in a subsequent email.
>>
>> Oh no. You got me editing elisp with paredit mode turned on. Maybe it
>> will last more than 5 minutes this time :)
>>
>> Dan
>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Emacs-orgmode mailing list
>>>> Please use `Reply All' to send replies to the list.
>>>> Emacs-orgmode@gnu.org
>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-02-01 11:08 ` Carsten Dominik
@ 2011-02-01 11:22 ` Dan Davison
2011-02-01 11:30 ` Carsten Dominik
0 siblings, 1 reply; 9+ messages in thread
From: Dan Davison @ 2011-02-01 11:22 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Jeff Horn, emacs-orgmode, Andrea Crotti
Carsten Dominik <carsten.dominik@gmail.com> writes:
> Hi Dan,
>
> maybe just header in the default value to keep the echo area open for
> error messages?
Absolutely. But if you prefer, we could just do away with the echo-area
message entirely. That would have the advantage of leaving the user
interface unchanged.
With the default as '(header), my UI change only makes sense if we
believe that an appreciable number of users will disable the header
message and activate the echo-area message in its place.
Dan
>
> Cheers
>
> - Carsten
>
> On Feb 1, 2011, at 12:01 PM, Dan Davison wrote:
>
>>>> On Mon, Jan 31, 2011 at 5:04 AM, Andrea Crotti
>>>> <andrea.crotti.0@gmail.com> wrote:
>>>>> I found a strange behaviour which might be a bug, but maybe of my
>>>>> configuration.
>> [...]
>>>>> - go over an elisp code block
>>>>> - C-c ' to edit in the overlay
>>>>> - C-c ' to go back when done
>>>>>
>>>>> And it works perfectly, BUT if for example I remove a parenthesis
>>>>> before
>>>>> pressing C-c ', I can't go back.
>>>>>
>>>>> C-c ' becomes undefined and I have to kill both the overlay and the
>>>>> original buffer.
>>
>> [...]
>>> So it looks like paredit-mode refuses to start up (throws an error)
>>> if
>>> the parentheses are unbalanced. So how about we use
>>>
>>> #+begin_src emacs-lisp
>>> (add-hook 'emacs-lisp-mode-hook
>>> (lambda ()
>>> (condition-case nil
>>> (paredit-mode)
>>> (error (message "Failed to activate paredit mode")))))
>>> #+end_src
>>>
>>> At the moment this message gets stamped on by a message which
>>> org-edit-src always issues in the echo-area.
>>
>> When using C-c ', currently we can turn off the persistent message at
>> the top of the screen by setting `org-edit-src-persistent-message' to
>> nil, but we can't prevent the echo-area message without more code. The
>> echo area message may be useful for new users, but for experienced
>> users
>> it is unnecessary and risks obscuring more useful messages.
>>
>> This patch provides control over both messages. The relevant
>> customizable variable has a different name: `org-edit-src-messages'.
>>
>> Dan
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Change user option for controlling edit buffer messages
>>
>> * lisp/org-src.el (org-edit-src-messages): Change UI for
>> controlling
>> educational messages when src-code generating edit buffer.
>> (org-edit-src-code): Implement control over persistent header
>> message
>> and echo-area message.
>>
>> #+begin_src diff
>> diff --git a/lisp/org-src.el b/lisp/org-src.el
>> index f55e292..ea9be6c 100644
>> --- a/lisp/org-src.el
>> +++ b/lisp/org-src.el
>> @@ -113,13 +113,16 @@ editing it with \\[org-edit-src-code]. Has no
>> effect if
>> "If non-nil, blank lines are removed when exiting the code edit
>> buffer.")
>>
>> -(defcustom org-edit-src-persistent-message t
>> - "Non-nil means show persistent exit help message while editing
>> src examples.
>> -The message is shown in the header-line, which will be created in the
>> -first line of the window showing the editing buffer.
>> -When nil, the message will only be shown intermittently in the echo
>> area."
>> +(defcustom org-edit-src-messages '(message header)
>> + "Which messages to show when editing src examples.
>> +If 'header is a member of this list, then a message is shown in
>> +the header-line, which will be created in the first line of the
>> +window showing the editing buffer. If 'message is in the list,
>> +then a message will be displayed in the echo area."
>> :group 'org-edit-structure
>> - :type 'boolean)
>> + :type '(set :greedy t
>> + (const message)
>> + (const header)))
>>
>> (defcustom org-src-window-setup 'reorganize-frame
>> "How the source code edit buffer should be displayed.
>> @@ -320,9 +323,10 @@ buffer."
>> (org-set-local 'org-edit-src-block-indentation block-nindent)
>> (org-src-mode)
>> (set-buffer-modified-p nil)
>> - (and org-edit-src-persistent-message
>> + (and (memq 'header org-edit-src-messages)
>> (org-set-local 'header-line-format msg)))
>> - (unless quietp (message "%s" msg))
>> + (unless (or quietp (not (memq 'message org-edit-src-messages)))
>> + (message "%s" msg))
>> t)))
>>
>> (defun org-edit-src-continue (e)
>> #+end_src
>>
>>
>>
>>
>>
>>> I'm going to submit a patch
>>> to control that in a subsequent email.
>>>
>>> Oh no. You got me editing elisp with paredit mode turned on. Maybe it
>>> will last more than 5 minutes this time :)
>>>
>>> Dan
>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Emacs-orgmode mailing list
>>>>> Please use `Reply All' to send replies to the list.
>>>>> Emacs-orgmode@gnu.org
>>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-02-01 11:22 ` Dan Davison
@ 2011-02-01 11:30 ` Carsten Dominik
2011-02-01 11:47 ` Dan Davison
0 siblings, 1 reply; 9+ messages in thread
From: Carsten Dominik @ 2011-02-01 11:30 UTC (permalink / raw)
To: Dan Davison; +Cc: Jeff Horn, emacs-orgmode, Andrea Crotti
On Feb 1, 2011, at 12:22 PM, Dan Davison wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi Dan,
>>
>> maybe just header in the default value to keep the echo area open for
>> error messages?
>
> Absolutely. But if you prefer, we could just do away with the echo-
> area
> message entirely. That would have the advantage of leaving the user
> interface unchanged.
>
> With the default as '(header), my UI change only makes sense if we
> believe that an appreciable number of users will disable the header
> message and activate the echo-area message in its place.
There are people who hate the header line IIRC. But I guess you are
right - once people are ready to remove the header line for this
application, they will probably have memorized it.
I remember that I started with the echo area and introduced the header
line because people were asking how to get out of there, so I needed
something more persistent.
So I guess if the header line is the default, I'd be fine with
removing the echo area message altogether.
- Carsten
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Overlays and elisp code
2011-02-01 11:30 ` Carsten Dominik
@ 2011-02-01 11:47 ` Dan Davison
0 siblings, 0 replies; 9+ messages in thread
From: Dan Davison @ 2011-02-01 11:47 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Jeff Horn, emacs-orgmode, Andrea Crotti
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Feb 1, 2011, at 12:22 PM, Dan Davison wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Hi Dan,
>>>
>>> maybe just header in the default value to keep the echo area open for
>>> error messages?
>>
>> Absolutely. But if you prefer, we could just do away with the echo-
>> area
>> message entirely. That would have the advantage of leaving the user
>> interface unchanged.
>>
>> With the default as '(header), my UI change only makes sense if we
>> believe that an appreciable number of users will disable the header
>> message and activate the echo-area message in its place.
>
> There are people who hate the header line IIRC. But I guess you are
> right - once people are ready to remove the header line for this
> application, they will probably have memorized it.
>
> I remember that I started with the echo area and introduced the header
> line because people were asking how to get out of there, so I needed
> something more persistent.
>
> So I guess if the header line is the default, I'd be fine with
> removing the echo area message altogether.
I have done that, and removed my other patch from patchwork.
Dan
>
> - Carsten
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-02-01 11:47 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-31 10:04 Overlays and elisp code Andrea Crotti
2011-01-31 20:04 ` Jeff Horn
2011-02-01 8:08 ` Andrea Crotti
2011-02-01 10:51 ` Dan Davison
2011-02-01 11:01 ` Dan Davison
2011-02-01 11:08 ` Carsten Dominik
2011-02-01 11:22 ` Dan Davison
2011-02-01 11:30 ` Carsten Dominik
2011-02-01 11:47 ` Dan Davison
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).