[NonGNU ELPA] New package: ekg

[NonGNU ELPA] New package: ekg

[Andrew Hyatt]

Hi everyone,

I've created a new package called ekg, which can be found at 
https://github.com/ahyatt/ekg.  I'd like to add it to NonGNU ELPA.

This is a note-taking app in the same PKMS space as org-roam, but 
also can store other things as well - maybe one way to put it is 
that it's a way you can either creates notes with tags, or attach 
notes and tags to existing resources. Those resources now are just 
URLs but can be expanded later.

One of the notable design choices is that this is built on top of 
my triples package (which has been added to GNU ELPA), and so 
everything, notes, tags, URLs, and all, is stored in a sqlite 
database.

The README.org file in that repository has much more information 
about design and usage.

I have FSP papers, so this could theoretically go into GNU ELPA, 
but I'd like it to be easy to contribute to this, so I'd prefer 
not having to ask for FSF papers from all contributors.

Thank you, and please let me know what you think.

Re: [NonGNU ELPA] New package: ekg

[Jean Louis]

* Andrew Hyatt <ahyatt@gmail.com> [2023-01-03 01:29]:
> I've created a new package called ekg, which can be found at
> https://github.com/ahyatt/ekg.  I'd like to add it to NonGNU ELPA.

Great to see new package.

My opinions are not related to recording it to NonGNU ELPA.

Related to design, and being heavy user of 1736 different tags, it is
alright to search within titles, but that only titles are tags is not
quite in place. That it isn't unique to ekg, does not make it
better. Maybe there is no need to talk about tags in that place.

I search by title, and by tags, or by both, and by other complexities.

A document may be named "Certificate of Good Standing" and can have
tag "todo" or tag "Armenia", or "free" or anything that is not
directly related to title.

I leave that to you. However, I see that the idea comes from the
following problem you encountered:

> The advantage of this method is that it solves something that has
> bothered me for a while about the recent suite of tools like org-roam:
> backlinks are non-symmetrical. If you enter a note in your org-roam
> daily about emacs, and link it to the emacs note, then when you go to
> the emacs note, you have to explicitly enable the backlinks buffer to
> see the daily entry where you first entered it. Systems such as Logseq
> and the original Roam have backlinks alongside normal content, but
> this doesn’t seem possible in emacs, where a buffer of a file is
> expected show the file, and tricks with overlays can’t solve the
> issue

Your paragraph has explained something, I get only vague clue about
the main point.

Can you provide screenshot?

Is your main point to show the buffer with backlinks at all times?

Or to record the backlinks in first place?

> One of the notable design choices is that this is built on top of my triples
> package (which has been added to GNU ELPA), and so everything, notes, tags,
> URLs, and all, is stored in a sqlite database.

That is good, I may test it and see how it works and if it is scalable.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [NonGNU ELPA] New package: ekg

[Andrew Hyatt]

