Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Ihor Radchenko]

Tim Cross  writes:

> If you or others want to look at the 404 page issue, please do so. For
> right now, I'll just do a basic 404 page which Bastien can install
> easily. If you or others come up with something more sophisticated, it
> can be used to replace the simple basic version, otherwise we can
> revisit this later if necessary. 

+1
Having a simple 404 page is already an improvement.
There is no urgent need to prioritize further complexities just yet.
At least, there is no need to distract Tim from doing much more
important job of other WORG improvements.

If someone else is willing to allocate time and look into this issue,
feel free to reply here. We can then arrange access to the relevant
configs.

Best,
Ihor

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Tim Cross]

Max Nikulin  writes:

> On 05/07/2022 09:54, Tim Cross wrote:
>> Max Nikulin writes:
>>> Bastien. Re: Possible bug report: URL capitalization in online manual. Mon, 
>>> 10 Feb 2020
>>> 07:48:21 +0100 https://list.orgmode.org/874kvzdjka@gnu.org/
 I've now installed the rewrite rules on the server and all these links
 are redirecting correctly. Given the amount of Org documentation links
 living out there, that's really a good idea.
>
> Tim, is there any chance that Bastien forgot to send you some included file 
> for nginx
> configuration? However, the site ignores this file even it exists somewhere 
> on filesystem.
>

anything is possible. In a 'standard' nginx configuration, you would
typically have all the config related to s specific site in one
file. However, that is just convention, not a rule. 

>>> Tim Cross:
 At this point, my vote is to just do a basic updated 404 page that
 points to the index.html page for orgmode.org
>>>
>>> For the manual and for the guide directories I still consider links to the 
>>> table of
>>> contents (or even full table of contents) on 404 pages as a better variant.
>> I don't really care what specific page is linked to - just that we keep
>> it simple and have a link for an initial quick fix. Only reason I
>> mentioned the index.html page is that it has links to everything - worg,
>> git, manual, mail list etc. It is possible that people get to 404 via
>> links other than to the manual.
>
> I do not have ready to use snippet, but I am sure it should be possible to 
> set specific
> 404 pages for particular directories like the manual and the guide. Of 
> course, these
> pages, besides links to table of contents, may have another link to 
> index.html or a
> navigation header shared with other pages on the site.

Many things are possible. However, I'm trying very hard not to be overly
distracted by this issue, which I think is fairly insignificant. My
objective is to do as little as possible at this time because I want to
get back to cleanup of worg. It is quite possible that work will also
have some influence on the rest of the org web space. 

If you or others want to look at the 404 page issue, please do so. For
right now, I'll just do a basic 404 page which Bastien can install
easily. If you or others come up with something more sophisticated, it
can be used to replace the simple basic version, otherwise we can
revisit this later if necessary. 

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Max Nikulin]

On 05/07/2022 09:54, Tim Cross wrote:

Max Nikulin writes:

Bastien. Re: Possible bug report: URL capitalization in online manual. Mon, 10 
Feb 2020
07:48:21 +0100 https://list.orgmode.org/874kvzdjka@gnu.org/

I've now installed the rewrite rules on the server and all these links
are redirecting correctly. Given the amount of Org documentation links
living out there, that's really a good idea.


Tim, is there any chance that Bastien forgot to send you some included 
file for nginx configuration? However, the site ignores this file even 
it exists somewhere on filesystem.



Tim Cross:

At this point, my vote is to just do a basic updated 404 page that
points to the index.html page for orgmode.org


For the manual and for the guide directories I still consider links to the 
table of
contents (or even full table of contents) on 404 pages as a better variant.


I don't really care what specific page is linked to - just that we keep
it simple and have a link for an initial quick fix. Only reason I
mentioned the index.html page is that it has links to everything - worg,
git, manual, mail list etc. It is possible that people get to 404 via
links other than to the manual.


I do not have ready to use snippet, but I am sure it should be possible 
to set specific 404 pages for particular directories like the manual and 
the guide. Of course, these pages, besides links to table of contents, 
may have another link to index.html or a navigation header shared with 
other pages on the site.

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Tim Cross]

Richard Stallman  writes:

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>
> However, if the web pages for a GNU package were to suggest people buy
> train tickets via internet, that would creste a moral conflict:
> promoting, in a GNU web site, the very practices that the GNU Project
> aims to put an end to.
>
> This is what we have rules about.  Not rules about whether you or
> anyone can run a nonfree program.  But rules, yes, against publicly
> legitimizing, or steering people toward using, nonfree programs, in
> direct connection with the GNU Project.
>
> You can say whatever you like if you do it in another context with no
> visible relation to GNU.  The point is that you shouldn't give the
> wrong idea of where the GNU Project stands on this issue.
>

Richard,

you still have not responded to my question and what was the main point
which started this thread.

How can it be that on one hand, projects are told they cannot have a
link to a means to make a donation which uses non-free software (such as
paypal), but the FSF has exactly that sort of link to obtain donations
for the FSF. Is this not hypocritical? 

As far as I see it, if having a link to paypal for donations is OK for
the FSF, then it is OK for a GNU project (provided the project also
includes wording to the effect we would prefer people use other methods
AND we provide another method, basically do the same as the FSF)

 

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Tim Cross]

Max Nikulin  writes:

> On 05/07/2022 05:37, Tim Cross wrote:
>> Max Nikulin writes:
>>>
>>> However it seems, Bastien earlier configured a set of rewrite rules mapping 
>>> old file names
>>> with more lower case letters to new ones. In my opinion it is the best 
>>> option and it
>>> should be restored. List of files may be committed to git (either Org or 
>>> site) to detect
>>> changes later and to add new mappings when some file disappears.
>> Are you sure about that. There is nothing along these lines in the nginx
>> config file that I can see. Also, my reading following that thread you
>> provided earlier was that Bastien thought the overhead to manage such
>> lists was too high?
>
> Bastien. Re: Possible bug report: URL capitalization in online manual. Mon, 
> 10 Feb 2020
> 07:48:21 +0100 https://list.orgmode.org/874kvzdjka@gnu.org/
>> I've now installed the rewrite rules on the server and all these links
>> are redirecting correctly. Given the amount of Org documentation links
>> living out there, that's really a good idea.
>
> I did not check it that time, so I can not be really sure. The rules might be 
> lost during
> migration to deployment using SourceHut. My expectation is "301 Moved 
> Permanently"
> redirection for obsolete file names.
>
> I do not think, a hundred of redirection rules gives significant overhead. I 
> attributed
> Bastien's "too much" to maintaining documentation for several versions of 
> Org. A part of
> original problem (if I get it correctly) was mix of old files survived from 
> earlier
> versions of the manual and current ones. Certainly removing of outdated files 
> was a proper
> step.
>
> Tim Cross:
>> At this point, my vote is to just do a basic updated 404 page that
>> points to the index.html page for orgmode.org
>
> For the manual and for the guide directories I still consider links to the 
> table of
> contents (or even full table of contents) on 404 pages as a better variant.

I don't really care what specific page is linked to - just that we keep
it simple and have a link for an initial quick fix. Only reason I
mentioned the index.html page is that it has links to everything - worg,
git, manual, mail list etc. It is possible that people get to 404 via
links other than to the manual. 

If you or someone else wants to do something more sophisticated, I'd say
go for it.  In the meantime, I will see if I can put together a default
404 page. However, I think only Bastien has the necessary access to
install it.

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It seems odd that our embrace of software freedom should keep us 
  > from collaborating as fully as we'd like.

