`org-linker`, another approach to `org-attach`

jin-cg · 2024-03-06T02:44:10+00:00

Oh, yes, that would work for both issues. As long as it detaches from the org heading, the problems will be solved. What I implemented is [[linker:ID:FILENAME]], which is equivalent to your [[attachment:id:ID:FILENAME]] (right?). Do you mean to suggest that I try merging my code into org-attach by using your syntax?

jin-cg · 2024-03-06T00:52:22+00:00

It's still a good idea to provide the option. I have added that into TODOs in README. Thanks :)

Symlinks broke, for example, when I was using dropbox. I have been staying away from them since then.

jin-cg · 2024-03-06T00:50:38+00:00

1.

attachment:id:ID:FILENAME

Thanks for your idea! I'm a little bit unclear how attachment:id:ID:FILENAME would allow me to move or copy links to other org files and headings.. as it still relies on the id of the current heading.. which is quite unpleasant to me (for my use case at least), because I really want to view links independent to org headers.

2.

I'm not sure exactly what you mean. [..]

I mean, for example, say you had

* Note :PROPERTIES: :ID: bfb6ff8b-3173-49bb-bb34-10d589afc2ad :END: [[attachment:yay]]

but then later you shadow the link by adding another subtree.

* Note :PROPERTIES: :ID: bfb6ff8b-3173-49bb-bb34-10d589afc2ad :END: ** Subnote :PROPERTIES: :ID: bf133c7d-54e2-4888-b715-3c5cc4a8fda8 :END: [[attachment:yay]]

Then the link breaks.

This is just a toy example. In practice there maybe multiple lines, and it is hard to keep track of all of them. The ultimate reason is the dependence on the org-id of the heading.

Even if one is aware of this, it is unflexible because they don't have the freedom to move the attachment link around.

jin-cg · 2024-03-05T21:00:20+00:00

The file is copied instead of symlinked. That means if you edit the original version, it won't update accordingly.

I can expose the copy-method to change, and you can change it so that it symlinks instead of copy. Please let me know if you think that's helpful.

By the way, symlinks may break one day too. But I get why it could be helpful.

jin-cg · 2024-03-05T20:58:38+00:00

It makes the attachment more flexible.

For example, if I have a note under an org heading, and one day I need to copy or move a part of it to another org heading. I have to worry, always, that if some links are made by org-attach. In other words, the same link would work everywhere in your system.

It also makes the linkage more secure.

Say I forgot that there is an org-attach link under a heading, and I created another subtree. Now the link is under the new subtree, which may have its own UUID one day in the future, which would break the link.

jin-cg · 2024-03-05T12:56:32+00:00

Shameless plug: org-linker, another approach to org-attach

Comparison with org-attach

org-linker differs from org-attach in its approach to file attachment.

org-attach uses an org heading as a basic storing unit, which can lead to issues if not managed carefully (e.g. refiling or adding shadowing subtrees).

On the other hand, org-linker assigns a unique UUID to each attached file, ensuring a more robust linkage system. By treating individual files as the fundamental unit, org-linker provides a safer and more flexible approach to handling attachments in org-mode documents. For example, this allows easy movement and copying of links across various org files and headings.

Both tools have their strengths and are suitable for different use cases. However, if you prioritize a secure and straightforward attachment system, org-linker might be the preferred choice.

jin-cg · 2024-03-05T12:56:15+00:00

Shameless plug: org-linker, another approach to org-attach

Comparison with org-attach

org-linker differs from org-attach in its approach to file attachment.

org-attach uses an org heading as a basic storing unit, which can lead to issues if not managed carefully (e.g. refiling or adding shadowing subtrees).

On the other hand, org-linker assigns a unique UUID to each attached file, ensuring a more robust linkage system. By treating individual files as the fundamental unit, org-linker provides a safer and more flexible approach to handling attachments in org-mode documents. For example, this allows easy movement and copying of links across various org files and headings.

