What primitive has moved point?

What primitive has moved point?

[Alan Mackenzie]

Hi Richard, Hi Emacs!

After point has been moved, how can I determine exactly which primitive
did the moving?

The reason I want to know is so as to handle "unbalanced" braces
properly in CC Mode when they're inside #if and friends.  Such as:

#if NEW_VERSION
int foo (int bar, int baz) {   // <========= brace A
#else
int foo (int bar) {    // <========== brace B
#endif

If the user arrives at brace B through scan-lists (e.g. with C-M-u) I
want to catch this (possibly by the use of point-entered/left text
properties), and according to some user options, perhaps adjust point to
brace A.

However, if the user gets to brace B with forward-line (e.g., with C-p)
I want to leave point well alone.

I want to draw this distinction regardless of whether point is moved
directly by the user or inside CC Mode's analysis functions.

Is there any way I can tell which of these primitives got me to brace B?

Thanks in advance!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What primitive has moved point?

[Stefan Monnier]

> After point has been moved, how can I determine exactly which primitive
> did the moving?

Down this path lies madness.

> (possibly by the use of point-entered/left text properties),

...more madness.

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


        Stefan

Re: What primitive has moved point?

[Richard Stallman]

    After point has been moved, how can I determine exactly which primitive
    did the moving?

I don't think there is a way to do that.

    If the user arrives at brace B through scan-lists (e.g. with C-M-u) I
    want to catch this (possibly by the use of point-entered/left text
    properties), and according to some user options, perhaps adjust point to
    brace A.

    However, if the user gets to brace B with forward-line (e.g., with C-p)
    I want to leave point well alone.

If there is a specific distinction that really needs to be made, we
could set up a mechanism to do it with.  But what about all the other
motion commands that exist?  characters, words, sentences, paragraphs,
pages, screen-line (M-r), search?

Maybe what you should do is make CC mode rebind the paren-based motion
keys to replacements, and make the CC mode code use the replacements.

Re: What primitive has moved point?

[Alan Mackenzie]

Hi, Stefan!

On Fri, Nov 06, 2009 at 10:36:05AM -0500, Stefan Monnier wrote:
> > After point has been moved, how can I determine exactly which
> > primitive did the moving?

> Down this path lies madness.

Hmmm.  Thinking about it a bit longer, you're probably right.  Though,
having been maintaining CC Mode for ~8 years, this madness is sadly no
longer to be avoided.  ;-(

> > (possibly by the use of point-entered/left text properties),

> ...more madness.

These properties were invented by somebody with some use in mind.  So
they can't be that mad.  OK, a quick grep shows they're used in the
games, and table.el.

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

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.
(iii) Each time point leaves such a region, splat the properties again.

What do you think?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What primitive has moved point?

[Stefan Monnier]

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

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

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

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


        Stefan

Re: What primitive has moved point?

[Alan Mackenzie]

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