It's not odd at all.  As we see various activities pushed into unjust
computing, which requires nonfree software and online dis-services,
remaining free sometimes becomes difficult.  You may have to refuse to
do certsin things "everyone" does.  If one of those things happens to
be useful for working on GNU, that's not surprising as tyranny marches
on.

The GNU Project, as part of the free software movement, condemns those
systems and calls them illegitimate.

How does this relate to what GNU contributors say and do about those
systems?  Mostly it doesn't.  What each contributor privately does
with computers isn't the GNU Project's business.  We have never tried
to make any rules about what computing contributors can or can't use.
But we do have rules about what computing they should promote publicly
in connection with GNU.

For instance, if you want to buy train tickets and maintain your
freedom, you need to pay cash at a station.  If you buy them by
internet, running nonfree JavaScript and identifying yourself, that is
a loss to your freedom, which we consider unfortunate.  But it doesn't
oppose the GNU Project's work, so we don't need rules about that.
It's up to you.

However, if the web pages for a GNU package were to suggest people buy
train tickets via internet, that would creste a moral conflict:
promoting, in a GNU web site, the very practices that the GNU Project
aims to put an end to.

This is what we have rules about.  Not rules about whether you or
anyone can run a nonfree program.  But rules, yes, against publicly
legitimizing, or steering people toward using, nonfree programs, in
direct connection with the GNU Project.

You can say whatever you like if you do it in another context with no
visible relation to GNU.  The point is that you shouldn't give the
wrong idea of where the GNU Project stands on this issue.

Meanwhile, we have a potential solution for donating money: GNU Taler.
It shows promise, for the long term: even national banks are starting
to get interested in it.  (See taler.net.)  But banking systems are
not set up to interact with it today.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Max Nikulin]

On 05/07/2022 05:37, Tim Cross wrote:

Max Nikulin writes:


However it seems, Bastien earlier configured a set of rewrite rules mapping old 
file names
with more lower case letters to new ones. In my opinion it is the best option 
and it
should be restored. List of files may be committed to git (either Org or site) 
to detect
changes later and to add new mappings when some file disappears.



Are you sure about that. There is nothing along these lines in the nginx
config file that I can see. Also, my reading following that thread you
provided earlier was that Bastien thought the overhead to manage such
lists was too high?


Bastien. Re: Possible bug report: URL capitalization in online manual. 
Mon, 10 Feb 2020 07:48:21 +0100 
https://list.orgmode.org/874kvzdjka@gnu.org/

I've now installed the rewrite rules on the server and all these links
are redirecting correctly. Given the amount of Org documentation links
living out there, that's really a good idea.


I did not check it that time, so I can not be really sure. The rules 
might be lost during migration to deployment using SourceHut. My 
expectation is "301 Moved Permanently" redirection for obsolete file names.


I do not think, a hundred of redirection rules gives significant 
overhead. I attributed Bastien's "too much" to maintaining documentation 
for several versions of Org. A part of original problem (if I get it 
correctly) was mix of old files survived from earlier versions of the 
manual and current ones. Certainly removing of outdated files was a 
proper step.


Tim Cross:

At this point, my vote is to just do a basic updated 404 page that
points to the index.html page for orgmode.org


For the manual and for the guide directories I still consider links to 
the table of contents (or even full table of contents) on 404 pages as a 
better variant.

Re: Moving to a literate file for .emacs

[Samuel Banya]

I have a literate Emacs config here that you can look at:
https://github.com/SamuelBanya/SamsEmacs/blob/main/configuration.org
https://github.com/SamuelBanya/SamsEmacs/blob/main/init.el

Take a look at the Emacs config links to other people's 'literate' Emacs 
configs, and you might get some ideas to steal from as well, look under 'Emacs 
Config Links (Custom User Configs, Emacs Distributions, etc.)':
https://apps.musimatic.xyz/webring.html

Also, Uncle Dave's Emacs YouTube tutorial is the best one for making an Emacs 
config based upon a 'config.org' file, would recommend this 100x:
https://www.youtube.com/playlist?list=PLX2044Ew-UVVv31a0-Qn3dA6Sd_-NyA1n

Hope this helps!

Sincerely,

Sam

On Mon, Jul 4, 2022, at 9:44 AM, Stephen Eglen wrote:
> I see many users are switching to using a 'literate programming'
> approach to tangling their .emacs file from an org file.
> 
> Has anyone solved the following problem though?  If I have a file called
> config.org containing:
> 
> * test
> 
> #+begin_src emacs-lisp
>   (defun quick-test ()
> "interactive"
> (* 3 9)
>   )
> #+end_src
> 
> 
> and then in my .emacs file I do:
> 
> (org-babel-load-file "~/config.org")
> 
> quick-test is indeed defined, but when I do C-c f RET quick-test RET it
> takes me to config.el (a tangled file, suitable for computers, not
> humans), rather than config.org.  Is it possible instead to get the
> editor to jump to the definition in config.org?
> 
> Stephen
> 
> 
> 

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Tim Cross]

Max Nikulin  writes:

>
> However it seems, Bastien earlier configured a set of rewrite rules mapping 
> old file names
> with more lower case letters to new ones. In my opinion it is the best option 
> and it
> should be restored. List of files may be committed to git (either Org or 
> site) to detect
> changes later and to add new mappings when some file disappears.


Are you sure about that. There is nothing along these lines in the nginx
config file that I can see. Also, my reading following that thread you
provided earlier was that Bastien thought the overhead to manage such
lists was too high?

I guess we need to wait for Bastien to indicate his preference. I find
things a little challenging as there seems to be a fair bit of
outdated/conflicting information scattered through various files/notes. 

At this point, my vote is to just do a basic updated 404 page that
points to the index.html page for orgmode.org so that users have
something to follow and not a big ugly 404 Not Found. The rest we can
consider later.

[PATCH] ob-latex: Added support for including files with a relative path

[General discussions about Org-mode.]

 Dear list, 

in the attachment you find a proposed patch to support including external files
when exporting a latex source block. Currently this was only possible by using a
:header argument. The problem with this approach is that, files needed to be
included with their absolute path.


My proposed change adds support for a :inputs header argument, which expands te
provided file paths to an absolute path before including them.


Example: 
#+HEADER: :file example.pdf
#+HEADER: :inputs '("./input/preamble.tex")
#+BEGIN_src latex
\begin{tikzpicture}
  \draw[->,custom-style] (-3,0) -- (-2,0)
    arc[radius=0.5cm,start angle=-180,endangle=0] (-1,0) -- (1,0)
    arc[radius=0.5cm,start angle=180,end angle=0] (2,0) -- (3,0);
    \filldraw (-1.5,0) circle[radius=1mm];
    \filldraw (1.5,0)circle[radius=1mm];
\end{tikzpicture}
#+END_src

Expands to 

\documentclass[article]...
\input{absolute/path/to/input/preamble.tex}
\begin{document}
\begin{tikzpicture}
  \draw[->,custom-style] (-3,0) -- (-2,0)
    arc[radius=0.5cm,start angle=-180,endangle=0] (-1,0) -- (1,0)
    arc[radius=0.5cm,start angle=180,end angle=0] (2,0) -- (3,0);
    \filldraw (-1.5,0) circle[radius=1mm];
    \filldraw (1.5,0)circle[radius=1mm];
\end{tikzpicture}
\end{document}
Kind regards,
Bob 

