Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Hi Timohy,

Timothy writes:

> I don’t think Ihor is suggesting we stop indicating that org-mode is part of
> Emacs.

Of course, I am convinced that Ihor is not saying that Org is not part
of Emacs, and I have to make it clear, that I have never suggested such
a thing. What's more, I understand and applaud his conciliatory effort
on this issue, since since a series of debates and noise have arisen
here on these matters.

What worries me are the consequences of insisting here on these debates.
That is why I have underlined what Russell has commented, as I think he
is right.

On the other hand, we must not forget that Org, as part of Emacs, is
part of GNU, and this is a mailing list from the GNU project. I think
everything related to the (possible) extension of GNU Org Mode outside
of GNU Emacs (even in software incompatible with the ethics and
philosophy of the GNU project) should be considered offtopic here and be
discussed in other forums. Otherwise it would only create confusion
among users.

Best regards,

Juan Manuel 

Re: quotation marks in table cell vs. org-babel-ref-resolve

[Greg Minshall]

hi, Tim,

thanks for the reply.

> I don't know. It could be related to the spreadsheet capabilities or it
> could simply be an oversight in how the code extracts values from
> tables.

if anyone has any knowledge in this area, i'd be curious to hear.

> I tend to use the function org-table-to-list to extract the data from a
> table. It gives me a nested list which I can then process with elisp in
> any way I want. I don't know if that would help or how it will interpret
> a cell whic contains both quoted and unquoted data.

for the record, things -- lists and lisps -- being equal, the function
you presumably meant to write was =org-table-to-lisp=.

=org-babel-ref-resolve= is convenient to use (as you provide a REF,
rather than create a [temp] buffer, visit the file, whatever).  but, it
isn't clear to me what functions (=org-babel-ref-resolve= and/or
=org-table-to-lisp=) should be considered part of the "Emacs Org Mode
API". :)

(i've gotten "around" the issue by prepending my e-mail addresses with
[: SPACE].)

cheers, Greg

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Timothy]

Hi Juan,

> I think that I cannot agree more with this. Org Mode is GNU Emacs, and
> the magic of Org Mode is the magic of GNU Emacs. That’s why I insist
> that going to Org means going to Emacs.

I don’t think Ihor is suggesting we stop indicating that org-mode is part of
Emacs. I think there’s been a fair bit of misinterpretation in this thread.
Let’s treat the proposal as what it is. Namely:
⁃ Indicating that Org as a concept has spread beyond Emacs (it has, look at the
  number of tools as extensions for it)
⁃ Perhaps use some of the tools that people have developed to provide a
  no-install in browser demo of some of the functionality
⁃ Improve our technical documentation and testing
⁃ Let people know what to expect from other tools/extensions that offer “Org 
support”

That’s it.

All the best,
Timothy

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Russell Adams writes:

> What makes Org dramatically different is the editing experience in
> Emacs. Collapsing the outline, filtering on metadata, exports, agenda,
> etc. Those are Emacs features, not specific to the actual markup
> format.
>
> My impression is we already have stretched our resources thin trying
> to maintain Org. Pushing to provide compatibility with non-Emacs tools
> seems a poor use of their time, and rude to ask of them.
>
> If non-Emacs users and coders want to use Org formatted files, they
> are free to spend their time customizing their tools to make it
> work. If the Org project owes anything to anyone, it's a consistent
> experience for the users who have used Org for years. Not changes to
> satisfy potential users or follow trendy fads.
>
> My experience has been that Org's markup is so simple and could be
> summarized in a few lines. Anything more complex enters the territory
> of Emacs only features (ie: drawers. exports, view control, source
> blocks, reporting). Those are unlikely to be portable, so we're back
> to "use Emacs".

I think that I cannot agree more with this. Org Mode is GNU Emacs, and
the magic of Org Mode is the magic of GNU Emacs. That's why I insist
that going to Org means going to Emacs.

Best regards,

Juan Manuel 

Re: [PATCH] ob-shell-test, test-ob-shell and introduction

[Thomas S. Dye]

Aloha Matt,

Matt  writes:

 > > I just verified with my employer that my contract grants an 
 > > exception for this
 > > project. Just emailed the request to ass...@gnu.org. 

Not surprisingly the FSF hasn't resources to verify my 
contract's exception and needs a written disclaimer from my 
employer. I'm waiting on this now.


 > Feel free to develop and
 > share patches before the assignment is complete, we’ll just 
 > wait till it’s gone
 > through before merging 
 
Given the contract exception, I'll start moving forward again 
with the assumption that I'll eventually get that written 
disclaimer.


 > Hope that helps.
 
It does, thank you. It's nice to know that my words aren't going 
into the void. :)


Good news.

Contributions to Worg aren't similarly restricted.  Feel free to 
push material there in the meantime.


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: Worg's library-of-babel.org (was: Dodgy Worg publishing?)

[Thomas S. Dye]

Aloha all,

Timothy  writes:


"Thomas S. Dye"  writes:

I checked this morning and I still get a 404 error when I 
follow the Worg link

in section 16.12 of the Org mode manual at orgmode.org.


(sigh) I already fixed a 2nd issue, it looks like there's at 
least a

3rd...


I still get the 404 error.

After some thought, it occurs to me that it is likely a bad idea 
to make changes to library-of-babel.org, which just contains 
source code blocks that might prove useful to Babel users.


Perhaps there is some way to indicate that this file just needs to 
be copied "as is" when Worg is published?  Or, if not, then 
perhaps the patch with the ungainly, working URL might be applied 
to the manual?


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [PATCH] ob-shell-test, test-ob-shell and introduction

[Matt]

 > > I just verified with my employer that my contract grants an exception for 
 > > this
 > > project. Just emailed the request to ass...@gnu.org. 

Not surprisingly the FSF hasn't resources to verify my contract's exception and 
needs a written disclaimer from my employer. I'm waiting on this now.

 > Feel free to develop and
 > share patches before the assignment is complete, we’ll just wait till it’s 
 > gone
 > through before merging 
 
