Who would've thought that [t testing 3] would link to Koheles? :D

Version 3.3.0 released!!

Added reference highlighting and informational tooltips instead of alerts (you still get one alert on submit if there are errors).

This code is very ugly. I jerry-rigged and kludged my way through most of the problems, but with any luck, and some help, I may be able to improve that down the line.

@HodofHod Might be a good time to update github.com/HodofHod/SE-Modifications/blob/master/README.md

@HodofHod this says bad syntax: [g kiddushin 29a]

but it works again if i throw in any letter as a flag

@HodofHod: I'm not sure if this is intended behavior, but the 'u' flag creates a link even without the 'l' flag: [t Gen. 25:10 um] == Gen 25:10

@HodofHod: Also, pasting this into the edit box causes a huge slowdown when trying to do anything in the edit box, such as scroll: github.com/HodofHod/SE-Modifications/wiki/…

@HodofHod: The period is no longer included in when the 'u' flag is used: [t Gen. 25:10 um] == Gen 25:10, should be Gen.

@HodofHod: As @DoubleAA pointed out: [g Ber. 3A] == [g Ber. 3A] does not work.

@HodofHod: That was strange, I copied and pasted the previous 2 links, and the text changed, but they did not link

`[g Ber. 3A ul]` == [Ber 3A](hebrewbooks.org/shas.aspx?mesechta=1&daf=3&format=pdf)
`[g Ber. 3A tl]` == [Brachos 3a](hebrewbooks.org/shas.aspx?mesechta=1&daf=3&format=text)

@HodofHod: I inputted this into the edit box:

obviously, each one is highlighted as invalid. However, the first and the rest are invalid for different reasons (1st == bad syntax, others == ambiguous). When you mouseover one of them, and then directly move to the next mouseover (without having the mouse go over any unhighlighted area) the tooltip does not update. So if I start with the first one, the tooltip stays "Bad Syntax" the whole way down

@DoubleAA @HodofHod same with Mishna Torah: [mt deot] == [mt deot]

[mt deot f] == mechon-mamre.org/i/1200.htm

@DoubleAA: I put together some syntax variations for regression testing here: github.com/HodofHod/SE-Modifications/wiki If you can think of any other variation that should be tested, you can add it

@DoubleAA @Menachem Thanks for your help! I'll get to working on these asap.

@DoubleAA Uh oh! This looks like it was introduced in the previous version. I tried to make it so that you could add a flag with no separator ([t bereishis 3 4e]) but that's causing the gemara's side to be interpreted as a flag.

Just noticed this:

@Menachem I can't replicate this. There's always some unhighlighted area for me.

Other bugs: There was some flickering on the chat tooltips: fixed:

I just re-loaded the tool for the first time in a while. Whoa! The hilighting is cool.

There is an edge-case issue where the scroll bar causes the textbox to become narrower and therefore break the line earlier than the highlight overlay. I'm still not sure how to deal with this.

@IsaacMoses Thanks!

@IsaacMoses :D

I've thought about extending this to other sites, but it may require a little reworking, especially regarding which textboxes to run it on, and when to apply the changes (here we do it on submit, but elsewhere that may not work.)

@HodofHod Individual other sites could certainly fork your work and adapt it intelligently to themselves

@Menachem replicated! This is only a problem in chat, where the line-height means that the highlights are flush.

@IsaacMoses Absolutely! I actually need to work with @CharlesKoppelman to incorporate his quoting features into this script. I'd like it to be pluggable, rather than nailed in.

Num 7:1

@IsaacMoses If it's been a really long while, you should check out the post previews, we've got live updates. It acts like the referencer is part of the native markdown.

@HodofHod Yeah, that's part of what I was referring to by "hilighting"

@HodofHod Does it have to elide my '.' when I use lu (e.g. I entered "Num." above)?

@IsaacMoses Great! That was something I wanted to do for a while, glad I finally got it done.

@HodofHod This is a major advance in user-friendliness

I'm checking this bug out.

@HodofHod Cool

I'll probably commit 3 or 4 bug fixes within the half hour.

Do you think that once this reaches a certain level of maturity, SE would consider incorporating it into custom code for MY?

chabad.org/library/article_cdo/aid/1188346

@IsaacMoses That'sd be amazing! But I don't know. It'd mean maintaining a custom markdown for MY.

Rambam, Hilchot Melachim uMilchamot 2:5

I'm sure this isn't news to you, but in chat, this doesn't work on <Enter>, only on clicking send

@HodofHod They've done it for other sites.

