profile
viewpoint
Rory O’Kane roryokane Jersey City, United States https://roryokane.com/

jlehmann/git-submod-enhancements 26

Enhancements for git usability when using submodules

kirstein/generator-node-cs 5

Yeoman generator for node-coffeescript with no excess bullshit

roryokane/build-it-break-it-fix-it-contest-fall-2014 2

My entry for the Build It Break It Fix It contest (https://www.builditbreakit.org/) in Fall 2014. Includes a write-up about how it works and what I learned.

roryokane/active_admin 1

The administration framework for Ruby on Rails applications.

roryokane/bigtuna 1

Continuous Integration software written on top of Ruby on Rails 3 and DelayedJob.

roryokane/adfilt 0

The place where I, DandelionSprout, store my web filter lists, including my Nordic adblock list. As simple as that, really.

roryokane/ADHN 0

Inline summaries on the HN front page

roryokane/advent-of-code-solutions 0

My solutions to the Advent of Code coding puzzles, in Clojure, Ruby, and other languages.

roryokane/athens 0

Open-Source Networked Thought

issue openedtimburgan/timburgan

chess|move|e6h6|2599

Just push 'Submit new issue'. You don't need to do anything else.

created time in 9 days

issue openedtimburgan/timburgan

chess|move|h6h5|2599

Just push 'Submit new issue'. You don't need to do anything else.

created time in 9 days

issue openedtimburgan/timburgan

chess|move|c4e6|2599

Just push 'Submit new issue'. You don't need to do anything else.

created time in 9 days

startedevdenis/adb_root

started time in 12 days

PR opened danburzo/nbf

Use “...” consistently in the README’s example
+2 -2

0 comment

1 changed file

pr created time in 14 days

push eventroryokane/nbf

Rory O’Kane

commit sha f143d7aabcbb6f0434acd2ab80d84a7dba9c4049

Use “...” consistently in the README’s example

view details

push time in 14 days

fork roryokane/nbf

CLI tool for working with the Netscape Bookmark File format

fork in 14 days

PR opened danburzo/qsx

In README, fix terminology of “{}” characters

Parentheses are usually understood to be “()”. See https://en.wikipedia.org/wiki/Bracket#Parentheses and https://en.wikipedia.org/wiki/Bracket#Curly_brackets.

+2 -2

0 comment

1 changed file

pr created time in 14 days

push eventroryokane/qsx

Rory O’Kane

commit sha e72b60a698f1c28caebed4a9e9ac76cd08c36056

In README, fix terminology of “{}” characters Parentheses are usually understood to be “()”. See https://en.wikipedia.org/wiki/Bracket#Parentheses and https://en.wikipedia.org/wiki/Bracket#Curly_brackets.

view details

push time in 14 days

fork roryokane/qsx

Extended CSS selectors for querying the DOM

fork in 14 days

pull request commentathensresearch/athens

(experimental) fix(parser): performance fix for parser using LL(1)-like parsing

@HaojiXu I don’t understand exactly what problem you were running into with the Unicode character classes in the hashtag parsing regexp, but I wondered if it was related to browser support for that feature:

From those tables it seems that \p{…} in regexps is supported in all modern browsers as well as Node since v10. However, Firefox only gained this support in the last month with the release of version 78. Were you testing on Firefox 77? If so, that could be the problem.

HaojiXu

comment created time in 15 days

startedchocolateboy/google-direct

started time in 16 days

issue commentathensresearch/athens

Figure out why loading big pages is so slow

It makes sense that any-char would be slow, so that’s probably a good guess.

The parse rule introduced in commit 9433e79 demonstrates a more efficient way to parse “any chars”:

<any-non-page-link-chars> = #'[^\\[\\]]*'

We can probably replace other uses of any-chars with similar constructions.

I didn’t write the parser with regexes like that to start with because such regexes slightly increase the difficulty of adding new syntax that may be nested. For example, if page links could contain **bold** text, the above regex would have to be #'([^*\\[\\]]|\\*[^*])*' (or you could use a shorter regex paired with another parse rule). The information that the syntax for bold text is ** would be duplicated both in the bold rule and in regexes of rules that can contain bold text.

tangjeff0

comment created time in 20 days

PR closed you-dont-need/You-Dont-Need-Lodash-Underscore

Correct the description of _.isString

The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

+1 -1

2 comments

1 changed file

roryokane

pr closed time in 20 days

pull request commentyou-dont-need/You-Dont-Need-Lodash-Underscore

Correct the description of _.isString

I notice that you already merged a PR that incorporates this PR’s changes and also does the extra things you were asking me to do: PR #288. That means there is no need for my PR, so I will close it.

roryokane

comment created time in 20 days

startedparnold-x/nasc

started time in 24 days

push eventroryokane/CalcuDoc

Rory O’Kane

commit sha 8990f427052918073ddcde39a94efc724b8b7c90

Update README image link so it renders on GitHub It rendered on GitHub before, but GitHub changed their Markdown rendering engine.

view details

push time in 25 days

issue openedfacebook/flow

Can’t assign values to `mixed` when it’s within an Array or Object type

Flow version: v0.128.0

Expected behavior

According to the documentation page Mixed Types, anything can be assigned to mixed:

mixed will accept any type of value. Strings, numbers, objects, functions– anything will work.

That documentation page doesn’t say it should work any different when mixed is inside an array or object. Therefore, the following code, which uses an Array<mixed> type, should pass Flow type checking:

const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

Additionally, all of the example code in the “Actual behavior” section should pass Flow type checking.

I know that covariance and contravariance can sometimes cause similar confusion, but I don’t see why it would change my expectations here.

Actual behavior

Flow raises type errors in four of the six paragraphs of code below (demo on Try Flow):

// @flow

// mixed works when it’s a top-level value
const num: number = 3;
const mix: mixed = num;

// mixed FAILS inside array types
const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

// mixed FAILS inside object types
const personWithNumberAge: { age: number } = { age: 55 };
const personWithMixedAge: { age: mixed } = personWithNumberAge;

// mixed FAILS inside indexed object types
const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
const stringsToMixed: { [string]: mixed } = stringsToNumbers;

// mixed FAILS inside indexed object types as function parameters (my use-case)
function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
  return Object.keys(obj);
}
withStringsToMixed(stringsToNumbers);

// generics work inside indexed object types
function withStringsToGeneric<T>(obj: { [string]: T }): Array<string> {
  return Object.keys(obj);
}
withStringsToGeneric(stringsToNumbers);

The type errors are of this form:

Cannot assign somethingContainingNumbers to somethingContainingMixed because number [1] is incompatible with mixed [2] in [some container]. [incompatible-type]

    9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                          ^ Cannot assign `arrayOfNumbers` to `arrayOfMixed` because number [1] is incompatible with mixed [2] in array element. [incompatible-type]
        References:
        8: const arrayOfNumbers: Array<number> = [1, 2, 3];
                                       ^ [1]
        9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                     ^ [2]
    13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                                   ^ Cannot assign `personWithNumberAge` to `personWithMixedAge` because number [1] is incompatible with mixed [2] in property `age`. [incompatible-type]
        References:
        12: const personWithNumberAge: { age: number } = { age: 55 };
                                              ^ [1]
        13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                             ^ [2]
    17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                                    ^ Cannot assign `stringsToNumbers` to `stringsToMixed` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-type]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                              ^ [2]
    23: withStringsToMixed(stringsToNumbers);
                           ^ Cannot call `withStringsToMixed` with `stringsToNumbers` bound to `obj` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-call]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        20: function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
                                                         ^ [2]

As the last paragraph “generics work inside indexed object types” shows, this issue can be worked around by adding an unused generic parameter to the function. This workaround is only possible if the mixed-containing type is a parameter to the function, not if it’s a local variable.

For comparison, when I try writing equivalent code in TypeScript by changing mixed to unknown, TypeScript raises no errors. I know that Flow and TypeScript are not always directly comparable, though, since their type systems differ in a few ways.

created time in a month

PR opened microsoft/TypeScript-Handbook

Document `unknown` in Basic Types

Right now, the unknown top-level type is only documented in the release notes: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type

It’s good to document unknown next to the any type, because it replaces certain use-cases for any. This new documentation gives an overview of unknown and focuses on giving practical examples, while the existing release notes focus on defining the new feature and give exhaustive examples.

Fixes #960

+51 -6

0 comment

1 changed file

pr created time in a month

create barnchroryokane/TypeScript-Handbook

branch : document-unknown-type

created branch time in a month

fork roryokane/TypeScript-Handbook

The TypeScript Handbook is a comprehensive guide to the TypeScript language

fork in a month

issue commentjorgebucaran/hyperapp

Lorem ipsum in your website

Specifically, the pages that contain nothing but placeholder text are hyperapp.dev/guides (edit guides.md) and hyperapp.dev/ecosystem (edit ecosystem.md).

iamanas20

comment created time in a month

PR opened jorgebucaran/hyperapp

Fix spelling of “whether” in tutorial

affects https://hyperapp.dev/tutorial

+4 -4

0 comment

1 changed file

pr created time in a month

push eventroryokane/hyperapp

Rory O’Kane

commit sha 6cb99b7a806ab9d69599c8ef4b17467a2cc435c3

Fix spelling of “whether” in tutorial

view details

push time in a month

fork roryokane/hyperapp

The tiny framework for building hypertext applications.

https://hyperapp.dev

fork in a month

PR opened you-dont-need/You-Dont-Need-Lodash-Underscore

Correct the description of _.isString

The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

+1 -1

0 comment

1 changed file

pr created time in a month

push eventroryokane/You-Dont-Need-Lodash-Underscore

Rory O’Kane

commit sha 1f1bb0b567db383f31b69d99d0eacdfccab8d3a4

Correct the description of _.isString The previous description was copy-pasted from _.endsWith. This updated description comes from https://lodash.com/docs/4.17.15#isString.

view details

push time in a month

fork roryokane/You-Dont-Need-Lodash-Underscore

List of JavaScript methods which you can use natively + ESLint Plugin

fork in a month

issue commentlobsters/lobsters

Refactoring: rename Comment scope `for_user` to `accessible_to_user`

I’m not working on this, so feel free.

roryokane

comment created time in a month

issue commentfacebook/react