0001-lisp-ob-latex.el-Added-latex-inputs.patch
Description: Binary data

Re: Moving to a literate file for .emacs

[Immanuel Litzroth]

It's possible to let tangling generate comments that will link back to the
literate file where you defined the function.
https://orgmode.org/manual/Extracting-Source-Code.html
See the comment header arg.

Then you could advise the relevant functions that do emacs function lookup
to check whether there's such a "link comment" near the definition and jump
to that instead.

All this is rather hackish and I stopped doing my init files in literate org.
Immanuel

On Mon, Jul 4, 2022 at 4:07 PM Stephen Eglen  wrote:
>
> I see many users are switching to using a 'literate programming'
> approach to tangling their .emacs file from an org file.
>
> Has anyone solved the following problem though?  If I have a file called
> config.org containing:
>
> * test
>
> #+begin_src emacs-lisp
>   (defun quick-test ()
> "interactive"
> (* 3 9)
>   )
> #+end_src
>
>
> and then in my .emacs file I do:
>
> (org-babel-load-file "~/config.org")
>
> quick-test is indeed defined, but when I do C-c f RET quick-test RET it
> takes me to config.el (a tangled file, suitable for computers, not
> humans), rather than config.org.  Is it possible instead to get the
> editor to jump to the definition in config.org?
>
> Stephen
>
>


-- 
-- A man must either resolve to point out nothing new or to become a
slave to defend it. -- Sir Isaac Newton

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Michael Powe]

On 7/4/2022 08:38, Ihor Radchenko wrote:

Timothy  writes:


In this entire 40+ message thread, only two options have been listed (besides
the FSF’s special arrangement) which do not direct people to non-free JS:
Cryptocurrancy
   Which is volatile in value, regional regulation, and
   individual distaste.
Cheques
   Which are a dying (and in some places dead) form of bank transfer
   instruction. It’s already been established that Ihor would face a US$200 
fee
   when collecting a cheque, and over where I am the central bank announced 
in
   2019 that at a point in the near future the “it will be appropriate to 
wind up
   the cheque system”. Last year a neighbouring country stopped offering or
   receiving cheques altogether.

[ ... ]

So, to sum up the situation I’d suggest we pick from the following options:
⁃ Accept the situation isn’t great
⁃ Build/fund a new tool
⁃ Convince an existing tool to be more libera-friendly
⁃ Use the FSF as an intermediary

Asking maintainers not to accept donations (or making it prohibitively
difficult) is not a solution.

I support this statement.


Hello,

Same. This discussion is a classic illustration of making the perfect an 
enemy of the good. In a foot race, the goal is to get across the finish 
line. Similarly, our goal is to get our money where it needs to go. It's 
good to keep that in mind.


Thanks.

mp

--
"Do not neglect to do good, and to share what you have." - Hebrews 13:16a
Michael Powe
Naugatuck CT USA
po...@ctpowe.net

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Max Nikulin]

On 04/07/2022 19:58, Ihor Radchenko wrote:


If JS is the only option it is still better to have it and fall back to
more generic page if JS is not supported. Of course, given that the JS
code is not going to be too complex and not going to require too much
maintenance.


It is possible to perform a kind of fuzzy matching on the server, but I 
am unsure if Bastien wouldn't mind a dynamic 404 page.


The manual and the short guide may have their own 404 pages explaining 
that some page is not available any more and offering table of contents.


However it seems, Bastien earlier configured a set of rewrite rules 
mapping old file names with more lower case letters to new ones. In my 
opinion it is the best option and it should be restored. List of files 
may be committed to git (either Org or site) to detect changes later and 
to add new mappings when some file disappears.

Re: Org and Hyperbole

[Robert Weiner]

Correct.  It uses just C-h h to activate the Hyperbole minor mode and to 
display its keyboard driven minibuffer menu.  This is a normal global key 
binding which you can easily rebind to anything you like.

-- rsw

> On Jul 4, 2022, at 10:44 AM, Fraga, Eric  wrote:
> 
> On Monday,  4 Jul 2022 at 21:09, Tim Cross wrote:
>> It appears that hyperbole now uses C-h h as its menu key. Other C-h
>> bindings appear to be unaffected (you just don't get the old Hello file
>> which you normally have bound to C-h h).
> 
> Ah, that sounds better.  I can definitely manage without easy access to
> the hello file! ;-)
> 
> -- 
> : Eric S Fraga, with org release_9.5.4-605-g0ed0de in Emacs 29.0.50

Re: re-scanning bibliography for org-cite

[Bruce D'Arcus]

On Thu, Jun 9, 2022 at 12:00 PM Fraga, Eric  wrote:
>
> On Thursday,  9 Jun 2022 at 10:34, Bruce D'Arcus wrote:
> > It should take another few days of development and testing before I'm
> > ready to merge it, but it pretty much works now, and any help with
> > code review and/or testing would be much appreciated.
>
> Okay, let me know.  It's easy enough for me to replace 'basic with
> 'citar again!

Took a bit longer than "days," because we ended up making a ton of
other changes, but it's now merged.

The result should be a snappy UI that appropriately adapts to local
buffer context, and updates the cache as needed.

Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

[Sébastien Miquel]

Marking this as resolved on updates.orgmode.org, 2nd try.

|Fixed.|

--
Sébastien Miquel

Re: Customizing org-columns-modify-value-for-display-function to shorten time-stamps in colview

[Mekeor Melire]

2022-07-01 / 20:06 / yanta...@gmail.com:

> Mekeor Melire  writes:
>
> > But it results in empty (nil, I guess) time-stamps being displayed as
> > the current time; and non-nil time-stamps being displayed with the
> > current hour and minute. What's wrong?
>
> Empty time-stamps will be literally empty: "" (that is: empty string).
> (if "" 1 2) will return 1. That's why you got unexpected result.
> You could instead use (if (and value (not (string-empty-p value))) ...)
>
> Best,
> Ihor

thank you very much, ihor. this worked! :)

Re: [BUG] formatting at edges of link

[Tor Kringeland]

Ihor Radchenko  writes:

> All the examples above are not valid links.
> Note that Org link consist of link itself and a description:
> [[link][description]].

I was a bit fast in my explanation.  I mean formatting the description,
of course.

