* Src blocks fontification issue
@ 2010-09-02 18:27 Julien Fantin
2010-09-02 22:48 ` Dan Davison
0 siblings, 1 reply; 7+ messages in thread
From: Julien Fantin @ 2010-09-02 18:27 UTC (permalink / raw)
To: emacs-orgmode
First congratulations on adding in-line fontification to source
blocks, that's a great addition.
However, since I pulled those changes, a recurring issue I've been
having has become even more annoying.
When opening an org file, some src blocks headers don't seem to get
parsed properly, and now as a result, don't get fontified.
They are functional though, since they properly get tangled, and C-c '
performs as expected.
If I edit the header line, or the ones directly before and after it,
the block gets back to normal.
Here is a screenshot to make things clearer, as you can see there are
no differences in formatting, and those properties drawer don't have
anything weird, just a single ID.
http://imagebin.org/112413
I was meaning to post a screenshot with whitespace-mode on to stress
that there are no apparent formatting differences, but it turned out
activating it fixed the issue !
Not sure what I can do to further help debugging this ?
Cheers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Src blocks fontification issue
2010-09-02 18:27 Src blocks fontification issue Julien Fantin
@ 2010-09-02 22:48 ` Dan Davison
2010-09-03 8:04 ` Julien Fantin
0 siblings, 1 reply; 7+ messages in thread
From: Dan Davison @ 2010-09-02 22:48 UTC (permalink / raw)
To: Julien Fantin; +Cc: emacs-orgmode
Julien Fantin <julien.fantin@gmail.com> writes:
> First congratulations on adding in-line fontification to source
> blocks, that's a great addition.
>
> However, since I pulled those changes, a recurring issue I've been
> having has become even more annoying.
>
> When opening an org file, some src blocks headers don't seem to get
> parsed properly, and now as a result, don't get fontified.
> They are functional though, since they properly get tangled, and C-c '
> performs as expected.
> If I edit the header line, or the ones directly before and after it,
> the block gets back to normal.
>
> Here is a screenshot to make things clearer, as you can see there are
> no differences in formatting, and those properties drawer don't have
> anything weird, just a single ID.
>
> http://imagebin.org/112413
>
> I was meaning to post a screenshot with whitespace-mode on to stress
> that there are no apparent formatting differences, but it turned out
> activating it fixed the issue !
>
> Not sure what I can do to further help debugging this ?
Hi Julien,
I don't have any clever ideas about this, so I'm just going to suggest
the obvious: first a sanity check that it doesn't occur with emacs
-Q. Then some sort of quasi-binary search through your emacs
customisations. It looks like you're storing your emacs customisation in
an Org file, so you can knock out entire trees with :tangle: no
properties.
Dan
p.s. On a completely unrelated note, if you haven't already tried it:
(add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
where the `pretty-lambdas' function is in starter-kit-defuns.org at
git://github.com/eschulte/emacs-starter-kit.git
(defun pretty-lambdas ()
(font-lock-add-keywords
nil `(("(?\\(lambda\\>\\)"
(0 (progn (compose-region (match-beginning 1) (match-end 1)
,(make-char 'greek-iso8859-7 107))
nil))))))
>
> Cheers
>
> _______________________________________________
> 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] 7+ messages in thread
* Re: Src blocks fontification issue
2010-09-02 22:48 ` Dan Davison
@ 2010-09-03 8:04 ` Julien Fantin
2010-09-03 15:23 ` Dan Davison
0 siblings, 1 reply; 7+ messages in thread
From: Julien Fantin @ 2010-09-03 8:04 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
Hi Dan,
thanks for the answer and the unsollicited tip :)
I tried opening the file with a bare emacs and the problem persists.
I use true indentation in my files, which I think isn't what most
people do, so maybe the parser gets confused by a combination of
blocks not starting at column 0, and some other formatting, but I'm
failing to see the pattern...
Here is one of the incriminated files:
http://pastebin.com/raw.php?i=yxdUmpKx
Hope this is any help...
Cheers
On Fri, Sep 3, 2010 at 12:48 AM, Dan Davison <davison@stats.ox.ac.uk> wrote:
> Julien Fantin <julien.fantin@gmail.com> writes:
>
>> First congratulations on adding in-line fontification to source
>> blocks, that's a great addition.
>>
>> However, since I pulled those changes, a recurring issue I've been
>> having has become even more annoying.
>>
>> When opening an org file, some src blocks headers don't seem to get
>> parsed properly, and now as a result, don't get fontified.
>> They are functional though, since they properly get tangled, and C-c '
>> performs as expected.
>> If I edit the header line, or the ones directly before and after it,
>> the block gets back to normal.
>>
>> Here is a screenshot to make things clearer, as you can see there are
>> no differences in formatting, and those properties drawer don't have
>> anything weird, just a single ID.
>>
>> http://imagebin.org/112413
>>
>> I was meaning to post a screenshot with whitespace-mode on to stress
>> that there are no apparent formatting differences, but it turned out
>> activating it fixed the issue !
>>
>> Not sure what I can do to further help debugging this ?
>
> Hi Julien,
>
> I don't have any clever ideas about this, so I'm just going to suggest
> the obvious: first a sanity check that it doesn't occur with emacs
> -Q. Then some sort of quasi-binary search through your emacs
> customisations. It looks like you're storing your emacs customisation in
> an Org file, so you can knock out entire trees with :tangle: no
> properties.
>
> Dan
>
> p.s. On a completely unrelated note, if you haven't already tried it:
>
> (add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
>
> where the `pretty-lambdas' function is in starter-kit-defuns.org at
> git://github.com/eschulte/emacs-starter-kit.git
>
> (defun pretty-lambdas ()
> (font-lock-add-keywords
> nil `(("(?\\(lambda\\>\\)"
> (0 (progn (compose-region (match-beginning 1) (match-end 1)
> ,(make-char 'greek-iso8859-7 107))
> nil))))))
>
>>
>> Cheers
>>
>> _______________________________________________
>> 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] 7+ messages in thread
* Re: Src blocks fontification issue
2010-09-03 8:04 ` Julien Fantin
@ 2010-09-03 15:23 ` Dan Davison
2010-09-03 15:50 ` Julien Fantin
2010-09-03 17:56 ` Carsten Dominik
0 siblings, 2 replies; 7+ messages in thread
From: Dan Davison @ 2010-09-03 15:23 UTC (permalink / raw)
To: Julien Fantin; +Cc: emacs-orgmode
Julien Fantin <julien.fantin@gmail.com> writes:
> I tried opening the file with a bare emacs and the problem persists.
>
> I use true indentation in my files, which I think isn't what most
> people do, so maybe the parser gets confused by a combination of
> blocks not starting at column 0, and some other formatting, but I'm
> failing to see the pattern...
Me too. While you may well be right that I have broken something, first
let's concentrate on what appears to be a long-standing bug; in fact I
think it has never worked correctly. Basic fontification of src blocks
elements was introduced over a year ago at this commit
--8<---------------cut here---------------start------------->8---
commit 476493d3b300b8dc379ea7e42c974461d6f3dfb5
Author: Carsten Dominik <carsten.dominik@gmail.com>
Date: Sat May 23 22:58:38 2009 +0200
Fontification: Better treatment of #+ lines and blocks
The content of blocks like #+begin_example will be marked with a
separate face. That same face is also used for single lines
introducing text for specific backends.
--8<---------------cut here---------------end--------------->8---
Priot to that commit the whole block, and the begin_src end_src lines
had no special fontification. After that commit, a test file (below)
based on yours is not correctly fontified on startup. It is correctly
fontified when font-lock is triggered subsequently by some keyborad
input nearby. But it seems very sensitive to changes in the test file
and I haven't worked out what's going on.
Test file: the final code block is not fontified, nor are the BEGIN_SRC
and END_SRC lines. (emacs 24, org commit 476493d3b300 and subsequent)
--8<---------------cut here---------------start------------->8---
* Setup
#+BEGIN_SRC emacs-lisp
(add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
(add-hook 'org-mode-hook
'(lambda ()
(auto-fill-mode t)
(define-key org-mode-map (kbd "RET") 'org-return-indent)
(flyspell-mode 1)))
;; windmove fix
(add-hook 'org-shiftup-final-hook 'windmove-up)
(add-hook 'org-shiftleft-final-hook 'windmove-left)
(add-hook 'org-shiftdown-final-hook 'windmove-down)
(add-hook 'org-shiftright-final-hook 'windmove-right)
#+END_SRC
** Helpers
#+BEGIN_SRC emacs-lisp
(defun is-bogus-file-p (file)
"Return t if file is a temporary file as in .#foo or a . .. reference returned by directory-files"
(or (member file '("." ".."))
(string-match "^.#.+" file)))
#+END_SRC
* Customization
#+BEGIN_SRC emacs-lisp
(setq org-return-follows-link t
org-special-ctrl-a/e t
org-special-ctrl-k t
org-completion-use-ido t
org-log-into-drawer t
org-startup-indented nil
org-hide-leading-stars t
org-startup-folded t
org-empty-line-terminates-plain-lists t
org-adapt-indentation t
org-yank-folded-subtrees t
org-M-RET-may-split-line nil
org-enforce-todo-dependencies t
org-enforce-todo-checkbox-dependencies t)
;; (setq org-blank-before-new-entry '((heading . always)
;; (plain-list-item . always)))
#+END_SRC
--8<---------------cut here---------------end--------------->8---
Dan
>
> Here is one of the incriminated files:
>
> http://pastebin.com/raw.php?i=yxdUmpKx
>
> Hope this is any help...
>
> Cheers
>
> On Fri, Sep 3, 2010 at 12:48 AM, Dan Davison <davison@stats.ox.ac.uk> wrote:
>> Julien Fantin <julien.fantin@gmail.com> writes:
>>
>>> First congratulations on adding in-line fontification to source
>>> blocks, that's a great addition.
>>>
>>> However, since I pulled those changes, a recurring issue I've been
>>> having has become even more annoying.
>>>
>>> When opening an org file, some src blocks headers don't seem to get
>>> parsed properly, and now as a result, don't get fontified.
>>> They are functional though, since they properly get tangled, and C-c '
>>> performs as expected.
>>> If I edit the header line, or the ones directly before and after it,
>>> the block gets back to normal.
>>>
>>> Here is a screenshot to make things clearer, as you can see there are
>>> no differences in formatting, and those properties drawer don't have
>>> anything weird, just a single ID.
>>>
>>> http://imagebin.org/112413
>>>
>>> I was meaning to post a screenshot with whitespace-mode on to stress
>>> that there are no apparent formatting differences, but it turned out
>>> activating it fixed the issue !
>>>
>>> Not sure what I can do to further help debugging this ?
>>
>> Hi Julien,
>>
>> I don't have any clever ideas about this, so I'm just going to suggest
>> the obvious: first a sanity check that it doesn't occur with emacs
>> -Q. Then some sort of quasi-binary search through your emacs
>> customisations. It looks like you're storing your emacs customisation in
>> an Org file, so you can knock out entire trees with :tangle: no
>> properties.
>>
>> Dan
>>
>> p.s. On a completely unrelated note, if you haven't already tried it:
>>
>> (add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
>>
>> where the `pretty-lambdas' function is in starter-kit-defuns.org at
>> git://github.com/eschulte/emacs-starter-kit.git
>>
>> (defun pretty-lambdas ()
>> (font-lock-add-keywords
>> nil `(("(?\\(lambda\\>\\)"
>> (0 (progn (compose-region (match-beginning 1) (match-end 1)
>> ,(make-char 'greek-iso8859-7 107))
>> nil))))))
>>
>>>
>>> Cheers
>>>
>>> _______________________________________________
>>> 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] 7+ messages in thread
* Re: Src blocks fontification issue
2010-09-03 15:23 ` Dan Davison
@ 2010-09-03 15:50 ` Julien Fantin
2010-09-03 17:56 ` Carsten Dominik
1 sibling, 0 replies; 7+ messages in thread
From: Julien Fantin @ 2010-09-03 15:50 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
I'm sorry if I implied that this issue appeared since your changes
Dan, as it's not the case indeed.
I tried un-indenting the scr block headers, and the problem goes away,
so I'd say it's definitely related to the handling of indented
headers.
I looked at that commit and the regexps do take care of detecting
them, but I'm afraid the code is too involved for me to be of any
help...
I hope this can get fixed, if not I might consider sticking to col 0
for src blocks...
Cheers
On Fri, Sep 3, 2010 at 5:23 PM, Dan Davison <davison@stats.ox.ac.uk> wrote:
> Julien Fantin <julien.fantin@gmail.com> writes:
>
>> I tried opening the file with a bare emacs and the problem persists.
>>
>> I use true indentation in my files, which I think isn't what most
>> people do, so maybe the parser gets confused by a combination of
>> blocks not starting at column 0, and some other formatting, but I'm
>> failing to see the pattern...
>
> Me too. While you may well be right that I have broken something, first
> let's concentrate on what appears to be a long-standing bug; in fact I
> think it has never worked correctly. Basic fontification of src blocks
> elements was introduced over a year ago at this commit
>
> --8<---------------cut here---------------start------------->8---
> commit 476493d3b300b8dc379ea7e42c974461d6f3dfb5
> Author: Carsten Dominik <carsten.dominik@gmail.com>
> Date: Sat May 23 22:58:38 2009 +0200
>
> Fontification: Better treatment of #+ lines and blocks
>
> The content of blocks like #+begin_example will be marked with a
> separate face. That same face is also used for single lines
> introducing text for specific backends.
> --8<---------------cut here---------------end--------------->8---
>
> Priot to that commit the whole block, and the begin_src end_src lines
> had no special fontification. After that commit, a test file (below)
> based on yours is not correctly fontified on startup. It is correctly
> fontified when font-lock is triggered subsequently by some keyborad
> input nearby. But it seems very sensitive to changes in the test file
> and I haven't worked out what's going on.
>
> Test file: the final code block is not fontified, nor are the BEGIN_SRC
> and END_SRC lines. (emacs 24, org commit 476493d3b300 and subsequent)
>
> --8<---------------cut here---------------start------------->8---
> * Setup
> #+BEGIN_SRC emacs-lisp
> (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
> (add-hook 'org-mode-hook
> '(lambda ()
> (auto-fill-mode t)
> (define-key org-mode-map (kbd "RET") 'org-return-indent)
> (flyspell-mode 1)))
>
>
> ;; windmove fix
> (add-hook 'org-shiftup-final-hook 'windmove-up)
> (add-hook 'org-shiftleft-final-hook 'windmove-left)
> (add-hook 'org-shiftdown-final-hook 'windmove-down)
> (add-hook 'org-shiftright-final-hook 'windmove-right)
> #+END_SRC
> ** Helpers
> #+BEGIN_SRC emacs-lisp
> (defun is-bogus-file-p (file)
> "Return t if file is a temporary file as in .#foo or a . .. reference returned by directory-files"
> (or (member file '("." ".."))
> (string-match "^.#.+" file)))
> #+END_SRC
> * Customization
> #+BEGIN_SRC emacs-lisp
> (setq org-return-follows-link t
> org-special-ctrl-a/e t
> org-special-ctrl-k t
> org-completion-use-ido t
> org-log-into-drawer t
> org-startup-indented nil
> org-hide-leading-stars t
> org-startup-folded t
> org-empty-line-terminates-plain-lists t
> org-adapt-indentation t
> org-yank-folded-subtrees t
> org-M-RET-may-split-line nil
> org-enforce-todo-dependencies t
> org-enforce-todo-checkbox-dependencies t)
>
> ;; (setq org-blank-before-new-entry '((heading . always)
> ;; (plain-list-item . always)))
> #+END_SRC
> --8<---------------cut here---------------end--------------->8---
>
>
> Dan
>
>>
>> Here is one of the incriminated files:
>>
>> http://pastebin.com/raw.php?i=yxdUmpKx
>>
>> Hope this is any help...
>>
>> Cheers
>>
>> On Fri, Sep 3, 2010 at 12:48 AM, Dan Davison <davison@stats.ox.ac.uk> wrote:
>>> Julien Fantin <julien.fantin@gmail.com> writes:
>>>
>>>> First congratulations on adding in-line fontification to source
>>>> blocks, that's a great addition.
>>>>
>>>> However, since I pulled those changes, a recurring issue I've been
>>>> having has become even more annoying.
>>>>
>>>> When opening an org file, some src blocks headers don't seem to get
>>>> parsed properly, and now as a result, don't get fontified.
>>>> They are functional though, since they properly get tangled, and C-c '
>>>> performs as expected.
>>>> If I edit the header line, or the ones directly before and after it,
>>>> the block gets back to normal.
>>>>
>>>> Here is a screenshot to make things clearer, as you can see there are
>>>> no differences in formatting, and those properties drawer don't have
>>>> anything weird, just a single ID.
>>>>
>>>> http://imagebin.org/112413
>>>>
>>>> I was meaning to post a screenshot with whitespace-mode on to stress
>>>> that there are no apparent formatting differences, but it turned out
>>>> activating it fixed the issue !
>>>>
>>>> Not sure what I can do to further help debugging this ?
>>>
>>> Hi Julien,
>>>
>>> I don't have any clever ideas about this, so I'm just going to suggest
>>> the obvious: first a sanity check that it doesn't occur with emacs
>>> -Q. Then some sort of quasi-binary search through your emacs
>>> customisations. It looks like you're storing your emacs customisation in
>>> an Org file, so you can knock out entire trees with :tangle: no
>>> properties.
>>>
>>> Dan
>>>
>>> p.s. On a completely unrelated note, if you haven't already tried it:
>>>
>>> (add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
>>>
>>> where the `pretty-lambdas' function is in starter-kit-defuns.org at
>>> git://github.com/eschulte/emacs-starter-kit.git
>>>
>>> (defun pretty-lambdas ()
>>> (font-lock-add-keywords
>>> nil `(("(?\\(lambda\\>\\)"
>>> (0 (progn (compose-region (match-beginning 1) (match-end 1)
>>> ,(make-char 'greek-iso8859-7 107))
>>> nil))))))
>>>
>>>>
>>>> Cheers
>>>>
>>>> _______________________________________________
>>>> 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] 7+ messages in thread
* Re: Re: Src blocks fontification issue
2010-09-03 15:23 ` Dan Davison
2010-09-03 15:50 ` Julien Fantin
@ 2010-09-03 17:56 ` Carsten Dominik
2010-09-03 18:38 ` Julien Fantin
1 sibling, 1 reply; 7+ messages in thread
From: Carsten Dominik @ 2010-09-03 17:56 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Julien Fantin
On Sep 3, 2010, at 5:23 PM, Dan Davison wrote:
> Julien Fantin <julien.fantin@gmail.com> writes:
>
>> I tried opening the file with a bare emacs and the problem persists.
>>
>> I use true indentation in my files, which I think isn't what most
>> people do, so maybe the parser gets confused by a combination of
>> blocks not starting at column 0, and some other formatting, but I'm
>> failing to see the pattern...
>
> Me too. While you may well be right that I have broken something,
> first
> let's concentrate on what appears to be a long-standing bug; in fact I
> think it has never worked correctly. Basic fontification of src blocks
> elements was introduced over a year ago at this commit
>
> --8<---------------cut here---------------start------------->8---
> commit 476493d3b300b8dc379ea7e42c974461d6f3dfb5
> Author: Carsten Dominik <carsten.dominik@gmail.com>
> Date: Sat May 23 22:58:38 2009 +0200
>
> Fontification: Better treatment of #+ lines and blocks
>
> The content of blocks like #+begin_example will be marked with a
> separate face. That same face is also used for single lines
> introducing text for specific backends.
> --8<---------------cut here---------------end--------------->8---
I remember that this was quite tricky to implement, lots of problems
because you have to scan outside of the range font-lock wants to look
at etc. Would be great if you could find out how to fix this.
Before this patch, the text in block would be fontified like org-mode,
which looked terrible ... :)
- Carsten
>
> Priot to that commit the whole block, and the begin_src end_src lines
> had no special fontification. After that commit, a test file (below)
> based on yours is not correctly fontified on startup. It is correctly
> fontified when font-lock is triggered subsequently by some keyborad
> input nearby. But it seems very sensitive to changes in the test file
> and I haven't worked out what's going on.
>
> Test file: the final code block is not fontified, nor are the
> BEGIN_SRC
> and END_SRC lines. (emacs 24, org commit 476493d3b300 and subsequent)
>
> --8<---------------cut here---------------start------------->8---
> * Setup
> #+BEGIN_SRC emacs-lisp
> (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)
> $" . org-mode))
> (add-hook 'org-mode-hook
> '(lambda ()
> (auto-fill-mode t)
> (define-key org-mode-map (kbd "RET") 'org-return-
> indent)
> (flyspell-mode 1)))
>
>
> ;; windmove fix
> (add-hook 'org-shiftup-final-hook 'windmove-up)
> (add-hook 'org-shiftleft-final-hook 'windmove-left)
> (add-hook 'org-shiftdown-final-hook 'windmove-down)
> (add-hook 'org-shiftright-final-hook 'windmove-right)
> #+END_SRC
> ** Helpers
> #+BEGIN_SRC emacs-lisp
> (defun is-bogus-file-p (file)
> "Return t if file is a temporary file as in .#foo or a . ..
> reference returned by directory-files"
> (or (member file '("." ".."))
> (string-match "^.#.+" file)))
> #+END_SRC
> * Customization
> #+BEGIN_SRC emacs-lisp
> (setq org-return-follows-link t
> org-special-ctrl-a/e t
> org-special-ctrl-k t
> org-completion-use-ido t
> org-log-into-drawer t
> org-startup-indented nil
> org-hide-leading-stars t
> org-startup-folded t
> org-empty-line-terminates-plain-lists t
> org-adapt-indentation t
> org-yank-folded-subtrees t
> org-M-RET-may-split-line nil
> org-enforce-todo-dependencies t
> org-enforce-todo-checkbox-dependencies t)
>
> ;; (setq org-blank-before-new-entry '((heading . always)
> ;; (plain-list-item . always)))
> #+END_SRC
> --8<---------------cut here---------------end--------------->8---
>
>
> Dan
>
>>
>> Here is one of the incriminated files:
>>
>> http://pastebin.com/raw.php?i=yxdUmpKx
>>
>> Hope this is any help...
>>
>> Cheers
>>
>> On Fri, Sep 3, 2010 at 12:48 AM, Dan Davison
>> <davison@stats.ox.ac.uk> wrote:
>>> Julien Fantin <julien.fantin@gmail.com> writes:
>>>
>>>> First congratulations on adding in-line fontification to source
>>>> blocks, that's a great addition.
>>>>
>>>> However, since I pulled those changes, a recurring issue I've been
>>>> having has become even more annoying.
>>>>
>>>> When opening an org file, some src blocks headers don't seem to get
>>>> parsed properly, and now as a result, don't get fontified.
>>>> They are functional though, since they properly get tangled, and
>>>> C-c '
>>>> performs as expected.
>>>> If I edit the header line, or the ones directly before and after
>>>> it,
>>>> the block gets back to normal.
>>>>
>>>> Here is a screenshot to make things clearer, as you can see there
>>>> are
>>>> no differences in formatting, and those properties drawer don't
>>>> have
>>>> anything weird, just a single ID.
>>>>
>>>> http://imagebin.org/112413
>>>>
>>>> I was meaning to post a screenshot with whitespace-mode on to
>>>> stress
>>>> that there are no apparent formatting differences, but it turned
>>>> out
>>>> activating it fixed the issue !
>>>>
>>>> Not sure what I can do to further help debugging this ?
>>>
>>> Hi Julien,
>>>
>>> I don't have any clever ideas about this, so I'm just going to
>>> suggest
>>> the obvious: first a sanity check that it doesn't occur with emacs
>>> -Q. Then some sort of quasi-binary search through your emacs
>>> customisations. It looks like you're storing your emacs
>>> customisation in
>>> an Org file, so you can knock out entire trees with :tangle: no
>>> properties.
>>>
>>> Dan
>>>
>>> p.s. On a completely unrelated note, if you haven't already tried
>>> it:
>>>
>>> (add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
>>>
>>> where the `pretty-lambdas' function is in starter-kit-defuns.org at
>>> git://github.com/eschulte/emacs-starter-kit.git
>>>
>>> (defun pretty-lambdas ()
>>> (font-lock-add-keywords
>>> nil `(("(?\\(lambda\\>\\)"
>>> (0 (progn (compose-region (match-beginning 1) (match-end 1)
>>> ,(make-char 'greek-iso8859-7
>>> 107))
>>> nil))))))
>>>
>>>>
>>>> Cheers
>>>>
>>>> _______________________________________________
>>>> 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
- Carsten
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: Src blocks fontification issue
2010-09-03 17:56 ` Carsten Dominik
@ 2010-09-03 18:38 ` Julien Fantin
0 siblings, 0 replies; 7+ messages in thread
From: Julien Fantin @ 2010-09-03 18:38 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Dan Davison, emacs-orgmode
Carsten, I'll look into it when I get a chance, even though I doubt
I'll be able to fix it if you describe it as tricky yourself ;)
Any pointers on where to start looking though ?
Cheers
On Fri, Sep 3, 2010 at 7:56 PM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
>
> On Sep 3, 2010, at 5:23 PM, Dan Davison wrote:
>
>> Julien Fantin <julien.fantin@gmail.com> writes:
>>
>>> I tried opening the file with a bare emacs and the problem persists.
>>>
>>> I use true indentation in my files, which I think isn't what most
>>> people do, so maybe the parser gets confused by a combination of
>>> blocks not starting at column 0, and some other formatting, but I'm
>>> failing to see the pattern...
>>
>> Me too. While you may well be right that I have broken something, first
>> let's concentrate on what appears to be a long-standing bug; in fact I
>> think it has never worked correctly. Basic fontification of src blocks
>> elements was introduced over a year ago at this commit
>>
>> --8<---------------cut here---------------start------------->8---
>> commit 476493d3b300b8dc379ea7e42c974461d6f3dfb5
>> Author: Carsten Dominik <carsten.dominik@gmail.com>
>> Date: Sat May 23 22:58:38 2009 +0200
>>
>> Fontification: Better treatment of #+ lines and blocks
>>
>> The content of blocks like #+begin_example will be marked with a
>> separate face. That same face is also used for single lines
>> introducing text for specific backends.
>> --8<---------------cut here---------------end--------------->8---
>
> I remember that this was quite tricky to implement, lots of problems because
> you have to scan outside of the range font-lock wants to look at etc.
> Would be great if you could find out how to fix this.
>
> Before this patch, the text in block would be fontified like org-mode, which
> looked terrible ... :)
>
> - Carsten
>
>
>>
>> Priot to that commit the whole block, and the begin_src end_src lines
>> had no special fontification. After that commit, a test file (below)
>> based on yours is not correctly fontified on startup. It is correctly
>> fontified when font-lock is triggered subsequently by some keyborad
>> input nearby. But it seems very sensitive to changes in the test file
>> and I haven't worked out what's going on.
>>
>> Test file: the final code block is not fontified, nor are the BEGIN_SRC
>> and END_SRC lines. (emacs 24, org commit 476493d3b300 and subsequent)
>>
>> --8<---------------cut here---------------start------------->8---
>> * Setup
>> #+BEGIN_SRC emacs-lisp
>> (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" .
>> org-mode))
>> (add-hook 'org-mode-hook
>> '(lambda ()
>> (auto-fill-mode t)
>> (define-key org-mode-map (kbd "RET") 'org-return-indent)
>> (flyspell-mode 1)))
>>
>>
>> ;; windmove fix
>> (add-hook 'org-shiftup-final-hook 'windmove-up)
>> (add-hook 'org-shiftleft-final-hook 'windmove-left)
>> (add-hook 'org-shiftdown-final-hook 'windmove-down)
>> (add-hook 'org-shiftright-final-hook 'windmove-right)
>> #+END_SRC
>> ** Helpers
>> #+BEGIN_SRC emacs-lisp
>> (defun is-bogus-file-p (file)
>> "Return t if file is a temporary file as in .#foo or a . .. reference
>> returned by directory-files"
>> (or (member file '("." ".."))
>> (string-match "^.#.+" file)))
>> #+END_SRC
>> * Customization
>> #+BEGIN_SRC emacs-lisp
>> (setq org-return-follows-link t
>> org-special-ctrl-a/e t
>> org-special-ctrl-k t
>> org-completion-use-ido t
>> org-log-into-drawer t
>> org-startup-indented nil
>> org-hide-leading-stars t
>> org-startup-folded t
>> org-empty-line-terminates-plain-lists t
>> org-adapt-indentation t
>> org-yank-folded-subtrees t
>> org-M-RET-may-split-line nil
>> org-enforce-todo-dependencies t
>> org-enforce-todo-checkbox-dependencies t)
>>
>> ;; (setq org-blank-before-new-entry '((heading . always)
>> ;; (plain-list-item . always)))
>> #+END_SRC
>> --8<---------------cut here---------------end--------------->8---
>>
>>
>> Dan
>>
>>>
>>> Here is one of the incriminated files:
>>>
>>> http://pastebin.com/raw.php?i=yxdUmpKx
>>>
>>> Hope this is any help...
>>>
>>> Cheers
>>>
>>> On Fri, Sep 3, 2010 at 12:48 AM, Dan Davison <davison@stats.ox.ac.uk>
>>> wrote:
>>>>
>>>> Julien Fantin <julien.fantin@gmail.com> writes:
>>>>
>>>>> First congratulations on adding in-line fontification to source
>>>>> blocks, that's a great addition.
>>>>>
>>>>> However, since I pulled those changes, a recurring issue I've been
>>>>> having has become even more annoying.
>>>>>
>>>>> When opening an org file, some src blocks headers don't seem to get
>>>>> parsed properly, and now as a result, don't get fontified.
>>>>> They are functional though, since they properly get tangled, and C-c '
>>>>> performs as expected.
>>>>> If I edit the header line, or the ones directly before and after it,
>>>>> the block gets back to normal.
>>>>>
>>>>> Here is a screenshot to make things clearer, as you can see there are
>>>>> no differences in formatting, and those properties drawer don't have
>>>>> anything weird, just a single ID.
>>>>>
>>>>> http://imagebin.org/112413
>>>>>
>>>>> I was meaning to post a screenshot with whitespace-mode on to stress
>>>>> that there are no apparent formatting differences, but it turned out
>>>>> activating it fixed the issue !
>>>>>
>>>>> Not sure what I can do to further help debugging this ?
>>>>
>>>> Hi Julien,
>>>>
>>>> I don't have any clever ideas about this, so I'm just going to suggest
>>>> the obvious: first a sanity check that it doesn't occur with emacs
>>>> -Q. Then some sort of quasi-binary search through your emacs
>>>> customisations. It looks like you're storing your emacs customisation in
>>>> an Org file, so you can knock out entire trees with :tangle: no
>>>> properties.
>>>>
>>>> Dan
>>>>
>>>> p.s. On a completely unrelated note, if you haven't already tried it:
>>>>
>>>> (add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
>>>>
>>>> where the `pretty-lambdas' function is in starter-kit-defuns.org at
>>>> git://github.com/eschulte/emacs-starter-kit.git
>>>>
>>>> (defun pretty-lambdas ()
>>>> (font-lock-add-keywords
>>>> nil `(("(?\\(lambda\\>\\)"
>>>> (0 (progn (compose-region (match-beginning 1) (match-end 1)
>>>> ,(make-char 'greek-iso8859-7 107))
>>>> nil))))))
>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> - Carsten
>
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-09-03 18:40 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-02 18:27 Src blocks fontification issue Julien Fantin
2010-09-02 22:48 ` Dan Davison
2010-09-03 8:04 ` Julien Fantin
2010-09-03 15:23 ` Dan Davison
2010-09-03 15:50 ` Julien Fantin
2010-09-03 17:56 ` Carsten Dominik
2010-09-03 18:38 ` Julien Fantin
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).