emacs-devel
[Top][All Lists]
Advanced

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

Re: CC Mode and electric-pair "problem".


From: Stephen Leake
Subject: Re: CC Mode and electric-pair "problem".
Date: Fri, 06 Jul 2018 16:58:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt)

Stefan Monnier <address@hidden> writes:

> An unterminated string can only occur in an invalid piece of code.
> To the extent that invalid code has no clear meaning, there's no way
> to know what is really the "right" behavior.

True, but I still agree with Alan; treat the newline as a string
terminator for fontification.

> My point of view is that Emacs should focus on behaving as correctly as
> possible for valid code.  The only effort worth doing w.r.t invalid code
> is to avoid doing something clearly harmful and to help the user make
> the code valid again.  Anything further than that is time that would be
> better spent improving the handling of valid code.

I disagree. When we are editing code, it has incorrect syntax most of the
time, yet we still as Emacs to fontify and indent it. So it is a strong
requirement that Emacs work "acceptably well" in this context.

I'm working on adding robust error correction to my Ada parser,
precisely for this purpose.

> I don't see any concrete benefit (for the user) of the new behavior over
> the old (or the reverse for that matter).  Either behavior is equally
> good and which behavior is better will depend on things which Emacs
> cannot know unless the user explicitly tells us.

Right. It would be nice to have the "terminate string on newline"
behavior as an option.

>> Up till now, Emacs hasn't bothered - it just allows these strings, and the
>> subsequent buffer portion, to be fontified randomly.
>
> It's not random: it's arbitrary.  The new behavior is also arbitrary.

Right.

> OTOH, there is very concrete evidence that the new behavior is worse in
> the sense that it adds complexity to the code and (as expected)
> introduces bugs.
>
> To me, this is a bad tradeoff.

Ok. I'm hoping for a coding solution that is not as complex.

-- 
-- Stephe



reply via email to

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