@IsaacMoses Oh! Right, I remember this has been reported before. Hmm.

Bug: bottom of long tooltip not visible in chat.

@IsaacMoses Well then, sure!

@IsaacMoses I can probably work that out.

@HodofHod I first encountered the problem in the meta "ask a question" edit box

@Menachem Oooh, I see it!

@HodofHod I'm working on pulling the quoting feature out as a plugin, but I've had real-life get in the way. Most recent work is not on Github, but someone wants to put in the time, I'd be happy to take a pull request @IsaacMoses

@CharlesKoppelman Pesky "real life". Always interfering.

Somebody should do something about that.

@HodofHod :) By the way, I do have some changes in the featurePlugin branch locally... I'll commit it when I get the chance (likely Sunday)

@CharlesKoppelman Ok. You'll rebase first?

(I think that's how it works. I'm still new to this git stuff)

@HodofHod I'll try to merge your stuff in, but probalby after I commit the changes I have pending

I'll let you know what happens :)

@CharlesKoppelman Fair enough. Sorry if my code is a mess and hard to merge :(

@HodofHod I wonder if we should start developing code in files and having a build process of sorts that pulls them into one file

@CharlesKoppelman Hobbyist here. You're saying that each code section/function would be a different file, combined and committed at intervals?

@HodofHod Also, for what it's worth, smaller commits make merging code a bit easier

@CharlesKoppelman Hm. I see what you're saying. In this case, I don't think I could've split up the commits very well, since almost all the changes are interdependent.

@HodofHod that's perfect to put in one commit then :)

@HodofHod yeah something like that. basically, there'd be a folder in the repo (let's call it "lib") that has small bits of code, and there'd be a script file that you can run which compiles it all (somehow) into MY.Referencer.user.js

@HodofHod That way, @Menachem can work on adding Shulchan Aruch while you work on shiny UI features

or whatever

and the merges become easier

@CharlesKoppelman Gotcha. A warning then. This commit makes changes to nearly every function. search, reference, link, .link, are all changed. I wish I could say it was for a good reason, but really, it's just to pass back the error messages.

@HodofHod cool. might still be a good reason :)

@CharlesKoppelman Hmm. Has this really become a big enough project to warrant that? Wow.

@HodofHod no, probably not. i am just used to over-architecting things :)

...also I'm picturing other sites using this referencer for things like academic journals, dictionaries, and classical sources

which means that they'd want the basic functionality but not Mishne Torah

@CharlesKoppelman @IsaacMoses As regards running this on other sites (like Sefaria suggested) has another problem, namely that most other sites don't accept markdown, and only some accept html.

@Menachem Hmm. That's not good. It won't affect most users, b"h, but still. The truth is I'm certainly calling the relevant functions way too often, and this is because of that. I hope to streamline the code a bit.

@Alex Hello!

@HodofHod I'm confused at this. What do you mean?

..oh! you mean chat.stackexchange.com/transcript/message/10496740#10496740

I meant other SE sites

@CharlesKoppelman Oh! I was thinking of Sefaria's tweet.

@HodofHod :-) that's my tweet to Sefaria

@CharlesKoppelman Right, I was looking at their response

@HodofHod Oh I didn't even see that until now!

We can swap out the replacement syntax pretty easily. We'd need to work at it

@CharlesKoppelman Right. But many sites don't allow markdown or html, making this useless, at least client-side.

@HodofHod true. But if we're just talking the sefaria integration, it requires neither

@CharlesKoppelman True! I didn't think of that.

Any reason we need to allow multiple separators between groups?

@HodofHod typos and spaces. Also this format: chat.stackexchange.com/transcript/message/10470924#10470924

@CharlesKoppelman Hm. It's causing the '.' in [t Num. 3:4 lu] to get left out.

@HodofHod Yeah, i think it's fine to omit. or we can drop . as a delimeter. i'd drop - while you're at it so we can start doing ranges one day

....by "fine to omit" i mean "fine to not allow multiple separators"

i think allowing multiple spaces is useful, though, just because it's an easy mistake to make

@CharlesKoppelman Wait, I just discovered that since your OOP change, the name group can be greedy again. That fixes the problem. Hopefully it doesn't cause anymore that I may have forgotten...