Given the contract exception, I'll start moving forward again with the 
assumption that I'll eventually get that written disclaimer.

 > Hope that helps.
 
It does, thank you. It's nice to know that my words aren't going into the void. 
:)

Re: Org-syntax: Intra-word markup

[Samuel Wales]

i think i can't add much useful to these threads, i agree with the
simplicity, but, a nuance, want for org to have had a bit more
consistency growing up.  e.g. quoting/escaping, demarcation, and
applicability of features in different contexts.

sort of a "mentally factored user interface" where the user's
expectation is pretty straightforwardly met.  e.g. works here so
should also work there.  or, there is only one rule for doing this.
that kind of thing.  orthogonality also.  few exceptions.

it is understandable in context that inconsistencies exist, and that
might apply to various maintenance-over-heavy things users want.

if we are to remove features as suggested below, then i suggest, where
possible, consistency be a desideratum for final result.


On 12/5/21, Russell Adams  wrote:
> On Sat, Dec 04, 2021 at 10:51:47AM +1100, Tim Cross wrote:
>>
>> Tom Gillespie  writes:
>>
>> > I don't mean to be a wet blanket...
>
> I'd like to be a wet blanket.
>
>> +infinity!
>>
>> Please, please can we stop trying to satisfy every edge case or extend
>> the markup to satisfy every possible scenario.
>
> +infinity^2
>
> I've often thought Org needs to hit the brakes and stop adding
> features, or cut out features that have a high support/maintenance
> cost. We need to respect our maintainers' time.
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> I think your working off a false premise. Your view is that org mode
>> should be available in other editors/software so that others can realise
>> the power and benefits it provides. I can understand that position.
>
> A clarification: my premise is that org mode should be available in
> other _free_ editors/software. If we provide the means for other free
> software to support Org mode (either as markup format or as some subset
> of Elist implementation), it will benefit software freedom in general.
> Whatever helper information (think of tests) we provide, it should be
> licensed under GPLv3 with the following effect:
>

I don't disagree with this objective. My objection is to changing the
emphasis or priority of org mode as an Emacs mode to a general technical
specification for a small part of what is org-mode, the markup (I will
outline the concerns I have in doing this below). The other point of
course is that if you make it easier to implement org markdown in other
editors, you don't have control over whether they are implemented in
free or non-free solutions. 

> https://www.gnu.org/licenses/quick-guide-gplv3.html
>>> It's always possible to use GPLed code to write software that
>>> implements DRM. However, if someone does that with code protected by
>>> GPLv3, section 3 says that the system will not count as an effective
>>> technological "protection" measure. This means that if you break the
>>> DRM, you'll be free to distribute your own software that does that,
>>> and you won't be threatened by the DMCA or similar laws.
>
> The fact is that e.g. Github already provides support for Org markup.
> They do it for their own profit and we cannot stop them. If we have a
> controlled criteria about quality of third-party Org mode support, there
> will be means to interfere with non-free software attempting to makes
> profits out of Org mode. For example, if Github do not integrate our
> recommended test suite (with all the legal consequences defined in
> GPLv3), we will be able to have a list of third-party tools and, among
> free alternatives, mention that Github support for Org is not verified
> and most likely not consistent with other _free_ tools. We cannot do it
> now.
>

There is a fatal flaw in this argument. The GPL licenses code, not the
underlying idea (which is essentially what patents are about). We can
define all the quality criteria we like for 3rd party implementations,
but we cannot enforce them unless they are also using the GPL'd code. As
this code is elisp, it is extremely unlikely any 3rd party
implementation will be using it. In short, defining clear specifications
and minimal quality criteria will only have baring on code added to org
mode - it would, for example, have no effect on what github has/is
implementing. 

>> However, the FSF position would be exactly the opposite. They would
>> argue that orgmode is a powerful and flexible tool that is part of Emacs
>> and if you want that power and flexibility, you need to use Emacs. Org
>> mode has probably done more to bring new users to Emacs than any other
>> Emacs mode in the last 30 years. As a consequence, you will find not
>> only little support towards making it available in other editors, you
>> are likely to run into active resistance. As you say, org-mode can be
>> thought of as a brand name and that is a brand name owned by the FSF as
>> an official GNU project and a goal of the FSF is to convert people to
>> use GNU free software. Anything which has the potential to take the
>> power of org mode and make it available in non-free software (not simply
>> open source) is not going to be supported or welcomed.
>
> I am very much sceptical that third-party tools can provide the level of
> Org support Emacs does provide. Emacs is and will remain the most
> feature-full tool for people to use Org mode. Org mode's largest power
> is configurability thanks to Emacs. On the other hand, Org mode's
> support would be welcome in tools like TeXMacs or in forges like
> Sourcehut (currently only supporting markdown).
>

I don't disagree about the benefit of org markup being supported in 3rd
party tools. I disagree with the proposal to change the emphasis of the
org-mode project from being an Emacs mode to being a more general
technology.

Consider this contrived scenario.

We have adopted a change in emphasis to promote org mode as a more
general solution and clarified the specification to make it easier for
3rd parties to implement.

Meanwhile, Emacs development continues and new features/capabilities
continue to be added. In particular, a new feature is added which is
extremely powerful and would be a huge benefit for Emacs org-mode users.
However, there is a problem. In order to take advantage of this new
feature, significant changes are required for the specification. This
will result in implementations requiring considerable work in order to
update them to the new specification. 

Re: Org-syntax: Intra-word markup

[Russell Adams]

On Sat, Dec 04, 2021 at 10:51:47AM +1100, Tim Cross wrote:
>
> Tom Gillespie  writes:
>
> > I don't mean to be a wet blanket...

I'd like to be a wet blanket.

> +infinity!
>
> Please, please can we stop trying to satisfy every edge case or extend
> the markup to satisfy every possible scenario.

+infinity^2

I've often thought Org needs to hit the brakes and stop adding
features, or cut out features that have a high support/maintenance
cost. We need to respect our maintainers' time.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Org-syntax: Intra-word markup

