Here is Warnings and Backtrace
> From: Ihor Radchenko
> To: Jay Dresser
> Cc: emacs-orgmode@gnu.org
> Subject: 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/)]
> Date: Sat, 04 Dec 2021 21:56:25 +0800
>
>
Dear Fellow Orgers,
The recent spike of discussions following Karl's presentation in
Emacsconf 2021 revealed a lot of controversy among Org and Emacs
enthusiasts. Yet, Karl named a number of very real problems surrounding
Org mode usage outside Emacs.
>From the narrow perspective of this mailing
Nicolas Goaziou writes:
>> Maybe we can just say "... lesser elements" that cannot contain other
>> elements."? Then, we mention that some elements cannot contain objects
>> in the description of those elements.
>
> But then, you do not remove the ambiguity that is condemned in this
> thread.
Max Nikulin writes:
> >8
> * A
> B
> 8<
>
> C-c C-* while cursor is at the end of second line
Thanks! I was able to reproduce. And it is bad news.
> Current command: (nil 26 30)
> Chars modified: 26
> Buffer modified: 30
This has the same footprint with
(let
Michael 1 writes:
> Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
> org-docview-open("file.odt::1")
> org-link-open((link (:type "docview" :path "file.odt::1" :format bracket
> :raw-link "docview:file.odt::1" :application nil :search-option nil :begin
> 364 :end 453
Nicolas Goaziou writes:
>> I noticed that make test became extremely slow recently.
>> The first bottleneck can be seen in
>>
>> make BTEST_RE="^test-org-cite/adjust-note" test
>>
>> passed 1/1 test-org-cite/adjust-note (12.321278 sec)
>>
>> The test takes 12sec!
>
> Fixed. Thank you.
Sorry,
On Sat, Dec 4, 2021, 5:25 PM Tim Cross wrote:
>
> Given that Nicholas cannot remember the reason for the original function
> and suspects it was meant to be an internal only function, I think this
> patch is probably the best way forward and should be applied.
>
Thanks. Nicolas asked me to add
Is it related to
https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html
I implemented that idea for fun once:
https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
John
---
Professor John Kitchin
Given that Nicholas cannot remember the reason for the original function
and suspects it was meant to be an internal only function, I think this
patch is probably the best way forward and should be applied.
Kaushal Modi writes:
> On Tue, Nov 30, 2021 at 6:29 PM Tim Cross wrote:
>
> It would
idk and will go along with whatever developers decide, but your note
was a good reminder that visible mode can be checked.
also made me wonder if it is possible to move anything from org-macs
out to topic-specific files like org-visibility.el or so? no?
[idk what org visibility functions do
the quoted post below, which had message id
20524da70901041233g105f372fv175a47dc9884f...@mail.gmail.com , starts a
thread relevant to the current discussion of syntax, at least
historically, maybe practically. could not find it online.
there were succeeding threads with examples and other stuff
Sébastien Miquel writes:
> Hi,
>
> Thank you for having a look.
>
> Tim Cross writes:
>> This also seems like an edge case and I'm not convinced yet another
>> option is justified. Why have eilisp in org blocks rather than an
>> emacs-lisp block?
>
> By org src blocks I meant an org emacs-lisp
On 04 Dec 2021, Daniel Fleischer wrote:
The "Contribute" page at
https://orgmode.org/worg/org-contribute.html does not mention
git://git.sv.gnu.org/emacs/org-mode.git . Actually, now that I
look around, the "Maintenance" page at
https://orgmode.org/worg/org-maintenance.html doesn't mention
> Since org is a valid export backend though, perhaps this behaviour should be
> reserved for @@:…@@, i.e. no export backend, which I think semantically fits
> fairly nicely.
This ends up being even more convenient than I initially realized.
The current spec for export snippets is ambiguous when
Greg Minshall writes:
> hi, Tim,
>
>> The key question is what is the use case for having this 'mixed' content
>> in a table cell?
>
> in my case, i am putting RFC822('ish) e-mail addresses in a column of an
> org-mode table. and, i want to extract them.
>
> | oxymo...@example.com
Max Nikulin writes:
> On 04/12/2021 04:48, Tim Cross wrote:
>> My vote is to simply maintain the status quo. Don't modify the syntax,
>> don't make the zero space character somewhat special or processed in any
>> special way during export. In short, accept that inner word markup has
>> only
Karl Fogel [2021-12-04 Sat 14:59] wrote:
> The "Contribute" page at https://orgmode.org/worg/org-contribute.html does
> not mention
> git://git.sv.gnu.org/emacs/org-mode.git . Actually, now that I look around,
> the "Maintenance" page at
> https://orgmode.org/worg/org-maintenance.html doesn't
Hi John,
John Kitchin writes:
> Along these lines (and combining the s-exp suggestion from Max) , you
> can achieve something like this with links.
I like this idea of merging the Maxim's proposal with the power of links.
In any case, this and other workarounds provided here make it clear
The "Contribute" page at
https://orgmode.org/worg/org-contribute.html does not mention
git://git.sv.gnu.org/emacs/org-mode.git . Actually, now that I
look around, the "Maintenance" page at
https://orgmode.org/worg/org-maintenance.html doesn't mention the
repository address either. It does
The function `org-truely-invisible-p' is defined in
'lisp/org-macs.el', but it is not used anywhere anymore in Org
Mode, nor is it used anywhere in GNU Emacs (I checked on both
'emacs-28' branch and 'master' branch).
The last (and possibly only?) call to that function was removed
from
Hi Tom,
> After a bunch of rambling (see below if interested), I think I have
> a solution that should work for everyone. The key realization is that
> what we really want is the ability to have a “parse me separately”
> type of syntax. This meets the intra-word syntax needs and might
> meet some
Along these lines (and combining the s-exp suggestion from Max) , you can
achieve something like this with links.
This is lightly tested, and I am not thrilled with the eval for exporting,
but I couldn't get a macro to work on the export function to avoid it, and
this is just a proof of concept
Hi all,
After a bunch of rambling (see below if interested), I think I have
a solution that should work for everyone. The key realization is that
what we really want is the ability to have a "parse me separately"
type of syntax. This meets the intra-word syntax needs and might
meet some other
On 2021-12-04, at 08:22, Ihor Radchenko wrote:
> Marcin Borkowski writes:
>> 2. We modify Emacs itself to somehow highlight the ZWS. There is (kind
>> of) a precedent – a no-breaking space is already fontified with
>> =nobreak-space= face. At the very least, make whitespace-mode somehow
>>
Hello,
Ihor Radchenko writes:
> I noticed that make test became extremely slow recently.
> The first bottleneck can be seen in
>
> make BTEST_RE="^test-org-cite/adjust-note" test
>
> passed 1/1 test-org-cite/adjust-note (12.321278 sec)
>
> The test takes 12sec!
Fixed. Thank you.
Regards,
--
Max Nikulin writes:
> Maybe this issue should be considered independently of itra-word emphasis.
Yes I agree. Apologies for mixing up this topic in the discussion about
intra-word emphasis...
> Second and third examples looks like they should be supported. Ihor
> mentioned treating punctuation
Am 03.12.2021 um 15:24 schrieb Max Nikulin:
On 03/12/2021 02:03, Nicolas Goaziou wrote:
Denis Maier writes:
As for suggestions: If just using /intra/word creates ambiguities, what
about the asciidoc solution? So //intra//word?
I sympathize to the idea of intra-word emphasis, but the syntax
Dear John,
It is in fact an org cite issue. With org-ref 2, I used to write:
something like [[cite:key][page n]] with C-l + description .
With org-ref 3, I see that I must write now: [[cite:key page n]] and it
works with ieee csl style also.
(I still do not know how to quote directly
On 04/12/2021 04:48, Tim Cross wrote:
My vote is to simply maintain the status quo. Don't modify the syntax,
don't make the zero space character somewhat special or processed in any
special way during export. In short, accept that inner word markup has
only limited support and if that is a
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.
Org's big strength is in its simplicity. This comes at a price -
limitations in what can be done. If those limitations are unacceptable,
Dear John,
Another more important point. It is now more probably a point where
org-ref 3 needs to be improved: it seems to me that the format
[numerical_reference, page] or (name_reference, page) cannot be produced
for the html export.
(The format [numerical_reference, page] was produced with
Ihor Radchenko writes:
>> There are actually three types of elements: not all elements can contain
>> objects.
>
> You are right. However, I am not sure if it is a good idea to mention
> this in the introduction part of the syntax document.
>
> Maybe we can just say "... lesser elements" that
On 04/12/2021 00:13, John Kitchin wrote:
[1]class="csl-right-inline">G. Scalia, C.A. Grambow, B. Pernici, Y.-P. Li,
W.H. Green, https://doi.org/10.1021/acs.jcim.9b00975
I don't see why there is an extra line there, I guess it is some CSS
styling.
by default is a block-level element,
Nicolas Goaziou writes:
>> This sounds reasonable. We can change
>>
>> - Three categories are used to classify these environments: “Greater
>> elements”, “elements”, and “objects”, from the broadest scope to the
>> narrowest. The word “element” is used for both Greater and non-Greater
>>
Jay Dresser writes:
>
> I did org-cycle, via S-TAB, and an error occurred. I don't know why.
Thanks for reporting!
Could you also post the warning text next time you encounter it? The
text contains important clues that can help us to understand what went
wrong.
Best,
Ihor
On 03/12/2021 02:09, Juan Manuel Macías wrote:
I believe, that emphasis marks are a part of Org that can be very
shocking to new users. I mean, there is a series of behaviors that seem
obvious and trivial in the emphasized text, but that in Org are not
possible out of the box, unless you
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello,
Ihor Radchenko writes:
> Timothy writes:
>
>> ⁃ Elements
>> • Greater Elements
>> • (other) Elements
>>
>> to
>>
>> ⁃ Elements
>> • Greater Elements
>> • Lesser Elements
>
> This sounds reasonable. We can change
>
> - Three categories are used to classify these environments:
Hi Ihor,
> This sounds reasonable. We can change
> [snip]
I’ll make a note in my draft then.
>>> [Comments on headings and sections]
>>
>> This accords with my reading of the document and the way I’ve implemented
>> things
>> in OrgMode.jl (see
>>
39 matches
Mail list logo
