Once I saw somewhere a sly link to w3c.org document. And it was suffixed by "diff" or something like, for instance: http://www.w3.org/TR/selectors-api2/diff/bla-bla-bla.
And it show what was added, what was removed like in diff tool.
So my question is, how can I view diff between documents on w3c.org without externall tools?
You're looking for this service:
http://services.w3.org/htmldiff
(was found by googeling: w3c diff, second result).
Example: http://services.w3.org/htmldiff?doc1=&doc2=http%3A%2F%2Fwww.w3.org%2FTR%2Fselectors-api2%2F
Related
Years ago, I wrote a small app in itext2 to gather reports on a weekly basis and concatenate them into one PDF. The app used com.lowagie.text.pdf.PdfCopy to copy and merge the PDFs. And it worked fine. Performed exactly as expected.
A few weeks ago I looked into migrating the application to itex7. To that end, I used the copyPagesTo method of com.itextpdf.kernel.pdf.PdfDocument. When run on the same file set, this produces warnings like:
WARN PdfNameTree - Name "section.1" already exists in the name tree; old value will be replaced by the new one.
When I click on the link to "section.1" in the first document of the merged PDF, I am taken to "section.1" of the last document. Not what I expected and not what happens when using the itext2 app. In the PDF's produced by itext2, if I click on the link to "section.1" of the first document in the combined PDF, I am taken to section 1 of the first document.
There is a hint in Javadocs for copyPagesTo saying
If outlines destination names are the same in different documents, all
such outlines will lead to a single location in the resultant
document. In this case iText will log a warning. This can be avoided
by renaming destinations names in the source document.
There is however, no explanation of how this should be done. I find it odd that this should be necessary in itext7, although it wasn't in itext2.
Is there a simple way to get around his problem?
I've also tried the Sejda desktop app and it produces correct results, but I would prefer to automate the process through a batch script.
My guess is iText 2 didn't even know it might be a problem.
If iText can't deduplicate destination names, the procedure is roughly:
Follow /Catalog -> /Names -> /Dests in each document to find the destination name tree.
Deduplicate the names, by adding suffixes. Remember that a name with a suffix added might be equal to an existing name in the same or another document. Be careful!
Now you can rewrite the destination name trees. Since you have only used suffixes, you can do this in place - the lexicographic ordering of the names is unaltered so the search tree structure is not broken.
Now, rewrite destination links in each PDF for the new names. For example any dictionary entry with key /Dest, or any /D in a /GoTo action.
Now, after all this preprocessing, the files will merge without name clashes.
(I know all this because I've just implemented it for my own PDF software. It's slightly hairy stuff, but not intractable.)
If you like, I can provide a devel version of cpdf with this functionality, if you would like to test it.
I know I can exclude one author by -author:someone, but it looks like excluding 2 authors doesn't work: -author:user1 -author:user2. The result will include the user2.
I read GitHub search syntax doc but could find a solution.
Is there a way to exclude 2 authors at the same time?
I don't seem to be facing the same issue as you for some reason. I tried searching "rust" in:name, to show all repos matching the exact phrase "rust", which gave me the following results (you can view them on GitHub here):
screenshot of searching "rust" in:name on GitHub
I then searched "rust" in:name -user:rust-lang -user:TheAlgorithms -user:tensorflow (view them on GitHub here) to exclude the first 3 authors from the results, which worked a charm:
screenshot of searching "rust" in:name -user:rust-lang -user:TheAlgorithms -user:tensorflow on GitHub
I'm trying to find the source for R14B05.
The reason is that I want to see how Precise Explanation of Typing Errors was implemented. That page provides a link to the source code, but it doens't seem to be version-controlled. So I want to diff against the code is based on in order to see what changed.
The page that links to the paper says that the code is based on R14B05, so now I'd like to try diffing against R14B05.
I look at https://github.com/erlang/otp/releases?after=OTP_R16B01_RC1 or git tag -l in the repo, I can only find R14B04, then the R15 series–no R14B05.
I see no R14B05 anywhere, only R14B01-R14B04.
http://erlang.org/download/ and http://erlang.org/documentation/ seems to have old files.
doc-5.8.5 is for Erlang/OTP R14B04, and the next one, which is doc-5.9, is for Erlang/OTP R15B. There does not appear to be a R14B05 one, so perhaps it indeed could be a typo. Perhaps they thought 5.8.5 was R14B05?
You could try contacting the authors as well, just in case.
How can I view the Markdown of a comment in a GitHub issue? For example, I would like to see the Markdown that makes up this comment:
https://github.com/jashkenas/backbone/issues/3857#issue-116738665
Simply replace username, reponame and issue number in the following url:
https://api.github.com/repos/USERNAME/REPONAME/issues/NUMBER/comments
Here's an example
First, the first post is the actual issue itself, not accessible but the GitHub issue API:
https://api.github.com/repos/jashkenas/backbone/issues/3857/comments
That list only 3 comments, since the first post is not a comment.
The issue itself has a formatted body:
https://api.github.com/repos/jashkenas/backbone/issues/3857
That returns:
"body": "In Safari , pass a path using unicode string to `navigate` method like this\r\n\r\n```js\r\nBackbone.history.navigate('/city/北京',{trigger:true});\r\n```\r\nThe hash is incorrect. It output\r\n\r\n```js\r\nlocation.hash\r\n//> #/city/%17%AC\r\n```\r\n\r\nI tracked the code, it caused by `_updateHash` method.\r\n\r\nThe call stack created by `History.prototype.navigate` method like this\r\n\r\n* navigate\r\n - decodeFragment\r\n - _updateHash\r\n\r\nThe fragment passed to `_updateHash`, was decoded by `decodeFragment`, so the hash was incorrect。\r\n\r\nI also searched the commit history, the `decodeFragment` added in \"1.2.0\"\r\n\r\nPS: My english is not good, although I am trying to improve\r\n\r\n",
That is not exactly mardown:
In Safari , pass a path using unicode string to `navigate` method like this
```js\r\nBackbone.history.navigate('/city/北京',{trigger:true});
```\r\nThe hash is incorrect. It output
```js\r\nlocation.hash
//> #/city/%17%AC
```
I tracked the code, it caused by `_updateHash` method.
The call stack created by `History.prototype.navigate` method like this
* navigate
- decodeFragment
- _updateHash
The fragment passed to `_updateHash`, was decoded by `decodeFragment`, so the hash was incorrect。
I also searched the commit history, the `decodeFragment` added in \"1.2.0\"
PS: My english is not good, although I am trying to improve
The second comment in this issue has two images, so those fancy effects are no markdow:
https://cloud.githubusercontent.com/assets/516562/11164567/62f9ddf6-8b2f-11e5-8aa8-631c1aa84422.gif
[https://jsfiddle.net/leexiaosi/uyp3o6ek/](https://jsfiddle.net/leexiaosi/uyp3o6ek/)
**notice!!!** : please open in safari.
### the record of safari
### the record of chrome
It's probably late. But I could somewhat do it this way (at least in firefox).
I am assuming your intention is to copy the formatting of the comment.
This is not an exact solution, but since GitHub supports HTML tags in comments, this will work just fine.
Right click somewhere at the top of the comment you want to copy.
Inspect element
In the Inspect Element box, you will find a line that's a few lines above the highlighted line which has this code:
<td class="d-block comment-body markdown-body js-comment-body">
Right click on the line having the above code
Select Copy>Inner HTML
Now you can either paste this in a comment box, preview it and you'll be able to see the same formatting, OR use an online HTML to MD converter.
You can see the raw markdown by using "Quote reply" (found after clicking three dots at top right of a comment.
Here's the beginning of the comment you asked for:
In Safari , pass a path using unicode string to navigate method like this
Backbone.history.navigate('/city/北京',{trigger:true});
The hash is incorrect. It output
location.hash
//> #/city/%17%AC
...
I'm new to Github and just want to browse through repos to find interesting ones.
I want, say, all ruby repos with more than 100 followers.
I go to advanced search and try "followers:100"
and get only repos with EXACTLY 100 followers (4 at the moment).
That differs from what i expect to be default behavior - find repos with 100 or more followers (more like Stackoverflow search works).
I am quite frustrated, because I can't get what is expected to be basic search functionality from a very popular site, and that makes me think that I'm obviously not understanding something very simple (because I think it is not possible for Github not to have such functions).
So is there a way for me to get the desired result?
Update January 2013 (source: "A whole new code search")
followers:>100
(intervals are supported: followers:100..150)
Original answer (April 2011)
followers:[100 TO *]
should do what you want: see your query with 100 or more followers.
(Note: the "TO" needs to be in uppercase)
(Source: New and Improved Search)
For example, we can search:
for people with a username fuzzily similar to ‘chacon’
who use Ruby as their primary language,
have at least 5 repos and
at least one follower:
You might also like the Hubscovery application. A simple search interface for Github.