Re: org-mode for package documentation

[Payas Relekar]

Björn Bidar  writes:

> Philip Kaludercic  writes:
>
>> Christopher Dimech  writes:
>>
>>> Dear Compeers,
>>>
>>> Some months ago there had been a discussion about using org-mode
>>> to produce package documentation.  Which would allow the use of
>>> Latex3 (e.g. use of colour, floating images).
>>
>> Where/when did this happen?  Could you provide a few pointers?
>
> I don't know exactly but when use-package was merged into Emacs there
> were discussions if keeping the documentation in org-mode format is
> fine.
>
> From what I understood it is possible.

IIRC, Richard Stallman said he'd be amenable to it, _provided that_ Org
fulfilled all the requisite functionality from Texinfo.

Ihor (org maintainer) was also receptive, but I don't remember if/how
much progress happened towards the goal.

--

Re: [FR] Enhancing footnote managment (via indirect buffer)?

[Payas Relekar]

Andrea Lazzarini  writes:

> I've fiddled with org-edit-special and I see it has a major flaw, at least in 
> my opinion.
> It inserts all changes without keeping track of the undos, as opposed to the 
> indirect
> buffer solution, which also had the advantage of doing everything from a 
> single buffer:
> it operates as some sort of 'window' on a part of the file, rather than 
> feeling as some
> sort of out-of-the-normal operation. Aren't there other possibile use cases 
> for indirect
> buffers in org mode? Why are they considered inferior to other solutions? I 
> ask just
> for my understanding.
>
> (A combination of eldoc + org-edit-special might be rather affecting on the
> seamlessness of the workflow, but this is of course my simple personal 
> opinion).

I've been playing with org-footnote-assistance, and this is again just
another opinion, but I'm also preferring the indirect buffer. It just
puts things in better perspective.


--

Re: [BUG] Add option for category to be derived from #+TITLE instead of file name [9.6 ( @ /nix/store/jv2kmcbm79k4g6i778hblw98l0pxxghf-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6/)]

[Payas Relekar]

Payas Relekar  writes:

