* org-edit-src-code font lock problem
@ 2009-04-29 19:23 Dan Davison
2009-05-05 12:46 ` Carsten Dominik
0 siblings, 1 reply; 4+ messages in thread
From: Dan Davison @ 2009-04-29 19:23 UTC (permalink / raw)
To: emacs org-mode mailing list
I'm finding that the font-lock in the indirect buffer spawned by C-c '
on a source code block is not correct when there is a preceding (odd
number of) apostrophes / backticks etc (depending on the language). E.g.
* this works fine as there is no apostrophe
#+begin_src sh
for i in $(seq -w 1 22) ; do
echo $i
done
#+end_src
* but this doesn't work correctly because of the single-quote / apostrophe
#+begin_src sh
for i in $(seq -w 1 22) ; do
echo $i
done
#+end_src
The second example thinks it's in a single-quote-delimited string.
org-version 6.26trans
emacs-version 23.0.91.1
Dan
p.s. A minor wish-list item: would it be possible to introduce a
variable (say org-expert or something like that) which, when non-nil,
prevents the appearance of instructive messages such as the one that
appears on org-edit-src-code?
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: org-edit-src-code font lock problem 2009-04-29 19:23 org-edit-src-code font lock problem Dan Davison @ 2009-05-05 12:46 ` Carsten Dominik 2009-05-05 14:17 ` Dan Davison 0 siblings, 1 reply; 4+ messages in thread From: Carsten Dominik @ 2009-05-05 12:46 UTC (permalink / raw) To: Dan Davison; +Cc: emacs org-mode mailing list Hi Dan, On Apr 29, 2009, at 9:23 PM, Dan Davison wrote: > I'm finding that the font-lock in the indirect buffer spawned by C-c ' > on a source code block is not correct when there is a preceding (odd > number of) apostrophes / backticks etc (depending on the language). > E.g. > > * this works fine as there is no apostrophe > #+begin_src sh > for i in $(seq -w 1 22) ; do > echo $i > done > #+end_src > > * but this doesn't work correctly because of the single-quote / > apostrophe > #+begin_src sh > for i in $(seq -w 1 22) ; do > echo $i > done > #+end_src > > The second example thinks it's in a single-quote-delimited string. Hmmm, this is a serious problem................. time passing ...... OK, I have addressed it by using not a narrowed indirect buffer to edit these snippets, but a truly separate buffer. Thanks for the report. > > org-version 6.26trans > emacs-version 23.0.91.1 > > Dan > > p.s. A minor wish-list item: would it be possible to introduce a > variable (say org-expert or something like that) which, when non-nil, > prevents the appearance of instructive messages such as the one that > appears on org-edit-src-code? Which one do you mean? The message in the echo area (last line of the frame), or the one appearing permanently in the first line of the buffer window? And which other cases of messages did you have in mind? I am not sure if I understand how these are bothering you. - Carsten > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: 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] 4+ messages in thread
* Re: org-edit-src-code font lock problem 2009-05-05 12:46 ` Carsten Dominik @ 2009-05-05 14:17 ` Dan Davison 2009-05-05 16:15 ` Carsten Dominik 0 siblings, 1 reply; 4+ messages in thread From: Dan Davison @ 2009-05-05 14:17 UTC (permalink / raw) To: emacs org-mode mailing list Carsten Dominik <carsten.dominik@gmail.com> writes: > Hi Dan, > > On Apr 29, 2009, at 9:23 PM, Dan Davison wrote: > >> I'm finding that the font-lock in the indirect buffer spawned by C-c ' >> on a source code block is not correct when there is a preceding (odd >> number of) apostrophes / backticks etc (depending on the >> language). E.g. >> >> * this works fine as there is no apostrophe >> #+begin_src sh >> for i in $(seq -w 1 22) ; do >> echo $i >> done >> #+end_src >> >> * but this doesn't work correctly because of the single-quote / >> apostrophe >> #+begin_src sh >> for i in $(seq -w 1 22) ; do >> echo $i >> done >> #+end_src >> >> The second example thinks it's in a single-quote-delimited string. > > Hmmm, this is a serious problem................. time passing ...... > OK, I have addressed it by using not a narrowed indirect buffer to > edit these snippets, but a truly separate buffer. Great, thanks. > Thanks for the report. > >> >> org-version 6.26trans >> emacs-version 23.0.91.1 >> >> Dan >> >> p.s. A minor wish-list item: would it be possible to introduce a >> variable (say org-expert or something like that) which, when non-nil, >> prevents the appearance of instructive messages such as the one that >> appears on org-edit-src-code? > > Which one do you mean? The message in the echo area (last line of > the frame), or the one appearing permanently in the first line of > the buffer window? The permanent one in the first line. > > And which other cases of messages did you have in mind? None at the moment! I just thought, seeing as the header is used to give a help message by org-edit-src-code, it might be worth introducing a mechanism whereby one can choose between two "levels" of help messages. I didn't mean to give the impression that I had several things I wanted to change. > > I am not sure if I understand how these are bothering you. I admit this is a personal and mainly aesthetic preference -- once I've learned how to use it and the relevant key binding, I prefer to have (the option to have) a screen free from content other than the minimum necessary (the echo area will still provide the information). I'm guessing that quite a few org users have dispensed with the emacs menu bar (and scroll bars), and was thinking that the proposed option might appeal to those sorts of people. Dan p.s. I think the docstring in org-edit-src-code needs updating to reflect the change. > > - Carsten > > >> >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Remember: 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 > Remember: 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] 4+ messages in thread
* Re: org-edit-src-code font lock problem 2009-05-05 14:17 ` Dan Davison @ 2009-05-05 16:15 ` Carsten Dominik 0 siblings, 0 replies; 4+ messages in thread From: Carsten Dominik @ 2009-05-05 16:15 UTC (permalink / raw) To: Dan Davison; +Cc: emacs org-mode mailing list On May 5, 2009, at 4:17 PM, Dan Davison wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> Hi Dan, >> >> On Apr 29, 2009, at 9:23 PM, Dan Davison wrote: >> >>> I'm finding that the font-lock in the indirect buffer spawned by C- >>> c ' >>> on a source code block is not correct when there is a preceding (odd >>> number of) apostrophes / backticks etc (depending on the >>> language). E.g. >>> >>> * this works fine as there is no apostrophe >>> #+begin_src sh >>> for i in $(seq -w 1 22) ; do >>> echo $i >>> done >>> #+end_src >>> >>> * but this doesn't work correctly because of the single-quote / >>> apostrophe >>> #+begin_src sh >>> for i in $(seq -w 1 22) ; do >>> echo $i >>> done >>> #+end_src >>> >>> The second example thinks it's in a single-quote-delimited string. >> >> Hmmm, this is a serious problem................. time passing ...... >> OK, I have addressed it by using not a narrowed indirect buffer to >> edit these snippets, but a truly separate buffer. > > Great, thanks. > >> Thanks for the report. >> >>> >>> org-version 6.26trans >>> emacs-version 23.0.91.1 >>> >>> Dan >>> >>> p.s. A minor wish-list item: would it be possible to introduce a >>> variable (say org-expert or something like that) which, when non- >>> nil, >>> prevents the appearance of instructive messages such as the one that >>> appears on org-edit-src-code? >> >> Which one do you mean? The message in the echo area (last line of >> the frame), or the one appearing permanently in the first line of >> the buffer window? > > The permanent one in the first line. > >> >> And which other cases of messages did you have in mind? > > None at the moment! I just thought, seeing as the header is used to > give > a help message by org-edit-src-code, it might be worth introducing a > mechanism whereby one can choose between two "levels" of help > messages. I didn't mean to give the impression that I had several > things > I wanted to change. I am not in favor of removing such messages in bulk. Org-mode has so many facets that a user might be tempted to turn off these messages after feeling familiar in one area, and then not being educated sufficiently in other areas as a effect of toggling a single `org-export' variable. >> I am not sure if I understand how these are bothering you. > > I admit this is a personal and mainly aesthetic preference -- once > I've > learned how to use it and the relevant key binding, I prefer to have > (the option to have) a screen free from content other than the minimum > necessary (the echo area will still provide the information). I'm > guessing that quite a few org users have dispensed with the emacs menu > bar (and scroll bars), and was thinking that the proposed option might > appeal to those sorts of people. You can do (setq org-edit-src-persistent-message nil) after updating from git. We will address similar messages in other areas as people report to be distracted by them. > Dan > > p.s. I think the docstring in org-edit-src-code needs updating to > reflect the change. Yes, thanks, I did that too. - Carsten ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-05-05 16:15 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-29 19:23 org-edit-src-code font lock problem Dan Davison 2009-05-05 12:46 ` Carsten Dominik 2009-05-05 14:17 ` Dan Davison 2009-05-05 16:15 ` Carsten Dominik
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).