[Top][All Lists]

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

Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC M

From: João Távora
Subject: Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode
Date: Wed, 3 Jul 2019 14:31:58 +0100

On Wed, Jul 3, 2019 at 11:58 AM Alan Mackenzie <address@hidden> wrote:

> I'm fully aware it's a git commit hash.  Funnily enough, I don't
> memorise such hashes, so if you wish to draw my attention to some
> commit, please have the decency to give me its date,

Look I'm not being indecent, Alan. Stop this. just `git show fe06f64b`,
and move on.

> You're complaining that a dubious trick borne of incorrectness no longer
> works.  

Why are you dictating what I can and can't use that to select
the region between the two quotes? I write my text, fill the pargaph,
select it with C-M-u C-M-SPC (nicely chained "u" and SPC) and then
I C-S-% to put in the backslahes. You may well consider it a "trick"
and "dubious" and "stupid", but it's the way I work.

Anyway, tell me, out of curiosity, how do you do it? How do you create

"this \
text, \
for \


> I think, perhaps, you encounter such broken strings extremely rarely,
> and you're making a big song and dance over a relatively minor matter.

No, it's pretty routine, really.  Help blurbs in c++ and multi-line shell
commands in Makefiles, from the top of my head.  C-M-stuff is so
second nature in Emacs I don't even think when I'm using it, I just
expect it to work. I have user commands that use the underlying
functions, too.  By the way C-M-u is backward-up-list, not up-list
as I stated earlier (but both are broken, I think).

> can you suggest some other mechanism by
> which CC Mode can create the required font-locking?  If you can, and
> it's workable, we all win.

No, I can't, but I've asked others to chime in. I would personally do it
(in fact I already do do it) via flymake-mode. If you don't like that, sorry.

> C-M-u and C-M-f aren't broken.  You just have unreasonable expectations
> of them.

If you call unreasonable expectations gained from many years of using
Emacs in a variety of modes, including, up to very recently, cc-mode,
then clearly there's little point in proceeding this argument.

> > > No, you'd be cleaning up your code, to conform with the reality that in
> > > 2019 major modes use syntax-table text properties.  Features from CC
> > > Mode have a habit of migrating to the Emacs core.
> > It's not "my" code and I won't be bullied into making changes I don't
> > agree with.
> If anybody's the bully around here, it's not me.  I found a minor bug in
> electric-pair-mode, diagnosed it, and reported it.

You believe this is a bug in e-p-m. It's certainly your right to believe
that. I believe it's a bug in cc-mode. Do I have that right, too? Good.
Shall I open a bug report to joust with it, or is saying so enough?
I'd much rather the conflicting feature be disabled or made optional
in cc-mode, so that not only e-p-m starts working but also C-M-u,
C-M-f, etc. If don't agree, find a small enough solution that fixes
e-p-m, propose it here,  then find a consensus that overrides my
opinion, it happens all the time, won't hold it against you or
anyone else, good luck.

João Távora

reply via email to

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