[nongnu] elpa/geiser-kawa cf06550 030/119: Small changes to README

[Philip Kaludercic]

branch: elpa/geiser-kawa
commit cf0655030f74783e364119843f8c80a049f8e179
Author: spellcard199 <spellcard199@protonmail.com>
Commit: spellcard199 <spellcard199@protonmail.com>

    Small changes to README
---
 README.org | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.org b/README.org
index dc3cb66..ce4b257 100644
--- a/README.org
+++ b/README.org
@@ -71,7 +71,7 @@ The whole project is in a persistent "experimental" state, 
but this part even mo
 The main interactive elisp function is 
=geiser-kawa-complete-java-fmp-at-point=. It's not bound to a key by default.
 
 For this to work you have to:
-- use Kawa's type annotations: rememver that the Kawa compiler mostly trusts 
you and can't actually check
+- use Kawa's type annotations: rememver that the Kawa compiler mostly trusts 
you
 - avoid syntax errors (e.g. unbalanced parentheses, wrong number of children 
sexps inside a form, etc...)
 
 How it works (the region getting part is quite rudimentray):
@@ -114,7 +114,7 @@ geiser-kawa VS geiser-kawa-scheme - recap table:
 
 If you use geiser as a dependency in a Cask project, Cask eagerly expands the 
=define-geiser-implementation= macro with =load-file-name= having the wrong 
value. The result is that geiser implementations in geiser do not work when 
geiser is managed as a dependency by Cask.
 
-Link to the issue I've opened in Cask: https://github.com/cask/cask/issues/472.
+Link to the issue I've opened in Cask: 
[[https://github.com/cask/cask/issues/472]].
 
 As a (temporary?) workaround, geiser-kawa.el quotes 
=define-geiser-implementation= and wraps it an =eval= form, and that avoids:
 1. macro expansion to happen during cask-cli.el execution