SymbolView: Add a plain-text-parser
AbandonedPublic

Authored by loh.tar on Jul 30 2018, 7:56 PM.

Details

Reviewers
sars
Group Reviewers
Kate
Summary
With this you have something like a table of contents when reading /
edit a plain text file like a README or other reasonably structured
file like a config file, CHANGELOG, diary or who knows what else.

See testfile.txt for the full description.

- Split and sort katesymbolviewerplugin_PART_SRCS in CMakeLists
Test Plan

Try the testfile.txt and some of your own plain text files

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
loh.tar created this revision.Jul 30 2018, 7:56 PM
Restricted Application added a project: Kate. · View Herald TranscriptJul 30 2018, 7:56 PM
Restricted Application added a subscriber: kwrite-devel. · View Herald Transcript
loh.tar requested review of this revision.Jul 30 2018, 7:56 PM

There are some comments added what "should be best", but that's of cause only my questionable opinion. Feedback is appreciated.

I'm not so happy with these icons. They looks nice but give me no idea what they mean. So I waste not much time to think about which one to use for section / header / paragraph. I searched in my installed icons for something fitting but without success. Ideas?

Is there any special use of the copyright/author block? Is that still the right one to use? I have seen similar with a copyright notice. And recently I took a look at ktexteditor/document.h which looks completely different, but very nice, perfect documented.

Hi Lothar. Everything in the KTextEditor namespace is public API. That's why we usually try to have excellent documentation there. The public API is also available on api.kde.org in the KTextEditor framework:
https://api.kde.org/frameworks/ktexteditor/html/classKTextEditor.html
https://api.kde.org/frameworks/ktexteditor/html/classKTextEditor_1_1Document.html

That said, it of course also makes sense to document internal API :)

Hello Dominik!

The public API is also available on api.kde.org in the KTextEditor framework:

Thanks for these hint

...it of course also makes sense to document internal API :)

Nice try to saddle me more work ;-)
Well, I may do it. But currently looks every part of these symbol-view very poor documented. So I think my new parser is in this point a step in the right direction.

...we usually try to have excellent documentation there

After a look there I found some issues which could be improved. But the "Report Bug Link" did not make me feel good, so I place it here, "off topic".

  • The layout miss on my screen some space between the longest "Parameter" name and its description e.g lineWrapped() looks like
    • Parameters
    • documentdocument which emitted this signal (missing space "document document")
    • position position where the wrap occurred

      I would prefer the description would avoid to repeat the parameter name, at least not start with, e.g
    • document Which emitted this signal
    • position Where the wrap occurred
  • The listed functions are not alphabetic ordered
  • The labels e.g. "signal" looks on my screen too small compared to the rest text
  • No "deprecated" label, I guess e.g. highlightingMode() is the "new" replacement for mode()
  • No reference from mode() -> highlightingMode()
sars added a comment.Aug 1 2018, 8:31 AM

Hi,

Wonder if this should be a markdown parsing plugin ;)

My first comment was supposed to be that please put the enums inside the parser class, but then I noticed like you wrote in the comments that all the parsers are part of the global KatePluginSymbolViewerView class...

I would still prefer that the enumerations would be placed in a namespace and that the helper functions would be static to not pollute the global namespace.

loh.tar updated this revision to Diff 38893.Aug 1 2018, 10:11 AM

I would still prefer that the enumerations would be placed in a namespace and that the helper functions would be static

Any drawback to put all in a namespace? Done so here

Wonder if this should be a markdown parsing plugin ;)

Sure, Markdown is very close. But not sure if it can be done all in one. Markdown is on my todo list

loh.tar updated this revision to Diff 39000.Aug 3 2018, 7:53 AM

Rename some enums to be more accurate and to be consistent with upcoming markdown_parser

SectionLine -> EqualLine
HeaderLine -> DashLine

A section/header consist of the text and the underlining, not the underlining itself

loh.tar updated this revision to Diff 39011.Aug 3 2018, 1:41 PM
  • Morph private namespace into class
  • Use define to shorten code lines
  • Rename all g_ to m_

There is no ctor/dtor as seen in katetabbar.cpp, objections?

@sars As mentioned elsewhere, I have now a (almost) finished version of a parser class. So don't invest to much of your limited time in this patch until the parser class version is uploaded. I hope you will like it.

loh.tar abandoned this revision.Aug 10 2018, 7:05 PM

I'm working on a replacement

sars added a comment.Aug 11 2018, 12:52 PM

OK, Cool :)

addons/symbolviewer/plaintext_parser.cpp
52 ↗(On Diff #38805)

You can do the init here with C++11. It is good practice to always initialize the member variables in the constructor or here, even if you always set them before usage.