[Russell Adams]

On Sat, Dec 04, 2021 at 10:01:15PM +0700, Max Nikulin wrote:
> On 04/12/2021 06:51, Tim Cross wrote:
> >
> > Please, please can we stop trying to satisfy every edge case or extend
> > the markup to satisfy every possible scenario.
>
> It is ridiculous to throw away a nice tool and start to struggle with
> another bunch of problems when a small missed feature is really required.

I think this is a problem of expectations. I don't export Org to
export perfect documents in every language. I expect Org to make a
simple subset of features available consistently.

With HTML or Latex you can create those words, and you can insert that
code into your Org document. Why does the Org syntax need to be
further extended to support this?

Part of the reason Org is a nice tool is that it is simple, and we
should be cautious trying to make it any more complex.


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams]

On Sun, Dec 05, 2021 at 06:59:20PM +, Juan Manuel Macías wrote:
> Frustration every time I want to recommend Org to many of my friends
> and colleagues, who don't even use Emacs.

I think this is the core of every interoperability argument: "Why do
we have to use Emacs to use Org?" It's called Emacs Org-mode for a
reason. Org-mode doesn't work outside of Emacs.

I've often told users that it's worth learning enough Emacs to use
Org, and have successfully moved several non-power users over to
Emacs. They know enough to consistently open their files, edit Org,
and quit. That's enough. They complain it's "ugly" compared to
"modern" GUI tools, but they can't deny the utility.

> I came to Org been an Emacs user already, so I was reasonably familiar
> with Emacs and Elisp, although what I used most was AUCTeX (and Markdown
> for my docs).

I'd have a hard time convincing users in Mordor to use a plain text
format, much less Org without Emacs.

> On the other hand, Org as a lightweight markup language is only
> a tiny part of Org. I don't think Org is better or worse as a markup
> language than Markdown, asciidoc or other similar formats.

What makes Org dramatically different is the editing experience in
Emacs. Collapsing the outline, filtering on metadata, exports, agenda,
etc. Those are Emacs features, not specific to the actual markup
format.

My impression is we already have stretched our resources thin trying
to maintain Org. Pushing to provide compatibility with non-Emacs tools
seems a poor use of their time, and rude to ask of them.

If non-Emacs users and coders want to use Org formatted files, they
are free to spend their time customizing their tools to make it
work. If the Org project owes anything to anyone, it's a consistent
experience for the users who have used Org for years. Not changes to
satisfy potential users or follow trendy fads.

My experience has been that Org's markup is so simple and could be
summarized in a few lines. Anything more complex enters the territory
of Emacs only features (ie: drawers. exports, view control, source
blocks, reporting). Those are unlikely to be portable, so we're back
to "use Emacs".

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: [BUG] Orgmode error prompted to submit [9.6 (9.6-??-27edae8 @ /home/chris/.emacs.d/.local/straight/build-27.2/org/)]

[christopher.pingitore]

Apologies for delay, I have not been able to reproduce the error message on my 
desktop or my laptop.
If you would like me to do anything additional please let me know. 

best Regards,
Chris

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Wednesday, December 1st, 2021 at 6:42 PM, Ihor Radchenko 
 wrote:

> "christopher.pingitore" via "General discussions about Org-mode."
> 

> emacs-orgmode@gnu.org writes:
> 

> > Warning (emacs): org-element--cache: Cache corruption detected in 
> > 2021-08-08--Org File Test for Sharing--TECH.org. Resetting.
> > 

> > The error was: (error "rx ‘**’ range error")
> > 

> > Backtrace:
> > 

> > nil
> > 

> > Please report this to Org mode mailing list (M-x org-submit-bug-report).
> 

> Thanks for reporting! We have made some progress toward fixing this in
> 

> recent commits (1593d3148). Can you update your Org and let us know if
> 

> you are still seeing the warning?
> 

> Best,
> 

> Ihor

signature.asc
Description: OpenPGP digital signature

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tim Cross]

"Bruce D'Arcus"  writes:

> On Sun, Dec 5, 2021 at 8:42 AM Tim Cross  wrote:
>
>> I think your working off a false premise. Your view is that org mode
>> should be available in other editors/software so that others can realise
>> the power and benefits it provides. I can understand that position.
>>
>> However, the FSF position would be exactly the opposite. They would
>> argue that orgmode is a powerful and flexible tool that is part of Emacs
>> and if you want that power and flexibility, you need to use Emacs.
>
> Perhaps, but Emacs org users benefit from better support for org
> documents outside of Emacs.
>

That may be true, but it is secondary to the main goal of the FSF. It
isn't about benefit or convenience. It is about freedom. My guess is
that the FSF position is likely to be something along the lines that
while supporting/encouraging org mode in other, possibly non-free,
software might be beneficial to Emacs users, it not only fails to
promote the objectives of the FSF, it may actually work against it by
decreasing the incentives to move away from a closed non-free solution
to an open free one. 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Timothy]

Hi Ihor,

Thank you for your email. I have little to add to you analysis and suggestions
other than my strong agreement. However, I will give some of my thoughts that
lead me to this position.

Ultimately, we have a choice. Do we wish to be hostile, or welcoming to interest
in Org outside org-mode? Under the “hostile” or “isolationist” option, we might:
⁃ Talk of Org not as a general format, but the /exclusive/ format of org-mode
⁃ Ignore any and all attempts to support .org files outside Emacs
Under the “welcoming” option, we might:
⁃ Treat OrgMode as a “brand name” for the Org file format, with org-mode as the
  reference implementation
⁃ Take reasonable steps (such as those Ihor suggests) to make Org seem
  relevant/interesting/usable (if inferior) without Emacs
⁃ Encourage efforts to support the format outside Emacs’ org-mode