@HodofHod what about `[t Num.3 4 lu]?

....but htat's such an oddball case I don't think we need to support it :)

@CharlesKoppelman Still works! It treats the . as a separator.

@HodofHod Then the catch is [t chron. 2 6]

which should be Divrei Hayamim Bet, Chapter 6

@CharlesKoppelman Still works! I don't know what sorcery hath made it, but it does!!

@HodofHod weird! well, then. good going!

:D

@blocks Hi! I got to take a peek at Sefaria, and it's looking awesome!

@blocks We hope to see you asking and answering around the site, that's where all the real Mi Yodeya magic happens! (But no pressure :D)

We've been discussing your suggestion to make the script work on other sites.

So @CharlesKoppelman Reminded me that the quoting feature can work anywhere, but the linking (the original purpose of the script) is a more specialized functionality.

@HodofHod @blocks Just wanted to second the Q&A thing. This is a side project for the actual purpose of the site :)

@blocks The problem I was running into with using the sefaria API through AJAX calls is that you don't allow CORS

So I needed to use GreaseMonkey's hack

which allows cross-origin ajax scripting. If you'd set up the sefaria website to allow CORS, this would be easier (but potentially dangerous)

@Menachem I've made some significant improvements to the speed, I'm going to try to do even more, but a commit is coming soon for this.

@blocks This is a potential way forward: stackoverflow.com/a/5047016

We don't support CORS, but we do support JSONP

@blocks ooh! how?

sefaria.org/api/texts/Gen.1?callback=foo

just add a "callback" parameter with the function name :)

thanks for bring to my attention that this is not at all explicit in the docs

@blocks perfect! it can likely be made browser-agnostic then

@blocks Welcome! Go symbiosis!

@blocks - then here's the beginnings of a sefaria bookmarklet: javascript:(function() { myAlert = function (data) { alert(data.he); }; var sefaria = document.createElement("script"); sefaria.type="application/javascript"; sefaria.src = "http://sefaria.org/api/texts/Rambam,_De'ot.3.1?context=0&commentary=0&callback=‌​myAlert"; document.body.appendChild(sefaria); })();

not for production use (obviously... for many reasons)

i'd want to integrate the search routine that @HodofHod did and then add in jquery to search/replace in all textarea and textboxes on the page

@HodofHod: The latest version seems to introduce a bug in the standard markup editing of questions and answers. I'll try to explain. 1) I enter some text in the edit box 2) highlight a section of the text with the intention of turning it into a link 3) click the link button on top of the edit box 4) enter link and press enter. -- Instead of linkifying the text I want, it puts [enter link description here][1] in the beginning of the edit box text.

@HodofHod: I tried this on a browser that does not have the plugin installed, and it works fine.

@Menachem Did this work in previous versions?

@HodofHod I do it pretty regularly, and I've never noticed it until now. Note that I am not using the plugin's functionality to automatically linkify something, I'm just trying to create a regular link in an answer or question I post.

@HodofHod: Let me know if you can replicate this

@Menachem I can. I think I can track this down.

@HodofHod: This answer - judaism.stackexchange.com/a/30164/603 - had the following text: Rambam Terumot 3:4 I wanted to linkify it as follows: [mt Rambam Terumot 3:4 lu] The result was not quite as intended: Rambam, Rambam Terumot 3:4

Rambam ([mt Maaserot 1:14 lu])` became Rambam (Rambam, Maaserot 1:14)

@Menachem I just committed some major speed improvements. Now I'm going to work on these two bugs.

@Menachem Why didn't you just replace the "Rambam" in the original text with "mt"? These two terms are synonymous.

@IsaacMoses ah - this is because we are always adding Rambam with the u option

I guess you wouldn't ever want your text to say "Tanach, Bereishit 1:1"

@IsaacMoses Didn't think of it. I like to be able to just take what other people put in, surround it with brackets and a couple flags, and have it just work.

that was a feature in the original mt lilnker and I wanted to preserve that

@CharlesKoppelman How about instead of appending "Rambam, " to the auto-text, add "Hilchot " to the beginning of each book title? That way, if someone doesn't set it off manually with "Rambam" or "Mishne Torah," it still looks like a Rambam reference, and if someone does, there's no redundancy?

@Menachem Fixed this

@IsaacMoses I'm not committed to this particular feature in any way. :)

If you do that, then Menachem would just have to know to wrap the "Terumot 3:4" and not the preceding "Rambam," and he'd end up with "Rambam Hilchot Terumot 3:4"

@HodofHod let me know when you commit it

I haven't committed it yet, though. Trying to fix the linking problem

@Menachem Will do.

@Menachem Did you see the speed improvements?

@HodofHod not yet

Also, fixed this problem:

That was committed with the speed ups

@HodofHod just checked it out. That is a huge speed improvement, good job!

@blocks שלום עליך! Hope to see you around :)

