bug#20732: in-string-p fails

bug#20732: in-string-p fails

[Andreas Röhler]

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

bug#20732: in-string-p fails

[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'.

bug#20732: in-string-p fails

[Andreas Röhler]

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. :)

bug#20732: in-string-p fails

[Stefan Monnier]

> (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

bug#20732: in-string-p fails

[Dmitry Gutov]

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=✓

bug#20732: in-string-p fails

[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.

> 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"?

bug#20732: in-string-p fails

[Stefan Monnier]

>> 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

bug#20732: in-string-p fails

[Andreas Röhler]

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

bug#20732: in-string-p fails

[Andreas Röhler]

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)))

bug#20732: in-string-p fails

[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?

bug#20732: in-string-p fails

[Andreas Röhler]

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.

bug#20732: in-string-p fails

[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)))))

bug#20732: in-string-p fails

[Dmitry Gutov]

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.

bug#20732: in-string-p fails

[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)))))

bug#20732: in-string-p fails

[Dmitry Gutov]

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.

bug#20732: in-string-p fails

[Andreas Röhler]

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)))))

bug#20732: in-string-p fails

[Stefan Monnier]

> 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

bug#20732: in-string-p fails

[Stefan Monnier]

> 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

bug#20732: in-string-p fails

[Dmitry Gutov]

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.

bug#20732: in-string-p fails

[Dmitry Gutov]

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.

bug#20732: in-string-p fails

[Drew Adams]

> > 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.

bug#20732: in-string-p fails

[Dmitry Gutov]

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.