To me, the choice is clear. I think we loose nothing by choosing by welcoming
interest in Org outside org-mode, but potentially gain much. As Emacs users, we
can think of ourselves as living in a little Emacs bubble (of around 2% of
developers if StackOverflow’s developer survey is to be believed). Like Karl
Voit, I believe Org holds a lot of value as a markup format in and of itself.
The other 98% + some non-developers have good reason in my mind to be curious
about Org. I imagine many of us regularly interact with such people. We see this
interest manifested not only in extensions for various other editors ([neovim],
[atom], [vs code], [sublime], etc.), but also parsers and tools that work with 
Org
like Hugo, Pandoc, and LogSeq. We do not live in a bubble. We all benefit from
such efforts.

*The more people use Org, in some form, the greater the chance that someone
making a new tool will think to support it.*

Whatever we may make of it, there is clear interest in Org (to some extent)
separately from Emacs. By ignoring that, we only do ourselves and potential
future Org / Emacs org-mode users a disservice.

People are currently making editor extensions and tools for Emacs outside
org-mode. I don’t think this is suddenly going to stop. We might as well help
such efforts. Good tools that work with Org are good for Org / org-mode. By
providing good clear documentation, and a well-defined grammar, we reduce the
risk of different implementations of the syntax and functionality defined by
org-mode. We could even provide some for of “implementation roadmap” (linked to
the syntax specification) to help developers understand what is required to
implement certain functionality (both markup/syntax, and editing features —
more on this idea I’ve had in a future email). Karl Voit’s idea of “levels” of
Org helps make the task less daunting.

Yes, it will take a bit of effort to do this, and in particular to do this well.
I feel it would likely be worth it though. From the efforts we’ve seen so far,
we have nothing to loose and much we could gain.

All the best,
Timothy

p.s. I see some concerns have been raised about freedom and Org outside Emacs.
While the FSF/GNU project are champions of the FOSS movement, there are many
other FOSS projects and FOSS editors. To decry helping non-GNU/FSF
projects/editors because there are non-free projects/editors seems a bit much.
If improving our documentation and being friendlier to non-Emacs users looking
at the project website is anti-freedom/breaks FSF rules, what’s making an Emacs
build for Windows?


[neovim] 

[atom] 

[vs code] 

[sublime] 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Ihor Radchenko writes:

> Ok. Let me explain my thought process.
>
> First of all, there is no burden on users of Org mode in making edits to
> orgmode.org. It is a burden on Org contributors.
>
> One of the aims of my proposal is reducing this burden by involving
> non-emacs users to provide contributions to Org (e.g. by making more
> tests for Org-element parser). To do it, we need to make the
> contribution process for non-emacs developers easier. Ideally, without
> too much effort on our side.
>
> The idea of involving non-emacs users does have a potential because we
> do know that third-party tools are already using Org. The problem is the
> disconnect between those tools and Org mode proper.
>
> The sources of the disconnect are (1) lack of technical "blueprints" for
> Org that do not require knowing Elisp; (2) lack of discovereability of
> Org mode as something that can live outside narrow field of Emacs. In
> this branch of our discussion, I am going to talk about the second
> point.
>
> People simply do not expect to see a markup language when they encounter
> a link with "Org mode for Emacs" title. Someone looking for Org mode
> markup to be used in, say, websites will think that "Org mode for Emacs"
> is limited to Emacs. Someone just interested in plain text markup will
> find no relevance at all.
>
> Title is important. If we care at all about orgmode.org website
> appearing in search results, we want the title and the summary to have 2
> main properties: (1) Provide search keywords to make it searchable by
> potentially interested people; (2) Provide a title that immediately
> signal that our website contains the information people are looking for.
>
> Now, we need to understand what kind of people may be looking to
> orgmode.org website.
>
> 1. Existing emacs users
>
>If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
>is indeed recognisable. On the other hand, the word "Org mode" does
>not provide much further info, except that it is a major (or maybe
>minor?) mode for "Org"??
>
>Now, consider "Org mode: your life in plain text".
>For emacs users, "Org mode" is not just a strange phrase, but a very
>clear indication that we are talking about Emacs.
>The "your life in plain text" provides extra information about what
>"Org mode" refers to. Clearly, text documents and "your life in plain
>text" should resonate with every Emacs user's soul.
>
>We can change the second variant of the title to contain "Emacs", but
>will it add much value? I am not convinced. On the other hand, making
>title too long or too complex _is_ bad. Long titles tend to be
>skipped (there was even formal research on this!)
>
> 2. Non-emacs users interested in plain text markup
>
>These users know nothing about Emacs and "Org mode" has no meaning
>for them as is. So, we do need something more descriptive.
>Adding "Emacs" may be fine, but it will serve no purpose for people
>not familiar with emacs. Just another unknown term making the title
>longer.
>
> 3. Non-emacs users interested in GTD/project management, etc
>"Org mode: your life in plain text" is somewhat relevant when people
>are looking to manage "life" (typically true for GTD enthusiasts).
>
>Though we can probably do better for this category.
>Maybe "Org mode: manage your life and notes in plain text"?
>Though it makes the title less relevant to group #2.
>
> 4. Researchers looking for ipython-like environment
>
>Not covered, except by reading my proposed site summary. I am not
>sure how we can improve title for this audience.
>
> 5. ??? (Suggestions are welcome)
>
> Of course, better suggestions for the title are welcome. I just wanted
> to make it clear the reasoning I do not like the current title and how
> the proposed alternative is better (though not ideal).
>
> Finally, I want to emphasise that our aim for search engines is not
> advertising Emacs (we already do it by trapping users inside Org and
> making them switch to Emacs by force :evil_laughter:). The aim is
> encouraging people to use and contribute to Org mode in useful ways
> (even unrelated to writing Elisp or, really, any code at all).
>
> Search result is just an entrance for users to be curious about the new
> beast of "Org mode". The website front page is the means to make users
> try. And the Org mode itself is the way to make users fall in love with
> Org in one way or another (even unrelated to Emacs [at least
> initially]).

Ihor, thank you very much for explaining your motivation in detail. I
think I understand it and (on the important points) I share it. In my
case, as an Org Mode user I often feel a mixture of happiness and
frustration. Happiness on using Org. Frustration every time I want to
recommend Org to many of my friends and colleagues, who don't even use
Emacs. GNU Emacs is a great, labyrinthine, fascinating building. Almost
like a city. And Org is a 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Ihor Radchenko]

