Re: org-assert-version considered harmful

[Timothy]

Hi Ihor,

> Should we use the next planned release version number on main branch as
> a convention?

For what it’s worth, in my own build of Org I set `org-release' to
`MAJOR.(MINOR+1).0', e.g. when the last tag is `9.5.5' I set `org-release' to 
`9.6.0'.
The `.0' suffix serves to differentiate this from the later `9.6' release, 
looking
at historical first-minor-version releases (`9.5', `9.4', `9.3', etc.) the patch
version seems to be omitted in each initial minor release.

I think it could make sense to apply this approach to the main branch.

All the best,
Timothy

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Timothy]

Hi Ihor,

> Jean Louis  writes:
>
>> For IRC, there are ways to record history, and I am sure that
>> such history may be recorded with referencable hyperlinks.
>>
>> Look at this example from Guix IRC channel:
>> 
>
> AFAIU, this should be supported by the IRC server. Does irc.libera.chat
> (where #org-mode channel is hosted) support logging?

On this note, I’ve recently discovered
 which looks rather 
promising
to me.

All the best,
Timothy

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Ihor Radchenko]

Jean Louis  writes:

> For IRC, there are ways to record history, and I am sure that
> such history may be recorded with referencable hyperlinks.
>
> Look at this example from Guix IRC channel:
> https://logs.guix.gnu.org/

