Narrow/widen in folding.el

Narrow/widen in folding.el

[Leo Alekseyev]

I use folding.el a lot, and find it useful, but its interaction with
isearch is decidedly suboptimal: if you start with a folded buffer,
search for something, and land in a fold, the buffer will be narrowed
to this fold, and to get out you have to hit C-x n w.  This becomes a
pain when I have to do lots of small quick searches/edits in a folded
document.  Is there a way to fix this behavior?..

--Leo

Re: Narrow/widen in folding.el

[Andrea Crotti]

Leo Alekseyev <dnquark@gmail.com> writes:

> I use folding.el a lot, and find it useful, but its interaction with
> isearch is decidedly suboptimal: if you start with a folded buffer,
> search for something, and land in a fold, the buffer will be narrowed
> to this fold, and to get out you have to hit C-x n w.  This becomes a
> pain when I have to do lots of small quick searches/edits in a folded
> document.  Is there a way to fix this behavior?..
>
> --Leo

I suggest to try org-mode, you can do the same things that you're doing
now but is much more powerful.
If I use isearch it expands when it finds something and doesn't narrow
it back if I press for example C-a, C-e

Re: Narrow/widen in folding.el

[Tassilo Horn]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

Hi!

>> I use folding.el a lot, and find it useful, but its interaction with
>> isearch is decidedly suboptimal: if you start with a folded buffer,
>> search for something, and land in a fold, the buffer will be narrowed
>> to this fold, and to get out you have to hit C-x n w.  This becomes a
>> pain when I have to do lots of small quick searches/edits in a folded
>> document.  Is there a way to fix this behavior?..
>
> I suggest to try org-mode, you can do the same things that you're doing
> now but is much more powerful.

But org-mode doesn't work for source code files, e.g. it's not the right
thing for using folding in C++ files.

> If I use isearch it expands when it finds something and doesn't narrow
> it back if I press for example C-a, C-e

org builds upon outline mode, and outline provides a nice
outline-minor-mode that can be used to use outlining in any files.  It
also temporally unhides hidden parts when isearching.

I have a small config snippet that calculates the right
`outline-regexp'.  Basically, it's the current buffer's comment syntax
followed by at least one *.  The more *s, the higher the level.

--8<---------------cut here---------------start------------->8---
(require 'outline)

(defvar th-outline-minor-mode-font-lock-keywords
  '((eval . (list (concat "^\\(?:" outline-regexp "\\).*")
                  0 '(outline-font-lock-face) t t)))
  "Additional expressions to highlight in Orgstruct Mode and Outline minor mode.
The difference to `outline-font-lock-keywords' is that this will
overwrite other highlighting.")

(defun th-outline-regexp ()
  "Calculate the outline regexp for the current mode."
  (let ((comment-starter (replace-regexp-in-string
                          "[[:space:]]+" "" comment-start)))
    (when (string= comment-starter ";")
      (setq comment-starter ";;"))
    (concat comment-starter "[*]+ ")))

