[Top][All Lists]

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

Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp

From: Alan Mackenzie
Subject: Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe.
Date: Mon, 5 Dec 2011 11:35:03 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Stefan,

On Sun, Dec 04, 2011 at 10:33:37PM -0500, Stefan Monnier wrote:
> >>> If you change (nth 5 ppss) you would still have to say that (nth 4 ppss)
> >>> is unreliable in this special case.
> >> Not if (nth 5 ppss) says that the buffer position is the one *after* the
> >> "/*" sequence.  Of course for "*/" we'd conversely want to use the state
> >> *before* "*/".
> > What I meant was that the caller would have to care about (nth 5 ppss)
> > too, wherever she now looked only at (nth 3 ppss) and (nth 4 ppss).

> That's what I understood and my suggestion does address this issue (tho
> it means that (nth 5 ppss) will sometimes refer to a buffer position
> after (point) and sometimes before).

I think this is very wrong, and will lead to unwanted complications.  I
would suggest this:

  5. `t' if point is just after a quote character.  The character just
  scanned if that might be part of a double character comment boundary.

This should be straightforward to hack.

However, there will be crazy hackers who have tested (nth 5 ppss) as
being non-nil, rather than looking for t.  :-(  I say, tough on them.

> A case that needs to work is "/*/" in C mode, for example.

The above suggestion would handle this appropriately.

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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