>
> Descriptions will be correctly formatted.
>
> [[https://orgmode.org][/italic/]] should work just fine.

This does not work for me.  "italic" isn't italicized.  But for example

  [[https://orgmode.org][normal /italic/ normal]]
u
works as expected.  To get what I want in the previous example I have to
write

  /[[https://orgmode.org][italic]]/

Re: [PATCH] org-attach-attach: fix symlinks

[Matt Price]

sorry I've been MIA -- I have been swamped at work and stopped following
the list!

Thank you for this, but more generally for the huge amount of work you put
in to improving org for everyone. The last year or so has seen such huge
improvements for me -- I am immensely grateful to everyone.

On Mon, Jul 4, 2022 at 9:01 AM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > Attaching an alternative patch. It makes use of make-symbolic-link
> > arguments.
>
> Applied onto main via 13a3dbcc9.
>
> Best,
> Ihor
>

Re: Org and Hyperbole

[Fraga, Eric]

On Monday,  4 Jul 2022 at 21:09, Tim Cross wrote:
> It appears that hyperbole now uses C-h h as its menu key. Other C-h
> bindings appear to be unaffected (you just don't get the old Hello file
> which you normally have bound to C-h h).

Ah, that sounds better.  I can definitely manage without easy access to
the hello file! ;-)

-- 
: Eric S Fraga, with org release_9.5.4-605-g0ed0de in Emacs 29.0.50

Re: [BUG] wrapping links

[Tor Kringeland]

Ihor Radchenko  writes:

> Could you please elaborate?
> The above link (if changed to more correct [[https://orgmode.org][this
> link looks ugly]] will be exported without the newlines and extra
> spaces.

Yes.  I don't mean in export, but in org-mode itself.  Since the second
line in the example starts with leading spaces, those spaces will be
formatted as part of the link (with a blue nuderline).  So Org correctly
recognizes multi-line links, it's just that the formatting in this case
is ugly.

#+begin_example
- [[https://orgmode.org][this
  link looks ugly]]
#+end_example

The same happens with underline formatting.  With bold or italic
formatting it does not happen because no visible change to spaces is
made.  For example

#+begin_example
  _formatting continues into the
  second line_
#+end_example

looks ugly as well.  Both because the leading spaces on the second line
are formatted and (arguably) because the newline at the end of the first
line is formatted as an underline as well (like a space).

Re: [more absurd]

[Uwe Brauer]

>>>writes:

> On Mon, Jul 04, 2022 at 09:42:01AM +0200, Uwe Brauer wrote:
> [...]

>> That is the first time I remember that on this list, questions of the
>> foundation of mathematics are discussed 

> Such things happen :)

>> Back to the point, maybe I am too conservative, but I would include 0
>> within the natural numbers,

> If you really were, you wouldn't. Peano himself didn't ;-)

Well, as far as I remember my university first course, he did, and
according to wikipedia https://en.wikipedia.org/wiki/Peano_axioms or you
mentioned German

https://de.wikipedia.org/wiki/Peano-Axiome

He did!

But I have no access right now to his original work
>> and the example I started with, needs to
>> cover that case (student marks range between 0 to 10 both included), so
>> sorting should work (for me) in that case.

> See? I went to school in Spain, so I know about that 0..10 scale.
> But then I went to school in Germany, so I also know about the
> 6..1 scale. Go figure :)

Well, but Germany switched to the 0-15 scale a long long time ago, at least for 
high school


>> I don't see, so far any benefit for not considering 0 in that sorting
>> process.

> But your concrete problem isn't a sorting process at all, just a
> conversion process: empty space gets translated to zero. As someone
> else found out in this thread.

Ah right, ok so that seems then a but to me, the whole point of my
sorting is to find empty fields.

Uwe 

-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 


smime.p7s
Description: S/MIME cryptographic signature

Moving to a literate file for .emacs

[Stephen Eglen]

I see many users are switching to using a 'literate programming'
approach to tangling their .emacs file from an org file.

Has anyone solved the following problem though?  If I have a file called
config.org containing:

* test

#+begin_src emacs-lisp
  (defun quick-test ()
"interactive"
(* 3 9)
  )
#+end_src


and then in my .emacs file I do:

(org-babel-load-file "~/config.org")

quick-test is indeed defined, but when I do C-c f RET quick-test RET it
takes me to config.el (a tangled file, suitable for computers, not
humans), rather than config.org.  Is it possible instead to get the
editor to jump to the definition in config.org?

Stephen

Re: [BUG] @* in [cite/nocite:@*] is a valid special LaTeX bibliography key, but it is highlighted using "error" face by oc.el (was: [PATCH] oc-csl: Add support for nocite citations)

[Bruce D'Arcus]

On Mon, Jul 4, 2022 at 8:57 AM András Simonyi  wrote:
> It seems to me that "*" as a key is sophisticated enough that if we have to 
> make a decision
> about the default fontification then it is better to err on the side
> of supposing that a user using it knows what they are doing,

+1

Bruce

Re: [more absurd]

[Martin Steffen]

>writes:


> About the cultural thing... you seem to be a zero-counter (as I

I guess I am, by maybe have not been a zero-counter from the start, but
a 1-counter. I vaguely remember to have learnt (at school? beginning at
university?) that ``THE natural numbers'' (the ones Kronecker claimed to
have been created by God) start with $1$. There are referred to by
$\mathbb{N}$, and then there's also some versions, written
$\mathbb{N}_0$ (THE natural numbers ``extended'' by 0), they can be
handy too, sometimes.


>From a constructivistic point of view (and as a computer scientist, one
is obliged to have a constructivist view), for me 0 belongs to the most
natural way of defining natural numbers.

The fact that some theorems or facts are stated better this way or the
other is minor (as long as it's not that the vast majority of math on
Nats gets simpler without 0 (or with 0). One would also not work with
Nats starting at two like Nat ={2, 3,4,...}, for the extravagant
advantage to avoid stating clumsily a special-case condition ``a prime
number is a natural number larger or equal 2 and only divisible by 1 or
itself'' (if one thinks 1 and 0 are better not included in the prime
numbers, as most would do).

Constructing the nats from first principles seems to me a Nat is either
0, or the successor of a nat (succ n). Also for lists (and in complete
analogy): Lists are either empty () or built from cons-ing an element to
a list.

An analogous construction would of course also work using 1 as base
case resp. a one-element list as basic constructor. But it ``feels''
less natural for me in the meantime.


[talking about programming and data structures: while I think from a
practical (and aesthetic) point of view, lists should include the empty
list, and not start with lists of length 1 (likewise that functions
should be allowed to have a 0-length input parameter list), I found it
interesteding that _internally_, lists and similar data structures are
often usefully implemented with some ``sentinel'' node, i.e., the empty
lists is represented by some ``dummy cell'' in memory (not by
``nothing''), and a list of length n has additionally one such dummy
cell at the end, say, to make walking through the list, resp. checking
for the end more smooth and uniform, sometimes.]















> am, too): there, too, I think that "our" position isn't in any way
> "better" -- some theorems look better this way, some that way;
> some inductions are easier to start at 1, some at 0.

> Cheers -- t

Re: [PATCH] org-attach-attach: fix symlinks

[Ihor Radchenko]

Ihor Radchenko  writes:

> Attaching an alternative patch. It makes use of make-symbolic-link
> arguments.

Applied onto main via 13a3dbcc9.

Best,
Ihor

Re: when does :cache not cache?

[Ihor Radchenko]

Ihor Radchenko  writes:

> The patch introduces a new functionality to ob-core.el allowing more
> stable temporary file names. I am not sure if my implementation is the
> best way to solve the problem, so comments are welcome.

Applied onto main via 080462198.

Best,
Ihor

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Ihor Radchenko]

Tim Cross  writes:

>> This sounds like a good idea.
>> I am not sure if it is feasible, but the 404 page could also provide
>> suggestions based on similar existing links. I have something like
>> https://list.orgmode.org/orgmode/83tu89b7pr@gnu.org/ in mind.
>
> Sorry, I don't understand the relevance of that link (it seems to be to
> a discussion about GC size?).

The link I provided is pointing to a thread, which is not in Org ML.
Yet, list.orgmode.org is able to detect messages in other mailing lists
:)

For me, the page in the link looks like:

Message-ID: <83tu89b7pr@gnu.org>
found in another inbox:

https://yhetil.org/emacs-devel/83tu89b7pr@gnu.org/

Perhaps try an external site:

https://marc.info/?i=83tu89b7pr@gnu.org
https://www.mail-archive.com/search?l=mid=83tu89b7pr@gnu.org
nntp://news.gmane.io/83tu89b7pr@gnu.org
https://lists.debian.org/msgid-search/83tu89b7pr@gnu.org
https://docs.FreeBSD.org/cgi/mid.cgi?db=mid=83tu89b7pr@gnu.org
https://www.w3.org/mid/83tu89b7pr@gnu.org
http://www.postgresql.org/message-id/83tu89b7pr@gnu.org
https://lists.debconf.org/cgi-lurker/keyword.cgi?doc-url=/lurker=en.html=id:83tu89b7pr@gnu.org

> Yes, you should be able to use JS to examine the URL which failed and
> transform it by making the first character of each word in the url
> filename upper case. Essentially do what was proposed with the rewrite
> rules, but which wouldn't have the same performance hit as it would only
> be triggered when incorrect URLs were entered and wold run in the browser.
>
> The only downside is it wouldn't work with non JS based browsers (like
> eww). If the server had support for server side scripting (perl, ruby,
> etc) it could be done so that it would work with all browsers by doing
> the rendering server side.

If JS is the only option it is still better to have it and fall back to
more generic page if JS is not supported. Of course, given that the JS
code is not going to be too complex and not going to require too much
maintenance.

Best,
Ihor

Re: [BUG] @* in [cite/nocite:@*] is a valid special LaTeX bibliography key, but it is highlighted using "error" face by oc.el (was: [PATCH] oc-csl: Add support for nocite citations)

[András Simonyi]

Dear All,

On Mon, 4 Jul 2022 at 14:27, Ihor Radchenko  wrote:

> András Simonyi  writes:

> I do not agree.
> If someone sets up natbib for latex export and basic for other formats,
> "*" will not be correctly exported in those other formats (because basic
> does not support @* syntax) - something fontification should better
> highlight for the user.

yes, the basic export processor is, well, basic in certain respects.
But then this is the case with more advanced citation styles, e.g.
"locators" as well, which is supported by the biblatex export
processor and not by "basic"; nonetheless, the "basic" activation
processor's fontification doesn't signal "error" if someone uses the
"locators"  style, in fact it doesn't check whether a used citation
style is supported by any of the processors. It seems to me that "*"
as a key is sophisticated enough that if we have to make a decision
about the default fontification then it is better to err on the side
of supposing that a user using it knows what they are doing, Of
course, others' mileage may vary, and it'd be very interesting to hear
other opinions.

best wishes,
András



> Also, are there any similar non-key constructs in latex in addition to "*"?
>
> Best,
> Ihor

Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

[Sébastien Miquel]

Marking this as resolved on updates.orgmode.org.

|Fixed.|

--
Sébastien Miquel

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> I do have an alternative suggestion which may help. Given that the
>> 'broken' URLs are actually from external links to old documentation
>> which has been removed, what we could do is create a more informative
>> 404 page. Once users are on the 'real' site, the case issue does not
>> exist. It is only a problem due to outdated URLs on external sites like
>> stack overflow. Instead of just saying 404 Not Found, the page could say
>> the requested URL was not found and is likely a link to old outdated doc
>> documentation. The page could include a link to the main orgmode
>> page. This would be a fairly simple 'fix' that would improve user
>> experience to some degree. 
>
> This sounds like a good idea.
> I am not sure if it is feasible, but the 404 page could also provide
> suggestions based on similar existing links. I have something like
> https://list.orgmode.org/orgmode/83tu89b7pr@gnu.org/ in mind.
>

Sorry, I don't understand the relevance of that link (it seems to be to
a discussion about GC size?).

