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