xquery-mode / cider-any

Evaluate any buffer in cider – Replaced by Oook
0 stars 1 forks source link

hook for xml pretty-printing #8

Closed m-g-r closed 7 years ago

m-g-r commented 8 years ago

Hi, I currently use the function attached to pretty print xml buffers that have not even newlines (so that other auto-indentation does not work). It would be nice to have a hook somewhere in cider-any-uruk to add it. Right now, I temporarily added it to cider-any-uruk-display-buffer, but actually I would consider it to be some kind of content conversion filter that might be used regardless of the current handler (that is, in between eval and handle).

Of course, it would be nice to just call it in case of xml content, but right now cider-any seems to be content agnostic, right?

Consider this to be just a suggestion to think about! I'm not sure yet whether it is a good idea at all, to silently convert content. Maybe it is much better to just do the conversion always manually.

Thanks, Max

nxml-pretty-format.el.txt

proofit404 commented 8 years ago

I think it should be possible to integrate this feature easily.

proofit404 commented 8 years ago

I've added an example how to use xmllint with xml result and skip it in other. You need to evaluate all this forms to activate desired behavior. Please give it a try.

m-g-r commented 8 years ago

Works like a charm. I especially like that it detects the xml, and that you have not to do the detection yourself.

Now it'd be nice to easily to switch between both modes. Or have the nxml-version to warn somehow somewhere that the content has been silently pretty printed. What do you think about it? I'm a bit mixed minded what would be good. (Though, the multiple connection stuff is more important.)

Thanks, man!

proofit404 commented 8 years ago

If you want to turn on and off this feature, I can add customizable variable and toggle command for it. But I don't know what did you mean by "to warn somehow somewhere that the content has been silently pretty printed."

hanshuebner commented 8 years ago

I don't think that any warning is necessary. White space in XML can almost always be considered to be irrelevant, so always warning the user would not make any sense in the real world.

m-g-r commented 8 years ago

Just a flag in the buffer modeline or something like that. Non intrusive but visible, so that you think about the fact that it is not the original content, should in fact the reformatting introduce errors. (I don't know, maybe in case of incorrect xml.)

Easy toggling to switch the pretty-printing would be nice.

proofit404 commented 8 years ago

xmllint-mode was introduced today. To toggle pretty print behavior you can enable and disable this mode. Also it has xmllint-indicator customizable variable, so you can choose what string to use for flag in the buffer mode line.

hanshuebner commented 8 years ago

I've loaded examples/xmllint-mode and enabled it using M-x xmllint-mode, but my results are not formatted. Any ideas?

proofit404 commented 8 years ago

Mark part of the result buffer which cause this problem. Yank it into new buffer and call M-x normal-mode RET. Is current major mode equals to nxml-mode?

hanshuebner commented 8 years ago

​When I paste some XML from the result buffer into a new buffer and call M-x normal-mode, the buffer stays in "Fundamental" mode.

hanshuebner commented 8 years ago

It seems that the problem does not occur with all queries, so it most likely has something to do with the type that uruk reports for a query return element. Let me investigate some more before you put any effort into this.

proofit404 commented 8 years ago

Emacs can't understand that this content is actually XML rather plain text. I reused this mechanism to detect if result should be petty printed or not.

hanshuebner commented 8 years ago

Here's an example that shows how XML result indentation works and doesn't:

xquery version "1.0-ml";

declare namespace c = "http://mcna.net/Schema/claims/1.0";

((/c:claim[c:access-point/c:facility/c:type = "INDIVIDUAL"])[1], doc('/claims/10123935.xml'))

This returns 2 results. The first one (which is basically a query looking for some element satisfying a condition) is not indented, the second one (directly retrieving a document by URL) is. I suspect that uruk reports different types for each of these return values and that this causes the indentation not to be performed in the first case, but this is more a guess.

hanshuebner commented 7 years ago

Indenting seems to work only for documents that are retrieved from MarkLogic, not for elements that are constructed in XQuery. If you evaluate this:

<foo>
  <bar>
    <baz>
      hello world
</baz>
</bar>
</foo>

indentation is not triggered. This seems to make it more likely that the difference is in how document()s and element()s are returned by uruk.

proofit404 commented 7 years ago

Uruk returns list of strings of evaluated results. Isn't it?

hanshuebner commented 7 years ago

Yes, and I've now found out what the cause of the problem is. If one fetches a full document from MarkLogic, it contains <?xml version="1.0" encoding="UTF-8"?> as the first line which apparently is what nxml-mode is looking for to enable itself. For the purpose of the MarkLogic integration, it would be sufficient to look for a leading < sign. If the formatter fails for some reason (xmllint will exit with a non-zero exit status), the return value should be displayed unformatted. Possible?

proofit404 commented 7 years ago

Yes. I don't see any problem with that implementation.

proofit404 commented 7 years ago

Done. If result have < as it first non blank char then pretty printing is applied.

m-g-r commented 7 years ago

xmllint should probably be renamed to something more specific. This is not a general xmllint-mode but something very specific for cider-any-uruk. Maybe cider-any-uruk-pprint or nxml-pprint-uruk were more fitting names, though arguably more ugly.

proofit404 commented 7 years ago

I've renamed xmllint to the cider-any-uruk-pprint.

Can be this issue considered solved?

m-g-r commented 7 years ago

Yes. Works well. Thank you!