Yes, you should be able to use JS to examine the URL which failed and
transform it by making the first character of each word in the url
filename upper case. Essentially do what was proposed with the rewrite
rules, but which wouldn't have the same performance hit as it would only
be triggered when incorrect URLs were entered and wold run in the browser.

The only downside is it wouldn't work with non JS based browsers (like
eww). If the server had support for server side scripting (perl, ruby,
etc) it could be done so that it would work with all browsers by doing
the rendering server side.

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Ihor Radchenko]

Timothy  writes:

> In this entire 40+ message thread, only two options have been listed (besides
> the FSF’s special arrangement) which do not direct people to non-free JS:
> Cryptocurrancy
>   Which is volatile in value, regional regulation, and
>   individual distaste.
> Cheques
>   Which are a dying (and in some places dead) form of bank transfer
>   instruction. It’s already been established that Ihor would face a 
> US$200 fee
>   when collecting a cheque, and over where I am the central bank 
> announced in
>   2019 that at a point in the near future the “it will be appropriate to 
> wind up
>   the cheque system”. Last year a neighbouring country stopped offering or
>   receiving cheques altogether.

You did not list direct bank transfers.
They should be doable given that a person looking to donate contuct us
via email to obtain transfer info. Though I am not 100% sure how it
holds from the point of view of privacy and suceptibility to scam.

> I think it’s fair to say these are not viable options, leaving accepting
> donations via Liberapay, Stripe, etc. as the only practical options. Until 
> then,
> let’s not allow perfect to be the enemy of good.
>
> As it happens though, Stripe seem to have open sourced all of their frontend
> code — all of these repos  seem to be MIT-licensed.
> Perhaps we just need to get this to be compatible with liberajs?

If Stripe is licensed under GNU-compatible license, it is great news and
the whole problem appears to be solved. There is no requirement that
every appropriately licensed JS code is also correctly recognized
by liberajs.

> So, to sum up the situation I’d suggest we pick from the following options:
> ⁃ Accept the situation isn’t great
> ⁃ Build/fund a new tool
> ⁃ Convince an existing tool to be more libera-friendly
> ⁃ Use the FSF as an intermediary
>
> Asking maintainers not to accept donations (or making it prohibitively
> difficult) is not a solution.

I support this statement.

Best,
Ihor

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Ihor Radchenko]

"Thomas S. Dye"  writes:

> Yes, your Chinese bank charges exorbitant fees for cashing US 
> checks.  That won't work.
>
> It seems odd that our embrace of software freedom should keep us 
> from collaborating as fully as we'd like.

I think that the last resort not involving non-free software is a bank
transfer (if your bank allows performing bank transfers without running
software*).

Best,
Ihor

* Last time, my bank still forced me to use their bank app even when I
  went to the bank branch and tried to do a bank transfer.

Re: [BUG] Inline src blocks do not work for LaTeX [9.5.4 (release_9.5.4-3-g6dc785 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Timothy  writes:

> Hi Ihor,
>
> Two comments on this:
>
>> The inline src block defaults should probably be documented. See
>> 
>> Patches are welcome.
>
> I think it would also be nice if one could set inline header args with
> `#+properties' and `:PROPERTIES:' in the same manner as block header args.

AFAIK, it is already the case. Only org-babel-default-inline-header-args
is distinct for the inline src blocks. Buffer-local header-args
property, if set, does apply to both inline and normal src blocks.

>> The confusing behavior about exporting results for code blocks when the
>> corresponding ob-*.el is not loaded is trickier. We had a related
>> discussion on this topic in
>> 
>> Though I am not sure how we can improve the situation. Ideas are
>> welcome.
>
> One of the nice things Doom does with Org is add lazy-auto-loading of ob-*
> backends. I’ve been poking Henrik for a while to upstream this (and a bunch of
> other things) to Org, and am tentatively hopeful it will happen some time this
> year.

Sounds promising :)

Best,
Ihor

Re: [BUG] @* in [cite/nocite:@*] is a valid special LaTeX bibliography key, but it is highlighted using "error" face by oc.el (was: [PATCH] oc-csl: Add support for nocite citations)

[Ihor Radchenko]

András Simonyi  writes:

> I think that the problem with simply adding one or more new activation
> processors with different fontification for the "*" key is that Org
> has no way of knowing (at least for sure) which export processor will
> be used for a exporting a certain Org buffer, since it can depend on
> the chosen export backend (see the variable
> org-cite-export-processors). E.g., org-cite could be set up to use the
> "natbib" processor for "LaTeX" export and the "basic" processor for
> any other format.  I think that it'd be more in the spirit of the
> "basic" activation processor to be more permissive and not treat "*"
> as an error, similarly to citation styles not supported by the "basic"
> export processor but supported by others.

I do not agree.
If someone sets up natbib for latex export and basic for other formats,
"*" will not be correctly exported in those other formats (because basic
does not support @* syntax) - something fontification should better
highlight for the user.

Also, are there any similar non-key constructs in latex in addition to "*"?

Best,
Ihor

Re: [more absurd]

[tomas]

On Mon, Jul 04, 2022 at 09:42:01AM +0200, Uwe Brauer wrote:

[...]

> That is the first time I remember that on this list, questions of the
> foundation of mathematics are discussed 

Such things happen :)

