todo.sr.ht

Entries have a "See also" section at the end, usually with links to other glossary entries. On the other hand, if a "source" entry mentions a "target" entry in the regular text, this text is just text, not a link.

It would probably be helpful if the inline text contained links to other glossary entries where appropriate. This has the disadvantage that reading a glossary entry with lots of links could be distracting and tempt a reader to "meander" too much, but probably having the links is better overall.

I had thought about this feature previously, but haven't implemented it yet because I don't like that links created by secref would have the title of the target entry, which is capitalized. This would look odd in the text. I need to find out how I can use alternative text. Ideally I want to lowercase the first character for the target text automatically, so the text stays the same as it is now, without links.

#1 Add checkboxes to show only entries for wanted categories 4 months ago

Comment by ~sschwarzer on ~sschwarzer/racket-glossary

Caveat: We don't only need JavaScript to change the displayed entries when one of the checkboxes is (un)selected. We also need to react to a user clicking on a cross-reference to a glossary entry that's currently hidden.

I suppose in this case it would be best to "auto-select" the level the cross-reference is in. For example, if only the "basic" level is shown and a user clicks on a link leading to an "intermediate" entry, the "intermediate" level should be added to the checkboxes and all included entries should be made visible before scrolling to the just-selected entry.

#1 Add checkboxes to show only entries for wanted categories 4 months ago

Comment by ~sschwarzer on ~sschwarzer/racket-glossary

@glossary-entry["Something" '(basic stub)]{...}

This is now @glossary-entry["Something" 'basic #:stub #t]{...}.

#151 SFTP support (FTPS is already supported!) 5 months ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

Hi ~dolfinus :-)

Well, there is https://docs.paramiko.org/en/stable/api/sftp.html

Yes, I mentioned/discussed it in the ticket description. :-)

I think the topic is rather complicated, so at least at the moment it doesn't seem worth it to work on Paramiko integration in ftputil.

Of course, and maybe that's what you meant, if someone needs "just" SFTP support without compatibility with the ftputil API, they may be fine with using Paramiko's SFTP class directly.

A "subfeature" I'd like to have is to take the project (and/or context/tag) from the last component of the directory path where each todo.txt is located. This might make the feature much more practical to use.

If I only implement the variant of using the directory for a +project, the command line change should actually be easy, i.e. add a command line option that will be applied to all todo.txt files. So this should probably be the starting point to experiment with such a feature.

Caveats:

Directory names may contain characters not allowed in a project label. In this case, I could either remove such characters or replace them with (for example) underscores.

A leaf directory name may be used more than once, so tasks from different todo.txt files would get the same project assigned, which would make the projects indistinguishable in the combined report. Possible ways to deal with this:

Just do it, i.e. generate ambiguous project labels (but print a warning).

Append suffixes to the "duplicated" project name.

Include information from preceding directory components, not just the last one. This could be single characters (similar to how Vim does it in shortened paths in tabs) or full directory path components (going up in the directory hierarchy until the disambiguation is resolved).

Using the leaf directory for a project will probably make sense for different software projects, but not for generic paths like text/todo.txt or notes/todo.txt. In this case, the "project" would become +text or +notes, respectively.

A task could already have a project with the same name.

A todo.txt file may be in the root directory, so we don't have a directory name.

For a first prototype, I'll handle the caveats like this:

Replace invalid characters with underscores.

Use just the leaf directory for the project, and maybe add a warning for his case.

Just use the leaf directory, including possibly unhelpful projects like +notes.

Don't add duplicate project labels.

If a todo.txt file is in the root directory, don't add a project.

#1 Add contexts/projects/tags to all tasks in a file 6 months ago

Ticket created by ~sschwarzer on ~sschwarzer/todo-txt

todoreport can already merge several todo.txt files into one report by specifying all the todo.txt files on the command line.

If there are todo.txt files for multiple projects, each within their own project directory, it would be helpful to, for example, group tasks from several projects by priority. Now, to distinguish tasks from different projects in the combined report, the tasks should have a +project, but for the individual todo.txt files, adding a project they all share is redundant.

Therefore, todoreport should allow the assignment of projects (and potentially contexts or tags) to all tasks in a file, of course with a different project/context/tag for each file. :-)

The challenge here isn't so much the automatic assignment of projects/contexts/tags in the task processing, but rather to find a good command line interface for this feature.

#1 Add checkboxes to show only entries for wanted categories 8 months ago

Comment by ~sschwarzer on ~sschwarzer/racket-glossary

It seems the js-addition style property can be used to include a custom JavaScript file.