From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>
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:06:46 +0700 [thread overview]
Message-ID: <544D9AA6.5@yandex.ru> (raw)
In-Reply-To: <20141026173849.82988.qmail@mail.muc.de>
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.
> 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.
>> In that sense, the `sit-for' suggestion is not future-proof. So I'll try
>> only changing the syntax table around specific functions that don't
>> modify the buffer text, but just move point, since that was the actual goal.
>
> Might it be possible that you could get mixed up with less-than and
> greater-than (or even shift-right) operators? If so, be careful!
Thanks, but there are no "less-than" in a function signature.
>>> In the medium future (several weeks away), I'm hoping to fix CC Mode so
>>> that the text properties are applied to < ... > on an after-change
>>> function rather than at redisplay.
>
> ...., a change to use syntax-propertize needs the above change to happen
> first.
Not sure why, but ok.
>> 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)
...)
next prev parent reply other threads:[~2014-10-27 1:06 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 [this message]
2014-10-27 8:53 ` Alan Mackenzie
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544D9AA6.5@yandex.ru \
--to=dgutov@yandex.ru \
--cc=18826@debbugs.gnu.org \
--cc=acm@muc.de \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.