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