Julien Fantin <address@hidden> 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 <address@hidden>
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
<address@hidden> wrote:
Julien Fantin <address@hidden> 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.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode