Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TOC broken #6

Open
drewwells opened this issue Jul 19, 2011 · 5 comments
Open

TOC broken #6

drewwells opened this issue Jul 19, 2011 · 5 comments

Comments

@drewwells
Copy link
Contributor

Basically everything about TOC is broken, the only thing that seems to work is linking to other mdown files based on the autolinker.

Single file

APIStatus
Single-file
- {about.mdown}Broken
`File \n -{src/core}`Broken
Search by fileMissing
Manual linkBroken (autolinker or some case sensitive replacer is breaking it issue 5 )
Multi-file
- {about.mdown}Broken
`File \n - {src/core}` Broken (autolinker's dumb behavior sorta makes it work)
Search by fileMissing
Manual linkBroken (autolinker or some case sensitive replacer is breaking it issue 5 )
@dfreedm
Copy link
Owner

dfreedm commented Jul 20, 2011

Damn. I'll take a look at it.

@drewwells
Copy link
Contributor Author

I think I misunderstood how the TOC worked, we're depending heavily on h1 tags for iding files. There is a bit in dave's documentation on linking files by filetype. I'm going to work on that.

I also want to fix the autolinker from breaking already built anchors.

For instance [core](src/core.js) becomes <a href="src/core.js">core</a> but then the autolinker produces:

<a href="src/<a href="src/core.js">core</a>.js">core</a>

See the first instance of core is replaced with a link, the second left is as is (a different bug?).

So based on the ticket description, I'd say some of this is invalid. Do you think we should have a format for linking to files, or depend solely on h1 / filetype as the perl version does?

@drewwells
Copy link
Contributor Author

I gave search by filetype a serious look today. I was able to get it generally working in the Index, however it's going to be quite difficult to do it in the TOC. I am piggy backing on h1finder, to do a lookup for file type references. So at the same time that indexes are found, I find files with a specific type and built a list combining both.

However, the TOC is generated prior to processing the files and finding indexes. I need to rearrange things, so that h1indexing happens before any sort of markdown occurs. After markdown happens, it's too late to replace - [js] with

- file.js
- file2.js
- file3.js

I'm afraid I want have time over the next few days to do such a major refactor. I'm on vacation next week, so it may be a while before I get back into this.

@drewwells
Copy link
Contributor Author

The autolink mess is fixed by the [] wrappers. The directory enumeration code works very well, perhaps filetype searches should work within that context. I was going to do a recursive search for files, but it may be better to start with just directory searching.

How about we do something like this:

dir/*.js              - Find files in that directory only
dir/**.js            - Find files recursively from that directory
**.js                   - Find files recursively from pwd

#1 should be a simple regex, #2 and #3 may be difficult but you've made a good start at recursive parsing.

@dfreedm
Copy link
Owner

dfreedm commented Aug 14, 2011

That sounds good. It might be easier to just do a path-parsing step for all three cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants