-
Notifications
You must be signed in to change notification settings - Fork 167
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
unfinished: make markdown links fold into clickable links like org-mode #107
unfinished: make markdown links fold into clickable links like org-mode #107
Conversation
Sorry I haven't gotten back to you yet. I haven't seen org-mode's link folding yet, but I will take a look. I also have an incomplete local branch with a matching function for links and I have some ideas about how to best implement this, but it may be a couple of days before I can write them down in more detail. When investigating #110 I found some more general issues with the way cached match data is used that should be fixed first. |
Ok, no worries. I'll take a look at that too when I can. |
I was looking for something else and found this. Maybe it is of interest? |
That sounds really promising. My problem was that I was getting that weird On Sun, Mar 13, 2016, 10:54 Jason Blevins notifications@github.com wrote:
|
Yeah, sorry for the slow response on my end too. Still haven't looked at org-mode links, but I will. And I'll dig up my own branch to see what the hang up was there. Honestly, I didn't look too closely at the code on SO. I'm not necessarily endorsing what's there, but given the topic I thought I'd pass it along in case there was anything useful. Briefly, my thoughts are that for inline elements like links we should skip the text property phase and jump straight to fontification with a matching function (and match all components in one pass, rather than making one pass for link text, another for the URL part, etc.). |
Makes sense, both performance-wise and complexity-wise. I thought it'd make On Sun, Mar 13, 2016, 14:42 Jason Blevins notifications@github.com wrote:
|
Was there ever any progress on this? Folding of links would be a huge boost to readability in Emacs. I would definitely take inspiration from org-mode, as it handles links very nicely. |
I agree. It's high on my list now--long inline links have been bugging me a lot lately--and I have some time to work on it. I've got a local working branch, where I'm taking a different approach than this patch, but it's not ready yet. As an aside, this is related to issue #130. |
Sounds good! I'm happy to test or provide any feedback in the future. |
Check out the latest master. Here are the relevant changes:
The remaining part is to write an easy link editing function, but as in org-mode you can delete the last character to edit the URL for now. |
Excellent, thanks! Just took a quick look and it works fine on my end. Any reason for displaying as Thanks again! |
Great! With Org, there is only one type of link (I think). In Markdown, however we have inline and reference links (and wiki links as an extension). The only way to tell the difference is if we keep the final brackets or parentheses, so I didn't hide those (yet). It's also part of a bigger plan, in which we will have an option to hide most or all markup (including the link brackets) as a separate level of hiding. |
Sounds good, was just curious. Definitely already a nice improvement to having long links everywhere. |
I've been trying to work on something like this for the past few days. Basically, org-mode turns all plaintext links into clickable links that go to elsewhere in the file, to places in other files, to web pages, whatever. I was looking at implementing something like that for markdown-mode which would basically just:
This doesn't do either of those things yet, because to do that I would have had to be able to apply text properties to links. So I started off with emulating the current link highlighting with properties instead of font lock regexes. This currently doesn't work and hangs in weird situations; in particular, the text:
where
|
is the location of point, hangs when RET is pressed. In addition,[]()
isn't highlighted correctly, although it is propertized correctly. I don't know why that's the case, because[a](a)
is highlighted and propertized correctly, and the regex allows for no characters in between brackets.Would this be a feature that would be cool to finish and then enable with a toggle? Is there anything obvious I'm doing that might cause the current behavior to hang and incorrectly highlight?