Re: What primitive has moved point?

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan!

On Sat, Nov 07, 2009 at 09:48:38PM -0500, Stefan Monnier wrote:
> >> > However, if the user gets to brace B with forward-line (e.g., with C-p)
> >> > I want to leave point well alone.

> >> I think your "feature" will be a misfeature, but if you really really
> >> want to implement it, the sanest way is probably to consider not the
> >> primitive used, but the direction of the movement: remember point in
> >> pre-command-hook, and compare in post-command-hook.  Otherwise: wrap all
> >> the relevant primitives (via defadvice, for example) and make them do
> >> what you want.

> > Actually, users have been complaining for a long time about "alternative"
> > parens in branches of #if's not scanning or parsing properly.  I WANT TO
> > FIX THIS, difficult though it might be.

> I know it's difficult, and it's not even clear what it means in general.

It can't be specified with mathematical precision, no, but it's clear
enough what it means in the normal case.  If your scan-lists'ing OVER a
#if/#else/#endif, only ONE of the alternative bits of code should count.

If you're C-M-p'ing up to a brace, you need to decide, somehow, which
branch to go for.  However, let us assume the axiom of choice.  ;-)

Which branch of the #if?  This would be a user option, with these sort of
alternatives:

(i) always go to the earliest in the buffer
(ii) ..............  latest ...............
(iii) always to to the first encountered in the direction of movement.
(iv) Go to the one indicated by `hide-ifdef-env', from hide-ifdef-mode.

Note that these choices only need happen when the user (or
`c-guess-syntactic-context') uses a list-movement type command.  For a
C-p, just move into the line requested.

> > Maybe this would be a better idea:
> > (i) "Neutralize" the syntactic value of every character inside a #define
> > or each branch of #if/#elseif/#else apart from the favoured one.  Do this
> > neutralization by splatting the area with syntax-table text properties,
> > whilst remembering what the "real" properties should be.
> > (ii) Each time point enters such a "splatted" region, restore the
> > properties.  Also restore them for the purpose of font locking.

> Doesn't sound like an attractive solution, since you have to choose one
> of the alternatives, and then the user will be surprised when the other
> alternatives don't work right.

It's got to be better than what we've got at the moment.

> The "right way" would be to extend syntax-tables so they can jump from
> #else to #endif (or to #if when going backwards).

Indeed.  I've been thinking quite a bit about this, but I've not got
beyond the thinking stage.  I think we could do with (i) syntactic
"islands", i.e. buffer regions that the syntax routines would just skip
over, or be confined within; they should be allowed to have their own
syntax table (and even their own major mode or major "sub"mode, or
whatever).  This would support "multi-mode" things like web languages, or
here-docs inside shell scripts; (ii) "streams", an extension, where
several "islands" get regarded as a single syntactic piece.  For literate
programming;  (iii) "Alternatives": for #if/#elsif/#else/#endif.

These changes would not be hard.  They're just grind work.  The designer
would need to think hard about what `eobp' means at the "beginning of an
island", and such things.

> > (iii) Each time point leaves such a region, splat the properties again.
> > What do you think?

> I also think down this way lies madness.  It's just piling up hacks over
> hacks, and while it may improve some behaviors it will screw up others.

C is also "just" a big hack.  Maybe you're right, maybe not.  However,
with sensible extensions to the syntax routines, C/C++/ObjC modes could
be grossly simplified by separating (?as submodes) "normal C Mode" from
"#define Mode", etc.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).