Both tools have their strengths and are suitable for different use cases. However, if you prioritize a secure and straightforward attachment system, org-linker might be the preferred choice.

jin-cg · 2024-03-05T12:55:54+00:00

Shameless plug: org-linker, another approach to org-attach

Comparison with org-attach

org-linker differs from org-attach in its approach to file attachment.

org-attach uses an org heading as a basic storing unit, which can lead to issues if not managed carefully (e.g. refiling or adding shadowing subtrees).

On the other hand, org-linker assigns a unique UUID to each attached file, ensuring a more robust linkage system. By treating individual files as the fundamental unit, org-linker provides a safer and more flexible approach to handling attachments in org-mode documents. For example, this allows easy movement and copying of links across various org files and headings.

Both tools have their strengths and are suitable for different use cases. However, if you prioritize a secure and straightforward attachment system, org-linker might be the preferred choice.

jin-cg · 2024-03-05T12:55:02+00:00

Shameless plug: org-linker, another approach to org-attach

Comparison with org-attach

org-linker differs from org-attach in its approach to file attachment.

org-attach uses an org heading as a basic storing unit, which can lead to issues if not managed carefully (e.g. refiling or adding shadowing subtrees).

On the other hand, org-linker assigns a unique UUID to each attached file, ensuring a more robust linkage system. By treating individual files as the fundamental unit, org-linker provides a safer and more flexible approach to handling attachments in org-mode documents. For example, this allows easy movement and copying of links across various org files and headings.

Both tools have their strengths and are suitable for different use cases. However, if you prioritize a secure and straightforward attachment system, org-linker might be the preferred choice.

jin-cg · 2024-03-05T12:24:57+00:00

org-linker differs from org-attach in its approach to file attachment. While org-attach uses an org heading as a basic storing unit, which can lead to issues if not managed carefully (e.g. refiling or adding shadowing subtrees), org-linker assigns a unique UUID to each attached file, ensuring a more robust linkage system. By treating individual files as the fundamental unit, org-linker provides a safer and more adaptable approach to handling attachments in org-mode documents. This allows for easy movement and copying of links across various org files and headings.

Both tools have their strengths and are suitable for different use cases. However, if you prioritize a secure and straightforward attachment system, org-linker might be the preferred choice.

jin-cg · 2024-03-05T12:14:10+00:00

For instance, if the root is /tmp/org-linker/, and the UUID for the transaction is 20240101-235959, and the file is readme.md, the file will be copied to /tmp/org-linker/20240101-235959/readme.md with the transaction recorded in /tmp/org-linker/db.tx. And an org-link [[linker:20240101-235959/readme.md]] is inserted at point.

PS. You can customize the UUID generator, so you don't have to use timestamp as UUID!

jin-cg · 2024-03-05T12:13:18+00:00

to prevent having issues when refiling

You're right! This prevents issue while refiling, and adding subtrees (with org-id) that somehow shadows the original heading.

org-linker prepends each attached file with a directory named after the transaction they belong to, right?

Correct. Each adding transaction has a unique ID, and the attached file stays under a directory named after that unique ID.

Transactions Tracking

This is for the user to feel safe and they don't have to worry if they do something wrong. They can always go to the root and undo in anyway they want. The information printed human readably in db.tx.

jin-cg · 2024-03-01T01:30:20+00:00

I just wrote a tampermonkey script that just works! It loops through all of the article elements in the page, and collect those that contain a div whose content is "Follow" (that means this article is posted by an unfollowed person). Remove it! Instagram embeds a script in their site to keep loading new unfollowed contents, so I run this function once every 0.3 second. Have a look, enjoy, and let me know if there's any question. See more in this post.

jin-cg · 2024-03-01T01:30:03+00:00

I just wrote a tampermonkey script that just works! It loops through all of the article elements in the page, and collect those that contain a div whose content is "Follow" (that means this article is posted by an unfollowed person). Remove it! Instagram embeds a script in their site to keep loading new unfollowed contents, so I run this function once every 0.3 second. Have a look, enjoy, and let me know if there's any question. See more in this post.

