unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 18826@debbugs.gnu.org
Subject: bug#18826: 24.3.94; c++-mode bad indentation after programmatic insert	with	locally	changed syntax table
Date: Mon, 27 Oct 2014 08:53:28 +0000	[thread overview]
Message-ID: <20141027085328.GA2771@acm.acm> (raw)
In-Reply-To: <544D9AA6.5@yandex.ru>

Hello, Dmitry.

On Mon, Oct 27, 2014 at 08:06:46AM +0700, Dmitry Gutov wrote:
> On 10/27/2014 12:38 AM, Alan Mackenzie wrote:

> > They're not syntax-table text properties, so the setting of them doesn't
> > belong in syntax-propertize.

> Well, they are used to set syntax information, so syntax-propertize is a 
> much better place for them, conceptually, than font-lock.

They (that is, the c-is-sws and c-in-sws properties) mark syntactic
whitespace.  They're set during calls to c-forward-syntactic-ws and
c-backward-syntactic-ws, which are used all over the place, just as much
in the indentation engine, and the commands, as in font lock.  They're
intended to mark CPP structures and, especially, massive comments, such
as are frequently found at the beginning of source files.  They're
intended to speed up the skipping of WS.

> > Maybe it will, maybe it won't.  `syntax-propertize' has the disadvantage
> > of inefficiency; at any buffer change, all syntax-table text properties
> > after the position of the change are effectively wiped out, even where
> > (as is usual) this isn't necessary.

> If it's a actually a problem, maybe you need to be able to use a custom 
> invalidation strategy. Aside from the strategy itself, this shouldn't be 
> too hard to implement.

It's already implemented and running.  :-)  The syntax-table properties
in the vicinity of a buffer change are removed and re-applied with tender
loving care.

[ ... ]

> >> Hmm. My current workaround is to use a temporary syntax table that
> >> inherits from c++-mode-syntax-table (but has angle brackets in the
> >> 'paren' class). Sounds like it might also create a conflict, if maybe a
> >> more subtle one.

> > Any reason you don't use the current syntax table as the base to add the
> > descriptors for < and > to rather than creating a new, blank one?  You
> > could use `copy-syntax-table'.

> Is that much different from what I described above? I do

>    (with-syntax-table (make-syntax-table (syntax-table)
>      ...)

No it's not.  Apologies.  I hadn't read your email properly.

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2014-10-27  8:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-25 14:25 bug#18826: 24.3.94; c++-mode bad indentation after programmatic insert with locally changed syntax table Dmitry Gutov
     [not found] ` <mailman.12024.1414247237.1147.bug-gnu-emacs@gnu.org>
2014-10-25 19:34   ` Alan Mackenzie
2014-10-25 22:45     ` Dmitry Gutov
     [not found] ` <mailman.12048.1414277182.1147.bug-gnu-emacs@gnu.org>
2014-10-25 23:24   ` Alan Mackenzie
2014-10-26 15:09     ` Dmitry Gutov
2014-10-26 17:07       ` Stefan Monnier
2014-10-25 23:25 ` Stefan Monnier
     [not found] ` <jwv61f7ohq0.fsf-monnier+emacsbugs@gnu.org>
2014-10-26 14:56   ` Dmitry Gutov
2014-10-26 14:56   ` Dmitry Gutov
2014-10-26 17:03     ` Stefan Monnier
     [not found] ` <mailman.12080.1414336227.1147.bug-gnu-emacs@gnu.org>
2014-10-26 17:38   ` Alan Mackenzie
2014-10-27  1:06     ` Dmitry Gutov
2014-10-27  8:53       ` Alan Mackenzie [this message]
2014-10-27 10:21         ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141027085328.GA2771@acm.acm \
    --to=acm@muc.de \
    --cc=18826@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).