(defun th-outline-minor-mode-init ()
  (interactive)
  (unless (eq major-mode 'latex-mode)
    (setq outline-regexp (th-outline-regexp))
    (font-lock-add-keywords
     nil
     th-outline-minor-mode-font-lock-keywords)))

(add-hook 'outline-minor-mode-hook
          'th-outline-minor-mode-init)
--8<---------------cut here---------------end--------------->8---

So in Lisp, I can do:

;;* Headline 1
;;** Headline 1.1
;;** Headline 1.2

and in C I can do

//* Headline 1
//** Headline 1.1
//** Headline 1.2

I also bind TAB to a function that calls `org-cycle' if I'm on an
outline heading, and in all other cases does what TAB would do normally.

Bye,
Tassilo

Re: Narrow/widen in folding.el

[Andrea Crotti]

Tassilo Horn <tassilo@member.fsf.org> writes:

>
> But org-mode doesn't work for source code files, e.g. it's not the right
> thing for using folding in C++ files.

Aha ok I didn't understand it was for source code.
Anyway for C++ with cedet and the function

senator-fold-tag
it works perfectly for me, not sure if it's what you want...
I have this
  (local-set-key [f6] 'senator-fold-tag-toggle)

for the buffers supported by semantic.

Now I remember I also tried to do something like this some time ago, but
I couldn't stand the fact that I had to use a special syntax for it.

So I gave up and now I found senator-fold-tag which works perfectly
fine.

I think also it would be nice to implement some "fold-everything",
"unfold-everything" using this feature.

Re: Narrow/widen in folding.el

[Tassilo Horn]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

Hi Andrea,

>> But org-mode doesn't work for source code files, e.g. it's not the
>> right thing for using folding in C++ files.
>
> Aha ok I didn't understand it was for source code.

Nah, no-one said that.  But folding.el and outline.el (both minor modes)
can be used in any buffer, whereas org-mode (a major mode) is for
org-files only.  So activating org-mode in a lisp buffer ==> lisp
completion, highlighting, and indentation are gone.

> Anyway for C++ with cedet and the function
>
> senator-fold-tag
> it works perfectly for me, not sure if it's what you want...
> I have this
>   (local-set-key [f6] 'senator-fold-tag-toggle)
>
> for the buffers supported by semantic.

Yes, several modes implement some folding capabilities wtr. some
syntactic constructs of a programming language.  For example, there's
also hs-minor-mode, which can collapse/expand blocks in languages like
C/C++/Java.

That's a good thing, but with outline-minor-mode (or folding.el), you
can add more coarse-grained sections to structure your code into several
groups of things (e.g. functions) belonging together, like:

;;* Code
;;** User Variables
;;** User Commands
;;** Internal Implementation
;;*** General
;;*** Feature A
;;*** Feature B

> Now I remember I also tried to do something like this some time ago,
> but I couldn't stand the fact that I had to use a special syntax for
> it.

That's what I like with `outline-minor-mode' and my config (i.e. outline
headings are `comment-start' + one or many *s).  You would comment your
code anyway (I hope so!), and adding a few * to make a comment a
headline to make the structure of the file visible is worth it.

But I agree, that I don't like folding.el's obtrusive {{{ ... }}}
syntax, too.

Bye,
Tassilo

Re: Narrow/widen in folding.el

[Andrea Crotti]

Tassilo Horn <tassilo@member.fsf.org> writes:
>
> Yes, several modes implement some folding capabilities wtr. some
> syntactic constructs of a programming language.  For example, there's
> also hs-minor-mode, which can collapse/expand blocks in languages like
> C/C++/Java.
>
> That's a good thing, but with outline-minor-mode (or folding.el), you
> can add more coarse-grained sections to structure your code into several
> groups of things (e.g. functions) belonging together, like:
>
> ;;* Code
> ;;** User Variables
> ;;** User Commands
> ;;** Internal Implementation
> ;;*** General
> ;;*** Feature A
> ;;*** Feature B

Ah thanks for hs-minor-mode, it's also quite nice and it works at least
with python and C++.

Sure structuring is very nice, but I don't see why you need it when you
can jump fast to sections?
I use tags, isearch or grep as a last resource, and it's very fast.

>
> That's what I like with `outline-minor-mode' and my config (i.e. outline
> headings are `comment-start' + one or many *s).  You would comment your
> code anyway (I hope so!), and adding a few * to make a comment a
> headline to make the structure of the file visible is worth it.
>
> But I agree, that I don't like folding.el's obtrusive {{{ ... }}}
> syntax, too.
>
> Bye,
> Tassilo

Well depends, I never comment trivial functions, I try to make them
clear enough and with good names, that's already enough.
So adding a comment just to create the right section would be already
too annoying, but of course becasue I don't really feel I need it.

Re: Narrow/widen in folding.el

[Leo Alekseyev]

>> Now I remember I also tried to do something like this some time ago,
>> but I couldn't stand the fact that I had to use a special syntax for
>> it.
>
> That's what I like with `outline-minor-mode' and my config (i.e. outline
> headings are `comment-start' + one or many *s).  You would comment your
> code anyway (I hope so!), and adding a few * to make a comment a
> headline to make the structure of the file visible is worth it.
>
> But I agree, that I don't like folding.el's obtrusive {{{ ... }}}
> syntax, too.


Hi Tassilo; thanks for the code snippet in your previous message.  In
fact, I had started using outline-minor-mode just in the way you
described, but I manually set up the regexes for the few languages
where I used it, so your code will definitely come in handy.

The problem with this approach, though, is the overly rigid structure:
the end of one fold is necessarily the beginning of another fold.  For
some use cases, it works rather well.  Sometimes, however, I simply
want a piece of text folded without it being logically tied to any
hierarchy.  For instance, I want to hide a header or a footer, or a
long block of commented text in the middle of the document, etc.  In
org-mode, you can achieve this effect by using "drawers", where you
have e.g. a mark-up like :DETAILS: <long block of folding/unfolding
text here> :END:.  In fact, if someone ported that functionality to
outline-minor-mode, I'd probably use that.  Failing this, folding.el
is a good option.  Unfortunately, this brings us back to the original
issue -- folding.el's annoying narrow/widen behavior in isearch.  I am
still hoping someone familiar with folding.el might help clarify the
issue :)

In general, I would say that folding behavior is one area where Emacs
could improve.  If you do a search, you'll find lots of people on
StackOverflow and other forums trying to figure out folding in Emacs.
The problem is the fragmentation of folding mechanisms, and the fact
that each has limits, drawbacks, and/or bugs.  This is remedied to a
point by using fold-dwim, and the new fold-dwim-org.  However, my pipe
dream is that someone will write a end-all folding mode that will roll
into it functionality that's currently scattered across outline minor
mode, folding.el, hideshow, and various enhancements of the above
(hideshow-org, fold-dwim, etc.)

It would probably make the most sense to merge the functionality of
folding.el into outline-minor-mode, and set it up with org bindings,
possibly through fold-dwim-org.  Code folding could be done with
hideshow, although CEDET's folding might be a better option at this
point...

--Leo

Re: Narrow/widen in folding.el

[Tassilo Horn]

Leo Alekseyev <dnquark@gmail.com> writes:

Hi Leo,

> The problem with this approach, though, is the overly rigid structure:
> the end of one fold is necessarily the beginning of another fold.  For
> some use cases, it works rather well.  Sometimes, however, I simply
> want a piece of text folded without it being logically tied to any
> hierarchy.

Hm, ok.  I never had the need for arbitrary folding, but only to
coarse-grained hierarchical folding (outline-minor-mode) and syntactical
folding wrt. some programming language (hs-minor-mode and friends).

But concerning folding.el and isearch: folding.el should put a special
text properties on the overlay.

,----[ (info "(elisp)Invisible Text") ]
|    Incremental search can make invisible overlays visible temporarily
| and/or permanently when a match includes invisible text.  To enable
| this, the overlay should have a non-`nil' `isearch-open-invisible'
| property.  The property value should be a function to be called with
| the overlay as an argument.  This function should make the overlay
| visible permanently; it is used when the match overlaps the overlay on
| exit from the search.
| 
|    During the search, such overlays are made temporarily visible by
| temporarily modifying their invisible and intangible properties.  If you
| want this to be done differently for a certain overlay, give it an
| `isearch-open-invisible-temporary' property which is a function.  The
| function is called with two arguments: the first is the overlay, and
| the second is `nil' to make the overlay visible, or `t' to make it
| invisible again.
`----

That should be pretty trivial to hack into it.

Bye,
Tassilo

Re: Narrow/widen in folding.el

[Leo Alekseyev]

On Wed, Dec 22, 2010 at 3:02 AM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Leo Alekseyev <dnquark@gmail.com> writes:
>
> Hi Leo,
>
>> The problem with this approach, though, is the overly rigid structure:
>> the end of one fold is necessarily the beginning of another fold.  For
>> some use cases, it works rather well.  Sometimes, however, I simply
>> want a piece of text folded without it being logically tied to any
>> hierarchy.

Arbitrary folding is handy for headers/footers.  Also, I do a lot of
data analysis in addition to coding, and arbitrary folding can be very
useful there...

> But concerning folding.el and isearch: folding.el should put a special
> text properties on the overlay.
>
> ,----[ (info "(elisp)Invisible Text") ]
> |    Incremental search can make invisible overlays visible temporarily
> | and/or permanently when a match includes invisible text.  To enable
> | this, the overlay should have a non-`nil' `isearch-open-invisible'
> | property.  The property value should be a function to be called with
> | the overlay as an argument.  This function should make the overlay
> | visible permanently; it is used when the match overlaps the overlay on
> | exit from the search.
> |
> |    During the search, such overlays are made temporarily visible by
> | temporarily modifying their invisible and intangible properties.  If you
> | want this to be done differently for a certain overlay, give it an
> | `isearch-open-invisible-temporary' property which is a function.  The
> | function is called with two arguments: the first is the overlay, and
> | the second is `nil' to make the overlay visible, or `t' to make it
> | invisible again.
> `----


In fact, I found the resolution to my original question:
(setq folding-narrow-by-default nil)

I saw this variable before in folding.el's documentation, but I
misunderstood the terminology that was being used ("opening" folds vs
"entering" folds), and didn't realize that the variable controlled
narrowing just like I want it to.  When I went source-browsing
inspired by your message, I realized what it actually did :)

--Leo

Re: Narrow/widen in folding.el

[Tim X]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

>
> Sure structuring is very nice, but I don't see why you need it when you
> can jump fast to sections?
> I use tags, isearch or grep as a last resource, and it's very fast.
>

I find both very useful. Things like tags, isearch and grep are great
for jumping around in source files - especially if they are large.
However, folding is very useful when you want to be able to
see/reference a bit of code that is some distance from the code your
working on and don't want to have to actually move the cursor back and
forward. I find it particularly useful if the folding marks/comments
also conatin some additional information, such as the argument types to
a function. Now, when writing some code and I can't remember the order
of arguments etc, rather than having to move the cursor, I just glance
up and the folded comment provides the memory jolt I needed. 

Sometimes, I also find folding helps reveal the algorithm I'm owrking on
in a more concise, brief form - helping to keep me on track i.e. see the
forest, not the trees. 

Essentially, its not an either/or situation. I also find folding more
useful with some languages than others, so type of source code is
probablyh a factor as well. 

The tip on using outline minor mode rather than one of the existing
dedicated folding modes is very useful. I've always found the various
implementations of folding as in folding.el, folding-mode.el etc to be a
bit clunky - isearch and cumbersome key bindings being the two major
frustrations. The example earlier in this thread using outline has
reminded me that I've always planned to see if that would be a better
solution and it looks promising, so thanks.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Narrow/widen in folding.el

[Leo Alekseyev]

On Tue, Dec 21, 2010 at 10:42 AM, Tassilo Horn <tassilo@member.fsf.org> wrote:

>
> I have a small config snippet that calculates the right
> `outline-regexp'.  Basically, it's the current buffer's comment syntax
> followed by at least one *.  The more *s, the higher the level.
>
> --8<---------------cut here---------------start------------->8---
> (require 'outline)
>
> (defvar th-outline-minor-mode-font-lock-keywords
>  '((eval . (list (concat "^\\(?:" outline-regexp "\\).*")
>                  0 '(outline-font-lock-face) t t)))
>  "Additional expressions to highlight in Orgstruct Mode and Outline minor mode.
> The difference to `outline-font-lock-keywords' is that this will
> overwrite other highlighting.")
>
> (defun th-outline-regexp ()
>  "Calculate the outline regexp for the current mode."
>  (let ((comment-starter (replace-regexp-in-string
>                          "[[:space:]]+" "" comment-start)))
>    (when (string= comment-starter ";")
>      (setq comment-starter ";;"))
>    (concat comment-starter "[*]+ ")))
>
> (defun th-outline-minor-mode-init ()
>  (interactive)
>  (unless (eq major-mode 'latex-mode)
>    (setq outline-regexp (th-outline-regexp))
>    (font-lock-add-keywords
>     nil
>     th-outline-minor-mode-font-lock-keywords)))
>
> (add-hook 'outline-minor-mode-hook
>          'th-outline-minor-mode-init)
> --8<---------------cut here---------------end--------------->8---

I've started using Tassilo's snippet in some of my projects and I like
it a lot, especially combined with org-mode's visibility cycling (cf
http://orgmode.org/faq.html#sec-1.2 ).

I've been running into the following issue: I turn on the
outline-minor-mode through a file-local variable, e.g. "--  -*-
mode:sql; mode:outline-minor  -*- ".  However, the headings are not
fontified until I manually toggle outline-minor-mode on and off.  This
is somewhat strange, since the new entries do appear in
font-lock-keywords-alist.  But even toggling font-lock-mode doesn't
make it work, only re-enabling outline-minor-mode.  I'd love to hear
your thoughts on how to fix this :)

--Leo

Re: Narrow/widen in folding.el

[Leo Alekseyev]

On Fri, Dec 24, 2010 at 6:18 PM, Leo Alekseyev <dnquark@gmail.com> wrote:

> I've been running into the following issue: I turn on the
> outline-minor-mode through a file-local variable, e.g. "--  -*-
> mode:sql; mode:outline-minor  -*- ".  However, the headings are not
> fontified until I manually toggle outline-minor-mode on and off.  This
> is somewhat strange, since the new entries do appear in
> font-lock-keywords-alist.  But even toggling font-lock-mode doesn't
> make it work, only re-enabling outline-minor-mode.  I'd love to hear
> your thoughts on how to fix this :)

Upon further experimentation, a correction: when turning on
outline-minor-mode through the file-local-variable, the
outline-minor-mode hooks don't run.  Perhaps this warrants a thread of
its own?...

Re: Narrow/widen in folding.el

[Leo Alekseyev]

On Tue, Dec 21, 2010 at 10:42 AM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> --8<---------------cut here---------------start------------->8---
> (require 'outline)
>
> (defvar th-outline-minor-mode-font-lock-keywords
>  '((eval . (list (concat "^\\(?:" outline-regexp "\\).*")
>                  0 '(outline-font-lock-face) t t)))
>  "Additional expressions to highlight in Orgstruct Mode and Outline minor mode.
> The difference to `outline-font-lock-keywords' is that this will
> overwrite other highlighting.")
>
> (defun th-outline-regexp ()
>  "Calculate the outline regexp for the current mode."
>  (let ((comment-starter (replace-regexp-in-string
>                          "[[:space:]]+" "" comment-start)))
>    (when (string= comment-starter ";")
>      (setq comment-starter ";;"))
>    (concat comment-starter "[*]+ ")))
>
> (defun th-outline-minor-mode-init ()
>  (interactive)
>  (unless (eq major-mode 'latex-mode)
>    (setq outline-regexp (th-outline-regexp))
>    (font-lock-add-keywords
>     nil
>     th-outline-minor-mode-font-lock-keywords)))
>
> (add-hook 'outline-minor-mode-hook
>          'th-outline-minor-mode-init)
> --8<---------------cut here---------------end--------------->8---

Sincerest apologies for the spam, and please disregard the previous
two messages.  The problem with the above snippet still exists for me,
but only for certain modes.  In particular, for sql-mode, when
th-outline-minor-mode-init is invoked via a hook when loading a file,
as in Tassilo's code above, the font-lock-keywords variable does not
appear to be set correctly.  However, when th-outline-minor-mode-init
is called interactively (either via M-x th-outline-minor-mode-init, or
evaluating (outline-minor-mode t)), everything starts working.  In
other modes (e.g. shell and R), font-lock-keywords are set correctly,
it seems, but the font-lock for first level heading doesn't seem to
work.  In elisp mode, everything works :)

It's pretty hard to nail down the problem exactly, since it tends to
be (a) mode-specific and (b) depends on whether the code is being
called via a hook or interactively.  Still, if there's a quick obvious
fix, I'd like to know :)

Re: Narrow/widen in folding.el

[Tim X]

Leo Alekseyev <dnquark@gmail.com> writes:

> On Tue, Dec 21, 2010 at 10:42 AM, Tassilo Horn <tassilo@member.fsf.org> wrote:
>> --8<---------------cut here---------------start------------->8---
>> (require 'outline)
>>
>> (defvar th-outline-minor-mode-font-lock-keywords
>>  '((eval . (list (concat "^\\(?:" outline-regexp "\\).*")
>>                  0 '(outline-font-lock-face) t t)))
>>  "Additional expressions to highlight in Orgstruct Mode and Outline minor mode.
>> The difference to `outline-font-lock-keywords' is that this will
>> overwrite other highlighting.")
>>
>> (defun th-outline-regexp ()
>>  "Calculate the outline regexp for the current mode."
>>  (let ((comment-starter (replace-regexp-in-string
>>                          "[[:space:]]+" "" comment-start)))
>>    (when (string= comment-starter ";")
>>      (setq comment-starter ";;"))
>>    (concat comment-starter "[*]+ ")))
>>
>> (defun th-outline-minor-mode-init ()
>>  (interactive)
>>  (unless (eq major-mode 'latex-mode)
>>    (setq outline-regexp (th-outline-regexp))
>>    (font-lock-add-keywords
>>     nil
>>     th-outline-minor-mode-font-lock-keywords)))
>>
>> (add-hook 'outline-minor-mode-hook
>>          'th-outline-minor-mode-init)
>> --8<---------------cut here---------------end--------------->8---
>
> Sincerest apologies for the spam, and please disregard the previous
> two messages.  The problem with the above snippet still exists for me,
> but only for certain modes.  In particular, for sql-mode, when
> th-outline-minor-mode-init is invoked via a hook when loading a file,
> as in Tassilo's code above, the font-lock-keywords variable does not
> appear to be set correctly.  However, when th-outline-minor-mode-init
> is called interactively (either via M-x th-outline-minor-mode-init, or
> evaluating (outline-minor-mode t)), everything starts working.  In
> other modes (e.g. shell and R), font-lock-keywords are set correctly,
> it seems, but the font-lock for first level heading doesn't seem to
> work.  In elisp mode, everything works :)
>
> It's pretty hard to nail down the problem exactly, since it tends to
> be (a) mode-specific and (b) depends on whether the code is being
> called via a hook or interactively.  Still, if there's a quick obvious
> fix, I'd like to know :)
>

I'm not sure if this is relevant or not, but I've noticed some
inconsistent behavior with respect to font-lock and sql mode. This is
someting which has only appeared in the last couple of weeks (using bzr
trunk for emacs 24.0.50). 

I've been working on a derived mode for coding pl/sql which is derived
from sql mode. I've found that in my derived mode, I have to explicitly
call sql-set-product in the load hook, even though I have sql-product
set to oracle. Essentially, this appears to reload the mode. In other
cases, using sql mode, I've noticed I sometimes need to start sql-mode,
set the product to ansi and then set it back o oracle in order to get
the appropriate font locking. 

My guess is that there is some sort of weird font lock issue arising
form sql modes attempt to support multiple different sets of font lock
keywords. This could be what is impacting on your use of outline as
well. 

As mentioned, this issue only started to appear in the last few weeks
i.e. this month. I've looked through the changelog and can't see
anything obvious. If/when I track it down, I will possibly log a bug
report if this is warranted. However, as I cannot nail it down yet and
as I'm mainly only seeing it with my own derived mode, I will wait until
I'm confident its not something wrong that I"m doing. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Narrow/widen in folding.el

[Tassilo Horn]

Tim X <timx@nospam.dev.null> writes:

Hi Tim,

> As mentioned, this issue only started to appear in the last few weeks
> i.e. this month.  I've looked through the changelog and can't see
> anything obvious.  If/when I track it down, I will possibly log a bug
> report if this is warranted.  However, as I cannot nail it down yet
> and as I'm mainly only seeing it with my own derived mode, I will wait
> until I'm confident its not something wrong that I"m doing.

Well, that doesn't really help, but I also have some font-lock issues
with LaTeX documents + custem Hi-Lock keywords.  If I load the document
and then do M-x hi-lock-mode, everything works fine.  But if I enable
that mode using %% mode: hi-lock, it's font locking doesn't become
active, although the mode is on.  Of course, in every minimal test case
I tried to produce, it always works fine. :-)

Long story short: If you can nail it down, please file a bug report and
post the link here.

Bye,
Tassilo

Re: Narrow/widen in folding.el

[Tim X]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Tim X <timx@nospam.dev.null> writes:
>
> Hi Tim,
>
>> As mentioned, this issue only started to appear in the last few weeks
>> i.e. this month.  I've looked through the changelog and can't see
>> anything obvious.  If/when I track it down, I will possibly log a bug
>> report if this is warranted.  However, as I cannot nail it down yet
>> and as I'm mainly only seeing it with my own derived mode, I will wait
>> until I'm confident its not something wrong that I"m doing.
>
> Well, that doesn't really help, but I also have some font-lock issues
> with LaTeX documents + custem Hi-Lock keywords.  If I load the document
> and then do M-x hi-lock-mode, everything works fine.  But if I enable
> that mode using %% mode: hi-lock, it's font locking doesn't become
> active, although the mode is on.  Of course, in every minimal test case
> I tried to produce, it always works fine. :-)
>
> Long story short: If you can nail it down, please file a bug report and
> post the link here.
>

Will do. However, at present, it is secondary to what I'm trying to do.
With the dev version of emacs, I frequently find such issues are
transient and they often get resolved before I manage to nail them down.
As an example, I was using re-builder two days ago and noticed some
issues with it. I just did a bzr pull and noticed that there have been
some changes with re-builder and some of the rx stuff - could well be
that this fixes the re-builder issues I've observed AND possibly
font-lock issues since it too makes extensive use of regexps. 

Tim

-- 
tcross (at) rapttech dot com dot au