> Back to the point, maybe I am too conservative, but I would include 0
> within the natural numbers,

If you really were, you wouldn't. Peano himself didn't ;-)

> and the example I started with, needs to
> cover that case (student marks range between 0 to 10 both included), so
> sorting should work (for me) in that case.

See? I went to school in Spain, so I know about that 0..10 scale.
But then I went to school in Germany, so I also know about the
6..1 scale. Go figure :)

> I don't see, so far any benefit for not considering 0 in that sorting
> process.

But your concrete problem isn't a sorting process at all, just a
conversion process: empty space gets translated to zero. As someone
else found out in this thread.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [more absurd]

[tomas]

On Mon, Jul 04, 2022 at 08:46:11AM +0200, Martin Steffen wrote:

[...]

> In some sense that's defendable (that what could call natural numbers is
> a cultural question or historical, like looking at what Peano did nor
> did not define).
> 
> On the other hand, one normally does not just deals with the numbers as
> such, one does something with it (like comparing them or calculating
> with them) [...]

Yes, since Uwe mentioned Peano, that's why I pointed out that
Peano doesn't care (you have to get to algebra, i.e. "up" in
the conventional foundational ladder) for 0 to have a special
role.

About the cultural thing... you seem to be a zero-counter (as
I am, too): there, too, I think that "our" position isn't in
any way "better" -- some theorems look better this way, some
that way; some inductions are easier to start at 1, some at
0.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ )]

[Ihor Radchenko]

Tim Cross  writes:

> I do have an alternative suggestion which may help. Given that the
> 'broken' URLs are actually from external links to old documentation
> which has been removed, what we could do is create a more informative
> 404 page. Once users are on the 'real' site, the case issue does not
> exist. It is only a problem due to outdated URLs on external sites like
> stack overflow. Instead of just saying 404 Not Found, the page could say
> the requested URL was not found and is likely a link to old outdated doc
> documentation. The page could include a link to the main orgmode
> page. This would be a fairly simple 'fix' that would improve user
> experience to some degree. 

This sounds like a good idea.
I am not sure if it is feasible, but the 404 page could also provide
suggestions based on similar existing links. I have something like
https://list.orgmode.org/orgmode/83tu89b7pr@gnu.org/ in mind.

Best,
Ihor

Re: [PATCH] org.el (org-latex-preview): With an active region, act on it

[Sébastien Miquel]

Marking this as resolved on updates.orgmode.org.

Applied.

--
Sébastien Miquel

