emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Julien Fantin <julien.fantin@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Dan Davison <davison@stats.ox.ac.uk>, emacs-orgmode@gnu.org
Subject: Re: Re: Src blocks fontification issue
Date: Fri, 3 Sep 2010 20:38:05 +0200	[thread overview]
Message-ID: <AANLkTinFpnq2h00RaGCKJFy0_NvuJq93b8LLBqKo6ZEN@mail.gmail.com> (raw)
In-Reply-To: <33867E1A-68A7-4891-A7AE-24B73B5EC779@gmail.com>

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
>
>
>
>

      reply	other threads:[~2010-09-03 18:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinFpnq2h00RaGCKJFy0_NvuJq93b8LLBqKo6ZEN@mail.gmail.com \
    --to=julien.fantin@gmail.com \
    --cc=carsten.dominik@gmail.com \
    --cc=davison@stats.ox.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).