> If you have a conrete situation where the current behavior is
 > problematic, firsyt you need to understand how those things work:
 > there are 2 places where invisibility impacts movement:
 > - when combined with `intangible', it impacts every single movement of
 >   `point', including within elisp functions.  This may "do the right
 >   thing" in some sense, but it tends to break a lot of code, and
 >   it can be terribly difficult to write code that works in the face of
 >   intangible properties.  So I highly recommend against the use of
 >   `intangible' except for those rare cases where it's *really*
 >   absolutely needed.

Intangible text was never mentioned in this thread.

 > - when not combined with `intangible', invisible properties have the
 >   effect (just like composition and display properties) that after each
 >   *command* (i..e more or less just after running post-command-hook)
 >   point is moved outside of the invisible text.  Now since it's done at
 >   the end of a command (which may have moved point many times in
 >   arbitrarily complex ways), you can't do it right 100% of the time.
 >   OTOH this interacts fine with pretty much any elisp code.
 >
 > Many of the problems you point out have to do with interactions with C-n
 > and C-p which are surprisingly complex functions.  The interaction
 > between all three is even worse.
 >
 > So if you can try and reproduce the problem with only C-n/C-p (i.e. no
 > intangible text and with non-nil disable-point-adjustement) or with
 > only intangible text or with only invisible text, that makes it more
 > likely we can try and fix it.

This thread is about `line-move-ignore-invisible' - an option defined in
simple.el with the following doc-string:

	  *Non-nil means C-n and C-p ignore invisible lines.
	  Outline mode sets this.

Either this option makes sense - then we have to talk about C-n/C-p
_and_ invisible text - or it doesn't.  In the latter case let's remove
the option and the problem is resolved.

 > Also the interaction with those things is sufficiently bad, that there
 > are many problematic cases.  So if the problem only appears when you mix
 > those, to have a better chance of seeing your bug fixed, try to make
 > sure the symptom is really serious: e.g. C-n does move at all (or moves
 > backward).

I never use "those things" hence I don't care about whether these
qualify as "serious symptoms".  I just reacted to a couple of problems
reported by others.  One of these was

	 "the cursor stays put, i.e., C-p is a no-op here"

reported in 2004.  Apparently, it didn't have much chance getting fixed
then.

 > And focus on *1* problem at a time.

I focused on *1* solution at a time.

 >>Meanwhile could you please check my patch for simple.el too?
 >
 >
 > Please post it again,

Attached.