AFAIU, this should be supported by the IRC server. Does irc.libera.chat
(where #org-mode channel is hosted) support logging?

-- 
Ihor Radchenko,
Org mode contributor,
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: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>> Paragraph.
>
> In this case I would not see it necessary, IMHO. For simple things (of
> the begin/end style) there are the special blocks. And for more complex
> pre- and/or post- code we have export blocks and export snippets. Since
> there is no heading involved here, there would be no danger of the
> pre-code leaving with the content of the previous header.

I do not insist on this. I just see supporting this easier (it will work
automatically) compared to explicitly limiting :export_template to
headings/inlinetasks.

Also, some people prefer to have such option (Pedro Andres Aranda
Gutierrez in off-list reply to
https://orgmode.org/list/87fsgmyyhw.fsf@localhost)

-- 
Ihor Radchenko,
Org mode contributor,
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: [BUG] Face attribute customization is ignored [9.5.5 (9.5.5-gbe2246 @ /home/dav/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

David Vicente  writes:

> On 24/09/22 02:58, Ihor Radchenko wrote:
>> Yes, it does. Just set it to nil, and you will be good to go.
>
>
> Won't that have other effects?

Hmm. A single side effect will be that the fonts will not be applied to
the newline characters after the begin/end block lines. However, this
difference, AFAIK, only matters when there is :extend face property.

If you want to be really safe, try setting the :extend face property in
org-font-lock-set-keywords-hook or in org-mode-hook.

-- 
Ihor Radchenko,
Org mode contributor,
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: org-assert-version considered harmful

[Ihor Radchenko]

Bastien  writes:

> Ihor Radchenko  writes:
>
>> Then, I am inclined towards easing the version check to (org-version)
>> instead of (org-git-version).
>
> FWIW strong +1 here.

There is one more concern we may need to solve prior to changing
org-git-version to org-version.

Currently, main and bugfix branches both have (org-version) ; => "9.5.5"
As a result, the assertion will not catch the important case when users
mix Org version installed via package.el and Org version installed from
git.

Should we use the next planned release version number on main branch as
a convention?

-- 
Ihor Radchenko,
Org mode contributor,
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: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

[Bastien]

Hi Daniel,

Daniel Kraus  writes:

> Attached is the patch changed the logic to use a temp file with
> org-babel-eval.

Applied in main as 764642f5, thanks a lot and sorry for the delay.

I also added you to https://orgmode.org/worg/contributors.html.

Would you consider taking over the maintainance of ob-clojure.el?

-- 
 Bastien

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Bastien]

Ihor Radchenko  writes:

> For reference, I am seeing this feature as a step towards better
> modularity of org-list.el.

Modularity is good if we have use-cases for it, at least one feature
relying on it.  I wouldn't implement a feature just to add modularity.

> The current list code is rather monolithic
> and leaves no room for user customization of the commands. (Also, see
> recent discussions about converting between lists and headings
> https://list.orgmode.org/orgmode/877d4luxb8.fsf@localhost/
> https://orgmode.org/list/877d3k70lu.fsf@localhost)

I'm not convinced the first report is a bug in the way list are
handled.  The second is a bug in the way headings are transformed as
list items (leaving footnotes in a poor state).  If more modularity
helps fixing these edge cases, then why not.

> Even if we do not provide "canceled" items in lists, having an
> infrastructure to customize list commands better will be a good thing to
> have.

Of course, I guess you can think of useful customization of list
commands -- perhaps that what we should think about first: would it be
a good thing to allow customization of list commands? what use-case?

2 cts,

-- 
 Bastien

Re: [External] : Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Bastien Guerry]

Ihor Radchenko  writes:

> I am leaning towards removing `this-command' check, unless there are
> important reasons to keep it.

Yes, please go ahead.

-- 
 Bastien

Re: org-assert-version considered harmful

[Bastien]

Ihor Radchenko  writes:

> Then, I am inclined towards easing the version check to (org-version)
> instead of (org-git-version).

FWIW strong +1 here.

-- 
 Bastien

Re: [PATCH] babel output seems to drop anything before % (in session)

[Bastien Guerry]

Ihor Radchenko  writes:

> May you clarify if we are following the FSF copyright assignment rules
> for test?

Yes, we should.  Tests are just source code.

-- 
 Bastien

Re: [PATCH] babel output seems to drop anything before % (in session)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Applied onto main via a35d16368.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a35d163685908386833a3d549ed110931bf3915a
>
> I did not do anything with Daniele's patch because it requires FSF
> copyright.

Bastien,

If I recall correctly, our tests are not all contributed by people with
FSF assignments even for non-tiny contributions.

May you clarify if we are following the FSF copyright assignment rules
for test?

-- 
Ihor Radchenko,
Org mode contributor,
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: IM dev discussions?

[Jean Louis]

* Tim Cross  [2022-09-24 05:10]:
> messenger is probably just to IM with their parents!). From their
> perspective, FB is what their parents use and email is what their
> grandparents use! No way will they use a mail list.

That may be the trend within a generation.

Though there are interest groups and when interest is high
enough, people will open email to enter into the group.

That was the reason to open up those other communication lines
- the interest.

-- 
Jean

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

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

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Jean Louis]

* Ihor Radchenko  [2022-09-21 11:15]:
> The disadvantage of IRC is absence of message history.
> Without history, small-sized channels like I am proposing (dedicated to
> Org mode devs) are not very useful. We live in different time zones and
> countries.

>From Org master view point, every message shall be
referencable to be usable for future as part of the knowledge
base.

E-mails are very referencable, and mailing list too.

For IRC, there are ways to record history, and I am sure that
such history may be recorded with referencable hyperlinks.

Look at this example from Guix IRC channel:
https://logs.guix.gnu.org/

It is irrelevant and also natural that we are in different
time zones and countries. System administrator may decide the
reference time zone.

-- 
Jean

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

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

Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Juan Manuel Macías]

Hi, Ihor, sorry for the late reply,

Ihor Radchenko writes:

> Having read the available replies in this thread, I am thinking of the
> following:
>
> 1. Instead of explicit prefix and suffix, we can unify extra text around
>the exported Org element to a template:
>
> * headline
> :PROPERTIES:
> :ATTR_BACKEND: :export_template "\begin{myenv}\n%s\n\end{myenv}"
> :ATTR_BACKEND+: "The %%s instances are replaced by the exported element"
> :ATTR_BACKEND+: (concat "arbitrary sexp, the exported element is bound to: " 
> *this*)
> :ATTR_BACKEND+: babel_block_name(exported=*this*)
> :ATTR_BACKEND+: "the property lines are concatenated with \" \" (space),"
> :ATTR_BACKEND+: "just like the usual approach in `org-export-read-attribute'"
> :END:

I really like this approach and I would buy it. On the one hand, if I
understand correctly, it's a universal solution that doesn't depend on a
particular backend (although, to be honest, I don't see much use for
this beyond LaTeX: maybe in HTML). And, on the other hand,
`:export_template' is an attribute that can be, as you say, very
versatile. With this, in my opinion, it would no longer be necessary to
define two 'pre' and 'post' attributes.

I imagine the value of ATTR_BACKEND (would quotes be necessary?) could
be easily converted to a plist, with code borrowed from
`org-export-read-attribute':

(:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} ... etc. ...")

> #+ATTR_BACKEND: :export_template "can also work on non-headings"
> Paragraph.

In this case I would not see it necessary, IMHO. For simple things (of
the begin/end style) there are the special blocks. And for more complex
pre- and/or post- code we have export blocks and export snippets. Since
there is no heading involved here, there would be no danger of the
pre-code leaving with the content of the previous header.

Best regards,

Juan Manuel 

-- 
--
--
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: Opening of links

[Max Nikulin]

On 23/09/2022 21:49, Guillaume MULLER wrote:


- My OS settings are configured so that PDFs are opened in Evince. I 
configured this with "xfce4-settings-manager > Default Applications" 
(which runs "xfce4-mime-settings" under the hood) and it can be verified 
with "xdg-open test.pdf" or by opening Thunar and clicking on "test.pdf".


I would name it desktop environment configuration since OS may have more 
settings and it is your issue.


These settings likely alters ~/.config/mimeapps.list
https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html
"Association between MIME types and applications"

Unfortunately Emacs does not support this part of XDG specs, so there 
are no ready to use functions to work with .desktop files and MIME 
associations. You may add entries calling xdg-open for file types you 
wish to the `org-file-apps' custom variable.


   So, where in the world does org-mode/Emacs finds that it should use 
Calibre instead of Evince?


You may have mailcap configuration where Calibre has higher priority 
than Evince, check /etc/mailcap
RFC 1524. A User Agent Configuration Mechanism For Multimedia Mail 
Format Information

https://www.rfc-editor.org/rfc/rfc1524.html

Emacs has limited support of mailcap and it is used by Org mode. 
Besides system configuration, Emacs has a set of predefined association. 
Unfortunately the latter is broken in Emacs-27, see

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40247
#40247 - 27.0.90; mailcap-mime-data erased when parsing mime parts - GNU 
bug report logs


- Now, I would like to circumvent this global OS behavior, so that Emacs 
itself would be used specifically to open PDF links in files I open in 
Emacs. When I was using Vanilla Emacs, I was advised to use pdf-tools, 
and given a config that was working. I translated that into my DoomEmacs 
config.org as follows:

   (use-package! pdf-tools
     :magic ("%PDF" . pdf-view-mode)
     :config
   (pdf-tools-install :no-query)
     )
   But apparently it does not override org's (default) behavior of 
opening PDF file with external tools.


The code of `org-open-file' is tricky. You may instrument this function 
for debugging and step through it to realize what actually happens. 
Maybe pdf-tools vs. doc-view mode choice is controlled by `auto-mode-alist'.


Concerning external viewer configuration, you may adapt for Evince the 
following approach:
Max Nikulin. Re: Org mode links: Open a PDF file at a given page and 
highlight a given string. Sat, 3 Sep 2022 20:00:47 +0700. 
https://list.orgmode.org/tevj61$17d8$1...@ciao.gmane.io

Re: [BUG] Face attribute customization is ignored [9.5.5 (9.5.5-gbe2246 @ /home/dav/.emacs.d/straight/build/org/)]

[David Vicente]

On 24/09/22 02:58, Ihor Radchenko wrote:

Yes, it does. Just set it to nil, and you will be good to go.



Won't that have other effects?

Re: refresh not working for org-mode from git

[Colin Baxter]

The solution is to use `make autoloads'. I suppose that should have been
obvious to me at the beginning. After git pull (`+' in vc-dir) the
working recipe is:

1. rm *.elc
2. Update in org-mode buffer using C-c C-x !
3. make clean
4. make autoloads
5. Check update org-mode via C-c C-x!
6. make
7. Check update org-mode again via C-c C-x!

Some of these steps might not be necessary. I will experiment.

Thank you all again for your help.

Best wishes,

Colin.

Re: [PATCH] Babel evaluation: location and timing information (v2)

[Timothy]

Hi All,

I’ve now resolved all the documentation issues Ihor raised, and since there were
no other concerns raised, I’ve just pushed this as
e8a797e1437d7aef2ce414694d2b642683f79976.

All the best,
Timothy

Re: refresh not working for org-mode from git

[Colin Baxter]

Dear Ithor,

> Ihor Radchenko  writes:


> Colin Baxter  writes:
>> Recently, if I use C-c C-x ! to refresh org-mode after a git
>> pull, I get an error. I then have to close down emacs and launch
>> again. This rather defeats the object of C-c C-x !. This appears
>> to have happened only recently

> Does it help if you run make after git pull?

I will certainly try that and miss out `make clean', at least in the
first round. As I said in the email to Tim, I will try various
combinations in the build process.

Thank you for your reply.

Best wishes,

Colin.

Re: refresh not working for org-mode from git

[Colin Baxter]

Thank you for your detailed reply.

> Tim Cross  writes:

> Colin Baxter  writes:

>> Recently, if I use C-c C-x ! to refresh org-mode after a git
>> pull, I get an error. I then have to close down emacs and launch
>> again. This rather defeats the object of C-c C-x !. This appears
>> to have happened only recently

- snip -

> I wasn't aware that command even existed. However, I suspect it
> will cause issues in your use case. I'm not sure it is a good
> command to actually have given the complexities associated with
> getting a clean org build.

> In many cases, you may not run into issues - especially if you do
> a git pull frequently. However, I can see various scenarios which
> will lead to inconsistent builds. I suspect the error you are
> seeing is the result of recent work to try and identify builds
> which are likely to result in an inconsistent 'mixed' version
> build.

That could well be the case here because the technique used to work up
until quite recently (~2 weeks)

> Detecting such scenarios is difficult and relies on a
> number of heuristics, one of which is to flag a problem if the
> loaded version and the target build version don't match.

> A lot would depend on how you build (re-compile) org mode after
> doing a git pull. If you compile it in a separate Emacs instance,
> you should have less issues and reloading after the build will
> likely work. However, if your trying to build org mode within the
> running Emacs where you have already loaded org mode, I suspect
> you will run into issues. You have a slight 'chicken and egg'
> issue and will run into similar issues as the common mixed build
> problems.

Normally, I use `M-x vc-dir' to update from git, then `M-x compile'
followed by `make clean' and `make'. Finally, update org-mode in the
same emacs with an org-mode buffer present. As I said, it used to work
well. 

> One thing which might work would be to ensure you run the reload
> command with the option to load from uncompiled sources BEFORE you
> run the build process and then re-run the load command after the
> build (loading compiled versions this time).

Yes, I will try that. And I will also ring all the other changes to see
what happens --- if anything. 

> I have no idea how things might break given the new native
> compilation modes in Emacs. I suspect it will cause all sorts of
> issue with your workflow.

I have avoided problems here by not using native compilation. I did try
it once in the past, but I didn't think it was worth the candle since
frankly I didn't notice any change in emacs performance, possibly
because I only do simple things with emacs.

> Personally, I always update org in a fresh instance of Emacs
> (before any org functionality is loaded) and I would always
> restart Emacs after updating a major packages like org mode. I'm
> not sure why we have the reload command - I suspect it may be a
> hang over from earlier attempts to work around the mixed build
> problem. I do suspect that given new native compilation modes and
> the additional complexity ths can cause, combined with increasing
> org mode complexity, the notion of being able to pull down a new
> version, build and reload it within one emacs instance is perhaps
> flawed or at the very least, is more complex than just forcing a
> reload of org *.elc files.

Indeed. Emacs seems to have became a rather complex beast in recent
years. Perhaps it was ever thus.

Best wishes,

Colin.

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Milan Zamazal]

> "TC" == Tim Cross  writes:

TC> At any rate, at this point, I suspect this is something best
TC> handled in individual configurations rather than attempting to
TC> impose a specific interpretation on everyone. If someone needs
TC> help to write a simple command to 'toggle' checkbox
TC> cancellation, I'm sure asking here will get some assistance.

To have it well integrated, at least the following functionality is
needed:

- To change to and from the canceled state.

- To clear all the list items statuses.

- Making all the related functionality (blockers, agenda, …) to
  recognize when a task list with canceled items is finished.

- Making it well working with things like org-modern.

It’s fair to say the functionality is not suitable for implementation in
Org for some reason (too complicated, unclear how to do it properly,
almost nobody needs it, …) but let’s not pretend it’s something that can
be added to an individual configuration easily.  Not that the above
couldn’t be implemented privately but the effort would be significant
and the hack would be ugly (modifying org-ctrl-c-ctrl-c? uh) and
non-portable (different markups by different users).  My Org
configuration is already cluttered enough and I rather keep living
without this functionality than polluting it with additional hacks.

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: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Timothy]

Hi Bastien,

> IMHO if someone with UX/UI experience can/wants to interview real Org
> newcomers, that will help us a lot for deciding about such tiny changes.

Unfortunately, it can be quite hard to find such people on the ML etc. (funny
about that ).

For what it’s worth, when doing the original website re-design I went to some
effort to get the thoughts of people who don’t use Org to make sure it did a
decent job communicating the essentials.

With regards to the current banner, I’m inclined to remove the report bug text:
having that as well as the badge-link is simply confusing, and the badge-link to
the feedback page is better.

We can also add a source code badge using the git icon and linking to
, and I’d then be 
inclined
to remove the “Repository …” text for similar reasons.

All the best,
Timothy

Re: IM dev discussions?

[Ihor Radchenko]

Mark Barton  writes:

>> You will likely find more young people
>> who use Emacs and org will also use email more, but I don't know if that
>> is because the types of people attracted to Emacs and org mode are also
>> the types of people more attracted to email for comms.
>
>
> My trend has been moving from GUI to the benefit that text based solutions 
> provide: reproducibility, version control, and documentation. 
> In my case, email is much easier to extract into my task management system 
> than most IM type solutions. IM is good for short conversations, but really 
> has a problem with organizing more historic data that may be needed for much 
> tougher topics that cannot be answered in a single session. Slack threads 
> really drive me crazy, because I have a hard time finding them again after a 
> day or so. This is where I use DEVONthink to associate different forms of 
> data into the related projects and use DEVONthink links in org mode for my 
> notes and task management.

Come on. We are talking about Org mode and Emacs.
Just load ol-irc.el and enjoy links to past conversations ;)
Matrix client for Org will likely have Org link support in future as
well.

And yes, you can bridge Slack to IRC/Matrix.

-- 
Ihor Radchenko,
Org mode contributor,
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: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Hi Timothy,

Timothy  writes:

> I think we’d want people to see this, and so I’d actually be inclined to make
> the “bug report” button link to this page, and the feedback button just be a
> `mailto:' link.

Done!

> For what it’s worth, I personally consider stuffing lines of “important!” text
> into that “what is Org?” banner ultimately counterproductive. I think it fails
> to provide the information with enough context (e.g. `M-x 
> org-submit-bug-report
> RET' doesn’t provide the information provided on the Feedback.html page), and 
> it
> also muddies the structure of the page while making it appear more cluttered.

IMHO if someone with UX/UI experience can/wants to interview real Org
newcomers, that will help us a lot for deciding about such tiny changes.

Best,

-- 
 Bastien

Re: IM dev discussions?

[Ihor Radchenko]

Timothy  writes:

> I find that very interesting to hear. It reminds me that the bcachefs matrix
> room (which I hang out in),which has a Jitsi widget. Over there it seems that
> occasionally the lead developer and the main other contributor seem to hang 
> out
> there while working on the project.
>
> Doing something similar for Org development is an interesting idea. Something
> similar probably could be set up with the Org room, or a dedicated Org-dev 
> room

This may be interesting, but it requires at least two participants to
get the discussion going.

> (I’m aware of Bastien’s thoughts on wanting development and help to not be
> separated, but while I like the idea of them living in the same space, I’m
> personally a big fan of categorisation. For instance, we could make an 
> org-mode
> space with a few different rooms: org-dev, org-help, org-showcase, org-chat,
> etc.).

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

-- 
Ihor Radchenko,
Org mode contributor,
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: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Hi Max,

Max Nikulin  writes:

> "Install from ELPA" without "GNU".

Fixed, thanks.

-- 
 Bastien