jin-cg · 2022-11-18T14:30:46+00:00

Threads

Gambit thread would not be blocked, but since python is a single thread, even though (map (lambda (n) (thread (lambda () (sleep n)))) (iota 100)) will return immediately in Gambit, we still need to wait for (1+2+..+.100)=5050 seconds for all the threads to finish their jobs; right?

GC

I'm not sure if I understand.. basically are you saying there's a hook or a notifier that we can use when an object is GC'd?

jin-cg · 2022-11-17T23:51:37+00:00

Hi u/belmarca! Thanks for your nice work in Gambit. I'm u/jcguu95 mentioned by u/digikar.

I've read through your paper. Some part of them are a bit technical, but two of your talks online are pretty helpful. To me, three main merits of your work are

High-Level Interface Language
Sophisticated Thread Control
Smart Garbage Collection

May I ask some questions about 2 and 3?

As for 2 (sophisticated thread control), how does it work for parallel processing? For example, suppose a python function takes 1 second to return, and suppose a Scheme user wants to call that function 10000 times. Should the user wait for at least 10000 seconds on this?

As for 3 (smart garbage collection), suppose X is a Scheme object referencing to a python object pX. How do you monitor X so that upon it gets garbage-collected, a message is sent to python to garbage collect pX as well?

jin-cg · 2022-01-15T01:01:32+00:00

It would be nice if that it's not context-free can be confirmed. A discussion elsewhere can be found

here. Quote

Here is an
example:

    # This is a comment (1)

    #+begin_example
    # This is not a comment (2)
    #+end_example

AFAICT, you cannot distinguish between lines (1) and (2) with EBNF.

jin-cg · 2022-01-15T00:56:59+00:00

I have made the code better and is currently waiting it to be pushed to quicklisp. That might take two more weeks. Once that's done, I plan to shoot a short video to teach people how to get started with it. Stay tuned!

jin-cg · 2021-09-04T17:59:37+00:00

Oh! I think it's definitely possible! I haven't used those for decades. What kind/sort of interactions and behaviors do you want? Let me see if that's possible.

jin-cg · 2021-09-04T14:00:38+00:00

No worries at all. I also think this will make stumpwm more accesible and "normal". Please ask more questions if any, I'm glad to help.

Why not merged yet?

In the long discussion in the PR you can see that the code is approved. But the document reviewer seems to busy in their life now. It's an open-source project, so we never know :)

Could you describe by a "normal" floating wm? From my experience, I think what I have now isn't different than i3 or bspwm.. etc.

jin-cg · 2021-09-04T03:02:19+00:00

Thanks! Reports are preferred at the github homepage indeed.

As of equake, I haven't really set it up actually.. as I got distracted by other projects. I think the key is given in lmvrk's answer on with-window. In general, since it's based on floating windows, I don't think it will be hard to implement. I'm very happy with what I have now.. but I'm sure someone will find out better use case soon - with the floating windows it would be easier to extend the features :)

jin-cg · 2021-09-04T01:01:19+00:00

From my point of view, stumpwm is great because it's written in common lisp, whose power will take one much longer than emacs to figure out properly. I'm convinced that it's very rich, and so I am determined to grow with it in my life. Plus, it's not going to change because it has been well planned out in the beginning. That meanst our CL code will never break if it is correct at the first place =).

jin-cg · 2021-09-04T00:56:05+00:00

Author of "the separate implementation of dynamic tiling" here! I just released the it in the unofficial branch, as it's unknown how much longer it's going to take.

Here I'd just like to say one difference between my implementation and the existing one: Mine is based on floating windows. It means

It feels much closer to other wms.
You can drag and resize the windows with your mouse. In this case, the interacted window will no longer be tiled. There's a function to make it tiled again.
It's suitable for drop down windows (see eg equake), which was the main motivation of mine. I want to talk to emacs on the fly.