Tim Cross  writes:

> - The suggested org mode in a browser example is unlikely to be
>   acceptable to the FSF (or RMS). The FSF is very much against cloud
>   based computing services or any web service which uses non-free
>   Javascript (which is most of them and one of the many reasons Github
>   is discouraged by the FSF).

You are not right. I am well aware about the freedom of computation and
proposed organise because it is not actually cloud-based. Organise is a
frontend. It is licensed under AGPL. AGPL is recommended by FSF for
network software.

> A number of the ideas proposed are good ideas for org mode generally -
> for example, a repository of reference documents which could be used for
> testing purposes would be extremely useful for org-mode development and
> testing. Likewise, any effort to clarify the syntax and remove any
> ambiguities is beneficial for org mode itself. However, the emphasis and
> priority needs to remain focused on org mode as a mode for Emacs. The
> use of org mode by other external programs is really outside (but
> related) to the project.

May you clarify which one of the proposed changes has insufficient
emphasis on org mode for Emacs? If you have concrete ideas for
improvement, feel free to propose them.

> As a consequence and to eliminate/remove potential conflicts with FSF
> philosophy and goals, it may be worth considering spinning off a
> separate project. which happens to use the same markup syntax, but is
> not a GNU project (though it would be good to still be GPL'd). 

I think that's what Karl proposed? I created this thread with specific
purpose to adapt his ideas to Org mode as a free software under FSF.

> If you want ot get a feel for the sort of issues which could come up
> when trying to develop/support 3rd party tools, have a look at the
> recent thread on creating an LSP server for emacs-lisp. While I
> personally disagree with most of the fears raised by some contributors
> to that thread and disagree with RMS's view that such a server would not
> be in the best interests of Emacs, the thread does give you a sample of
> the sort of issues which could come up with efforts to support or
> encourage 3rd party libraries for org markup, much of which could be
> avoided if the work is clearly not part of, related to or supported by
> the main org-mode project. 

I have looked through that thread. I do not think that it applies.
Implementing LSP server for Elisp will give little benefit for Emacs while
giving a "free" and large benefit to non-free software at the same time.

Our situation is different. What I propose in a nutshell is: (1) Improve
our technical documentation; (2) Improve our test coverage; (3) Attract
more users to Org mode. Everything gives benefits to Org. In addition to
better integration.

Best,
Ihor

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Ihor Radchenko]

Tim Cross  writes:

> I think your working off a false premise. Your view is that org mode
> should be available in other editors/software so that others can realise
> the power and benefits it provides. I can understand that position.

A clarification: my premise is that org mode should be available in
other _free_ editors/software. If we provide the means for other free
software to support Org mode (either as markup format or as some subset
of Elist implementation), it will benefit software freedom in general.
Whatever helper information (think of tests) we provide, it should be
licensed under GPLv3 with the following effect:

https://www.gnu.org/licenses/quick-guide-gplv3.html
>> It's always possible to use GPLed code to write software that
>> implements DRM. However, if someone does that with code protected by
>> GPLv3, section 3 says that the system will not count as an effective
>> technological "protection" measure. This means that if you break the
>> DRM, you'll be free to distribute your own software that does that,
>> and you won't be threatened by the DMCA or similar laws.

The fact is that e.g. Github already provides support for Org markup.
They do it for their own profit and we cannot stop them. If we have a
controlled criteria about quality of third-party Org mode support, there
will be means to interfere with non-free software attempting to makes
profits out of Org mode. For example, if Github do not integrate our
recommended test suite (with all the legal consequences defined in
GPLv3), we will be able to have a list of third-party tools and, among
free alternatives, mention that Github support for Org is not verified
and most likely not consistent with other _free_ tools. We cannot do it
now.

> However, the FSF position would be exactly the opposite. They would
> argue that orgmode is a powerful and flexible tool that is part of Emacs
> and if you want that power and flexibility, you need to use Emacs. Org
> mode has probably done more to bring new users to Emacs than any other
> Emacs mode in the last 30 years. As a consequence, you will find not
> only little support towards making it available in other editors, you
> are likely to run into active resistance. As you say, org-mode can be
> thought of as a brand name and that is a brand name owned by the FSF as
> an official GNU project and a goal of the FSF is to convert people to
> use GNU free software. Anything which has the potential to take the
> power of org mode and make it available in non-free software (not simply
> open source) is not going to be supported or welcomed.

I am very much sceptical that third-party tools can provide the level of
Org support Emacs does provide. Emacs is and will remain the most
feature-full tool for people to use Org mode. Org mode's largest power
is configurability thanks to Emacs. On the other hand, Org mode's
support would be welcome in tools like TeXMacs or in forges like
Sourcehut (currently only supporting markdown).

Best,
ihor

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Bruce D'Arcus]

On Sun, Dec 5, 2021 at 8:42 AM Tim Cross  wrote:

> I think your working off a false premise. Your view is that org mode
> should be available in other editors/software so that others can realise
> the power and benefits it provides. I can understand that position.
>
> However, the FSF position would be exactly the opposite. They would
> argue that orgmode is a powerful and flexible tool that is part of Emacs
> and if you want that power and flexibility, you need to use Emacs.

Perhaps, but Emacs org users benefit from better support for org
documents outside of Emacs.

Bruce

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tim Cross]

Ihor Radchenko  writes:

> Juan Manuel Macías  writes:
>
>> Yes, sorry for not explaining myself well: I was also referring to
>> search results, not the title in the web site...
>>
>> But the question is: what need is there to remove the reference to Emacs
>> in the search result? I think the emphasis is necessary. As we say in
>> spanish, it's like putting the bandage on before the wound. If there are
>> people who think that Org Mode can 'live' in some way outside of Emacs
>> (a respectable opinion, but that I do not share, at least 100%), I think
>> the burden of the work falls on them and not on us, the users of
>> Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
>> not my intention to initiate a controversy with it.
>
> Ok. Let me explain my thought process.
>
> First of all, there is no burden on users of Org mode in making edits to
> orgmode.org. It is a burden on Org contributors.
>
> One of the aims of my proposal is reducing this burden by involving
> non-emacs users to provide contributions to Org (e.g. by making more
> tests for Org-element parser). To do it, we need to make the
> contribution process for non-emacs developers easier. Ideally, without
> too much effort on our side.
>
> The idea of involving non-emacs users does have a potential because we
> do know that third-party tools are already using Org. The problem is the
> disconnect between those tools and Org mode proper.
>
> The sources of the disconnect are (1) lack of technical "blueprints" for
> Org that do not require knowing Elisp; (2) lack of discovereability of
> Org mode as something that can live outside narrow field of Emacs. In
> this branch of our discussion, I am going to talk about the second
> point.
>
> People simply do not expect to see a markup language when they encounter
> a link with "Org mode for Emacs" title. Someone looking for Org mode
> markup to be used in, say, websites will think that "Org mode for Emacs"
> is limited to Emacs. Someone just interested in plain text markup will
> find no relevance at all.
>
> Title is important. If we care at all about orgmode.org website
> appearing in search results, we want the title and the summary to have 2
> main properties: (1) Provide search keywords to make it searchable by
> potentially interested people; (2) Provide a title that immediately
> signal that our website contains the information people are looking for.
>
> Now, we need to understand what kind of people may be looking to
> orgmode.org website.
>
> 1. Existing emacs users
>
>If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
>is indeed recognisable. On the other hand, the word "Org mode" does
>not provide much further info, except that it is a major (or maybe
>minor?) mode for "Org"??
>
>Now, consider "Org mode: your life in plain text".
>For emacs users, "Org mode" is not just a strange phrase, but a very
>clear indication that we are talking about Emacs.
>The "your life in plain text" provides extra information about what
>"Org mode" refers to. Clearly, text documents and "your life in plain
>text" should resonate with every Emacs user's soul.
>
>We can change the second variant of the title to contain "Emacs", but
>will it add much value? I am not convinced. On the other hand, making
>title too long or too complex _is_ bad. Long titles tend to be
>skipped (there was even formal research on this!)
>
> 2. Non-emacs users interested in plain text markup
>
>These users know nothing about Emacs and "Org mode" has no meaning
>for them as is. So, we do need something more descriptive.
>Adding "Emacs" may be fine, but it will serve no purpose for people
>not familiar with emacs. Just another unknown term making the title
>longer.
>
> 3. Non-emacs users interested in GTD/project management, etc
>"Org mode: your life in plain text" is somewhat relevant when people
>are looking to manage "life" (typically true for GTD enthusiasts).
>
>Though we can probably do better for this category.
>Maybe "Org mode: manage your life and notes in plain text"?
>Though it makes the title less relevant to group #2.
>
> 4. Researchers looking for ipython-like environment
>
>Not covered, except by reading my proposed site summary. I am not
>sure how we can improve title for this audience.
>
> 5. ??? (Suggestions are welcome)
>
> Of course, better suggestions for the title are welcome. I just wanted
> to make it clear the reasoning I do not like the current title and how
> the proposed alternative is better (though not ideal).
>
> Finally, I want to emphasise that our aim for search engines is not
> advertising Emacs (we already do it by trapping users inside Org and
> making them switch to Emacs by force :evil_laughter:). The aim is
> encouraging people to use and contribute to Org mode in useful ways
> (even unrelated to writing Elisp or, really, any code at all).
>
> Search 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tim Cross]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> The website title is "Org mode for Emacs", repelling users who _do
>>not want_ to use Org inside Emacs. Maybe we can do better? Something
>>with less accent on Emacs like "Org mode: your life in plain text"
>
> I am not at all in favor of separating the 'Org Mode' name from 'GNU Emacs'.
> In any case, regardless of my opinion, I see here two problems:
>
> 1. "Org mode: your life in plain text". The word "mode" remains orphan:
> mode of what? It is clear that it is an Emacs mode, therefore it doesn't
> make much sense to hide Emacs and then suggest it.
>
> 2. One possibility: "Org: your life in plain text". But here what
> remains orphaned is "Org", too generic name. Unless "Org Mode" is a
> lexicalized construct, without reference to any emacs mode.
>
> (In any case, I would be extremely saddened if the reference to GNU Emacs
> disappears in the title, just to please a minority).
>

There is another big issue which people are not considering.

Org mode is a GNU project and it is part of Emacs. This actually has
some consequences, most notably -

- It is not acceptable for the project to explicitly or implicitly
  recommend or appear to recommend any non-free solutions or provide
  support for non-free software. Products like Github and MS Visual Code
  fall squarely in the unacceptable bucket.

- It would not be possible to reference any 3rd party libraries or
  programs which are not free software in the proposed list of external
  tools

- The suggested org mode in a browser example is unlikely to be
  acceptable to the FSF (or RMS). The FSF is very much against cloud
  based computing services or any web service which uses non-free
  Javascript (which is most of them and one of the many reasons Github
  is discouraged by the FSF).

A number of the ideas proposed are good ideas for org mode generally -
for example, a repository of reference documents which could be used for
testing purposes would be extremely useful for org-mode development and
testing. Likewise, any effort to clarify the syntax and remove any
ambiguities is beneficial for org mode itself. However, the emphasis and
priority needs to remain focused on org mode as a mode for Emacs. The
use of org mode by other external programs is really outside (but
related) to the project.