> After discovering categories
> (https://orgmode.org/manual/Categories.html) I'd like to use them
> everywhere because it makes agenda cleaner. But currently, it has only
> below options to get this value (in order of precedence, highest to lowest)
>
> - #+CATEGORY property (if present)
> - file name
>
> While I can set the property in my capture templates, it will only take
> effect on newly created files and will not retroactively apply all the
> previously created ones.
>
> As such, I'd like to propose adding variable to allow user to specify
> whether #+TITLE property should be preferred over #+CATEGORY. The
> default can continue as is, but if the user chooses to perfer title,
> order of preference will look like (highest to lowest):
>
> - #+TITLE (if present)
> - #+ CATEGORY (if present)
> - file name

Actually this is a mistake. It should always prefer explicit property
(#+CATEGORY) over implicit (#+TITLE). So the order should look like (if
the user modifies the variable, highest to lowest):

- #+CATEGORY (if present)
- #+TITLE (if present AND if user sets the variable)
- file name

Apologies for confusion.

Thanks,
Payas

--

[BUG] Add option for category to be derived from #+TITLE instead of file name [9.6 ( @ /nix/store/jv2kmcbm79k4g6i778hblw98l0pxxghf-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6/)]

[Payas Relekar]

After discovering categories
(https://orgmode.org/manual/Categories.html) I'd like to use them
everywhere because it makes agenda cleaner. But currently, it has only
below options to get this value (in order of precedence, highest to lowest)

- #+CATEGORY property (if present)
- file name

While I can set the property in my capture templates, it will only take
effect on newly created files and will not retroactively apply all the
previously created ones.

As such, I'd like to propose adding variable to allow user to specify
whether #+TITLE property should be preferred over #+CATEGORY. The
default can continue as is, but if the user chooses to perfer title,
order of preference will look like (highest to lowest):

- #+TITLE (if present)
- #+ CATEGORY (if present)
- file name

Will something like this be possible?

Thanks,
Payas

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, 
cairo version 1.16.0)
Package: Org mode version 9.6 ( @ 
/nix/store/jv2kmcbm79k4g6i778hblw98l0pxxghf-emacs-packages-deps/share/emacs/site-lisp/elpa/org-9.6/)
--

Re: [off-topic] E-readers and Org-Mode

[Payas Relekar]

Max Nikulin  writes:

> E-ink displays are slow (my device was manufactured 15 years ago but I do not
> expect dramatic improvement), so applications should be heavily optimized to
> provide acceptable experience. I do not think that Emacs is suitable.

There are people already using Emacs on e-ink displays, and from first
look its quite useful.

See https://twitter.com/ianthehenry/status/1481376985129500679?lang=en

Unsure on use for extended duration, I'll have to try out myself once
one is actually available in my country, but I'm liking the idea.

--

Re: [ANN] The 2022 Emacs User Survey is now open!

[Payas Relekar]

Great job on the survey!

Filled and submitted.

Timothy  writes:

> Hi All,
>
> I’m thrilled to announce that the Emacs User Survey 2022 is now open to
> responses. It is my hope that this may help emacs-devel, Emacs package
> maintainers, and the wider Emacs community develop a better understanding of
> how people experience Emacs on a day-to-day basis.
>
> 
>
> The survey will be open from October 24th to November 30th.
>
> This time there are /no/ non-free Javascript or user-tracking caveats as this
> features a bespoke survey framework written from scratch for the Emacs User
> Survey to support a pure HTML-forms + CSS approach with server-side rendering
> .
>
> See the [FAQ] for more information on the survey itself.
>
> It would be fantastic for this to be shared as far and wide as possible, to 
> get
> responses from a large swathe of the community. If you can share this with 
> Emacs
> communities you are a part of, as well as any friends or colleagues that use
> Emacs, that would be much appreciated.
>
> We can look forward to a discussion of the (preliminary) results in EmacsConf:
> .
>
> All the best,
> Timothy

--

Re: How do you manage complex project with Org-mode

[Payas Relekar]

Jean Louis  writes:

> * Sébastien Gendre  [2022-03-01 05:35]:
>> And I don't know how to manage this kind of projects with Org-mode.
>
> Just use pen and paper notebook. Carry it with you.

While nearly unparalleled on the input experience, pen-and-paper is
terrible at data retrieval.

--

Re: Org and Hyperbole

[Payas Relekar]

Robert Weiner  writes:

> Good to hear.  Maybe you can provide early feedback when it hits the
> Hyperbole pre-release in the elpa-devel package archive (pre-releases of
> Hyperbole packaged up from the git master branch tip).

I'll be happy to! Unfortunately I'm not able to always follow this list,
so if possible, please let me know when you have something I can try
out.

> Yes.  It will search over many files and even recursive directories of
> files.  Org-roam has a good model for rapid searching, so we'll have to
> consider something similar.  It might not be in the first release but will
> come by the second major release.

Thanks! I've found that without instant/near-instant search the chain of
thought breaks easily (Thanks, ADHD!), so this one is quite important.

> Each note will have an optional datetime stamp which will be on by
> default.  If you care to make one note per day, you can do that.

Sounds good!

> Yes, that is the reason for desiring some kind of database-backed indexing.

Yes, but from your other email it appears this one is not going to
happen due to previous Emacs versions not having built-in sqlite. Have
you thought of any alternate way for achieving same performance without
any built-in database?

> Yes.  The idea is that you initially capture notes into a single default
> file and then can quickly refile them as needed.

While single default file sounds good, individual daily files are better
IME. Because the single file inevitably becomes too large, unwieldy and
generally not the best place to go through quickly.

>> In short, the framework takes care of organization and makes retrieval
>> easy and all I have to worry about is the content.
>>
>
> Yes, I think we typically do this throughout Hyperbole, as it is very
> important to us.

Thanks! Hyperbole has been really good experience so far, because of
practically zero config and batteries included approach. Better
integration with stock Emacs stuff like Org, Gnus and Dired is always
welcome.

Thanks a lot for working on Hyperbole and being responsive!

--

Re: Interest in an Org video meetup?

[Payas Relekar]

Marcin Borkowski  writes:

> On 2022-10-06, at 16:40, Leslie Watter  wrote:
>
>> Would be great to see what others are doing in their workflows using org ;-)
>>
>> I'd like to join to!
>
> Great idea!
>
> Me too, though it depends on the schedule.  What time of day do you plan
> for that?

+1 for both interest in joining and time of day.

Thanks,
Payas
--

Re: Org and Hyperbole

[Payas Relekar]

Robert Weiner  writes:

> Thanks, Jean.  We have started work on a note-taking subsystem for
> Hyperbole that will store UUIDs per note and will likely support backlinks
> too.  We are seeing if we can make it support Koutlines, Emacs Outlines,
> Org mode files and Markdown files, searching across all formats at the same
> time.  The default for creating new notes will likely be a personal
> Koutline file.

Not Jean, but as someone using Org with Hyperbole, this is a great news!

> We welcome brief summaries of features you need for effective note taking
> in Emacs.  We are not looking to do much with images or on mobile devices,
> just focused on people who spend a lot of time in Emacs and want an
> easy-to-use notes system that does not require any external packages like
> SQLite.

For my 2c:

- Multiple small files vs single large file.
  I currently have former, with org-roam taking care of finding, linking
  and backlinking between files, making it a non-issue to easily build a
  network of connected topics/thoughts