[-- Attachment #1.1: Type: text/plain, Size: 3405 bytes --]

On Wed, Jan 4, 2023 at 3:03 AM Jean Louis <bugs@gnu.support> wrote:

> * Andrew Hyatt <ahyatt@gmail.com> [2023-01-03 01:29]:
> > I've created a new package called ekg, which can be found at
> > https://github.com/ahyatt/ekg.  I'd like to add it to NonGNU ELPA.
>
> Great to see new package.
>
> My opinions are not related to recording it to NonGNU ELPA.
>
> Related to design, and being heavy user of 1736 different tags, it is
> alright to search within titles, but that only titles are tags is not
> quite in place. That it isn't unique to ekg, does not make it
> better. Maybe there is no need to talk about tags in that place.
>
> I search by title, and by tags, or by both, and by other complexities.
>
> A document may be named "Certificate of Good Standing" and can have
> tag "todo" or tag "Armenia", or "free" or anything that is not
> directly related to title.
>
> I leave that to you. However, I see that the idea comes from the
> following problem you encountered:
>
> > The advantage of this method is that it solves something that has
> > bothered me for a while about the recent suite of tools like org-roam:
> > backlinks are non-symmetrical. If you enter a note in your org-roam
> > daily about emacs, and link it to the emacs note, then when you go to
> > the emacs note, you have to explicitly enable the backlinks buffer to
> > see the daily entry where you first entered it. Systems such as Logseq
> > and the original Roam have backlinks alongside normal content, but
> > this doesn’t seem possible in emacs, where a buffer of a file is
> > expected show the file, and tricks with overlays can’t solve the
> > issue
>
> Your paragraph has explained something, I get only vague clue about
> the main point.
>
> Can you provide screenshot?
>

I've attached a screenshot of ekg, showing a document about "chicago style
pizza" and a reference to it.  They both have the same tags: the date they
were created on, and "chicago style pizza".  If I want a note to show up
when I look at the "chicago style pizza" tag, then I tag it with that tag,
not link it.

This is opposed to the other way of doing it, where you have to use another
buffer.  I'm including a screenshot of how org-roam does it.  But that's
different also to how Logseq does it, which is to have the backlinks
inline.  I'm attaching a third screenshot to show you what I mean there,
see the "Unlinked references" at the bottom.

>
> Is your main point to show the buffer with backlinks at all times?
>

My main point is that it shouldn't be in a separate buffer.  I want it
inline.  It doesn't work to have it inline in the note itself, but it does
work if you have a buffer that lists all notes with the tag, and instead of
linking references to get the backlinks, you just tag things the same way.
Hope this helps.


>
> Or to record the backlinks in first place?
>
> > One of the notable design choices is that this is built on top of my
> triples
> > package (which has been added to GNU ELPA), and so everything, notes,
> tags,
> > URLs, and all, is stored in a sqlite database.
>
> That is good, I may test it and see how it works and if it is scalable.
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

[-- Attachment #1.2: Type: text/html, Size: 4520 bytes --]

[-- Attachment #2: Screenshot - ekg "backlinks".jpg --]
[-- Type: image/jpeg, Size: 263044 bytes --]

[-- Attachment #3: Screenshot - org roam backlinks.jpg --]
[-- Type: image/jpeg, Size: 399343 bytes --]

[-- Attachment #4: Screenshot - logseq backlinks.jpg --]
[-- Type: image/jpeg, Size: 366802 bytes --]

Re: [NonGNU ELPA] New package: ekg

[Jean Louis]

* Andrew Hyatt <ahyatt@gmail.com> [2023-01-05 04:26]:
> > > The advantage of this method is that it solves something that has
> > > bothered me for a while about the recent suite of tools like org-roam:
> > > backlinks are non-symmetrical. If you enter a note in your org-roam
> > > daily about emacs, and link it to the emacs note, then when you go to
> > > the emacs note, you have to explicitly enable the backlinks buffer to
> > > see the daily entry where you first entered it. Systems such as Logseq
> > > and the original Roam have backlinks alongside normal content, but
> > > this doesn’t seem possible in emacs, where a buffer of a file is
> > > expected show the file, and tricks with overlays can’t solve the
> > > issue
> >
> > Your paragraph has explained something, I get only vague clue about
> > the main point.
> >
> > Can you provide screenshot?
> >
> 
> I've attached a screenshot of ekg, showing a document about "chicago style
> pizza" and a reference to it.  They both have the same tags: the date they
> were created on, and "chicago style pizza".  If I want a note to show up
> when I look at the "chicago style pizza" tag, then I tag it with that tag,
> not link it.

I understand you wish to have backlinks inline and you use note name
to search for it as tags in same time. If that is really the only way
of searching it is right. 

> My main point is that it shouldn't be in a separate buffer.  I want
> it inline.  It doesn't work to have it inline in the note itself,
> but it does work if you have a buffer that lists all notes with the
> tag, and instead of linking references to get the backlinks, you
> just tag things the same way.  Hope this helps.

It looks good.

In the packages I develop I have different positions, there is:

- editing position, and in that position I did not think involving a
  buffer with backlinks.

- I have view position, that is where by press of one key like "i" for
  information, I can see tags related to the note, however, I could
  also see all the related people, other related elementary objects,
  and objects from where it is hyperlinked to current object.

And I can imagine that on a press of the key overlays could be used to
show at any time necessary information. That way information may be
shown and offered to user, without distracting all the time.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [NonGNU ELPA] New package: ekg

[Andrew Hyatt]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

It's been a few weeks since this proposal.  Besides Jean's feedback, I
haven't heard whether or not this package is acceptable, so I'm guessing
the timing of me sending this during holidays was probably unfortunate.
Could a maintainer please take a look and let me know?


On Mon, Jan 2, 2023 at 5:27 PM Andrew Hyatt <ahyatt@gmail.com> wrote:

>
> Hi everyone,
>
> I've created a new package called ekg, which can be found at
> https://github.com/ahyatt/ekg.  I'd like to add it to NonGNU ELPA.
>
> This is a note-taking app in the same PKMS space as org-roam, but
> also can store other things as well - maybe one way to put it is
> that it's a way you can either creates notes with tags, or attach
> notes and tags to existing resources. Those resources now are just
> URLs but can be expanded later.
>
> One of the notable design choices is that this is built on top of
> my triples package (which has been added to GNU ELPA), and so
> everything, notes, tags, URLs, and all, is stored in a sqlite
> database.
>
> The README.org file in that repository has much more information
> about design and usage.
>
> I have FSP papers, so this could theoretically go into GNU ELPA,
> but I'd like it to be easy to contribute to this, so I'd prefer
> not having to ask for FSF papers from all contributors.
>
> Thank you, and please let me know what you think.
>

[-- Attachment #2: Type: text/html, Size: 1859 bytes --]

Re: [NonGNU ELPA] New package: ekg

[Jean Louis]

* Andrew Hyatt <ahyatt@gmail.com> [2023-01-17 08:21]:
> It's been a few weeks since this proposal.  Besides Jean's feedback, I
> haven't heard whether or not this package is acceptable, so I'm guessing
> the timing of me sending this during holidays was probably unfortunate.
> Could a maintainer please take a look and let me know?

> > This is a note-taking app in the same PKMS space as org-roam, but
> > also can store other things as well - maybe one way to put it is
> > that it's a way you can either creates notes with tags, or attach
> > notes and tags to existing resources. Those resources now are just
> > URLs but can be expanded later.

Please include or support Emacs 29 version with SQLite built-in. Is it
possible? 

ekg--should-show-id-p: Symbol’s function definition is void: ffap-url-p

> > One of the notable design choices is that this is built on top of
> > my triples package (which has been added to GNU ELPA), and so
> > everything, notes, tags, URLs, and all, is stored in a sqlite
> > database.

I have predicted for myself that many similar packages would coming,
since the inception of built-in SQLite in Emacs. Those there were
other packages, it will become much easier to provide single-user
database based note taking applications. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [NonGNU ELPA] New package: ekg

[Andrew Hyatt]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

On Thu, Jan 19, 2023 at 5:19 AM Jean Louis <bugs@gnu.support> wrote:

> * Andrew Hyatt <ahyatt@gmail.com> [2023-01-17 08:21]:
> > It's been a few weeks since this proposal.  Besides Jean's feedback, I
> > haven't heard whether or not this package is acceptable, so I'm guessing
> > the timing of me sending this during holidays was probably unfortunate.
> > Could a maintainer please take a look and let me know?
>
> > > This is a note-taking app in the same PKMS space as org-roam, but
> > > also can store other things as well - maybe one way to put it is
> > > that it's a way you can either creates notes with tags, or attach
> > > notes and tags to existing resources. Those resources now are just
> > > URLs but can be expanded later.
>
> Please include or support Emacs 29 version with SQLite built-in. Is it
> possible?


Not only is it possible, we already do this.

>
>
> ekg--should-show-id-p: Symbol’s function definition is void: ffap-url-p
>

Thanks, fixed, by adding a require stanza at the top.


>
> > > One of the notable design choices is that this is built on top of
> > > my triples package (which has been added to GNU ELPA), and so
> > > everything, notes, tags, URLs, and all, is stored in a sqlite
> > > database.
>
> I have predicted for myself that many similar packages would coming,
> since the inception of built-in SQLite in Emacs. Those there were
> other packages, it will become much easier to provide single-user
> database based note taking applications.
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

[-- Attachment #2: Type: text/html, Size: 2623 bytes --]

Re: [NonGNU ELPA] New package: ekg

[Jean Louis]

* Andrew Hyatt <ahyatt@gmail.com> [2023-01-19 17:28]:
> > Please include or support Emacs 29 version with SQLite built-in. Is it
> > possible?
> 
> Not only is it possible, we already do this.

I can't see, I could see that it requires package emacs-sqlite3
something, I may be wrong. Maybe that package uses underlying sqlite
in new Emacs.

> > ekg--should-show-id-p: Symbol’s function definition is void: ffap-url-p
> >
> 
> Thanks, fixed, by adding a require stanza at the top.

After that, there is this error:

Symbol’s function definition is void: triples-with-transaction

and that takes place on C-c C-c in note buffer.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [NonGNU ELPA] New package: ekg

[Andrew Hyatt]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

It sounds like you are using an old version of the triples library. Can you
check to see if you have the latest version from gnu elpa?

On Fri, Jan 20, 2023 at 1:54 AM Jean Louis <bugs@gnu.support> wrote:

> * Andrew Hyatt <ahyatt@gmail.com> [2023-01-19 17:28]:
> > > Please include or support Emacs 29 version with SQLite built-in. Is it
> > > possible?
> >
> > Not only is it possible, we already do this.
>
> I can't see, I could see that it requires package emacs-sqlite3
> something, I may be wrong. Maybe that package uses underlying sqlite
> in new Emacs.
>
> > > ekg--should-show-id-p: Symbol’s function definition is void: ffap-url-p
> > >
> >
> > Thanks, fixed, by adding a require stanza at the top.
>
> After that, there is this error:
>
> Symbol’s function definition is void: triples-with-transaction
>
> and that takes place on C-c C-c in note buffer.
>
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

[-- Attachment #2: Type: text/html, Size: 1662 bytes --]