Overlays and elisp code

Overlays and elisp code

[Andrea Crotti]

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?

Re: Overlays and elisp code

[Jeff Horn]

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/

Re: Overlays and elisp code

[Andrea Crotti]

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...

Re: Overlays and elisp code

[Dan Davison]

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
>>

Re: Overlays and elisp code

[Dan Davison]

>> 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

Re: Re: Overlays and elisp code

[Carsten Dominik]

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

Re: Overlays and elisp code

[Dan Davison]

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

Re: Overlays and elisp code

[Carsten Dominik]

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

Re: Overlays and elisp code

[Dan Davison]

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