- Daily notes
  Every day gets its own note, only generated if visited. This allows
  dumping the thoughts at that moment rather than first hunting the
  correct node. Then they can be easily filtered into actual topic note,
  or just be referenced via backlinks buffer

- sqlite might just be better, considering overhead of opening and
  parsing hundreds-thousands of small files is non-negligible.

- Refiling
  Refile/move the subtree (in Org terms) can be easily moved to another
  file and the links automatically point to new location. This means I
  can always know rearranging stuff later is a possibility, and its less
  cognitive burden to organize.

In short, the framework takes care of organization and makes retrieval
easy and all I have to worry about is the content.

Thanks,
Payas

--

Re: IM dev discussions?

[Payas Relekar]

Bastien  writes:

> But then at some point we will have two problems: we will need to
> spend energy encouraging these Discourse users send their patches to
> the mailing list and people on this ML who are mostly here to help
> others will have to split their time and attention between the ML and
> forum.orgmode.org, because both will be official support channels
> for the Org community.

Maybe we don't need to split time checking both Discourse and Mailing
list, because Discourse comes with a 'mailing list mode':
https://racket.discourse.group/t/how-to-enable-mailing-list-mode/167/3

Admittedly I am yet to try it, but it can also provide filtering to mute
particular categories so they don't clutter your mailbox :)

Replying to discourse notification emails has worked well in my
experience, and there are apparently ways to create new posts by sending
emails as well:
https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099

Perhaps we can check if it is indeed possible to bridge both Discourse
and mailing list seamlessly (or close enough). There are some issues
with extra chrome and clutter in discourse notifications, but these 2
links are what I found in 5 minutes of googling. A more thorough
research might just yield what we desire.

Payas
--

Re: IM dev discussions?

[Payas Relekar]

Ihor Radchenko  writes:

> Is there is possibility to merge multiple rooms in Matrix/IRC?

There is! It is called Spaces, which allows arbitrary hierarchy of other
rooms (as well as spaces). NixOS organisation and its various sub-groups
are already quite successfully utilizing it, if you'd like to check that
out.

Unless you mean *merge*ing multiple rooms, in which case, I doubt it.
But, we can set aliases to rooms so as to have a room point to new one,
while old one remains accessible on a UUID-esq identifier.

Further details:
Matrix spaces: https://matrix.org/blog/2021/05/17/the-matrix-space-beta
NixOS matrix space: https://matrix.to/#/#community:nixos.org

Thanks,
Payas

--

Re: Support for tagging (special) blocks

[Payas Relekar]

Kaushal Modi  writes:

Tags are bit more generic though, and allow searching across not just
code blocks, but TODOs as well.

Thanks,
Payas

> On Wed, Aug 31, 2022 at 4:19 PM Sébastien Miquel 
> wrote:
>
>> Hi,
>>
>> I've been using tags on special blocks, src blocks and other, for two
>> purposes:
>>
>>   1. to control which blocks get exported, using the `#+exclude_tags`
>>  property.
>>   2. to fine tune the export, according to tags, of special blocks such as
>>  #+BEGIN_exercice:hard:
>>  …
>>  #+END_exercice
>>
>> Does anyone think this is useful and might warrant adding support for ?
>>
>
> I think that using the #+header: property for something like this might be
> more canonical.
> https://orgmode.org/manual/Using-Header-Arguments.html
>
> Example:
>
> =
>
> #+header: :tags noexport
> #+begin_foo
>
> ..
> #+end_foo
> =
>
> or
>
> =
>
> #+header: :tags hard
> #+begin_foo
>
> ..
> #+end_foo
> =
>
> It's also relatively easy to parse these headers:
>
> =
> (org-babel-parse-header-arguments (car (org-element-property :header
> special-block)))
> =
>

--

Re: org-babal-R-command

[Payas Relekar]

Naresh Gurbuxani  writes:

Can you escape spaces with backslash?

(setq org-babel-R-command “c:/Program\ Files/Microsoft/R\ 
Open/R-3.5.1/bin/R.exe —slave —no-save”)

Another way is to use single quotes:

(setq org-babel-R-command “'c:/Program Files/Microsoft/R 
Open/R-3.5.1/bin/R.exe' —slave —no-save”)

Thanks,
Payas


> In my windows computer, R is installed at c:/Program Files/Microsoft/R 
> Open/R-3.5.1/bin
>
> Notice two spaces: “Program Files” and “R Open”
>
> How can I set the variable org-babel-R-command?
>
> I tried
> (setq org-babel-R-command “c:/Progra~1/Microsoft/R Open/R-3.5.1/bin/R.exe 
> —slave —no-save”)
>
> But the space between R and Open is a problem.  What is the solution?
>
> Thanks,
> Naresh
>
> Sent from my iPhone

--