@HodofHod I just entered [t gen 1:2] and it's red

@CharlesKoppelman Well, I guess we discovered the downside!

It's considering the 1 as part of the name. [t gen 3:2] works

@HodofHod yeah, that's what i thought it was from. [t gen,1.2] works

Hm. What's the best fix for this?

@HodofHod only consider the number as part of the title if it matches titles that that would be valid. In this case Divrei Hayamim I, Melachim I, and Shmuel I.

@Menachem That would require a rewrite of the search function.

@CharlesKoppelman I just realized that the wrong bad behavior is happening. It should be matching Genesis and then getting the wrong chapter. An added 1 shouldn't make it ambiguous.

@HodofHod hrm. yes. but it's tring to find "gen 1" because the matcher is greedy

The truth is: There is no regexing way to distinguish between [t gen 1:2] and [t div 1:2]. The easiest solution to this that I can think of, is to simply disallow : as a separator between the title and the chapter. It makes sens to only allow it between chapters and verses.

@CharlesKoppelman is it because the matcher got greedy or because the following code tells it to treat a 1 or 2 as part of the title:

	if (['1', '2', 'i', 'ii'].indexOf(title_words[wordi]) !== -1) {//special case for multi-volumes
				word = '[,:]' + title_words[wordi] + '(,|$)';

@CharlesKoppelman Right. But the search() function should find one match for gen and return before even considering the volume number

@HodofHod So... how would you do that? it seems rough

@Menachem This code doesn't tell it that the 1 or 2 is part of the title; the regex does. This code just makes sure that, when matching 1 or 2 as part of the title, it only matches them as whole words, not partials. Otherwise i would be incredibly ambiguous.

@HodofHod this doesn't really solve the problem, because [t gen 1 2] still fails

@Menachem Yeah, I just realized that :(

.... Is the only reason this is greedy is to allow people to input periods at the end for their unaltered links?

@CharlesKoppelman ....kindof.

@HodofHod can we cahnage that? how come the old one works for [div 1 2]?

This problem is actually the reason it used to be non-greedy

@CharlesKoppelman It didn't. Hold on..

@HodofHod The OLD old one probalby did

Holy moley. I've been working on this for a month??

@HodofHod shkoyach

@HodofHod absolutely

@CharlesKoppelman :D Well, I've done something useful, learned a lot of JS and JQuery, and had fun. Time well spent in my book!

@CharlesKoppelman That was the old behavior.

oops. i edited the comment out.

Somebody stop me.

@HodofHod gah!

@CharlesKoppelman Yeah, that's what a lot of the code for the highlighting makes me yell.

so there are two problems, that i see

1. Users who are using u can't add a period

2. Users who are using u can't make their link "Shmuel 1"

3. (others can't use "Shmuel 1", but they can use Shmuel1, so who cares)

is that valid?

Can we make the u syntax more complex - like [t sam1 4:5 u|Shmuel 1]?

or provide that as an option?

That would let someone do somehitng like this, too:

[t Gen 5:1 u|This is the book of the generations of Adam]

@Menachem That puts a lot of Tanakh-specific knowledge into the search routine

@CharlesKoppelman That's possible: [This is the book of the generations of Adam]([t gen 5:1])

@HodofHod so you can do [Shmuel 1 1:2]([t shm1 1:2])

@Menachem That's what I thought you meant originally. That would require rewriting the search function and its arguments to allow for modification of the chapter and verse variables (which are not passed to search at all right now).

@CharlesKoppelman Absolutely.

@HodofHod and @Menachem Is this a problem we need to solve or can it just be part of syntax like @HodofHod said in the original specs?

note that [t gen 1] == chabad.org/library/bible_cdo/aid/8165 works properly

but [t mel1 2] doesnt

but [t melachim1 2] does

Ah. I broke my search function. It is probably impossible to link to a multi-volume sefer.

note that even [t shm1 1:1] does not work at the moment

[t 2chron 5:6 ml] is fine

@Menachem right, That's a search() issue, not a regex.

even crazier, [t shmuel1 3:1] links to chabad.org/library/bible_cdo/aid/15832#v=1, but [t 1shmuel 3:1] links to divrei hayamim

@CharlesKoppelman The problem is that if (titles_found.length === 0) in search() is always returning true, even if we've just appended some values to it.

I figured it out. On the first search pass, sam matches no whole word (as it should), and 1 is ambiguous. Ambiguous searches aren't retried as of now, since usually, subsequent search passes get broader. I'm writing a special case for this now, and we'll see where it goes from there.