emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* 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).