Contributing (looking for good first issues to tackle)

Contributing (looking for good first issues to tackle)

[Derek Chen-Becker]

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

Hi,

I've been a long-time user of org mode and while I already make monetary
donations, I would also like to help out in terms of code and
documentation. I've been writing software for a long time but only in the
last couple of years have I really started to dig into elisp, mostly to
write my own helper functions and customizations. Based on Ihor's recent
talk, I took a look at https://orgmode.org/worg/org-contribute.html and
https://tracker.orgmode.org/bugs but it's not clear to me if this is the
actual way we track issues or if this is just fancy indexing of the
mailing list (both?). Some of the bugs reported in the list already have a
message stating that the issue is fixed, so I'm also a little confused
about the consistency of the Woof index vs reality. As a first task, maybe
is there a way I could help triage things and mark completed
requests/bugfixes in Woof? Or do we have a different way of tracking things?

Thanks,

Derek


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

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

Re: Contributing (looking for good first issues to tackle)

[Dilip]

> (looking for good first issues to tackle)
Since you said this, I'd like to point to my own issue that I raised.
Even I have not tried to solve to debug the issue (which is bad on my
part)

https://list.orgmode.org/87y15bcbi1.fsf@localhost/

Even I have been a lurker here, just falling into the rabbit hole of
emacs and orgmode.

I should find myself some motivation to sit and solve issues and make
contributions.

The "future of Org" was definitely inspiring and fulfilling to re-think
org development for future ahead.


https://list.orgmode.org/8734iwel1o.fsf@localhost/T/#u

Also to remind tomorrow (11th Dec, 19:00 EST -- Turkey) there will be
OrgMeetup. It would be a great place to have more live discussions with
everyone.
Better to make sure to it attend as well.

-- 
Best,
Zororg

Re: Contributing (looking for good first issues to tackle)

[Russell Adams]

On Mon, Dec 09, 2024 at 11:41:38PM -0700, Derek Chen-Becker wrote:
> I've been a long-time user of org mode and while I already make monetary
> donations, I would also like to help out in terms of code and
> documentation.

I would suggest helping curate Worg by:

 - removing or fixing dead links
 - updating documentation
 - writing new articles

I've tried to help with this before, and there's always more.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com
                                    https://www.adamsinfoserv.com/

Re: Contributing (looking for good first issues to tackle)

[Derek Chen-Becker]

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

Hi Zororg,

I would be happy to work with you on this if you're interested in
collaborating on it. I'm a little concerned with the scope, given that Ihor
said: "We should probably fix handling indirect buffers across Org mode".
I'm not sure how extensive indirect buffer handling is across Org, or if
it's even consistent across Org right now. I'll probably need some help
from people more familiar with it to figure out a starting point, but I'm
excited to take a look :)

Cheers,

Derek

On Tue, Dec 10, 2024 at 3:02 AM Dilip <zororg@tilde.green> wrote:

>
> > (looking for good first issues to tackle)
> Since you said this, I'd like to point to my own issue that I raised.
> Even I have not tried to solve to debug the issue (which is bad on my
> part)
>
> https://list.orgmode.org/87y15bcbi1.fsf@localhost/
>
> Even I have been a lurker here, just falling into the rabbit hole of
> emacs and orgmode.
>
> I should find myself some motivation to sit and solve issues and make
> contributions.
>
> The "future of Org" was definitely inspiring and fulfilling to re-think
> org development for future ahead.
>
>
> https://list.orgmode.org/8734iwel1o.fsf@localhost/T/#u
>
> Also to remind tomorrow (11th Dec, 19:00 EST -- Turkey) there will be
> OrgMeetup. It would be a great place to have more live discussions with
> everyone.
> Better to make sure to it attend as well.
>
> --
> Best,
> Zororg
>


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

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

Re: Contributing (looking for good first issues to tackle)

[Ihor Radchenko]

Derek Chen-Becker <derek@chen-becker.org> writes:

> ... I took a look at https://orgmode.org/worg/org-contribute.html and
> https://tracker.orgmode.org/bugs but it's not clear to me if this is the
> actual way we track issues or if this is just fancy indexing of the
> mailing list (both?).

Thanks for your interest!

Woof! is the way to track issues, at least eventually.
It works by indexing the mailing list, so using Woof! simply saves you
from the noise of non-bug messages we get here.
You may also follow the whole mailing list if that's ok for you.

> ... Some of the bugs reported in the list already have a
> message stating that the issue is fixed, so I'm also a little confused
> about the consistency of the Woof index vs reality.

Woof! is still in early development, and we have an annoying bug there
causing some issues to remain open even after marking them closed.

   Bastien, can we do something about it? This problem keeps confusing
   potential contributors.