As a consequence and to eliminate/remove potential conflicts with FSF
philosophy and goals, it may be worth considering spinning off a
separate project. which happens to use the same markup syntax, but is
not a GNU project (though it would be good to still be GPL'd). 

If you want ot get a feel for the sort of issues which could come up
when trying to develop/support 3rd party tools, have a look at the
recent thread on creating an LSP server for emacs-lisp. While I
personally disagree with most of the fears raised by some contributors
to that thread and disagree with RMS's view that such a server would not
be in the best interests of Emacs, the thread does give you a sample of
the sort of issues which could come up with efforts to support or
encourage 3rd party libraries for org markup, much of which could be
avoided if the work is clearly not part of, related to or supported by
the main org-mode project. 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Yes, sorry for not explaining myself well: I was also referring to
> search results, not the title in the web site...
>
> But the question is: what need is there to remove the reference to Emacs
> in the search result? I think the emphasis is necessary. As we say in
> spanish, it's like putting the bandage on before the wound. If there are
> people who think that Org Mode can 'live' in some way outside of Emacs
> (a respectable opinion, but that I do not share, at least 100%), I think
> the burden of the work falls on them and not on us, the users of
> Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
> not my intention to initiate a controversy with it.

Ok. Let me explain my thought process.

First of all, there is no burden on users of Org mode in making edits to
orgmode.org. It is a burden on Org contributors.

One of the aims of my proposal is reducing this burden by involving
non-emacs users to provide contributions to Org (e.g. by making more
tests for Org-element parser). To do it, we need to make the
contribution process for non-emacs developers easier. Ideally, without
too much effort on our side.

The idea of involving non-emacs users does have a potential because we
do know that third-party tools are already using Org. The problem is the
disconnect between those tools and Org mode proper.

The sources of the disconnect are (1) lack of technical "blueprints" for
Org that do not require knowing Elisp; (2) lack of discovereability of
Org mode as something that can live outside narrow field of Emacs. In
this branch of our discussion, I am going to talk about the second
point.

People simply do not expect to see a markup language when they encounter
a link with "Org mode for Emacs" title. Someone looking for Org mode
markup to be used in, say, websites will think that "Org mode for Emacs"
is limited to Emacs. Someone just interested in plain text markup will
find no relevance at all.

Title is important. If we care at all about orgmode.org website
appearing in search results, we want the title and the summary to have 2
main properties: (1) Provide search keywords to make it searchable by
potentially interested people; (2) Provide a title that immediately
signal that our website contains the information people are looking for.

Now, we need to understand what kind of people may be looking to
orgmode.org website.

1. Existing emacs users

   If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
   is indeed recognisable. On the other hand, the word "Org mode" does
   not provide much further info, except that it is a major (or maybe
   minor?) mode for "Org"??
   
   Now, consider "Org mode: your life in plain text".
   For emacs users, "Org mode" is not just a strange phrase, but a very
   clear indication that we are talking about Emacs.
   The "your life in plain text" provides extra information about what
   "Org mode" refers to. Clearly, text documents and "your life in plain
   text" should resonate with every Emacs user's soul.

   We can change the second variant of the title to contain "Emacs", but
   will it add much value? I am not convinced. On the other hand, making
   title too long or too complex _is_ bad. Long titles tend to be
   skipped (there was even formal research on this!)

2. Non-emacs users interested in plain text markup

   These users know nothing about Emacs and "Org mode" has no meaning
   for them as is. So, we do need something more descriptive.
   Adding "Emacs" may be fine, but it will serve no purpose for people
   not familiar with emacs. Just another unknown term making the title
   longer.

3. Non-emacs users interested in GTD/project management, etc
   "Org mode: your life in plain text" is somewhat relevant when people
   are looking to manage "life" (typically true for GTD enthusiasts).

   Though we can probably do better for this category.
   Maybe "Org mode: manage your life and notes in plain text"?
   Though it makes the title less relevant to group #2.

4. Researchers looking for ipython-like environment

   Not covered, except by reading my proposed site summary. I am not
   sure how we can improve title for this audience.

5. ??? (Suggestions are welcome)

Of course, better suggestions for the title are welcome. I just wanted
to make it clear the reasoning I do not like the current title and how
the proposed alternative is better (though not ideal).

Finally, I want to emphasise that our aim for search engines is not
advertising Emacs (we already do it by trapping users inside Org and
making them switch to Emacs by force :evil_laughter:). The aim is
encouraging people to use and contribute to Org mode in useful ways
(even unrelated to writing Elisp or, really, any code at all).

Search result is just an entrance for users to be curious about the new
beast of "Org mode". The website front page is the means to make users
try. And the Org mode itself is the way to make users fall in love 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Heinz Tuechler]

Juan Manuel Macías wrote/hat geschrieben on/am 05.12.2021 12:08:

Ihor Radchenko writes:


I view "Org Mode" as a "brand name". Something uniquely identifying Org
mode and serving as a search term.


Yes, it makes sense.


Is it your principal position about the title specifically? Do you think
that just referring to Emacs in the website description is not
sufficient?



Note that my suggestion #1 has nothing to do with actual orgmode.org
front page. Just about how it appears in search results.


Yes, sorry for not explaining myself well: I was also referring to
search results, not the title in the web site...

But the question is: what need is there to remove the reference to Emacs
in the search result? I think the emphasis is necessary. As we say in
spanish, it's like putting the bandage on before the wound. If there are
people who think that Org Mode can 'live' in some way outside of Emacs
(a respectable opinion, but that I do not share, at least 100%), I think
the burden of the work falls on them and not on us, the users of
Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
not my intention to initiate a controversy with it.

Best regards,

Juan Manuel




As a humble emacs and org-mode user I second this "simple and subjectiv
opinion".
Therefore I would first mention org as an emacs mode and secondly as a
file format.

best regards,

Heinz

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Ihor Radchenko writes:

> I view "Org Mode" as a "brand name". Something uniquely identifying Org
> mode and serving as a search term.

Yes, it makes sense.

> Is it your principal position about the title specifically? Do you think
> that just referring to Emacs in the website description is not
> sufficient?

> Note that my suggestion #1 has nothing to do with actual orgmode.org
> front page. Just about how it appears in search results.

Yes, sorry for not explaining myself well: I was also referring to
search results, not the title in the web site...

But the question is: what need is there to remove the reference to Emacs
in the search result? I think the emphasis is necessary. As we say in
spanish, it's like putting the bandage on before the wound. If there are
people who think that Org Mode can 'live' in some way outside of Emacs
(a respectable opinion, but that I do not share, at least 100%), I think
the burden of the work falls on them and not on us, the users of
Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
not my intention to initiate a controversy with it.

