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. ]]]

The FSF accepts credit card payments without Javascript, thanks to a
special arrangement with a credit card processor.  But it is not easy
to get a credit card processor to accept you as a client that way.

-- 
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)

bug#49967: 27.2; org-copy-visible copies invisible text when there is a link

[Kyle Meyer]

close 49967 28.1
quit

Максим Бабушкин writes:

> The function org-copy-visible should copy visible text only, but it
> copies invisible text when there is a link in a header. For example, let
> an org buffer contains:
> [...]

Thanks for the detailed report, and sorry for the delayed response.
This should be fixed by f2833ff25 on Org's bugfix branch.

Note that Org's mailing list is the main place for development and
discussion of Org mode; you're more likely to get feedback by sending
bug reports to .

Re: Communication problems and possible problems with the website

[Timothy]

Hi Tim,

> +1. We cannot possibly support every user’s preferred platform. Besides,
> didn’t Discord just do an IPO? This increases the likelihood the

Not Discord, /Discourse/ — ,
.

It’s basically a good self-hostable OSS forum, who also offer limited free
hosting to other OSS projects but provide hosting as a commercial service.
Arguably much more in line with the goals of the FSF than Reddit/StackExchange.

For example discourses, see:




It’s rather nice at being able to have separate categories of discussion (e.g.
bugs, feature requests, development work-in-progress, workflow discussions) all
in one place and allowing people to only be subscribed to what they’re
interested in. When a thread drifts off-topic you can create a new linked thread
in another category, which is rather nice. It’s also much more searchable, along
with a few other benefits.

All the best,
Timothy

Re: Communication problems and possible problems with the website

[Tim Cross]

Bastien Guerry  writes:

>
> Discourse is nice but I'm not favor of installing an instance for Org.
>
> Beginners often ask questions on reddit.com and stackoverflow.com (and
> perhaps elsewhere): perhaps some regular users of these websites could
> serve as "contributors stewards", redirecting interesting bug reports,
> patches or feature requests on this mailing list.
>
> My gut feeling is that we should focus on making the mailing list more
> accessible for beginners, more useful for everyone before considering
> setting up another communication channel.
>

+1. We cannot possibly support every user's preferred platform. Besides,
didn't Discord just do an IPO? This increases the likelihood the
platform will now have a much higher revenue focus and could mean it may
transition over time to either a paid model or add advertising or some
other revenue raising model.

(I notice with interest that Google has started transitioning some of
its services which were previously free to a paid model and I wonder if
the free service gravy train might be coming to an end?)

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

[Bastien]

Richard Stallman  writes:

> So I wouldn't insist on (2)
> when deciding whether to buy something or donate to a cause.

When the cause is about supporting Free Software contributors, I think
it's good to favor donation services that support Free Software, hence
the choice for promoting the liberapay.com donation link only.

-- 
 Bastien

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

[Neil Jerram]

On Sun, 27 Feb 2022, 17:19 Bastien Guerry,  wrote:

> Jean Louis  writes:
>
> > Open up few crypto accounts and let people donate their crypto money
> > as well.
>
> I'm not in favor of this.
>

+1.  I assume this conversation is supposed to be ethically driven, and
cryptocurrencies are at least ethically questionable for their use of
energy.

Best wishes,
 Neil

Re: Communication problems and possible problems with the website

[Bastien Guerry]

Ihor Radchenko  writes:

> Some time ago, Timothy shared an idea of creating a discourse forum at
> orgmode.org. Discourse is FOSS and provides a familiar interface +
> ability to create and tag topics. The question is integration with Org
> ML, but I am pretty sure that discourse might be much easier to start
> with for new users. WDYT?

Discourse is nice but I'm not favor of installing an instance for Org.

Beginners often ask questions on reddit.com and stackoverflow.com (and
perhaps elsewhere): perhaps some regular users of these websites could
serve as "contributors stewards", redirecting interesting bug reports,
patches or feature requests on this mailing list.

My gut feeling is that we should focus on making the mailing list more
accessible for beginners, more useful for everyone before considering
setting up another communication channel.

