stevan / darkmeta Goto Github PK

Originally this was part of #4, but operators are a little tricky to link to, so this has to be worked out specifically.

The current line numbers plugin and line highlighter plugin are not so good for sharing, I would prefer it to work in the manner of github and metacpan. Might mean ditching these plugins, or might mean adding to them, we shall see.

The key aspect of this feature we want is social sharing, the ability to send someone a link with code highlighted.

It may be possible in some cases to be able to link SUPER:: and next::method calls to the actual superclass methods. Would be cool right?

Detecting core modules is easy, I should do that so that the syntax highlighter can know about them.

Should be as simple as passing the list of them to the new syntax highlighter code (see #1) and then having the JS link handler deal accordingly.

This is one of the logical conclusions to doing #13

Specifically JS, HTML and CSS seem sensible, maybe explore the lazy loader

I have begun altering the syntax highlighting to produce better CSS classes for which I can hook to, this is contrary to just efficient syntax highlighting, so best to move the code and call it something different (In case we want straight up Perl highlighting for some reason)

It would be nice to be able to display per-page statistics, such as:

• number of built-ins called
• number of packages loaded
• number of sub calls
• etc.

It would be a simple matter of asking jQuery to count the number of matching nodes for a given syntax CSS class, storing those counts somewhere and displaying them.

Make built-in functions, operators and keywords link out to specific perldocs.

Requires #3 to be done first.

The core modules should be in a predictable place (well, detectable anyway, we can always ask %INC for info) and we know they can be read by the running perl interpreter, so there is no reason you cannot navigate them as well.

See also #5

Build upon the line-number linking and sharing (see #7) and also allow a annotation to be embedded as well.

Ideally there should be some little icon to indicate that an annotation is there, clicking on it should enable the associated highlight and display the comment. It should be possible to dismiss a comment and have the highlight disappear as well.

Start out with just server specific annotations (the server can start up a SQLite DB or something), but this eventually should be able to be more centrally located if we want (a MySQL DB server or something).

Also, keep in mind the possible usages here, annotations can be

• Notes written for personal use when browsing the code
• Notes written to explain code to another person
• Notes written as a form of code review
• Notes intended to serve as long term public documentation

All of these imply differing levels of authorization, so that should be thought about.

And lastly, it would be great if these annotations could be accessible inside a text editor as well, but that is a completely different idea, but something to keep in mind.

See e94e393 ... this introduced an issue where when you select the code, the line numbers do not highlight, but they do show up in the copy/paste. This is likely just me not understanding the CSS here, so hopefully easy to fix.

We need to be able to differentiate between a module that is not from our DarkPAN codebase. Basically this means a Core or CPAN module, so the simplest fix is to link to metacpan docs for it.

Theme preferences should be stored in the users cookie, and we should respond appropriately with the right theme.

We should have a linkable file path at the top of the page.

Improve the syntax highlighter so that distinctions between keywords (if, foreach, etc) and built-in functions (map, length, etc) are more clear. Should be as simple as making different token regexp in the syntax highlighter code (which should be extracted in #1)

We need to detect use parent and use base, also extends (from Moose/Moo/etc) and maybe Mojo::Base as well. Detecting @ISA might be do-able, we will have to see.

We need to detect this for two reasons; we want to be able to make it linkable (of course), but also in case we want to be able follow SUPER and next::method calls (see #12) we will need this info.