HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
guns
vim-clojure-static
Vim Script2013–2015
guns / vim-clojure-static

vim-clojure-static

Meikel Brandmeyer's excellent Clojure runtime files

Developer ToolsLanguages & Compilers
Explore on GitHubRead Hacker News discussions
3Distinct people
4Mentions
0Explicit recommenders
423GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Meikel Brandmeyer's excellent Clojure runtime files

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month4 dated mentions

Observed mentions: 2013-08-13 19:20:48 UTC to 2015-05-05 02:06:13 UTC.

0122013-08-01 00:00:00 UTC to 2013-09-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsAug 20132013-09-01 00:00:00 UTC to 2013-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-10-01 00:00:00 UTC to 2013-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-11-01 00:00:00 UTC to 2013-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-12-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-01-01 00:00:00 UTC to 2014-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-02-01 00:00:00 UTC to 2014-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-03-01 00:00:00 UTC to 2014-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-04-01 00:00:00 UTC to 2014-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-05-01 00:00:00 UTC to 2014-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-06-01 00:00:00 UTC to 2014-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 20142014-07-01 00:00:00 UTC to 2014-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-08-01 00:00:00 UTC to 2014-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-09-01 00:00:00 UTC to 2014-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-10-01 00:00:00 UTC to 2014-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-11-01 00:00:00 UTC to 2014-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-12-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2015-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-02-01 00:00:00 UTC to 2015-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-03-01 00:00:00 UTC to 2015-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-04-01 00:00:00 UTC to 2015-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-05-01 00:00:00 UTC to 2015-06-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsMay 2015

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Aug 20132013-08-01 00:00:00 UTC2013-09-01 00:00:00 UTC202
Sep 20132013-09-01 00:00:00 UTC2013-10-01 00:00:00 UTC000
Oct 20132013-10-01 00:00:00 UTC2013-11-01 00:00:00 UTC000
Nov 20132013-11-01 00:00:00 UTC2013-12-01 00:00:00 UTC000
Dec 20132013-12-01 00:00:00 UTC2014-01-01 00:00:00 UTC101
Jan 20142014-01-01 00:00:00 UTC2014-02-01 00:00:00 UTC000
Feb 20142014-02-01 00:00:00 UTC2014-03-01 00:00:00 UTC000
Mar 20142014-03-01 00:00:00 UTC2014-04-01 00:00:00 UTC000
Apr 20142014-04-01 00:00:00 UTC2014-05-01 00:00:00 UTC000
May 20142014-05-01 00:00:00 UTC2014-06-01 00:00:00 UTC000
Jun 20142014-06-01 00:00:00 UTC2014-07-01 00:00:00 UTC000
Jul 20142014-07-01 00:00:00 UTC2014-08-01 00:00:00 UTC000
Aug 20142014-08-01 00:00:00 UTC2014-09-01 00:00:00 UTC000
Sep 20142014-09-01 00:00:00 UTC2014-10-01 00:00:00 UTC000
Oct 20142014-10-01 00:00:00 UTC2014-11-01 00:00:00 UTC000
Nov 20142014-11-01 00:00:00 UTC2014-12-01 00:00:00 UTC000
Dec 20142014-12-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
Jan 20152015-01-01 00:00:00 UTC2015-02-01 00:00:00 UTC000
Feb 20152015-02-01 00:00:00 UTC2015-03-01 00:00:00 UTC000
Mar 20152015-03-01 00:00:00 UTC2015-04-01 00:00:00 UTC000
Apr 20152015-04-01 00:00:00 UTC2015-05-01 00:00:00 UTC000
May 20152015-05-01 00:00:00 UTC2015-06-01 00:00:00 UTC101

What Hacker News says

2 sources
noprompt·Aug 16, 2013
> "But I don't think they address the problem inherent in Frak - there's no way to insure that the expression gives the intended result against an arbitrary input." I've made sure to thoroughly test the patterns produced by frak. They've also passed muster with another project where frak has proven to be a good idea (see this issue https://github.com/guns/vim-clojure-static/pull/28). While they are not full optimized (yet), I'm fairly sure they are correct. If you have found a counter example, please open an issue. > "The results with "barber" are indeterminate since the input string "bar" matches (^bar$) as well as (bar)." The next point release will allow users to specify an exact match. Initially, this wasn't an option because Clojure has two functions `re-find` and `re-match` for relaxed and strict matches respectively. user> (re-fi
Read the rest
nd #"bar" "barber") "bar" user> (re-find #"^bar$" "barber") nil > "I think VerbalExpressions suffers from a bit of the same conceptual problem as Frak - though perhaps to a lesser degree." There is nothing conceptually wrong with what VerbalExpressions or frak attempt to do. They may not provide value to everyone, but they are useful contributions and have tangible benefits. > "That problem is treating Regular Expressions as something other than the formal description of a language." Why is that a problem? It has been shown it's possible to use regular expressions as a means to perform arithmetic. Is that too a problem? I don't think so. Formality is a great thing and necessary. But it can also be the opposite. While I'll agree understanding it is important, I'll contend getting hung up on it is dangerous.
In Frak takes an entirely different approach to generating regular expressions
noprompt·Aug 13, 2013
Because that's not why I wrote frak. Originally, I wrote it to help eliminate backtracking and, indirectly, minimize the state table of two enormous regular expressions within Vim's Clojure syntax file (the README has a link in the "Why?" section by the way). Vim uses an NFA style engine and it was obvious to me that backtracking with these patterns would be an issue. Since we went to such great lengths to provide the most accurate regular expression highlighting possible for Clojure, which is pretty damn accurate, I figured we might as well try to make it performant. It turns out our efforts were not in vain. Have a look at this pull request: https://github.com/guns/vim-clojure-static/pull/28.
In frak: Transform collections of strings into regular expressions

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.