Request: API to access string literal information

[tkf]

I know it took some time to implement parser for triple quote, so it would be great if python.el provides APIs then other libraries can use the information. The API I have in mind is something that returns values bound in let* clause in python-fill-string. For example, how about a function called python-string-info to return a plist like this (so that you can easily destructure it by destructuring-bind):

(:start INT
 :end INT
 :num-quotes INT
 :quote-str STR  ; " or '
 :multi-line-p BOOL
 :docstring-p BOOL)

or probably a defstruct object. High-level API functions such as python-triple-string-p and python-docstring-p would be useful too.

BTW, I guess the variable marker in the beginning of python-fill-string is not used.

[andreas-roehler]

(defun py-docstring-p (pos) "Check to see if there is a docstring at POS." (save-excursion (goto-char pos) (if (looking-at-p "'''|\"\"\"") (progn (py-beginning-of-statement) (or (bobp) (py-beginning-of-def-or-class-p))) nil)))

provided by Tom Willemsen, MR seen here.

As for the requested API, which should be quite simple also, could you provide some example-code, use-case?

[andreas-roehler]

Here is py-in-triple-string-p

https://gist.github.com/andreas-roehler/5124486

Implementation for python.el must leave out line containing py-verbose-p, remaining stuff should work.

As for the python-string-info API

python-mode.el, py-fill-string delivers that values inside.

However, check for multi-line-p is done after formatting only. From there seems not useful to collect that at once.

Best,

Andreas

[tkf]

@andreas-roehler python.el already got a way to tell you about strings. It is just not exported. There is no need for writing another functions or borrow them from python-mode.el. All I am asking in this issue is to refactor python.el.

[fgallina]

@andreas-roehler this is not a bug tracker to discuss features/misfeatures of python-mode.el but of python.el. Talking about ways to perform such thing on python-mode.el is not only out of scope but also adds noise to the tracker. How the implementation details in python.el would be is up to me, unless you provide a full patch against python.el itself using its code-base.

What @tkf is asking if for is an API to access several string information python.el IS already aware of, instead of finding you way around the code. And I may well provide it once Emacs 24 is out (and it's likely it will end up into python-mode, like most stuff that happened since python.el release).

[tkf]

@fgallina That's good to hear! I hope python-mode.el quit being a major mode and become a minor mode that runs on top of python.el (and then probably rename)... Having two major modes for a language is really stupid and confusing. I hope providing enough APIs guides in this way.

[fgallina]

@tkf so, it's been a long time since this discussion. I think I rather prefer people use the functions separately to retrieve properly what they want from the context rather than keep convoluting python.el with this stuff. Perhaps for the tasks you have at hand it makes sense, you could perhaps write it as an extension to python.el?

Sorry for the long delay.