AFAIK, the new bug reports will consistently appear in the list. So, you
can take a look at the latest reports. They are likely to be unfixed.
You can also subscribe to see new bug reports via RSS:
https://tracker.orgmode.org/bugs.rss

> ... As a first task, maybe
> is there a way I could help triage things and mark completed
> requests/bugfixes in Woof? Or do we have a different way of tracking things?

As you can see, marking things completed is just a bug in Woof that we
should eventually solve. Woof! is written in Clojure and developed in
https://sr.ht/~bzg/woof/. Probably it is not what you want. (Or, if you
do, I am sure that Bastien will welcome contributions there.)

For triaging the bugs, you can look at the bugs without any response and
the bugs without _my_ response. These are the bugs I did not triage yet.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Contributing (looking for good first issues to tackle)

[Ihor Radchenko]

Derek Chen-Becker <derek@chen-becker.org> writes:

> I would be happy to work with you on this if you're interested in
> collaborating on it. I'm a little concerned with the scope, given that Ihor
> said: "We should probably fix handling indirect buffers across Org mode".
> I'm not sure how extensive indirect buffer handling is across Org, or if
> it's even consistent across Org right now. I'll probably need some help
> from people more familiar with it to figure out a starting point, but I'm
> excited to take a look :)

You do not need to address the whole thing at once. Start by trying to
fix the exact bug described:

1. Try to reproduce it locally
2. Find which part of Org code is causing the problem (you can use
   edebug, M-x debug-on-entry, or modifying the code with (message ...)
   or (debug) statements directly - remember that you can re-define
   functions on the fly in Elisp)
3. Try to fix it

I wrote about "across Org mode" because my quick debugging revealed that
the problematic code might be a pattern we use in various places in
Org. So, the whole Org code base should be carefully scanned to see if
we can fix the same problem in more places.

Such scanning usually starts from trying to regexp search code similar
to the problematic piece. In this case, AFAIR, it is simply usage of
`buffer-file-name' or `buffer-file-truename' assuming that it is never
nil.

It is also good for you that the original bug reporter is around. Having
someone else familiar with the problem might make things easier when you
cooperate together.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Contributing (looking for good first issues to tackle)

[Derek Chen-Becker]

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

OK, after some debugging it looks like the primary culprit is the
assignment of source-file from buffer-file-name. A quick patch seems to fix
it, but I can definitely see a pattern here if org functions are trying to
get the filename of the current buffer (I can submit an official patch if
this looks right):

modified   lisp/ob-tangle.el
@@ -269,7 +269,7 @@ matching a regular expression."
        (or (cdr (assq :tangle (nth 2 (org-babel-get-src-block-info
'no-eval))))
    (user-error "Point is not in a source code block"))))
     path-collector
-            (source-file buffer-file-name))
+            (source-file (buffer-file-name (buffer-base-buffer))))
  (mapc ;; map over file-names
  (lambda (by-fn)
    (let ((file-name (car by-fn)))

There are 339 uses of buffer-file-name that I can find, but most are just
bare (buffer-file-name). Are there any other cases besides indirect buffers
that we would need to handle? Would it be worth creating a new function
"org-buffer-file-name" that could properly handle indirect buffers and any
other special cases, or is it just a search and replace throughout?

Cheers,

Derek

On Tue, Dec 10, 2024 at 11:05 AM Ihor Radchenko <yantar92@posteo.net> wrote:

> Derek Chen-Becker <derek@chen-becker.org> writes:
>
> > I would be happy to work with you on this if you're interested in
> > collaborating on it. I'm a little concerned with the scope, given that
> Ihor
> > said: "We should probably fix handling indirect buffers across Org mode".
> > I'm not sure how extensive indirect buffer handling is across Org, or if
> > it's even consistent across Org right now. I'll probably need some help
> > from people more familiar with it to figure out a starting point, but I'm
> > excited to take a look :)
>
> You do not need to address the whole thing at once. Start by trying to
> fix the exact bug described:
>
> 1. Try to reproduce it locally
> 2. Find which part of Org code is causing the problem (you can use
>    edebug, M-x debug-on-entry, or modifying the code with (message ...)
>    or (debug) statements directly - remember that you can re-define
>    functions on the fly in Elisp)
> 3. Try to fix it
>
> I wrote about "across Org mode" because my quick debugging revealed that
> the problematic code might be a pattern we use in various places in
> Org. So, the whole Org code base should be carefully scanned to see if
> we can fix the same problem in more places.
>
> Such scanning usually starts from trying to regexp search code similar
> to the problematic piece. In this case, AFAIR, it is simply usage of
> `buffer-file-name' or `buffer-file-truename' assuming that it is never
> nil.
>
> It is also good for you that the original bug reporter is around. Having
> someone else familiar with the problem might make things easier when you
> cooperate together.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

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