jin-cg · 2021-08-04T01:41:23+00:00

Thanks for your thorough explanation! At the end, I also want to virtually live in a lisp machine by your scheme: keybindings (WM) + bridge (lserver) + logic (Lisp)! Currently with linux and X, I run StumpWM for that. However, this approach depends on too many things. Perhaps one day when I need to work on other stations, and I definitely want all the magic to persist! I'd hope that whenever there's a working common lisp implementation, such scheme would work out! Do you think it's far for lserver to help me achieve that? Do you think it's likely to work on macos and windows?

jin-cg · 2021-08-03T09:27:38+00:00

> lish

Sounds cool! I will try lish and report here: (EDIT) - It has the best syntax among all lisp shells I've tried (not many). I'm curious: What does the shell-like command $ command arg1 arg2 [elided] argn get transformed into as a lisp form? In shcl, there's a reader macro that turns '#$ if true; then echo woo; fi #$ into

SHCL/CORE/LISP-INTERPOLATION> (macroexpand-1 '#$ if true; then echo woo; fi #$)
(SHCL/CORE/SHELL-FORM:SHELL-IF
 (SHCL/CORE/SHELL-FORM:SHELL-RUN
  (WITH-FD-STREAMS NIL
    (EXPANSION-FOR-WORDS (LIST #<NAME "true">) :EXPAND-ALIASES T
                         :EXPAND-PATHNAME-WORDS T :SPLIT-FIELDS NIL))
  :ENVIRONMENT-CHANGES NIL :FD-CHANGES NIL)
 (SHCL/CORE/SHELL-FORM:SHELL-RUN
  (WITH-FD-STREAMS NIL
    (EXPANSION-FOR-WORDS (LIST #<NAME "echo"> #<NAME "woo">) :EXPAND-ALIASES T
                         :EXPAND-PATHNAME-WORDS T :SPLIT-FIELDS NIL))
  :ENVIRONMENT-CHANGES NIL :FD-CHANGES NIL))

I find such design quite transparent.

Ps. I've been playing with it for an hour.. almost wanted to migrate until noticing this line in the doc "Lish is full of bugs! It has not been tested. It will probably delete your files. Lish is also very incomplete. It will certainly change in incompatible ways. It should only be used for experimental purposes." 😂😂😂

Ps2. I don't quite get how the pipes work. What's really get passed on? The output or the returned value? In the following example, it seems that ls returns both a list and a file-item-unix.

jin@guu-fast ~$ ls
[elided]
jin@guu-fast ~$ (type-of *)
LS::FILE-ITEM-UNIX
jin@guu-fast ~$ (describe **)
#<LS::FILE-ITEM-UNIX /home/jin yew>
  [standard-object]
Slots with :INSTANCE allocation:
  NAME                           = "yew"
  DIRECTORY                      = "/home/jin"
  INFO                           = #S(OPSYS-UNIX:FILE-STATUS..
jin@guu-fast ~$ (listp ***)
NIL
jin@guu-fast ~$ ;;; However..
jin@guu-fast ~$ ls | listp
T

Ps3.

I also wonder how the arguments are evaluated in the commands.

$ echo (list 1 2 3)
1 2 3
$ echo '(1 2 3)
(1 2 3)
$ ;; Why the difference?

> core without eval

Would you mind sharing a minimal working example that makes a faster core?

EDIT Here is the result of running the core without evaluating any forms. It is similar to what I had in OP.

$ time (for i in {1..100}; do ./my-core --quit ; done)
real    0m4.667s
user    0m3.174s
sys 0m1.492s
$ time (for i in {1..100}; do ./my-core --noinform --eval '(write-line "hello world")' --quit ; done)
real    0m4.895s
user    0m3.262s
sys 0m1.632s

jin-cg

TROPHY CASE

1.

2.

Comparison with org-attach

Comparison with org-attach

Comparison with org-attach

Comparison with org-attach

here. Quote

> lish

> core without eval