I have a new version for Woof! (https://git.sr.ht/~bzg/woof) that I'd
like to finalize and set up this month - let's see how this helps and
reopen this topic in three or four months?

-- 
 Bastien

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

[Bastien Guerry]

Jean Louis  writes:

> Open up few crypto accounts and let people donate their crypto money
> as well. 

I'm not in favor of this.

-- 
 Bastien

Re: Communication problems and possible problems with the website

[Bastien]

Jean Louis  writes:

> Maybe you could make XMPP group for Org move on chat.orgmode.org and
> let people hoping through various Jabber/XMPP applications.

There are already IRC channels for discussion in real time, I don't
think setting up another way to have live discussions is worth the
maintainance burden.

-- 
 Bastien

Re: [BUG] org-insert-link should use DEFAULT in read-string when asking for description

[Visuwesh]

[ Please keep me in the CCs since I don't follow the list.  ]

[ஞாயிறு, பிப்ரவரி 27 2022] Max Nikulin wrote:

> On 26/02/2022 21:16, Visuwesh wrote:
>> [சனி, பிப்ரவரி 26 2022] Max Nikulin wrote:
>> 
>>> Are you suggesting replacing
>>>  (read-string "rs-initial: " "Some initial")
>>> by
>>>  (read-string "rs-default: " nil nil "Some default")
>>> ?
>> Yes, exactly.
>
> However you agreed that it would be regression since empty description
> use case would be impossible.
>

No.  It is impossible to do it using read-string, but it is possible to
do it by writing a function that calls read-from-minibuffer (and I gave
an example of a function that does this).

>> I admit that I forgot about this but Emacs can be made to not translate
>> empty string to the default argument if you DTRT when calling
>> `read-from-minibuffer' (and `read-shell-command' does this).  If writing
>> a new function just to get this functionality is too much, then I guess
>
> `read-shell-command' still has INITIAL argument and it is used by
> various callers (vc, grep). In addition, unlike for link description,
> I do not see any point in empty shell command (e.g. in vim :! allows
> to see output of previous shell command). So `read-shell-command' may
> behave quite differently.
>

Two things:

1. I dislike grep's behaviour.  However, I understand why grep
   behaves the way it does.  It makes far more sense to use the
   INITIAL argument in grep, but I don't see the same for
   org-insert-link.

   [ In grep, you rarely ever need to change the initial input.  ]

2. The reason why I cited read-shell-command does not have anything
   to do with the usefulness of empty string (or shell command).  I
   merely wanted to point out that you can have BOTH the DEFAULT
   argument (and no INITIAL), and can make the empty string a valid
   output from the function (i.e., without getting substituted by
   the DEFAULT argument).

I hope (2) makes sense.  I'm struggling to word it.

> Current way to ask for link description has the following properties:
> - Almost no action (just RET) if the user happy with suggested
>   description. Default description is provided with hope that it is
>   the most convenient option.
> - It is possible to erase everything and to get a link with no description.
> - The user is free to replace default description with arbitrary
>   alternative text.
>
> It is unclear for me how to tame `read-from-minibuffer' to get equally
> convenient behavior using DEFAULT argument instead of formally
> deprecated INITIAL one.
>

Please read the docstring of read-from-minibuffer.  You would be better
served by reading it than me replicating it here.  And I gave
read-shell-command as an example so others could study the function.

In essence, you can get the old behaviour (1) but you need to type M-n
beforehand.  Its one more key but it is far better than the current
behaviour since it is consistent with rest of the Emacs ecosystem (see
below also).

>> I can live with the current behaviour, but this inconsistency is an
>> annoyance since I end up with garbled link names, which I only notice
>> _afterwards_.
>
> Sorry, but I have not figured out what particular problem you met.

Inconsistency is the problem.  org-insert-link breaks my muscle memory.
I am not sure if you use the default completion system, but if you do,
org-insert-link sticks out by being intrusive.

With every command I use, when I know that the DEFAULT argument will be
of no use, I simply start typing.  However, with org-insert-link I have
to clear the input _first_ then start typing.  This never happens
elsewhere, even in grep (which you cite as an example)!

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

[Michael Powe]

On 2/27/2022 07:58, Timothy wrote:

Hi Max,


I guess we shall remove references to non-free software (like the
Sublime Text editor - I will do this later on.)

Frankly speaking, I never considered mention of sublime text in such context as
endorsing it. Even though such linking might cause transition in both direction,
I thought it was targeting mostly current sublime users. I believed that:
- It makes first step toward using Org easier since such possibility becomes
  discoverable through search engines.
- It reduces friction in heterogeneous teams when an Emacs user proposes to use
   Org markup. Later demonstrating features of real Org Mode may become a
  convincing argument to try GNU Emacs.

My 2c: I think being overly zealous with this is a bad idea. We need to meet
people where they are, not where we want them to be.


Hello,

Second that emotion.

I iterate a previous message I wrote: FSF has a PayPal link on its 
donations page. I don't think org needs to compete for the "purity" 
prize. The amount of money is less important than letting people express 
their support for the software, by voting with their wallet.


I live in the US. My bank is local. I can't make purchases outside the 
US without pre-clearing them with the bank -- unless I use PayPal. The 
latter is my choice. Everyone has their threshold of inconvenience.  
Mine happens to be getting on the phone with the bank every time I want 
to press the "buy" (or "donate") button.


Re: VS Code. Many extensions are copyrighted by their creators (e.g., 
Oracle, Salesforce). I know nothing about the legalese of copyright 
notices. Still, I would not expect that these extensions are free in the 
GNU sense.


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: Links to javascript-based websites from orgmode.org: Paypal and Github

[Timothy]

Hi Max,

 I guess we shall remove references to non-free software (like the
 Sublime Text editor - I will do this later on.)

> Frankly speaking, I never considered mention of sublime text in such context 
> as
> endorsing it. Even though such linking might cause transition in both 
> direction,
> I thought it was targeting mostly current sublime users. I believed that:
> - It makes first step toward using Org easier since such possibility becomes
>  discoverable through search engines.
> - It reduces friction in heterogeneous teams when an Emacs user proposes to 
> use
>   Org markup. Later demonstrating features of real Org Mode may become a
>  convincing argument to try GNU Emacs.

My 2c: I think being overly zealous with this is a bad idea. We need to meet
people where they are, not where we want them to be.

All the best,
Timothy

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

[Max Nikulin]

I guess we shall remove references to non-free software (like the
Sublime Text editor - I will do this later on.)



Ihor Radchenko writes:

Sounds reasonable.



On 26/02/2022 15:57, Bastien wrote:

Done.


Frankly speaking, I never considered mention of sublime text in such 
context as endorsing it. Even though such linking might cause transition 
in both direction, I thought it was targeting mostly current sublime 
users. I believed that:
- It makes first step toward using Org easier since such possibility 
becomes discoverable through search engines.
- It reduces friction in heterogeneous teams when an Emacs user proposes 
to use Org markup. Later demonstrating features of real Org Mode may 
become a convincing argument to try GNU Emacs.


As to search engines, some page on Worg may work almost as well. 
Visitors of the main page who came noticed a mention or a link has less 
chance to be hooked however.


Actually I considered Atom and VS Code (that are still on the main page) 
quite similar. I admit that they are open source, but are available 
packages are really free? Maybe my opinion was just distorted by a 
mention of a project aiming to remove telemetry code from VS Code, 
however even that code is actually free, not to mention that privacy is 
completely distinct issue.

Re: [BUG] org-insert-link should use DEFAULT in read-string when asking for description

[Max Nikulin]

On 26/02/2022 21:16, Visuwesh wrote:

[சனி, பிப்ரவரி 26 2022] Max Nikulin wrote:


Are you suggesting replacing
 (read-string "rs-initial: " "Some initial")
by
 (read-string "rs-default: " nil nil "Some default")
?


Yes, exactly.


However you agreed that it would be regression since empty description 
use case would be impossible.



I admit that I forgot about this but Emacs can be made to not translate
empty string to the default argument if you DTRT when calling
`read-from-minibuffer' (and `read-shell-command' does this).  If writing
a new function just to get this functionality is too much, then I guess


`read-shell-command' still has INITIAL argument and it is used by 
various callers (vc, grep). In addition, unlike for link description, I 
do not see any point in empty shell command (e.g. in vim :! allows to 
see output of previous shell command). So `read-shell-command' may 
behave quite differently.


Current way to ask for link description has the following properties:
- Almost no action (just RET) if the user happy with suggested 
description. Default description is provided with hope that it is the 
most convenient option.

- It is possible to erase everything and to get a link with no description.
- The user is free to replace default description with arbitrary 
alternative text.


It is unclear for me how to tame `read-from-minibuffer' to get equally 
convenient behavior using DEFAULT argument instead of formally 
deprecated INITIAL one.



I can live with the current behaviour, but this inconsistency is an
annoyance since I end up with garbled link names, which I only notice
_afterwards_.


Sorry, but I have not figured out what particular problem you met.

Re: org-cite and org-ref-cite

[Henrik Frisk]

Den lör 26 feb. 2022 kl 16:11 skrev John Kitchin :

> I would not recommend org-ref-cite (
> https://github.com/jkitchin/org-ref-cite). It was an early approach to
> trying to integrate org-ref with oc-cite. As far as I know, it worked fine
> for that, and was pretty complete for citations, but I have abandoned this
> approach and archived the repo. If anyone would like to take over this repo
> I would be happy to transfer it.
>
> If you are looking for something above and beyond the default oc-cite
> capabilities, https://github.com/bdarcus/citar is probably a better
> choice than org-ref-cite as it is actively developed.
>
>
I see. Didn't realize that. I will look into citar then, thanks!

/Henrik