bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15478: cc-mode does not obey electric-indent-mode


From: Josh
Subject: bug#15478: cc-mode does not obey electric-indent-mode
Date: Fri, 4 Oct 2013 14:21:22 -0700

On Thu, Oct 3, 2013 at 7:32 AM, Stefan Monnier <address@hidden> wrote:
> > What I'm suggesting is some sort of hook so that electric-indent-mode
> > (and electric-layout-mode, too, I suppose) invokes the "electric
> > engine" in CC Mode rather than trying to do the electric
> > indentation itself.
> Sounds OK.

Unless I'm misunderstanding, the indentation hook you're describing
seems very close to `electric-indent-functions':

    electric-indent-functions is a variable defined in `electric.el'.
    Its value is nil
      This variable may be risky if used as a file-local variable.
    Documentation:
    Special hook run to decide whether to auto-indent.
    Each function is called with one argument (the inserted char), with
    point right after that char, and it should return t to cause indentation,
    `no-indent' to prevent indentation or nil to let other functions decide.

Is there a reason why CC Mode couldn't supply a function here that
would perform appropriate indentation and then return `no-indent' to
stop traversal of electric-indent-functions?

Delegation of newline insertion decisions is similarly already supported
via `electric-layout-rules':

    electric-layout-rules
    electric-layout-rules is a variable defined in `electric.el'.
    Its value is nil
    Documentation:
    List of rules saying where to automatically insert newlines.
    Each rule has the form (CHAR . WHERE) where CHAR is the char
    that was just inserted and WHERE specifies where to insert newlines
    and can be: nil, `before', `after', `around', or a function of no
    arguments that returns one of those symbols.

If either or both of these delegation mechanisms are insufficient to
satisfy CC Mode's requirements, it would be interesting to hear how they
fall short.

Although I agree with your earlier point that major modes are best
suited to make decisions about /how/ to perform electric behavior for
their specific domains, which also seems to be borne out by the existing
delegation support, I've seen no justification for a major mode deciding
to disregard (!) my configuration of /whether/ to perform it at all.  I read
the electric-*-mode docstrings describing the exact behavior in
question and I disabled it.  That should be the end of the story.

Josh


reply via email to

[Prev in Thread] Current Thread [Next in Thread]