Re: [BUG] Inline src blocks do not work for LaTeX [9.5.4 (release_9.5.4-3-g6dc785 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> With #+PROPERTY: header-args+ :exports both, src_shell{ls} exports as
> "ls".  I did not expect that.  Note that I executed a normal BEGIN_SRC
> "shell" block seconds before, so Emacs must have loaded the relevant
> Lisp code.  I then started 'emacs -Q' and tried again.  This time,Org
> exported 'src' followed by a subscript 'shell'.

Can you please provide the detailed steps you executed starting from
emacs -Q? 

Best,
Ihor

Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note

[Ihor Radchenko]

Bhavin Gandhi  writes:

> While looking at the *Messages* buffer, I came across the command
> y-or-n-p-insert-y. There are commands for n, and other keys. When we
> press y, M-p etc, these commands get executed. So, even if we manage to
> fix the initial example in Emacs, the hook will still run while one is
> in the minibuffer.

This explains the observed behavior.

A possible fix could be let-binding post-command-hook to
(delq #'org-add-log-note post-command-hook), though we may get a similar
issue in other context in future.

A better fix may relate to the fact that org-add-log-setup is usually
used to run org-add-log-note at the end of current command. y-or-n-p or
any other kind of command (e.g. added via advice) will break this
assumption we use. So, org-add-log-setup could also store
`this-command', say, in `org-log-note-this-command' and
`org-add-log-note' can then execute only when `this-command' is the same
with `org-log-note-this-command'. WDYT?

Best,
Ihor

Re: [PATCH] oc-csl: Add support for nocite citations

[Ihor Radchenko]

András Simonyi  writes:

> Thanks, I have tried to address your comments in the attached new
> version of the patch.
> Note that the quotes around "csl" follow the manual's "Citation
> handling" chapter.

Since the fontification part appears to be unrelated to this particular
patch, I'd like to ask people who use CSL to test the patch. I do not
use CSL myself.

I have no further comments on the lisp part.

Best,
Ihor

Re: [PATCH] ox: fix comment exported as a blank line

[Ihor Radchenko]

Phil Estival  writes:

> * lisp/ox.el (org-export--skip-p): no longer export single-line
> comments as blank lines which did break paragraphs in two.
>
> TINYCHANGE

I think that this change may be useful in general. `org-export--skip-p'
is sometimes too rigid.

However, the proposed feature should probably be added as a
customization that is not enabled by default.

Best,
Ihor

Re: [patch] ox-html.el: add html attribute (verse numbers) to verse blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Nota bene: I understand that all these functionalities for verses are,
> at the moment, a minority in Org, since Org has a small number of
> Humanities users (here in Spain I try to gain followers among my
> colleagues, but it is an arduous task). In any case, I think features
> like this can attract more Humanities users...

I do like the proposed feature. However, I'd prefer if instead of
introducing a whole new functionality we could extend the existing one.
This approach generally leads to code that is easier to maintain.

> There are some differences between code numbering and verse numbering,
> which is a convention used in Humanities and used by wikipedia and other
> sites as well:
>
> - The first verse is never numbered;
>
> - White lines are not numbered;
>
> - Numbering is added in a sequence, never continuously. The sequence is
>   generally 5, but it is common to find sequences of 3, 10 or other
>   digits (with that I answer your second question).
> ...
> I think line numbering is an idiosyncratic case and should not be
> confused with standard line numbering as understood by Emacs linum-mode
> or any other text editor. What I don't know is if the switches code
> numbering could be reused in that peculiar case. An interesting
> functionality could be to choose at which number the quoted fragment or
> poem begins (because it is common to quote fragments of long poems. In
> the LaTeX version this is obtained by :latexcode \setverselinenums{}{}

>From the above, the verse numbering looks simply like an extended line
numbering. Normal line numbering can be thought as a subset of the
proposed features.

Best,
Ihor

Re: [PATCH] org.el: Fix the filling of regions containing lists

[Sébastien Miquel]

Applied, as 4e4250061.

Took a little while :P

--
Sébastien Miquel

Re: Org and Hyperbole

[Tim Cross]

"Fraga, Eric"  writes:

> Robert,
>
> just one quick comment and question (maybe the documentation covers
> this; if so, apologies): when I tried hyperbole years ago, the annoying
> thing was that it took over C-h.  My muscle memory after decades of
> Emacs use was disturbed significantly as I use C-h (for Emacs help) all
> the time.
>

It appears that hyperbole now uses C-h h as its menu key. Other C-h
bindings appear to be unaffected (you just don't get the old Hello file
which you normally have bound to C-h h).

Re: Org and Hyperbole

[Fraga, Eric]

On Monday,  4 Jul 2022 at 19:01, Ihor Radchenko wrote:
> I posted a bug report related to this in the past and it was fixed. So,
> situation may be somewhat better. You might try and see what happens.

Thank you.  I will play with this system again then.

-- 
Eric S Fraga, @ericsfraga:matrix.org, GnuPG: 0xc89193d8fffcf67d

Re: Org and Hyperbole

[Ihor Radchenko]

"Fraga, Eric"  writes:

> just one quick comment and question (maybe the documentation covers
> this; if so, apologies): when I tried hyperbole years ago, the annoying
> thing was that it took over C-h.  My muscle memory after decades of
> Emacs use was disturbed significantly as I use C-h (for Emacs help) all
> the time.

I posted a bug report related to this in the past and it was fixed. So,
situation may be somewhat better. You might try and see what happens.

However, it appears that something else regarding C-h changed after the
fix as well. At least, I cannot load hyperbole anymore because of some
other aggressive binding (I have C-h rebound to something else):

Debugger entered--Lisp error: (error "Key sequence C-h h starts with non-prefix 
key C-h")
  (global-set-key [8 104] hyperbole)
  (hkey-initialize)
  (hyperb:init)
  ...
  (require hyperbole nil t)

Best,
Ihor

Re: Org and Hyperbole

[Fraga, Eric]

Robert,

just one quick comment and question (maybe the documentation covers
this; if so, apologies): when I tried hyperbole years ago, the annoying
thing was that it took over C-h.  My muscle memory after decades of
Emacs use was disturbed significantly as I use C-h (for Emacs help) all
the time.

thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.4-605-g0ed0de in Emacs 29.0.50

[BUG?] Wrong quote positions in exported CSL bib items when export is done with C-u C-e

[András Simonyi]

Dear All,

I'm experiencing the following mysterious problem with the csl
citation export processor: exporting using the export dispatcher
without a prefix argument works fine, but when I repeat the export
action using C-u before C-e the exported bibliography items containing
quotes have the quotes shifted to incorrect places, seemingly with a
fix offset.

Minimal example:

Org document:
--8<---cut here---start->8---
#+cite_export: csl
#+bibliography: bib.bib
[cite:@Hobbs-1985-Ontological]
#+print_bibliography:
--8<---cut here---end--->8---

bib.bib:
--8<---cut here---start->8---
@inproceedings{Hobbs-1985-Ontological,
  title= {Ontological Promiscuity},
  author   = {Hobbs, Jerry R.},
  booktitle= {Proceedings of the 23rd Annual Meeting
of the Association for Computational Linguistics},
  year = {1985},
  location = {Chicago},
  organization = {Association for Computational Linguistics},
  pages= {61--69}
}
--8<---cut here---end--->8---

The single bibliography item is the correct

  Hobbs, Jerry R. 1985. “Ontological Promiscuity.” In /Proceedings of
  the 23rd Annual Meeting of the Association for Computational
  Linguistics/, 61–69. Chicago: Association for Computational
  Linguistics.

when exported with C-e and as an UTF-8 buffer

but contains an incorrectly places quote:

  Hobbs, Jerry R. 1985. “Ontological Promiscuity. In” /Proceedings of
  the 23rd Annual Meeting of the Association for Computational
  Linguistics/, 61–69. Chicago: Association for Computational
  Linguistics.

when exported (again) with C-u C-e.

Emacs version: 28.1
Org version:  9.5.4
(Citeproc version is Melpa 20220702.2132)

is anybody else seeing this behaviour?

thanks & best wishes,

András

org-mime-htmlize

[Joseph Vidal-Rosset]

Hello,

I noticed that org-mime-htmlize that I use sometimes with Gnus to send email 
with formulas in .png format and bibliographical references does no longer work 
for bibliographical references as it did before.

Example of citation : 

I do not know why it does not work, and I try to get and export with 
bibliographical references inside an email. I’m using org-ref 3.

Your help is welcome,

All the best,

Jo.

/home/joseph/Dropbox/myblog/blog.bib

Re: [more absurd]

[Uwe Brauer]

> In some sense that's defendable (that what could call natural numbers is
> a cultural question or historical, like looking at what Peano did nor
> did not define).

> On the other hand, one normally does not just deals with the numbers as
> such, one does something with it (like comparing them or calculating
> with them). If one takes the reservoir of numbers (in decimal notation,
> {0,1,2,3 .} indeed it is irrelelvant where to start, 0,1, or
> 23. Also if one does nothing else than comparing them (that would be
> considering them as "ordinals", one has one single smallest number, and
> again it's it's irrelevant if that's ``called'' nor notated $0$, "zero"
> or "1", or "23".

> Now, if one starts doing simple calculations (addition, multiplication),
> the natural numbers including 0 is simply more "elegant" or ``richer''
> than without. One has laws like n+0 = n, n*0=0 (one then says, 0 is a
> neutral element wrt. +, there is terminology for all than, and it's
> simply that N with 0 has nicer ``algebraic'' characteristics than
> without. It's quite analogous to the choice between defining lists as to
> include the empty list '() as a ``natural'' list, or insist on that
> ``natural'' lists must have 1 or more elements. 




> Foundational folks can elaborate on that analogy between lists and nats,
> but as you say, in both cases they favor to include 0 to nats and the
> empty list to lists (and there are more examples) and it's favored for
> good reasons (at least to them).

That is the first time I remember that on this list, questions of the
foundation of mathematics are discussed 

Back to the point, maybe I am too conservative, but I would include 0
within the natural numbers, and the example I started with, needs to
cover that case (student marks range between 0 to 10 both included), so
sorting should work (for me) in that case.

I don't see, so far any benefit for not considering 0 in that sorting
process.












-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 


smime.p7s
Description: S/MIME cryptographic signature

Re: [BUG] @* in [cite/nocite:@*] is a valid special LaTeX bibliography key, but it is highlighted using "error" face by oc.el (was: [PATCH] oc-csl: Add support for nocite citations)

[András Simonyi]

Dear All,

On Sun, 3 Jul 2022 at 15:09, Ihor Radchenko  wrote:

> Then, oc-natbib, oc-biblatex, and oc-csl should be modified to provide
> an alternative activation function that will not highlight @* as
> non-existing key.
>
> Probably, we can even use an alternative "special" key face, not
> 'org-cite-key.

AFAICS, the situation is rather complex: Org (the main branch)
currently contains five export processors (basic, bibtex, natbib,
biblatex and csl), but only a single activation processor called
"basic". Of the five export processors the three LaTeX-based ones
already support the "*" key in nocite citations, and the CSL processor
could also with my proposed patch, leaving only the "basic" one
without this feature.

I think that the problem with simply adding one or more new activation
processors with different fontification for the "*" key is that Org
has no way of knowing (at least for sure) which export processor will
be used for a exporting a certain Org buffer, since it can depend on
the chosen export backend (see the variable
org-cite-export-processors). E.g., org-cite could be set up to use the
"natbib" processor for "LaTeX" export and the "basic" processor for
any other format.  I think that it'd be more in the spirit of the
"basic" activation processor to be more permissive and not treat "*"
as an error, similarly to citation styles not supported by the "basic"
export processor but supported by others.

best wishes,
András

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Timothy]

Hello All,

I’ve been viewing this thread with trepidation for a while, and I’ve reached
a point where I feel compelled to add another 2c of mine.

> It’s about the GNU Project’s moral stand (nonfree software is an
> injustice, and encouraging people to use it is wrong), and what
> follows from that.
>
> The GNU Project takes a less extreme position: if a business asks
> customers to use nonfree software to communicate with the business, we
> advise people to refuse to use that software.
>
> Sometimes it’s possible to do business with that company
> and avoid the nonfree software.  Sometimes it’s not.
>
> As this example shows, there are various different kinds of
> scenarios involving businesses and nonfree software.  The GNU Project
> makes these distinctions and treats them differently.

This is all very well and good, however in this case we don’t seem to be dealing
with “a company” per se so much as the entire financial sector.

Hence, I find the question underlying this thread to be whether we should be so
uncompromising in avoiding directing users to non-free JS, that maintainers
should be effectively prohibited from soliciting donations.

Forgive me for this ideological transgression, but I personally find this
absurd. I hold that the GNU project and FSF should do everything reasonably
possible to promote FSF and help support the lovely people who devote time an
effort into enriching FOSS. I don’t think it’s news to anyone that FOSS devs are
overwhelmingly underappreciated and under-compensated for the work they do. We
do not do this for the money, but it dignifies the work we do and allows some of
us to devote more time to working on FOSS.

Adding significant road blocks between philanthropic individuals looking to
support a project they like and the project maintainers helps no one in the end.

In this entire 40+ message thread, only two options have been listed (besides
the FSF’s special arrangement) which do not direct people to non-free JS:
Cryptocurrancy
  Which is volatile in value, regional regulation, and
  individual distaste.
Cheques
  Which are a dying (and in some places dead) form of bank transfer
  instruction. It’s already been established that Ihor would face a US$200 
fee
  when collecting a cheque, and over where I am the central bank announced 
in
  2019 that at a point in the near future the “it will be appropriate to 
wind up
  the cheque system”. Last year a neighbouring country stopped offering or
  receiving cheques altogether.

I think it’s fair to say these are not viable options, leaving accepting
donations via Liberapay, Stripe, etc. as the only practical options. Until then,
let’s not allow perfect to be the enemy of good.

As it happens though, Stripe seem to have open sourced all of their frontend
code — all of these repos  seem to be MIT-licensed.
Perhaps we just need to get this to be compatible with liberajs?

Alternatively might the FSF be able to accept donations on the behalf of various
projects and distribute the money accordingly? Should the FSF indeed be the only
organisation capable of taking donations in a proper manner, why isn’t this
offered as a service for the wider community instead of withholding this freedom
and just complaining that others don’t provide it?

So, to sum up the situation I’d suggest we pick from the following options:
⁃ Accept the situation isn’t great
⁃ Build/fund a new tool
⁃ Convince an existing tool to be more libera-friendly
⁃ Use the FSF as an intermediary

Asking maintainers not to accept donations (or making it prohibitively
difficult) is not a solution.

All the best,
Timothy

Re: [more absurd]

[Martin Steffen]

>writes:

> On Mon, Jul 04, 2022 at 07:10:27AM +0200, Uwe Brauer wrote:

> [...]

>> That really su... (My use case only concerned numbers from 0-10).
>> 
>> So it boils down to the question: why isn't 0 considered as
>> natural numbers, as, according to the Peano axioms, it is?

> I don't know whether you're serious or making fun (Poe's Law and
> all that), but actually, Peano's axioms couldn't care less: as far
> as they are concerned, natural numbers could well start at 23 or
> something.

> Actually it seems to be some kind of "cultural question" whether
> mathematicians start counting at 0 or at 1; my observation is that
> they tend to agree across one faculty at one university.  I know
> positively one that tends to count from 1 (HU Berlin), another
> that counts from 0 (Freiburg), both in Germany.


In some sense that's defendable (that what could call natural numbers is
a cultural question or historical, like looking at what Peano did nor
did not define).

On the other hand, one normally does not just deals with the numbers as
such, one does something with it (like comparing them or calculating
with them). If one takes the reservoir of numbers (in decimal notation,
{0,1,2,3 .} indeed it is irrelelvant where to start, 0,1, or
23. Also if one does nothing else than comparing them (that would be
considering them as "ordinals", one has one single smallest number, and
again it's it's irrelevant if that's ``called'' nor notated $0$, "zero"
or "1", or "23".

Now, if one starts doing simple calculations (addition, multiplication),
the natural numbers including 0 is simply more "elegant" or ``richer''
than without. One has laws like n+0 = n, n*0=0 (one then says, 0 is a
neutral element wrt. +, there is terminology for all than, and it's
simply that N with 0 has nicer ``algebraic'' characteristics than
without. It's quite analogous to the choice between defining lists as to
include the empty list '() as a ``natural'' list, or insist on that
``natural'' lists must have 1 or more elements. 


> I once asked a maths prof and he said foundational folks (set
> theorists, math logicians -- that's the typical environment where
> you'd tend to stumble upon Peano) tend to favour starting at 0.


Foundational folks can elaborate on that analogy between lists and nats,
but as you say, in both cases they favor to include 0 to nats and the
empty list to lists (and there are more examples) and it's favored for
good reasons (at least to them).

best, Martin



> Historically, Peano himself seems to have been a one-counter:

>   "Peano's original formulation of the axioms used 1 instead of 0
> as the "first" natural number,[6] while the axioms in Formulario
> mathematico include zero."  as quoted in [1].

> Cheers

> [1] https://en.wikipedia.org/wiki/Peano_axioms -- t

Re: [more absurd]

[tomas]

On Mon, Jul 04, 2022 at 07:10:27AM +0200, Uwe Brauer wrote:

[...]

> That really su... (My use case only concerned numbers from 0-10).
> 
> So it boils down to the question: why isn't 0 considered as natural numbers, 
> as, according to the Peano axioms, it is?

I don't know whether you're serious or making fun (Poe's Law and
all that), but actually, Peano's axioms couldn't care less: as
far as they are concerned, natural numbers could well start at
23 or something.

Actually it seems to be some kind of "cultural question" whether
mathematicians start counting at 0 or at 1; my observation is
that they tend to agree across one faculty at one university.
I know positively one that tends to count from 1 (HU Berlin),
another that counts from 0 (Freiburg), both in Germany.

Something for mathematical ethnologists (do those exist?) to mull
over.

I once asked a maths prof and he said foundational folks (set
theorists, math logicians -- that's the typical environment
where you'd tend to stumble upon Peano) tend to favour starting
at 0.

Historically, Peano himself seems to have been a one-counter:

  "Peano's original formulation of the axioms used 1 instead
  of 0 as the "first" natural number,[6] while the axioms in
  Formulario mathematico include zero."  as quoted in [1].

Cheers

[1] https://en.wikipedia.org/wiki/Peano_axioms
-- 
t


signature.asc
Description: PGP signature