Proposition about onInput/onChange

If I understand your proposed solution correctly, React.$$useRealOnChange would be a global variable that would change the behavior of onChange in code such as <input onChange={event => handleChange(event)} />. The goal is to easily listen to the browser’s built-in change event.

I, too, wish that React allowed me to listen to the native change event. However, I have concerns about that specific solution. I worry that adding a global variable like React.$$useRealOnChange would cause surprising bugs and complicate testing. If you set React.$$useRealOnChange to true in one part of the code, it could affects parts of the code that were written assuming a value of false for it.

I favor the solution proposed by this older issue: #14857 “Easily handle browser 'change' events”. That issue proposed supporting a new attribute on input elements that act like a browser-native onchange attribute. It suggested these names as possibilities:

  • onChangeAndBlur
  • onChangeNative
  • onChangeCompleted
  • onCompleteChange

That issue was automatically closed for being “stale”, so perhaps this issue should become the new active issue about accessing the browser-native onchange.

mr21

comment created time in a month

startedcitybound/citybound

started time in a month

starteddabreegster/abstreet

started time in a month

startedkortina/vscode-markdown-notes

started time in a month

issue commentathensresearch/athens

Parser

I found this page that attempts to document Roam’s syntax: roam-tricks – Roam Shortcodes. Some of the syntaxes described there I hadn’t been aware of:

  • [alias]([[link]]) – a combination of the syntaxes that Athens currently calls url-link and page-link
  • {{foo}} codes
    • Each individual template, such as {{e}}, {{iframe: URL}}, or {{[[DONE]]}}, should have its own parsing logic so that it can capture the arguments it needs.
  • : codes
    • :diagram
    • :hiccup (e.g. :hiccup[:code 'code'])

I also learned of RoamTutorial – Secret & Advanced Features, which doesn’t reveal any syntaxes the other page doesn’t also include, but does go into more detail on how they are supposed to be rendered.

tangjeff0

comment created time in a month

issue openedlobsters/lobsters

Refactoring: rename Comment scope `for_user` to `accessible_to_user`

As discussed briefly on pushcx’s stream today from 1:14:00 to 1:15:25, this for_user scope in the Comment model:

https://github.com/lobsters/lobsters/blob/ee42f2f308fcc29b3c9f1250a0de58014ccb3567/app/models/comment.rb#L36

would be better if named accessible_to_user, given the separation of the in-development Comment.not_on_story_hidden_by scope.

All the callers will need to be renamed too. I see only 7 search results for .for_user in the codebase.

created time in 2 months

issue commentathensresearch/athens

Parser

