GNU bug report logs -
#20732
in-string-p fails
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20732 in the body.
You can then email your comments to 20732 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Thu, 04 Jun 2015 09:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Andreas Röhler <andreas.roehler <at> easy-emacs.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 04 Jun 2015 09:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Cursor at 4th line before sdsd:
"asdf
(defun foo1 (&optional beg end)
sdsd "
;;;
(in-string-p) returns falsely nil, because it scans from "(defun "
This would do it
(defun ar-in-string-p ()
"Return delimiters start position, if inside, otherwise return nil. "
(interactive)
(save-restriction
(widen)
(let* ((erg (nth 8 (parse-partial-sexp (point-min) (point))))
(la (unless erg (when (looking-at "\\s\"")
(match-beginning 0)))))
(setq erg (or erg la))
(when (interactive-p) (message "%s" erg))
erg)))
Introduced "widen" - IMO there is no reliability without.
It also returns t if at the first char of a string-delimiter.
Source:
http://bazaar.launchpad.net/~a-roehler/s-x-emacs-werkstatt/trunk/view/head:/misc-utils.el
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Thu, 04 Jun 2015 10:00:05 GMT)
Full text and
rfc822 format available.
Message #8 received at 20732 <at> debbugs.gnu.org (full text, mbox):
On 06/04/2015 12:27 PM, Andreas Röhler wrote:
> (in-string-p) returns falsely nil, because it scans from "(defun "
See "** Font Lock displays portions of the buffer in incorrect faces."
in etc/PROBLEMS.
> (let* ((erg (nth 8 (parse-partial-sexp (point-min) (point))))
This is clearly inadequate, because it discards the performance
optimizations offered by `syntax-ppss'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Thu, 04 Jun 2015 11:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 20732 <at> debbugs.gnu.org (full text, mbox):
Am 04.06.2015 um 11:58 schrieb Dmitry Gutov:
> On 06/04/2015 12:27 PM, Andreas Röhler wrote:
>
>> (in-string-p) returns falsely nil, because it scans from "(defun "
>
> See "** Font Lock displays portions of the buffer in incorrect faces."
> in etc/PROBLEMS.
>
>> (let* ((erg (nth 8 (parse-partial-sexp (point-min) (point))))
>
> This is clearly inadequate, because it discards the performance
> optimizations offered by `syntax-ppss'.
In question slow is better than false.
There is no way to know reliably if inside a string than scanning the
whole buffer. All other is woodoo.
In result, it needs to consider these requests with care, re-use the
result rather then salting la code with in-string-p calls. :)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Thu, 04 Jun 2015 16:25:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 20732 <at> debbugs.gnu.org (full text, mbox):
> (in-string-p) returns falsely nil, because it scans from "(defun "
FWIW, `in-string-p' is a bug. It should be called thing-at-point--in-string-p.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Thu, 04 Jun 2015 21:00:07 GMT)
Full text and
rfc822 format available.
Message #17 received at 20732 <at> debbugs.gnu.org (full text, mbox):
On 06/04/2015 07:00 PM, Stefan Monnier wrote:
> FWIW, `in-string-p' is a bug. It should be called thing-at-point--in-string-p.
There already is some third-party code using it, though.
https://github.com/search?l=emacs-lisp&q="in-string-p"&ref=searchresults&type=Code&utf8=✓
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility.
(Thu, 04 Jun 2015 21:07:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Andreas Röhler <andreas.roehler <at> easy-emacs.de>:
bug acknowledged by developer.
(Thu, 04 Jun 2015 21:07:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
On 06/04/2015 02:50 PM, Andreas Röhler wrote:
> In question slow is better than false.
Then (setq open-paren-in-column-0-is-defun-start nil) in your Emacs config.
> There is no way to know reliably if inside a string than scanning the
> whole buffer. All other is woodoo.
There's a whole package dedicated to doing is faster and in easier
fashion: lisp/emacs-lisp/syntax.el.
You're welcome to suggest improvements that don't sacrifice performance
to this extent.
> In result, it needs to consider these requests with care, re-use the
> result rather then salting la code with in-string-p calls. :)
What is "it"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Thu, 04 Jun 2015 22:30:06 GMT)
Full text and
rfc822 format available.
Message #25 received at 20732 <at> debbugs.gnu.org (full text, mbox):
>> FWIW, `in-string-p' is a bug. It should be called
>> thing-at-point--in-string-p.
> There already is some third-party code using it, though.
I don't doubt it. But that doesn't stop it from being a bug.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 05:42:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
Am 04.06.2015 um 23:06 schrieb Dmitry Gutov:
> On 06/04/2015 02:50 PM, Andreas Röhler wrote:
>
>> In question slow is better than false.
>
> Then (setq open-paren-in-column-0-is-defun-start nil) in your Emacs
> config.
>
What about make Emacs honoring its own grammar instead? - and nothing else
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 06:02:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
Am 04.06.2015 um 23:06 schrieb Dmitry Gutov:
> On 06/04/2015 02:50 PM, Andreas Röhler wrote:
>
>> In question slow is better than false.
>
> Then (setq open-paren-in-column-0-is-defun-start nil) in your Emacs
> config.
>
>> There is no way to know reliably if inside a string than scanning the
>> whole buffer. All other is woodoo.
>
> There's a whole package dedicated to doing is faster and in easier
> fashion: lisp/emacs-lisp/syntax.el.
>
> You're welcome to suggest improvements that don't sacrifice
> performance to this extent.
>
>
Why not have two functions dealing with different circumstances.
- in-string-p-maybe, which might guess first and fast, re-fine afterwards.
- a precise in-string-p running parse-partial-sexp on widened buffer.
(defun in-string-p-precise ()
"Returns the character which delimits the string if inside, nil
otherwise. "
(save-restriction
(widen)
(ignore-errors (nth 3 (parse-partial-sexp (point-min) (point))))))
Maybe also return t if at string-start pos already:
(eq (char-syntax (char-after)) 34)
When not called from complex environment (also precise):
(defun ar-in-string-p ()
"Return position, if inside or at opening delimiter.
Otherwise return nil. "
(interactive)
(save-restriction
(widen)
(let* ((pps (parse-partial-sexp (point-min) (point)))
(erg (and (nth 3 pps) (nth 8 pps)))
(la (unless erg (when (eq (char-syntax (char-after)) 34)
(point)))))
(setq erg (or erg la))
(when (interactive-p) (message "%s" erg))
erg)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 08:37:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
On 06/05/2015 09:01 AM, Andreas Röhler wrote:
> Why not have two functions dealing with different circumstances.
But there are no different circumstances.
How would a caller determine which function to use?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 08:59:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
Am 05.06.2015 um 10:36 schrieb Dmitry Gutov:
> On 06/05/2015 09:01 AM, Andreas Röhler wrote:
>
>> Why not have two functions dealing with different circumstances.
>
> But there are no different circumstances.
>
> How would a caller determine which function to use?
Thought there might some kind of lazyness be implemented already.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 10:41:02 GMT)
Full text and
rfc822 format available.
Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):
Am 05.06.2015 um 08:01 schrieb Andreas Röhler:
>
Meanwhile think calling "widen" here is a mistake. Rather accept
narrowing might change the buffers state WRT in-string-p
Here the corrected forms:
(defun ar-in-string-p ()
"Return position, if inside or at opening delimiter.
Otherwise return nil. "
(interactive)
(let* ((pps (parse-partial-sexp (point-min) (point)))
(erg (and (nth 3 pps) (nth 8 pps)))
(la (unless erg (when (eq (char-syntax (char-after)) 34)
(point)))))
(setq erg (or erg la))
(when (interactive-p) (message "%s" erg))
erg))
(defun ar-in-string-p-fast ()
"Returns start position if inside, nil otherwise. "
(ignore-errors (nth 8 (parse-partial-sexp (point-min) (point)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 11:19:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
On 06/05/2015 11:58 AM, Andreas Röhler wrote:
> Thought there might some kind of lazyness be implemented already.
I don't understand what you mean by that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 11:54:02 GMT)
Full text and
rfc822 format available.
Message #46 received at submit <at> debbugs.gnu.org (full text, mbox):
Am 05.06.2015 um 12:34 schrieb Andreas Röhler:
>
> Am 05.06.2015 um 08:01 schrieb Andreas Röhler:
>>
> Meanwhile think calling "widen" here is a mistake. Rather accept
> narrowing might change the buffers state WRT in-string-p
>
> Here the corrected forms:
>
> (defun ar-in-string-p ()
> "Return position, if inside or at opening delimiter.
>
> Otherwise return nil. "
> (interactive)
> (let* ((pps (parse-partial-sexp (point-min) (point)))
> (erg (and (nth 3 pps) (nth 8 pps)))
> (la (unless erg (when (eq (char-syntax (char-after)) 34)
> (point)))))
> (setq erg (or erg la))
> (when (interactive-p) (message "%s" erg))
> erg))
>
> (defun ar-in-string-p-fast ()
> "Returns start position if inside, nil otherwise. "
> (ignore-errors (nth 8 (parse-partial-sexp (point-min) (point)))))
>
>
>
Sorry, nth 8 would be not enough:
(defun ar-in-string-p-fast ()
"Returns start position if inside, nil otherwise. "
(ignore-errors (nth 3 (parse-partial-sexp (point-min) (point)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 12:18:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 20732 <at> debbugs.gnu.org (full text, mbox):
On 06/05/2015 01:29 AM, Stefan Monnier wrote:
> I don't doubt it. But that doesn't stop it from being a bug.
It only has two usages in the Emacs core. I'd rather remove it altogether.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 12:53:01 GMT)
Full text and
rfc822 format available.
Message #52 received at submit <at> debbugs.gnu.org (full text, mbox):
Am 05.06.2015 um 13:53 schrieb Andreas Röhler:
>
> Am 05.06.2015 um 12:34 schrieb Andreas Röhler:
>>
>> Am 05.06.2015 um 08:01 schrieb Andreas Röhler:
>>>
>> Meanwhile think calling "widen" here is a mistake. Rather accept
>> narrowing might change the buffers state WRT in-string-p
>>
>> Here the corrected forms:
>>
>> (defun ar-in-string-p ()
>> "Return position, if inside or at opening delimiter.
>>
>> Otherwise return nil. "
>> (interactive)
>> (let* ((pps (parse-partial-sexp (point-min) (point)))
>> (erg (and (nth 3 pps) (nth 8 pps)))
>> (la (unless erg (when (eq (char-syntax (char-after)) 34)
>> (point)))))
>> (setq erg (or erg la))
>> (when (interactive-p) (message "%s" erg))
>> erg))
>>
>> (defun ar-in-string-p-fast ()
>> "Returns start position if inside, nil otherwise. "
>> (ignore-errors (nth 8 (parse-partial-sexp (point-min) (point)))))
>>
>>
>>
>
> Sorry, nth 8 would be not enough:
>
> (defun ar-in-string-p-fast ()
> "Returns start position if inside, nil otherwise. "
> (ignore-errors (nth 3 (parse-partial-sexp (point-min) (point)))))
>
>
>
>
and correct the doc-string
(defun ar-in-string-p-fast ()
"If inside, return character which delimits the string, nil otherwise. "
(ignore-errors (nth 3 (parse-partial-sexp (point-min) (point)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 15:19:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
> Why not have two functions dealing with different circumstances.
Makes no sense. The simpler solution is to make syntax-ppss let-bind
open-paren-in-column-0-is-defun-start. After all, this variable's
optimization is not useful for syntax-ppss (which already optimizes the
same kinds of things but in a different way); it's only useful for
things like back_comment (i.e. things like backward-sexp, or
forward-comment with a negative argument).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 15:20:03 GMT)
Full text and
rfc822 format available.
Message #58 received at 20732 <at> debbugs.gnu.org (full text, mbox):
> It only has two usages in the Emacs core. I'd rather remove it altogether.
I.e. remove all uses and declare it obsolete. Sounds perfect.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Fri, 05 Jun 2015 20:07:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 20732-done <at> debbugs.gnu.org (full text, mbox):
On 06/05/2015 06:18 PM, Stefan Monnier wrote:
> Makes no sense. The simpler solution is to make syntax-ppss let-bind
> open-paren-in-column-0-is-defun-start. After all, this variable's
> optimization is not useful for syntax-ppss (which already optimizes the
> same kinds of things but in a different way); it's only useful for
> things like back_comment (i.e. things like backward-sexp, or
> forward-comment with a negative argument).
Actually, (nth 3 (syntax-ppss)) in an Elisp buffer doesn't suffer from
the same problem as (in-string-p) since bug#16247 was fixed, and
syntax-begin-function is nil there. So a simple fix would be to replace
the definition of the latter with the former.
We can bind open-paren-in-column-0-is-defun-start to nil, but if someone
set syntax-begin-function to #'beginning-of-defun, maybe they meant
something by that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Sat, 06 Jun 2015 10:01:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 20732 <at> debbugs.gnu.org (full text, mbox):
On 06/05/2015 06:19 PM, Stefan Monnier wrote:
> I.e. remove all uses and declare it obsolete. Sounds perfect.
Done. Guess I'll keep its definition as-is; maybe some people had a
reason to use it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Sat, 06 Jun 2015 18:38:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 20732 <at> debbugs.gnu.org (full text, mbox):
> > I.e. remove all uses and declare it obsolete. Sounds perfect.
>
> Done. Guess I'll keep its definition as-is; maybe some people had a
> reason to use it.
I use it in thingatpt+.el:
(let (strg-end)
(while (setq strg-end (in-string-p))
;; Skip past string element of list.
(skip-syntax-forward "^\"")
;; Skip past new string opening, `"', into next string.
(skip-syntax-forward "\"")))
Please be sure to specify how `in-string-p' should be replaced.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20732; Package
emacs.
(Sat, 06 Jun 2015 18:43:03 GMT)
Full text and
rfc822 format available.
Message #70 received at 20732 <at> debbugs.gnu.org (full text, mbox):
On 06/06/2015 09:37 PM, Drew Adams wrote:
> Please be sure to specify how `in-string-p' should be replaced.
The obsoletion message includes that info.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 05 Jul 2015 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 48 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.