Best regards,

Juan Manuel 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Ihor Radchenko]

Juan Manuel Macías  writes:

> I am not at all in favor of separating the 'Org Mode' name from 'GNU
> Emacs'.

To clarify, I do not suggest to remove the linkage between Org mode and
GNU Emacs. Just change the emphasis. I had no intention to remove the
reference to Emacs from search result. It should be still there in the
short description of orgmode.org. See the second part of my suggestion
#1.

> 1. "Org mode: your life in plain text". The word "mode" remains orphan:
> mode of what? It is clear that it is an Emacs mode, therefore it doesn't
> make much sense to hide Emacs and then suggest it.
>
> 2. One possibility: "Org: your life in plain text". But here what
> remains orphaned is "Org", too generic name. Unless "Org Mode" is a
> lexicalized construct, without reference to any emacs mode.

I view "Org Mode" as a "brand name". Something uniquely identifying Org
mode and serving as a search term.

> (In any case, I would be extremely saddened if the reference to GNU Emacs
> disappears in the title, just to please a minority).

Is it your principal position about the title specifically? Do you think
that just referring to Emacs in the website description is not
sufficient?

Note that my suggestion #1 has nothing to do with actual orgmode.org
front page. Just about how it appears in search results.

Best,
Ihor

Re: Org Mode "Contribute", "Maintenance" pages don't give repository.

[Daniel Fleischer]

Karl Fogel  writes:

> The reason I suggest this is that often when someone is hot on the trail of 
> debugging something, they haven't yet
> decided whether they want to become a contributor or not.  They just know 
> they want to ook at the latest sources so they
> can first figure out more about whatever ${technical_thing} they encountered. 
>  So making the latest sources very easy to
> find is a way of making it more likely that someone becomes a contributor, by 
> removing a commonly-encountered barrier.

You're right; I'll think of a way to present the git repo link, i.e. the
code earlier and more prominently for those who just want to jump and
examine the code.

-- 

Daniel Fleischer

Re: Some commentary on the Org Syntax document

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Nicolas Goaziou  writes:

>> But then, you do not remove the ambiguity that is condemned in this
>> thread. The greater element/element and greater element/lesser element
>> distinctions are equivalent, albeit not identical.
>
> AFAIU, elements = greater-elements ∪ lesser-elements
> The current syntax draft contains section "Greater elements" defining
> all the greater-elements and section "Elements" defining lesser-elements
> However, the word "elements" also refers to all possible elements in
> some parts of the draft.
> I propose to remove the ambiguity by referring to members of
> org-element-greater-elements as "greater elements"; to
> org-element-all-elements - org-element-greater-elements as "lesser
> elements"; and to org-element-all-elements as just "elements".

I understand the proposal. I'm just pointing out that currently, the
distinction exists already in some other form—as noted, what you call
lesser elements is currently the set difference between greater elements
and elements. Therefore, it is hardly a huge step forward.

In any case, both proposals are incomplete.

>> IIUC, you want three terms for elements (I am not even talking about
>> secondary strings, which can hold objects that are not part of
>> contents),
>
> Yep.

For clarity, I mean three terms /in addition to "elements"/. For
example, a drawer, a paragraph and a planning line all are elements.
Yet, they may be different enough so as to deserve their own label.

>> ... and probably two for objects: terminal and non-terminal.
>
> Sorry, I do not understand what you refer to here.

Some objects can contain other objects. Others cannot. Per above, it may
be ambiguous to use the term "object" for both categories.

In a nutshell, naming is hard.

Regards,
-- 
Nicolas Goaziou

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Ihor Radchenko writes:

> The website title is "Org mode for Emacs", repelling users who _do
>not want_ to use Org inside Emacs. Maybe we can do better? Something
>with less accent on Emacs like "Org mode: your life in plain text"

I am not at all in favor of separating the 'Org Mode' name from 'GNU Emacs'.
In any case, regardless of my opinion, I see here two problems:

1. "Org mode: your life in plain text". The word "mode" remains orphan:
mode of what? It is clear that it is an Emacs mode, therefore it doesn't
make much sense to hide Emacs and then suggest it.

2. One possibility: "Org: your life in plain text". But here what
remains orphaned is "Org", too generic name. Unless "Org Mode" is a
lexicalized construct, without reference to any emacs mode.

(In any case, I would be extremely saddened if the reference to GNU Emacs
disappears in the title, just to please a minority).

Best regards,

Juan Manuel 

Re: [PATCH] Fix org-comment-line-break-function

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> Thanks. Nicolas asked me to add tests for this patch. But I need to look
> into how to add tests for behavior of bindings. Need to add tests for M-j
> binding behavior when cursor is within a comment or outside.

I don't think you need to test the binding. You could test
(call-interactively o-c-l-b-f) instead. 

Besides, tests are not a blocker.

Regards,
-- 
Nicolas Goaziou

Re: [BUG] make test is extremely slow since b3cc2f793 [9.5.1 (9.5.1-g984367 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Sorry, but tests are still slow for me after the update.
> If I run the test from inside Emacs with ert, things got better, but
> make BTEST_RE="^test-org-cite/adjust-note" test
> still takes 12sec.

I cannot reproduce it. The test went down from 4.5s to 1.5s. I am using
Emacs 27.2.

Regards,
-- 
Nicolas Goaziou

Re: [BUG] Org requested me to send this after doing org-cycle [9.5.1 (release_9.5.1-205-g20ed79 @ /home/jay/Builds/org-mode/lisp/)]

[Ihor Radchenko]

Jay Dresser  writes:

> Here is Warnings and Backtrace
>
> == Backtrace ==
> Debugger entered--Lisp error: (error "rx ‘**’ range error")
>   signal(error ("rx ‘**’ range error"))

Can you update your Org mode to latest main? We had a recent commit
(328be6df4) aiming to solve this particular error.

Best,
Ihor