Exploratory tasks

  • [X] Interpret unknown syntax as regular text, not a parse error (#44)
  • [X] Basic parsing of links
  • [X] Figure out how to parse backslash-escaped characters
    • The url-link rule shows how to do this.
  • [X] Figure out how to parse nested formatting
    • The bold rule shows how to do this.
  • [ ] Figure out whether a way to convert parsed ASTs back to markup is necessary, and how to design it if so (related to #44)
    • As discussed on Discord, updating page links ([[foo]]) after a page rename currently uses patterns.cljc. I see that the regexes in patterns.cljc will fail in some cases, so ideally the parser could be used to find and replace page link targets. Note that this use-case wouldn’t necessarily require being able to serialize all AST nodes, only AST nodes that could be within page links.
    • One of my two ideas for parsing nested links (#5) would require this feature. If the other idea is used, it wouldn’t be required.
    • This could cause problems in one of these two ways, depending on the implementation:
      • The parse tree might have to remember which syntax was used to construct a given meaning, e.g. #foo vs. #[[foo]] and \(a\) vs. (a) in a URL. This would complicate the parser.
      • The serialization might just arbitrarily choose one of the possible syntaxes, causing the user’s markup to be reformatted. The markup would render the same but have different raw text from what the user inputted. This has potential to go wrong if the user types a syntax error that would auto-format away the wrong parts of their syntax.
  • [ ] Figure out whether we need to pass the :start-index and :end-index of each parse rule all the way through each transformation to the final AST, and how to design it if so.
    • As discussed on Discord, this might be necessary to place the text cursor at the point of the clicked text when converting a rendered block into a textarea after a click.
  • [ ] Parse nested links (#5)
    • Example Hiccup output: data/nested-link.hiccup
    • I see that Roam is missing a feature regarding this: it doesn’t highlight which link you will click when you hover. Can that be implemented with the Hiccup output above, or will we need a different structure?
    • Is there any way to trick the browser into using a non-nested a element to do the link-hover style change and link-click page change, so we don’t have to reimplement that in JavaScript?
  • [ ] Compile a list of all markup syntax Roam supports
    • Roam has the Help popup in the bottom right and also the Help database. But neither of them mentions all syntax: in a Roam user’s YouTube video, as well as in the Athens example database, I saw undocumented syntax foo:: that turns into “foo:”. Research: is there other undocumented syntax like this?

Straightforward tasks

Implement known syntaxes

I think these tasks should not be attempted until most of the exploratory tasks are done, because some of those exploratory tasks would require writing new code for every rule, and those tasks would be more tedious if more rules had to be accounted for at that time.

For each of these syntaxes:

  1. Research Roam’s handling of edge cases by writing sample text in Roam
  2. Decide on Athen’s desired handling, possibly taking cues from other markup syntaxes like CommonMark
  3. Implement the parsing and initial transformation in parser.cljc. Remember to update any other parser rules that allow the new syntax to be nested inside it.
  4. Write tests for that rule in parser_test.cljc.
  5. Implement rendering of that markup as Hiccup in parse_renderer.cljs.
  • [ ] block embeds: {{[[embed]]: ((3AJ0dXKyE))}}
    1. [ ] parsing only
    2. [ ] rendering the embedded block
  • [ ] ![image](http://example.com/foo.jpg) syntax (#25)
  • [X] **bold** syntax
  • [ ] __italics__ syntax
    • Will be implemented similarly to bold.
    • Something I was thinking about and didn’t bring up for discussion yet: would we rather eventually implement Markdown-compatible syntax, so italics would be _this_ and *this*? If so, should we implement Roam-compatible syntax now and write a converter later, or are there few enough Roam users that we can start with Markdown-compatible syntax?
  • [ ] ~~strikethrough~~ syntax
    • Will be implemented similarly to bold.
  • [ ] ^^highlight^^ syntax
    • Will be implemented similarly to bold.
  • [ ] `code` syntax
    • Won’t allow nested syntax. But figure out how ` escaping works, if it’s supported.
  • [ ] ```code block``` syntax
    • In Markdown, the text on the same line as the first ``` is a language identifier, but in Roam, it’s the first line of the code. Implement Roam syntax to start with since it’s slightly easier, but what’s our long-term plan?
  • [ ] $$LaTeX$$ syntax
    1. [ ] Parsing text between the $$ delimiters
    2. [ ] Integrating a LaTeX library to format the contents
  • [ ] header:: syntax
    • This syntax is undocumented in Roam’s help.
tangjeff0

comment created time in 2 months

delete branch roryokane/athens

delete branch : parse-formatting-within-url-link-text

delete time in 2 months

create barnchroryokane/athens

branch : merged/parse-formatting-within-url-link-text

created branch time in 2 months

startednikitavoloboev/gitupdate

started time in 2 months

pull request commentathensresearch/athens

feat(parsing): parse formatting syntax within url-link-text

I rebased on the latest master branch so that the tests would pass.

roryokane

comment created time in 2 months

push eventroryokane/athens

jeff

commit sha 6e33d82fa59ad2cafc390c0176ac8625322ff781

feat: Athena power search bar (#128) * feat: Athena power search bar - uses re-frame with devcards - still don't have a good solution for colors/opacities * fix: simplify logic in query

view details

Stuart Hanberg

commit sha cb22f8f13898b896509aebc668b28d7042870ca8

feat(icons): add material icons (#129) * feat(icons): using proper library * feat(icons): properly including icons * feat(icons): adding example icons and styles * chore(icons): add missing newline * feat(icons): more consistent style + help text * fix(icons): use proper element for icons * chore(icons): sort requires * fix(icons): fix typo causing missing require

view details

Rory O’Kane

commit sha 9afdd0a4019ba79e99e71dca48d3b7fd67e49fc1

feat(parsing): parse formatting syntax within url-link-text Allow writing bold-formatted text in a link with `**foo**`, or writing a literal `]` with `\]`. As the parsing of more formatting syntax such as `~~strikethrough~~` is implemented, this parse rule might need to be updated to accept that syntax as well. Only some of the new syntax will be allowed in link text. The backslash-escaping was taken from Markdown. Roam doesn’t support that syntax (yet?), but I think Athens should.

view details

push time in 2 months

push eventroryokane/yargs

Rory O’Kane

commit sha eb6c81201ed203f60e947c3b1d58ba873a4746df

docs(api): describe process.argv handling more generally

view details

push time in 2 months

pull request commentathensresearch/athens

feat(parsing): parse formatting syntax within url-link-text

This PR has test failures only because commit 2d79333c28dc865336e594ea97d75805d880efd4 broke the build. None of the failures are related to this PR.

roryokane

comment created time in 2 months

PR opened athensresearch/athens

feat(parsing): parse formatting syntax within url-link-text

Allow writing bold-formatted text in a link with **foo**, or writing a literal ] with \].

As the parsing of more formatting syntax such as ~~strikethrough~~ is implemented, this parse rule might need to be updated to accept that syntax as well. Only some of the new syntax will be allowed in link text.

The backslash-escaping was taken from Markdown. Roam doesn’t support that syntax (yet?), but I think Athens should.

Add ?w=1 to the GitHub diff URL to hide the whitespace-only changes in the second hunk of src/cljc/athens/parser.cljc.

+34 -11

0 comment

2 changed files

pr created time in 2 months

create barnchroryokane/athens

branch : parse-formatting-within-url-link-text

created branch time in 2 months

delete branch roryokane/athens

delete branch : parser-reduce-use-of-any-chars

delete time in 2 months

create barnchroryokane/athens

branch : merged/parser-reduce-use-of-any-chars

created branch time in 2 months

push eventroryokane/athens

jeff

commit sha f9273de96588f3d8fe452eb20bfb4eaf8e3286f9

feat(style-guide): composable css styles (#114)

view details

jeff

commit sha dff2a095927b913863e542af6ba4b0d711e77e17

Style guide (#115) * feat(style-guide): composable css styles * feat(style guide): semantic colors, IBM Plex types * fix: carve * fix: remove unused highlights. change opacity based on @jacobmorse rec * fix: tiny styling changes

view details

jeff

commit sha d3c36e8b82cbdd92acb392e946766fe76f9c1af5

All Pages (#116) * feat(style-guide): composable css styles * feat(style guide): semantic colors, IBM Plex types * fix: carve * fix: remove unused highlights. change opacity based on @jacobmorse rec * fix: tiny styling changes * feat(all pages): create dsdb helpers, format table Co-authored-by: Jeroen van Dijk <jeroentjevandijk@gmail.com>

view details

Rory O’Kane

commit sha 3fd43a5386087cf9c09f245d3bf54ad78a6672b0

feat: clearer browser tab titles (#117) Before: Page with title: “Athens vs Roam Tech Stack” Page without title: “Athens Research” After: Page with title: “Athens vs Roam Tech Stack – Athens” Page without title: “untitled – Athens”

view details

Rory O’Kane

commit sha 8658e4eec446a83c04615862d00929ee9ef7b5a5

style: reformat and restructure tests in parser_test.clj (#108) * style: undo wrong auto-formatting in parser_test.clj When I was making the changes in commit 19f607d85a8116bea02f326e8a07e636b8b1c863, my editor auto-formatted on paste despite being configured not to. I have submitted a bug report about that: https://github.com/BetterThanTomorrow/calva/issues/656. * style: make block-parser-tests more readable using `are` I think I understand the requirements of parsing enough to confirm that the current AST structure is appropriate, or at least would be easy to change everywhere if that were needed. So it’s okay to also remove the comments about not needing more tests. * style: nicer indentation of expected/input values in tests Configure cljstyle to let us use indents within `are` blocks instead of having to faux-indent by prefixing a comma. * Revert "style: nicer indentation of expected/input values in tests" This reverts commit a24c9583f4bdcadf4a685abc1dc694754fb9ce1e. * style: comma-less formatting of expected/input values in tests This style uses more vertical space, but makes each individual test case easier to read and is more idiomatic to Clojure. It also doesn’t require changing cljstyle configuration.

view details

push time in 2 months

PR opened athensresearch/athens

feat(parsing): more accurately parse block-ref, hashtag, and url-link-url

I replaced any-chars with more specific rules and then added tests for those rules. I also added tests for the untested parser rules block-ref and bold.

I based url-link-url’s escaping rules off CommonMark’s escaping rules for links. Roam doesn’t implement those escaping rules, but I think they should be implemented. There are some links in the sample database data/athens.datoms, e.g. [Syncope](https://en.wikipedia.org/wiki/Syncope_(medicine)), that are parsed incorrectly in Roam and are now parsed correctly in Athens.

The uses of any-chars I replaced were all of the uses that represented limited, non-generically-formattable text. The remaining uses of any-chars in the current parser will need to support recursive formatting such as bold text.

+61 -12

0 comment

2 changed files

pr created time in 2 months

create barnchroryokane/athens

branch : parser-reduce-use-of-any-chars

created branch time in 2 months

delete branch roryokane/athens

delete branch : remove-contenteditable

delete time in 2 months

create barnchroryokane/athens

branch : merged/remove-contenteditable

created branch time in 2 months

delete branch roryokane/athens

delete branch : parser-test-style-fix

delete time in 2 months

create barnchroryokane/athens

branch : merged/parser-test-style-fix

created branch time in 2 months

delete branch roryokane/athens

delete branch : parse-basic-url-links

delete time in 2 months

create barnchroryokane/athens

branch : merged/parse-basic-url-links

created branch time in 2 months

delete branch roryokane/athens

delete branch : ignore-cpcache

delete time in 2 months

create barnchroryokane/athens

branch : merged/ignore-cpcache

created branch time in 2 months

create barnchroryokane/athens

branch : merged/fix-clj-kondo-lint-warnings

created branch time in 2 months

delete branch roryokane/athens

delete branch : fix-clj-kondo-lint-warnings

delete time in 2 months

delete branch roryokane/athens

delete branch : fix-block-parse-failures

delete time in 2 months

create barnchroryokane/athens

branch : merged/fix-block-parse-failures

created branch time in 2 months

delete branch roryokane/athens

delete branch : extract-ast-parsing-step

delete time in 2 months

create barnchroryokane/athens

branch : merged/extract-ast-parsing-step

created branch time in 2 months

delete branch roryokane/athens

delete branch : design-system-add-fallback-font

delete time in 2 months

create barnchroryokane/athens

branch : merged/design-system-add-fallback-font

created branch time in 2 months

create barnchroryokane/athens

branch : merged/add-instructions-for-clj-kondo

created branch time in 2 months

delete branch roryokane/athens

delete branch : contributing-docs-for-tests-and-devcards

delete time in 2 months

create barnchroryokane/athens

branch : merged/contributing-docs-for-tests-and-devcards

created branch time in 2 months

delete branch roryokane/athens

delete branch : clearer-browser-tab-titles

delete time in 2 months

create barnchroryokane/athens

branch : merged/clearer-browser-tab-titles

created branch time in 2 months

delete branch roryokane/athens

delete branch : add-parse-failure-title-text

delete time in 2 months

create barnchroryokane/athens

branch : merged/add-parse-failure-title-text

created branch time in 2 months

delete branch roryokane/athens

delete branch : add-instructions-for-clj-kondo

delete time in 2 months

delete branch roryokane/athens

delete branch : add-ignore-file

delete time in 2 months

create barnchroryokane/athens

branch : merged/add-ignore-file

created branch time in 2 months

Pull request review commentathensresearch/athens

feat: clearer browser tab titles

   (fn [{:keys [db]} [_ new-match]]     (let [old-match   (:current-route db)           controllers (rfc/apply-controllers (:controllers old-match) new-match)-          node (subscribe [:node [:block/uid (-> new-match :path-params :id)]])] ;; TODO make the page title query work when zoomed in on a block-      (set! (.-title js/document) (or (:node/title @node) "Athens Research")) ;; TODO make this side effect explicit+          node (subscribe [:node [:block/uid (-> new-match :path-params :id)]]) ;; TODO make the page title query work when zoomed in on a block+          node-title (:node/title @node)

In this code node-title may be nil, which is why the next line has (or node-title "untitled"). Is there any Clojure naming convention that would let me suggest that node-title may be nil, like maybe-node-title, or is this name fine?

I know I could also merge the node-title line into page-title so there is never a possibly-nil variable, like this:

page-title (str (or (:node/title @node) "untitled") " – Athens")]

But I think that makes page-title too hard to understand at a glance.

roryokane

comment created time in 2 months

PR opened athensresearch/athens

feat: clearer browser tab titles

Before

  • Page with title: “Athens vs Roam Tech Stack”
  • Page without title: “Athens Research”

After

  • Page with title: “Athens vs Roam Tech Stack – Athens”
  • Page without title: “untitled – Athens”
+4 -2

0 comment

1 changed file

pr created time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha 057d26f42907f7516e6555b70d32e06ef865685b

feat: clearer browser tab titles Before: Page with title: “Athens vs Roam Tech Stack” Page without title: “Athens Research” After: Page with title: “Athens vs Roam Tech Stack – Athens” Page without title: “untitled – Athens”

view details

push time in 2 months

create barnchroryokane/athens

branch : clearer-browser-tab-titles

created branch time in 2 months

issue commentBetterThanTomorrow/calva

Can’t disable format on paste

Thanks. I think you accidentally wrote true, but after I changed it to false it fixed my problem:

  "[clojure]": {
    "editor.formatOnPaste": false,
  },

With this, Clojure code is not formatted on paste even with Calva enabled.

roryokane

comment created time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha 570ebe7f165df2bc5f3757f0f601f5bf6cdec20f

Revert "style: nicer indentation of expected/input values in tests" This reverts commit a24c9583f4bdcadf4a685abc1dc694754fb9ce1e.

view details

Rory O’Kane

commit sha 30b5492280b6d649015fafb202d7c45d0e22c4bb

style: comma-less formatting of expected/input values in tests This style uses more vertical space, but makes each individual test case easier to read and is more idiomatic to Clojure. It also doesn’t require changing cljstyle configuration.

view details

push time in 2 months

pull request commentjrieken/vscode-formatter-sample

Added warning about breaking Emmet

You filed your PR against the wrong repo. You should close this PR and re-file a PR against alexbabichev/vscode-pug-formatter.

BananaAcid

comment created time in 2 months

startedgreglook/cljstyle

started time in 2 months

PR opened greglook/cljstyle

Update obsolete key in configuration example.
+1 -1

0 comment

1 changed file

pr created time in 2 months

push eventroryokane/cljstyle

Rory O’Kane

commit sha 2f211497f0513f46265548507a04b28bba0d471c

Update obsolete key in configuration example.

view details

push time in 2 months

fork roryokane/cljstyle

A tool for formatting Clojure code

fork in 2 months

Pull request review commentathensresearch/athens

style: reformat and restructure tests in parser_test.clj

   (deftest block-parser-tests-  (is (= [:block] (parse-to-ast "")))-  (is (= [:block "OK? Yes."] (parse-to-ast "OK? Yes.")))-  (is (= [:block [:page-link "link"]] (parse-to-ast "[[link]]")))-  (is (= [:block "A " [:page-link "link"] "."] (parse-to-ast "A [[link]].")))-  (is (= [:block "[[text"] (parse-to-ast "[[text")))-  (is (= [:block [:url-link {:url "https://example.com/"} "an example"]] (parse-to-ast "[an example](https://example.com/)")))-  ;; Not including tests for every type of syntax because I expect the trees they are parsed to to change soon.-  ;; For now, additional tests would probably be more annoying than useful.-  )+  (are [x y] (= x (parse-to-ast y))+    [:block]+    , ""+    [:block "OK? Yes."]+    , "OK? Yes."+    [:block [:page-link "link"]]+    , "[[link]]"+    [:block "A " [:page-link "link"] "."]+    , "A [[link]]."+    [:block "[[text"]+    , "[[text"+    [:block [:url-link {:url "https://example.com/"} "an example"]]+    , "[an example](https://example.com/)"))

Whoops, there’s one test file I overlooked, /test/athens/lib/dom/attributes_test.cljc, that uses are with three variables. The alternating stair indent style isn’t appropriate for that code, yet cljstyle formats it because it uses are. I need to figure out a way to narrow the scope of the config indent rule.

roryokane

comment created time in 2 months

Pull request review commentathensresearch/athens

style: reformat and restructure tests in parser_test.clj

   (deftest block-parser-tests-  (is (= [:block] (parse-to-ast "")))-  (is (= [:block "OK? Yes."] (parse-to-ast "OK? Yes.")))-  (is (= [:block [:page-link "link"]] (parse-to-ast "[[link]]")))-  (is (= [:block "A " [:page-link "link"] "."] (parse-to-ast "A [[link]].")))-  (is (= [:block "[[text"] (parse-to-ast "[[text")))-  (is (= [:block [:url-link {:url "https://example.com/"} "an example"]] (parse-to-ast "[an example](https://example.com/)")))-  ;; Not including tests for every type of syntax because I expect the trees they are parsed to to change soon.-  ;; For now, additional tests would probably be more annoying than useful.-  )+  (are [x y] (= x (parse-to-ast y))+    [:block]+    , ""+    [:block "OK? Yes."]+    , "OK? Yes."+    [:block [:page-link "link"]]+    , "[[link]]"+    [:block "A " [:page-link "link"] "."]+    , "A [[link]]."+    [:block "[[text"]+    , "[[text"+    [:block [:url-link {:url "https://example.com/"} "an example"]]+    , "[an example](https://example.com/)"))

With the help of @jelmerderonde’s comment about tweaking cljstyle’s config, I configured cljstyle to automatically indent every second value in are forms. Do you find that style acceptable?

    ["some text" [:link] "around a link"]
      ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39]
      [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]
roryokane

comment created time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha a24c9583f4bdcadf4a685abc1dc694754fb9ce1e

style: nicer indentation of expected/input values in tests Configure cljstyle to let us use indents within `are` blocks instead of having to faux-indent by prefixing a comma.

view details

push time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha b6fbc9597b6c4f2a3f8fd347629ca8bcaff4ae8c

fix: add .cpcache to .gitignore (#104) The `.cpcache` directory was created after I installed the `clojure` binary and ran `script/carve`. `.cpcache` is described here: https://clojure.org/reference/deps_and_cli#_directories

view details

Jelmer de Ronde

commit sha b94a0db0c7a7e781c0b833285f095d01a54c7dd2

Adds merge prompt (#90) * Adds merge prompt * Add re-frame :timeout effect * Clear merge-prompt on timeout and on navigate * WIP * Finish merge transaction * Fix linter warning

view details

Rory O’Kane

commit sha 19f607d85a8116bea02f326e8a07e636b8b1c863

refactor(parsing): extract intermediate transform step, merge parse-transform-helper into parser (#102) * refactor(parsing): extract intermediate transform step transform to AST before transforming to Hiccup * refactor(parsing): merge parse-transform-helper into parser Now that the .cljc parser does transforms itself, rather than the .cljs parse-renderer, I don’t need a separate .cljc file to store the `combine-adjacent-strings` function.

view details

Rory O’Kane

commit sha abe0c0dc52df22243de3fe6b384dca6a60cb712d

feat(parsing): basic support for URL links (#105) I say this is “basic” support because it uses the `any-chars` rule, which is too eager. Eventually we will recursively parse the link text instead of capturing it all with a regex. I call them URL links instead of external links because theoretically, users might write URLs to internal pages such as http://localhost:3000/#/page/OaSVyM_nr.

view details

Rory O’Kane

commit sha c50fb6178fe3b6809bc5ca27f503709babcad6e5

Document in CONTRIBUTING.md how to run tests and devcards (#110) * docs(contributing): make spacing consistent, fix capitalization The spacing and formatting changes were made by running the file through Prettier (https://prettier.io/). * docs(contributing): document how to get tests and devcards running And improve wording in other parts of the document and in test scripts. * docs: Don't mention `lein devcards` To avoid confusion and having other ports than documented Co-authored-by: Jeroen van Dijk <jeroentjevandijk@gmail.com>

view details

Jeroen van Dijk

commit sha d25945ce7730d6a098d9310fceed890d7f1f865e

Add with-attributes to clean up attributes (#112) * Add with-attributes to clean up attributes Will add :on-keypress {:ESC (fn [event] )} later * No js/ vars in cljc namespaces * Fix clj-kondo warnings

view details

push time in 2 months

push eventroryokane/BadCode.rocks-Robot-Simulator

Rory O’Kane

commit sha 29791f59e8539e0fa5c2e402cc65e2f37fd0443c

Fix spelling of BadCode.rocks, the contest name

view details

push time in 2 months

create barnchroryokane/BadCode-Rocks-robot-simulator

branch : master

created branch time in 2 months

created repositoryroryokane/BadCode-Rocks-Robot-Simulator

Robot Simulator – BadCode Rocks 2018-12 contest entry. Artistically bad code.

created time in 2 months

Pull request review commentathensresearch/athens

style: reformat and restructure tests in parser_test.clj

   (deftest block-parser-tests-  (is (= [:block] (parse-to-ast "")))-  (is (= [:block "OK? Yes."] (parse-to-ast "OK? Yes.")))-  (is (= [:block [:page-link "link"]] (parse-to-ast "[[link]]")))-  (is (= [:block "A " [:page-link "link"] "."] (parse-to-ast "A [[link]].")))-  (is (= [:block "[[text"] (parse-to-ast "[[text")))-  (is (= [:block [:url-link {:url "https://example.com/"} "an example"]] (parse-to-ast "[an example](https://example.com/)")))-  ;; Not including tests for every type of syntax because I expect the trees they are parsed to to change soon.-  ;; For now, additional tests would probably be more annoying than useful.-  )+  (are [x y] (= x (parse-to-ast y))+    [:block]+    , ""+    [:block "OK? Yes."]+    , "OK? Yes."+    [:block [:page-link "link"]]+    , "[[link]]"+    [:block "A " [:page-link "link"] "."]+    , "A [[link]]."+    [:block "[[text"]+    , "[[text"+    [:block [:url-link {:url "https://example.com/"} "an example"]]+    , "[an example](https://example.com/)"))

I agree the commas look kind of ugly, but I thought they were the best of four bad options. Let me show you the options I considered so you can compare and choose the one you like most:

The following style was confusing because among the 10 similar lines, I found it hard to tell which line was the expected value and which was the input. I felt like I had to manually count from the top and remember which was even and which was odd.

    ["some text" [:link] "around a link"]
    ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39]
    [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]

If I put each expected value and input on the same line like the following code, I find it hard to see where one vector ends and the next begins, even with rainbow parens:

    ["some text" [:link] "around a link"] ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39] [{:something nil} "more" " " "text" [:link] "between" " " 

The following looks nice to me, but cljstyle doesn’t accept it. I can understand that it complains because it doesn’t reflect the structure of the forms, even though I know it reflects their semantics. One option would be using this and ignoring this file, but that could ignore other style problems in this file that should be caught, so I don’t like that option.

    ["some text" [:link] "around a link"]
      ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39]
      [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]

Since I liked the above but cljstyle didn’t, I added the commas to make it pass, resulting in the formatting in this PR:

    ["some text" [:link] "around a link"]
    , ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39]
    , [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]

Those are the options I thought of before, but now I’ve thought of a few more:

It seems cljstyle doesn’t mind if I put extra spaces between the expected value and input, as follows. It’s better than the single space version, at least. But I like putting the expected value and input on separate lines because it makes it easier to see what differences, if any, they have. Doing a visual diff when they are vertically close is easy for all the tests in this file because they all transform the input from left to right, so the corresponding parts of each value stay visually close.

    ["some text" [:link] "around a link"]   ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39]   [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]

I could also put a blank line between every expected-actual pair, as follows. This makes every line unambiguous but requires more scrolling when viewing the file in the editor.

    ["some text" [:link] "around a link"]
    ["some" " " "text" [:link] "around " "a link"]
    
    [{:something nil} "more text" [:link] "between elements" 39]
    [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]
    

Or I could try marking the lines with comments somehow, like as follows. I think it’s not that readable though, as the comments are at the end of each line. It’s hard to notice the comments with my syntax highlighting, so I have to scan to the end of each line to see them.

    ["some text" [:link] "around a link"] ;; key
    ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39] ;; key
    [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]

Adding commas at the end of key lines, as follows, has the same problem:

    ["some text" [:link] "around a link"],
    ["some" " " "text" [:link] "around " "a link"]
    [{:something nil} "more text" [:link] "between elements" 39],
    [{:something nil} "more" " " "text" [:link] "between" " " "elements" 39]

Those are the options I can think of now. Which of these do you prefer? If you still hate the commas-before-inputs style I think my next favorite one is the blank lines style.

roryokane

comment created time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha 8e82fc8365009e5fa5ae57306d28ecd830b15897

style: make block-parser-tests more readable using `are` I think I understand the requirements of parsing enough to confirm that the current AST structure is appropriate, or at least would be easy to change everywhere if that were needed. So it’s okay to also remove the comments about not needing more tests.

view details

push time in 2 months

PR opened athensresearch/athens

Document in CONTRIBUTING.md how to run tests and devcards

Devcards instructions were based on https://github.com/athensresearch/athens/pull/109#issuecomment-636395081

+93 -18

0 comment

3 changed files

pr created time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha a9c592520c5b0def8e8781f8c0fa21dfbd48f5cc

docs(contributing): document how to get tests and devcards running And improve wording in other parts of the document and in test scripts.

view details

push time in 2 months

push eventroryokane/athens

Rory O’Kane

commit sha 9db39fca97dcbbfc208755dcc82ecea3cc8e2bdc

docs(contributing): document how to get tests and devcards running And improve wording in other parts of the document

view details

push time in 2 months

create barnchroryokane/athens

branch : contributing-docs-for-tests-and-devcards

created branch time in 2 months

more