Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> While we're at it… maybe a 9.5.1 release is in order? Just sayin'…

Org 9.5.1 is planned to be the last stable version before the final
merge into the Emacs 28 branch, so I will ping the Emacs maintainers
first -- thanks for the reminder!

-- 
 Bastien

Dodgy Worg publishing? (was: [patch] Fix link to Library of Babel)

[Timothy]

Hi Thomas,

Thanks for catching this problem. To me this looks more like a problem with the
worg publishing than an outdated link. I’ve cc’d Bastien as he’s much more
familiar with the Worg publish process than I am.

“Thomas S. Dye”  writes:

> The attached patch changes a 404 link to the working link used on Worg.

All the best,
Timothy

Re: [PATCH] org-src: Reset buffer-modified-p after fontifying

[Timothy]

Hi Clément,

I've just had a look at your patch, and it seems very reasonable to me.
Hence, I've just pushed it as ebd06c1 :)

> Hi all,
>
> * lisp/org-src.el (org-src-font-lock-fontify-block): Reset the
> modification flag of the temporary fontification buffer after
> fontifying.
>
> Without this some modes cause Emacs to prompt about unsaved buffers
> when exiting: `Save buffer *org-src-fontification:...-mode*?'
>
> (I'm seeing this with Proof General's coq-mode, specifically.)
>
> Clément.
>
> [2. text/x-patch; 
> 0001-org-src-Reset-buffer-modified-p-after-fontifying.patch]...

--
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Greg Minshall]

Timothy,

> Just a quick note (see my long recent reply to Tim where I expand on this 
> more),
> but this isn’t new behaviour (isn’t actually affected by my recent changes) 
> and
> my concerns are with the viability of the necessary changes rather than 
> whether
> this would be good (we are of the same mind I think).

yes, i see.  i hadn't realized that.

maybe, though, we could start off by warning people who are writing
integer values; then deprecate it; then, N-releases from now, make it
illegal?

such a path might be worth it.  or, at least the warnings --
irrespective, i would say, of whether or not the decimal value turns
into some "reasonable" file mode value.

cheers, Greg

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Greg,

> i’d push back, even here, on allowing decimal.  file modes are bit
> masks.  to me, offering a way to set a bit mask via a *decimal* value
> seems a mistake.

Just a quick note (see my long recent reply to Tim where I expand on this more),
but this isn’t new behaviour (isn’t actually affected by my recent changes) and
my concerns are with the viability of the necessary changes rather than whether
this would be good (we are of the same mind I think).

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tim,

>> The parsing of “555” to the integer 555 is done by
>> org-babel-parse-header-arguments, and so can’t really be changed.
>
> I don't understand this. Why can't it be changed?

Well, it can't be changed without changing
org-babel-parse-header-arguments, which is quite a major change and I
suspect may be a breaking change.

Maybe it's fine? I just don't feel confident about this.

> When I said disable base 10 values, what I meant was generate an error
> if the value looks like it is base 10 i.e. does not have a leading o or
> #o. This makes it clear it has to be specified as an octal value and
> will alert users to this fact.

This is all well and good, but the point I'm making is that since due to
the current behaviour of org-babel-parse-header-arguments we can't
distinguish between :tangle-mode (identity #o555) and :tangle-mode 365
putting this idea /into practice/ doesn't look like it will be easy.

It's also worth noting that with regard to the recent changes that have
been made, this is not a new issue.

>> I think the ls-style is quite valuable for two reasons. It’s
>> well-established thanks to ls, and is particularly good for
>> understanding permissions at a glance.
>
> I would agree it is an established way to display the permissions
> associated with a filesystem object, but disagree it is a well
> established way to set such values - I know of no other tool which uses
> this format.

The driving motivation here is that while the tools which you mention do
not use this for setting permissions (e.g. chmod), they are only used
for /setting/ permissions. Since Org files aren't write-only, and
occasionally we go back and look at what we've written :P I think
allowing a format that is optimised for ease-of-reading instead of
ease-of-writing makes some sense. It is in this respect that I think
ls -l style is a good idea.

> It is also not the same as the ls -l display (no object
> type indicator). The ls -l also displays sticky bit, uid and gid. Does
> your format also support setting these values (something which can be
> done with the octal or symbolic formats) i.e. support s, S, t and T for
> the 'executable' bit for user/group?

Ah, I'm afraid that I'm not that up-together on sticky bits. I suspect
that it's not just the ls -l style that will need tweaking. I'll read up
on this in the next few days and update the ML.

> Personally, I prefer the symbolic form as it is shorter and clear. I
> find the ls -l form too easy to get wrong (especially with getting the
> number of '-' correct).

Isn't choice a great thing? :D In seriousness, this is exactly why I
think it's worth providing these options. At least thinking back to when
I started using Linux a few years ago I would have said the same thing
about the octal form, and was completely unfamiliar with chmod. I expect
different people to have different preferences with these three options,
but for one of them to be something most people are happy with.

>> Tim suggested that invalid forms should cause tangling to fail, but I feel 
>> this
>> may be a bit much. Personally I’m inclined to either
>> • warn, and don’t touch the file permissions (this is what currently occurs)
>> • use a very conservative file permission (e.g. rw——-).
>
> I'm unsure on this. My concern is people may not notice the warning and
> then be surprised later. Given the potential security issues, a later
> surprise is something to be avoided even if it is inconvenient. With
> respect to the default action to take, I would suggest we also need to
> look at the default umask setting for the user and if that is more
> restrictive, use that rather than some value like rw--- For all we
> know, the user has set a specific umask for a valid reason and will be
> surprised if emacs just ignores that to do what it wants (another
> surprise to be avoided).

> The user is not required to specify a mode. However, if they do and if
> we cannot interpret what they have specified without ambiguity, we
> should throw an error and cease processing. Making a guess as to what
> they intended in this situation is IMO a big mistake.

I don't see how using the default permissions is a potential security
risk? Could it surprise the user, yes, but that seems unavoidable when
the user is doing something invalid.

> My only preference for "#o" over just "o" prefix is to clearly signal to
> the user that it is an octal value and avoid the situation where you
> might glance a value and see the leading 'o' as a '0', missing the point
> it is an octal value not a decimal one. However, this seems like a low
> risk, so I'm happy either way.

Well, I've got "o" for now but that's not set in stone. With a lower
case "o" I feel the risk for confusion with "0" is quite low (besides
which a "0" prefix seems to be the C-style for octal anyway).

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Greg Minshall]

hi, Timothy,

> I’ve just pushed three commits that
> 1. Add “o555” as an octal shorthand
> 2. Perform a simple check that integer modes are valid*
> 3. Make the ls-style regex stricter
> ...
> * For example, “:tangle-mode 755” will now produce the warning:
>   “1363 is not a valid file mode octal. Did you give the decimal value 755 by
>   mistake?”. Maybe it would be worth adding “if so try o755” or similar?

i'd push back, even here, on allowing decimal.  file modes are bit
masks.  to me, offering a way to set a bit mask via a *decimal* value
seems a mistake.

my +/- one cent.

cheers, Greg

[ANN] EmacsConf 2021 schedule + how to watch and participate

[Amin Bandali]

Dear Emacsian friends,

This is it, the final stretch until EmacsConf 2021, coming up on
November 27 and 28 less than a week from now!  A few weeks ago,
we excitedly shared the EmacsConf 201 program with you.  We're now
happy to share the conference schedule with you, i.e. the program
plus each talk's (approximate) scheduled time slot:

 https://emacsconf.org/2021/schedule

All of the times listed on the schedule are in EST (UTC-5).  You can
click on each talk's title to open its page for more information,
including its scheduled time in your local time (displaying local time
requires running a tiny bit of AGPLv3+-licensed free/libre JavaScript
code, included on the talk pages).  For prerecorded talks, this time
is also when the talk's video will be made available on the same page.
Please note the '~' tildes near the times, indicating that they are
approximations and not meant to be taken as exact times.

On November 27 and 28 you will be able to watch the livestreams via
https://live.emacsconf.org, which also has details on how to watch the
streams using media players that support streaming (like mpv and VLC).
Also, for Asia-Pacific folks, there will be an alternate stream by
LibreAustralia, at 11:00-17:30 UTC+11 on Sunday, November 28.  Please
see the  https://libreau.org/upcoming.html#emacsconf21  page on their
site for more details and how to tune into the alternate stream.

Last but not least, please see the  https://emacsconf.org/2021  page
of the EmacsConf wiki for more details on watching and participating
in the conference.

We hope to see you all around on November 27-28 for EmacsConf 2021!

Amin Bandali, Leo Vivier, and Sacha Chua,
On behalf of the EmacsConf 2021 organizers team

Re: [PATCH] Accept more :tangle-mode specification forms

[Tim Cross]

Timothy  writes:

> * For example, “:tangle-mode 755” will now produce the warning:
>   “1363 is not a valid file mode octal. Did you give the decimal value 755 by
>   mistake?”. Maybe it would be worth adding “if so try o755” or similar?


I think that warning will be confusing for users. They will look at the
value 1363 and be confused where that value came from, likely assuming
they have found a bug in org mode. Perhaps something simpler like

"Decimal 555 is not a valid file mode specification. Did you mean to
specify it as an octal value? If so, prefix it with a 'o'".

Re: [PATCH] Accept more :tangle-mode specification forms

[Tim Cross]

Timothy  writes:

> The parsing of “555” to the integer 555 is done by
> org-babel-parse-header-arguments, and so can’t really be changed. For a simple
> octal notation our best bet is adding non-digit characters so it is left as a
> string, e.g. “o555”.

I don't understand this. Why can't it be changed? Doing so may not be
trivial, but I cannot see any reason it cannot be changed if we wanted
to. However, perhaps all we really need to do is look at the value
returned and if the value for mode is not a string, throw an error and
if it is a string, either match symbolic format or verify it has a
leading 'o' or '#o' and treat as octal, else throw an error. 

> Giving errors when a base 10 value has been given by accident would be a nice
> idea, but in practice isn’t easy as many base 10 values are valid octal 
> values,
> e.g. #o555 = 365. Likewise, I don’t think Tim’s suggestion of disallowing base
> 10 values is feasible.
>

Did you mean many base 10 values are valid mode setting values? All base
10 values can be expressed in octal, so I'm assuming you meant some base
10 values will translate into octal values which are valid mode setting
values. My point here is that such translations are unlikely to be what
the user expected.

I have never seen anyone use base 10 to specify mode settings. It takes
a lot more mental agility to derive a base 10 version for a valid mode
setting than it does to use octal, which has a clear and natural mapping
of the octal characters to the underlying bits used to represent the
mode for user, grop and other (as well as setuid, setgid and sticky
bit).

When I said disable base 10 values, what I meant was generate an error
if the value looks like it is base 10 i.e. does not have a leading o or
#o. This makes it clear it has to be specified as an octal value and
will alert users to this fact. 

> Regarding the concern that “we are making a rod for our back by trying to make
> this overly clever” and that the change makes it too complex — I disagree.
> Having had this discussion earlier we’ve ended up with,
> • a shorthand for octal
> • ls-style
> • chmod-style
> I think this small collection of distinct and simple input methods isn’t 
> overly
> clever or complex, and feel that it strikes the right balance between too many
> options and too little flexibility.
>

We will probably have to disagree here as I remain unconvinced. I guess
time will tell.

> Octal is great, for those that are familiar with it. Likewise, chmod-style is
> quite natural for those who are used to chmod. There’s little added complexity
> to the Org code base as we simply pass this to the Emacs function
> file-modes-symbolic-to-number. I think the ls-style is quite valuable for two
> reasons. It’s well-established thanks to ls, and is particularly good for
> understanding permissions at a glance.

I would agree it is an established way to display the permissions
associated with a filesystem object, but disagree it is a well
established way to set such values - I know of no other tool which uses
this format. It is also not the same as the ls -l display (no object
type indicator). The ls -l also displays sticky bit, uid and gid. Does
your format also support setting these values (something which can be
done with the octal or symbolic formats) i.e. support s, S, t and T for
the 'executable' bit for user/group?

>For reading Org files I think this is
> advantageous compared to the other styles. I’m don’t find assertions that this
> is non-typical or unpredictable well-founded. Each style/syntax is 
> well-defined,
> simple, distinct, and taken from very common/wide spread usage.
>

Again, I know of no other tool which uses the ls -l format to set file
mode permissions, so I cannot agree with the assertion it is well
established. Personally, I prefer the symbolic form as it is shorter and
clear. I find the ls -l form too easy to get wrong (especially with
getting the number of '-' correct).

> Tim suggested that invalid forms should cause tangling to fail, but I feel 
> this
> may be a bit much. Personally I’m inclined to either
> • warn, and don’t touch the file permissions (this is what currently occurs)
> • use a very conservative file permission (e.g. rw——-).

I'm unsure on this. My concern is people may not notice the warning and
then be surprised later. Given the potential security issues, a later
surprise is something to be avoided even if it is inconvenient. With
respect to the default action to take, I would suggest we also need to
look at the default umask setting for the user and if that is more
restrictive, use that rather than some value like rw--- For all we
know, the user has set a specific umask for a valid reason and will be
surprised if emacs just ignores that to do what it wants (another
surprise to be avoided).

The user is not required to specify a mode. However, if they do and if
we cannot interpret what they have specified without ambiguity, we
should throw an error and cease process

Re: Merging ox-texinfo+ into ox-texinfo

[Jonas Bernoulli]

Nicolas Goaziou  writes:
> I like the idea, thank you for suggesting it.

Great :D

>>#+TEXINFO_DEFFN: t
>
> The chosen UI is rather odd however. I cannot think of another use of
> controlling export thhough "#+keyword: boolean" syntax. Usually, we
> extend the "options" keyword. It could become, for example:
>
>   #+options: texinfo+:t
>
> Could it be possible to use that syntax instead?

Of course.  I probably used the separate keyword because all the entries
for ox-texinfo's :options-alist did that too, but if that's not how this
is usually done for booleans, then I see no reason not to change it.

>> It is possible to mix the two styles; you can use the ox-texinfo+.el
>> style for most or all definitions but use the additional flexibility of
>> ox-texinfo.el, when that is needed.
>
> How is it possible? Keywords are global. How do you change value
> locally?

Well... it turned out not to be true, but I should be able to get it to
work.  The idea is that the new shorthand handling is only used if such
a shorthand is actually used by the item that is being processed.  All
other list items should effectively be treated as before, but that isn't
the case yet.  For now all non-shorthand list items are simply treated
as @item, but `org-texinfo+-item' could be changed to instead fall back
to the `org-texinfo-item's default behavior in those cases.  (It would
still have to check whether it needs to begin and/or end the "item
container" (itemize/table/...), so it is not completely trivial, but
should be doable.)

For testing purposes I have moved the relevant `ox-texinfo+.el' code
into `ox-texinfo.el', changing only how the feature has to be enabled,
and everything that worked before continues to work.  If the feature is
enabled, then my manuals are exported the same as before and with the
feature disabled org-manual.org also results in the same texi file as
before.

So I have to address the above issue and then we also have to think
about naming.  I was thinking about using the term "shorthands"; instead
of "texinfo-deffn:t" we could use "texinfo-shorthands:t".  The functions
need to be renamed too of course, but IMO simply replacing "ox-texinfo+"
with "ox-texinfo-shorthand" is quite ugly.  Do you have a suggestion for
that?  All the new functions could be placed in the "Item" section.

 Jonas

[Aside] Generating commit messages for Org

[Timothy]

Hi All,

A few hours ago I noticed that I’ve made a few very minor mistakes in some of my
recent commit messages for Org. Realistically I don’t think I’m going to stop
making occasional mistake any time soon, eve if they do become rarer. So, I’ve
whipped up a magit hook that looks at the diff and fills in a /correct/ skeleton
in the commit message buffer.

For example, here’s what I get if a queue a few of my currently unstaged changes
┌
│ * lisp/org.el (org-place-formula-image, org-format-latex):
│ 
│ * lisp/org-macs.el (org-compile-file, org-async-queue):
└

This currently works with elisp functions/variables/etc. and headings from
documentation files. I’m sure it has a few rough edges, but it’s looking
promising so far.

Maybe a few of you might also find it of interest?

(the relevant commit is 
).

Another thought I’ve had is a commit lint function for flycheck to check some
extra things (two spaces after sentences, commit subject starting with a capital
letter, etc.), but I haven’t looked into that at all.

All the best,
Timothy

Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Ihor Radchenko  writes:
>
>> Bastien, should we package Org 9.5 to Org ELPA?
>
> Done, thanks a lot for the heads up!

While we're at it… maybe a 9.5.1 release is in order? Just sayin'…

Regards,
-- 
Nicolas Goaziou

Re: Org ELPA: does not include 9.5 as expected, archives appear largely identical?

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Hmm. I missed that we promised Org 9.5 to be distributed via old
> channels. I confirm that Org 9.5 is missing from Org ELPA.

Sorry for that.  The *tar files were actually built when 9.5 came out,
but somehow uploaded to the wrong directory.

> Bastien, should we package Org 9.5 to Org ELPA?

Done, thanks a lot for the heads up!

-- 
 Bastien

Re: [PATCH] oc-basic: add shorten-name function

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> Subject: [PATCH] oc-basic: Add function to shorten names
>
> * lisp/oc-basic.el (org-cite-basic--shorten-names): new function to
> shorten author names

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou

Is mouse necessary when working with PDF?

[Ypo]

What tool do you use to highlight PDF? Do you copy your highlights to a 
.org file?


I use org-noter, but it seems the mouse is necessary to work with PDF.

Best regards,

Ypo

Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> I updated the patch. If you have no objections on the new wording, I
> will push it to main.

Thanks for the update, and apologies in advance for being bold, as
I have some additional comments about it.

> * doc/org-manual.org (Emphasis and Monospace): Advice users to insert
> zero width space when Org does not parse emphasized text correctly.

Org _does_ parse emphasized text correctly. It may be seen as
unintuitive, but it's really a fontification problem. Anyway, this is
just a commit message…

> +=*=, =/=, =_=, ===, and =~= symbols inside =verbatim= or ~code~ can
> +sometimes produce unexpected markup.  

OK, but it's not limited to symbols within verbatim or code. What about
something like:

  Sometimes, when marked text also contains the marker character itself,
  the result may be unsettling.

  ...example follows (see below)...

> +#+begin_example
> +/The whole line is supposed to be marked italic, but the following
> +~user/?variable~ contains italics =/= marker and confuses Org parser/.
> +#+end_example

The whole line is not supposed to be marked as italic, as long as we
follow Org syntax. And the parser is not confused at all. The user may
be, however.

I suggest:

  /One may expect this whole sentence to be italicized, but the
  following ~user/?variable~ contains =/= character, which effectively
  stops emphasis there./

> +You can use zero width space to help Org sorting out the ambiguity.
> +See [[*Escape Character]] for more details.

Thinking about it a bit more, you might be right: we may slightly change
the closing part of the emphasis regexp, e.g.:

  (seq
   (not space)
   (group ,mark)
   (or (any space ?- ?')
   (and (any ?. ?, ?\; ?: ?! ?? ?\" ?\) ?\} ?\\ ?\[) (or space line-end))
   line-end))

The logic behind this is that in regular text, we assume usual
punctuation rules apply.

My concern is that the more complicated is the rule, the more difficult
it is to predict. Also, we introduce new corner case, e.g.,

  Woot! I just released Org *10*.0!

So, I'm not totally convinced it is worth the trouble.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Accept more :tangle-mode specification forms

[tomas]

On Sat, Nov 20, 2021 at 10:50:40PM +0800, Timothy wrote:
> Hi Thomas (& co.),

[...]

> Thanks. It helps that this list is fairly friendly to begin with :)

Friendly lists are made of friendly people, and there, your contribution
is... special.

> * For example, “:tangle-mode 755” will now produce the warning:
>   “1363 is not a valid file mode octal. Did you give the decimal value 755 by
>   mistake?”. Maybe it would be worth adding “if so try o755” or similar?

Awesome :)

Thanks & cheers
 - t


signature.asc
Description: PGP signature

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Thomas (& co.),

>> […] I’m thinking either “o555” or “#o555” would be a good improvement over
>> “(identity #o555), but am open to other suggestions.
>
> That’s reasonable. I’d even tend to disallow decimal. In usage, it’s too
> exotic and the potential for someone entering “just a number” expecting
> for it to be read as octal is too high. Is it worth the risk?

I’ve just pushed three commits that
1. Add “o555” as an octal shorthand
2. Perform a simple check that integer modes are valid*
3. Make the ls-style regex stricter

> Timothy, I really admire your patience, and your incredibly friendly way
> of doing things :)

Thanks. It helps that this list is fairly friendly to begin with :)

All the best,
Timothy

* For example, “:tangle-mode 755” will now produce the warning:
  “1363 is not a valid file mode octal. Did you give the decimal value 755 by
  mistake?”. Maybe it would be worth adding “if so try o755” or similar?

Re: [BUG] (org-element-context) on some link does not return search-option correctly

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> When I put point on an custom org link:
>
> #+begin_src org
> [[pdf:~/Org/Wiki/Computer Technology/Programming/Programming 
> Languages/Clojure/data/Books/Clojure经典实例.pdf::40++0.00][Clojure经典实例.pdf: Page 
> 40]]
> #+end_src
> ...
> You can see the result ~:search-option nil~. It suppose to be ~40++0.00~.

AFAIK, only file: links are parsed to have search-option.

If you want a custom link type to have search-option property, you
should use link abbrev.

Best,
Ihor

Re: [PATCH] Accept more :tangle-mode specification forms

[tomas]

On Sat, Nov 20, 2021 at 04:08:16PM +0800, Timothy wrote:
> Hi Tom, Tim, Thomas, and Greg,

[...]

> • a shorthand for octal
> • ls-style
> • chmod-style
> I think this small collection of distinct and simple input methods isn’t 
> overly
> clever or complex, and feel that it strikes the right balance between too many
> options and too little flexibility.

That sounds good.

> [...] I’m
> thinking either “o555” or “#o555” would be a good improvement over “(identity
> #o555), but am open to other suggestions.

That's reasonable. I'd even tend to disallow decimal. In usage, it's too
exotic and the potential for someone entering "just a number" expecting
for it to be read as octal is too high. Is it worth the risk?

Timothy, I really admire your patience, and your incredibly friendly way
of doing things :)

Cheers
 - t


signature.asc
Description: PGP signature

Re: [BUG] error on org-element--cache-process-request when TAB indent region select properties drawer

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> The bellowing error often raised when I region select multiple headlines 
> which contains properties
> drawer
>
> #+begin_src org
> |*** headline 1
> :PROPERTIES:
> :kkk:  2
> :END:
>
> ,*** headline 2
> :PROPERTIES:
> :kkk:  3
> :END:
> |
> #+end_src
>
> (Here the ~|~ and ~|~ represent the region select two headline 
> properties drawer.)
>
> then press =[Tab]= key to indent properties drawers will raise this error:

Thanks for the report! Are you able to reproduce it with clean emacs
config? I am unable to reproduce the problem with the provided example
and with org-adapt-indentation set to t.

Best,
Ihor

Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’

[Max Nikulin]

On 16/11/2021 14:43, Ihor Radchenko wrote:

Max Nikulin writes:


Better docs and some restriction on defcustom values were discussed earlier:
https://list.orgmode.org/87k0oyd3pw@nicolasgoaziou.fr/
Nicolas Goaziou. Re: Using backticks for the inline code delimeter? Mon,
19 Apr 2021 11:27:07 +0200

Sorry, I have not prepared a patch. I am not confident with defcustom
fine tuning and have not experimented with it since that time.


Maybe something like the attached?


My draft version is attached. Ihor, thank you for inspiration. Feel free 
to improve it. I hope, it makes problem more apparent to user who tries 
to customize markers. Have I missed some undesired side effects?


Unfortunately with "set" type in defcustom "catch inappropriate" item is 
not hidden for valid configuration.


I do not mind if you commit any variant.
diff --git a/doc/org-manual.org b/doc/org-manual.org
index a38dbec4a..b62c52e61 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -10814,9 +10814,11 @@ and verbatim string is not processed for Org specific syntax; it is
 exported verbatim.
 
 #+vindex: org-fontify-emphasized-text
+#+vindex: org-emphasis-alist
 To turn off fontification for marked up text, you can set
-~org-fontify-emphasized-text~ to ~nil~.  To narrow down the list of
-available markup syntax, you can customize ~org-emphasis-alist~.
+~org-fontify-emphasized-text~ to ~nil~.  For more fine-tuned
+fontification consider themes. It is possible to customize
+~org-emphasis-alist~ variable, but it will be deprecated.
 
 ** Subscripts and Superscripts
 :PROPERTIES:
diff --git a/lisp/org.el b/lisp/org.el
index cb1b58c51..ea62ae0b2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3771,6 +3771,25 @@ newline  The maximum number of newlines allowed in an emphasis exp.
 
 You need to reload Org or to restart Emacs after setting this.")
 
+(defun org-set-emphasis-alist (var value)
+  "Set VAR (`org-emphasis-alist') to VALUE and check it for ignored characters.
+Warn user that Org syntax can not be extended with new emphasis markers
+if such attempt is detected.  The function is intended for :set argument
+of `defcustom'."
+  (set var value)
+  (let ((unsupported
+	 (delq nil
+	   (mapcar
+(lambda (entry)
+  (let ((marker (car entry)))
+(unless (member marker '("*" "/" "_" "=" "~" "+")) marker)))
+value
+(when unsupported
+  (message "Warning! Unsupported markup characters '%s' detected in `%s'"
+	   (mapconcat #'identity unsupported " ")
+	   (symbol-name var
+  value)
+
 (defcustom org-emphasis-alist
   '(("*" bold)
 ("/" italic)
@@ -3779,23 +3798,41 @@ You need to reload Org or to restart Emacs after setting this.")
 ("~" org-code verbatim)
 ("+" (:strike-through t)))
   "Alist of characters and faces to emphasize text.
+Warning! This variable will be deprecated in favor of themes.
+
 Text starting and ending with a special character will be emphasized,
 for example *bold*, _underlined_ and /italic/.  This variable sets the
 marker characters and the face to be used by font-lock for highlighting
 in Org buffers.
 
+Do not change the characters and do not add new ones to use custom
+markers for existing styles or to introduce new styles.  Org syntax is
+not meant to be configurable and such modifications will not work with
+export.
+
 You need to reload Org or to restart Emacs after customizing this."
   :group 'org-appearance
   :set 'org-set-emph-re
   :version "24.4"
   :package-version '(Org . "8.0")
+  :set #'org-set-emphasis-alist
   :type '(repeat
-	  (list
-	   (string :tag "Marker character")
-	   (choice
-	(face :tag "Font-lock-face")
-	(plist :tag "Face property list"))
-	   (option (const verbatim)
+  (group
+   (choice
+:tag "Marker"
+(const :tag "*Bold*" "*")
+(const :tag "/Italic/" "/")
+(const :tag "_Underline_" "_")
+(const :tag "+Strike-through+" "+")
+(const :tag "=Verbatim=" "=")
+(const :tag "~Code~" "~")
+;; To warn users that it does not work.
+(string :tag "Unsupported ignored character"))
+   (choice
+:tag "Font"
+(face :tag "Face")
+(plist :tag "Property list"))
+   (option (const verbatim)
 
 (defvar org-protecting-blocks '("src" "example" "export")
   "Blocks that contain text that is quoted, i.e. not processed as Org syntax.

[BUG] (org-element-context) on some link does not return search-option correctly

[Christopher M. Miles]

When I put point on an custom org link:

#+begin_src org
[[pdf:~/Org/Wiki/Computer Technology/Programming/Programming 
Languages/Clojure/data/Books/Clojure经典实例.pdf::40++0.00][Clojure经典实例.pdf: Page 
40]]
#+end_src

Then press =[M-: (org-element-context) RET]= to get link element properties. I 
got:

#+begin_example
(link (:type "pdf" :path "~/Org/Wiki/Computer 
Technology/Programming/Programming 
Languages/Clojure/data/Books/Clojure经典实例.pdf::40++0.00" :format bracket 
:raw-link "pdf:~/Org/Wiki/Computer Technology/Programming/Programming 
Languages/Clojure/data/Books/Clojure经典实例.pdf::40++0.00" :application nil 
:search-option nil ...))
#+end_example

You can see the result ~:search-option nil~. It suppose to be ~40++0.00~.

I tested with other link like this:

#+begin_src org
[[file:hs_err_pid20491.log::kkk+2]]
#+end_src

It returns ~:search-option~ correctly:

#+begin_example
(link (:type "file" :path "hs_err_pid20491.log" :format bracket :raw-link 
"file:hs_err_pid20491.log::kkk+2" :application nil :search-option "kkk+2" ...))
#+end_example

-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

[BUG] error on org-element--cache-process-request when TAB indent region select properties drawer

[Christopher M. Miles]

The bellowing error often raised when I region select multiple headlines which 
contains properties
drawer

#+begin_src org
|*** headline 1
:PROPERTIES:
:kkk:  2
:END:

,*** headline 2
:PROPERTIES:
:kkk:  3
:END:
|
#+end_src

(Here the ~|~ and ~|~ represent the region select two headline 
properties drawer.)

then press =[Tab]= key to indent properties drawers will raise this error:

#+begin_example
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  >(26723 nil)
  (and (org-element-property :cached (aref next-request 4)) 
(org-element-property :begin (aref next-request 4)) (> (org-element-property 
:begin (aref next-request 4)) (org-element-property :begin parent)))
  (if (and (org-element-property :cached (aref next-request 4)) 
(org-element-property :begin (aref next-request 4)) (> (org-element-property 
:begin (aref next-request 4)) (org-element-property :begin parent))) nil (let* 
((v next-request)) (aset v 4 parent)))
  (let ((next-request (nth 1 org-element--cache-sync-requests))) (if (and 
(org-element-property :cached (aref next-request 4)) (org-element-property 
:begin (aref next-request 4)) (> (org-element-property :begin (aref 
next-request 4)) (org-element-property :begin parent))) nil (let* ((v 
next-request)) (aset v 4 parent
  (progn (if (or org-element--cache-diagnostics (eq 
org-element--cache-self-verify 'backtrace)) (progn (let* ((format-string 
(concat (format "org-element-cache diagnostics(%s): " ...) "Reached next 
request.")) (format-string (format format-string))) (if 
org-element--cache-diagnostics (warn "%s" format-string) (if 
org-element--cache-diagnostics-ring nil (setq 
org-element--cache-diagnostics-ring (make-ring 
org-element--cache-diagnostics-ring-size))) (ring-insert 
org-element--cache-diagnostics-ring format-string) (let ((next-request (nth 
1 org-element--cache-sync-requests))) (if (and (org-element-property :cached 
(aref next-request 4)) (org-element-property :begin (aref next-request 4)) (> 
(org-element-property :begin (aref next-request 4)) (org-element-property 
:begin parent))) nil (let* ((v next-request)) (aset v 4 parent (throw 'quit 
t))
  (if (and next-request-key (not (org-element--cache-key-less-p key 
next-request-key))) (progn (if (or org-element--cache-diagnostics (eq 
org-element--cache-self-verify 'backtrace)) (progn (let* ((format-string 
(concat ... "Reached next request.")) (format-string (format format-string))) 
(if org-element--cache-diagnostics (warn "%s" format-string) (if 
org-element--cache-diagnostics-ring nil (setq 
org-element--cache-diagnostics-ring ...)) (ring-insert 
org-element--cache-diagnostics-ring format-string) (let ((next-request (nth 
1 org-element--cache-sync-requests))) (if (and (org-element-property :cached 
(aref next-request 4)) (org-element-property :begin (aref next-request 4)) (> 
(org-element-property :begin (aref next-request 4)) (org-element-property 
:begin parent))) nil (let* ((v next-request)) (aset v 4 parent (throw 'quit 
t)))
  (if (org-element--cache-key-less-p key start) nil (if (and next-request-key 
(not (org-element--cache-key-less-p key next-request-key))) (progn (if (or 
org-element--cache-diagnostics (eq org-element--cache-self-verify 'backtrace)) 
(progn (let* ((format-string ...) (format-string ...)) (if 
org-element--cache-diagnostics (warn "%s" format-string) (if 
org-element--cache-diagnostics-ring nil ...) (ring-insert 
org-element--cache-diagnostics-ring format-string) (let ((next-request (nth 
1 org-element--cache-sync-requests))) (if (and (org-element-property :cached 
(aref next-request 4)) (org-element-property :begin (aref next-request 4)) (> 
(org-element-property :begin ...) (org-element-property :begin parent))) nil 
(let* ((v next-request)) (aset v 4 parent (throw 'quit t))) (if (or 
exit-flag (org-element--cache-interrupt-p time-limit)) (progn (if (or 
org-element--cache-diagnostics (eq org-element--cache-self-verify 'backtrace)) 
(progn (let* ((format-string ...) (format-string ...)) (if 
org-element--cache-diagnostics (warn "%s" format-string) (if 
org-element--cache-diagnostics-ring nil ...) (ring-insert 
org-element--cache-diagnostics-ring format-string) (let* ((v request)) 
(aset v 0 key)) (let* ((v request)) (aset v 4 parent)) (throw 
'org-element--cache-interrupt nil))) (if (= 0 offset) nil (if (>= 
org-element--cache-diagnostics-level 3) (progn (if (or 
org-element--cache-diagnostics (eq org-element--cache-self-verify 'backtrace)) 
(progn (let* (... ...) (if org-element--cache-diagnostics ... ... ...)) 
(org-element--cache-shift-positions data offset)) (let ((begin 
(org-element-property :begin data))) (while (and parent (<= 
(org-element-property :end parent) begin)) (setq parent (org-element-property 
:parent parent))) (cond ((and (not parent) (= 0 offset)) (throw 'quit nil)) 
((and parent (or (not (memq ... org-element-greater-elements)) (and 
(org-element-property :contents-begin parent) (< ... .

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tom, Tim, Thomas, and Greg,

Thank you all for your thoughts. I’ll try to respond to all the main points
raised below.

First off, in case it wasn’t clear in my earlier email when I said “#o555 works”
or the like I was being lazy and really meaning “(identity #o555)” works.

The parsing of “555” to the integer 555 is done by
org-babel-parse-header-arguments, and so can’t really be changed. For a simple
octal notation our best bet is adding non-digit characters so it is left as a
string, e.g. “o555”.

┌
│ 1 -> (org-babel-parse-header-arguments ":tangle-mode 555" light)
│ 1 <- org-babel-parse-header-arguments: ((:tangle-mode . 555))
│ ==
│ 1 -> (org-babel-parse-header-arguments ":tangle-mode o555" light)
│ 1 <- org-babel-parse-header-arguments: ((:tangle-mode . "o555"))
└

So while I’d like it if we could easily apply Tom’s suggestion to “change the
radix for bare integers to 8 when reading that particular header”, I don’t think
that’s very feasible, unfortunately.

Giving errors when a base 10 value has been given by accident would be a nice
idea, but in practice isn’t easy as many base 10 values are valid octal values,
e.g. #o555 = 365. Likewise, I don’t think Tim’s suggestion of disallowing base
10 values is feasible.

Regarding the concern that “we are making a rod for our back by trying to make
this overly clever” and that the change makes it too complex — I disagree.
Having had this discussion earlier we’ve ended up with,
• a shorthand for octal
• ls-style
• chmod-style
I think this small collection of distinct and simple input methods isn’t overly
clever or complex, and feel that it strikes the right balance between too many
options and too little flexibility.

Octal is great, for those that are familiar with it. Likewise, chmod-style is
quite natural for those who are used to chmod. There’s little added complexity
to the Org code base as we simply pass this to the Emacs function
file-modes-symbolic-to-number. I think the ls-style is quite valuable for two
reasons. It’s well-established thanks to ls, and is particularly good for
understanding permissions at a glance. For reading Org files I think this is
advantageous compared to the other styles. I’m don’t find assertions that this
is non-typical or unpredictable well-founded. Each style/syntax is well-defined,
simple, distinct, and taken from very common/wide spread usage.

Tim suggested that invalid forms should cause tangling to fail, but I feel this
may be a bit much. Personally I’m inclined to either
• warn, and don’t touch the file permissions (this is what currently occurs)
• use a very conservative file permission (e.g. rw——-).

So, as I see it the main decision that needs to be made is how to handle the
octal shorthand, now that it’s clear that the original plan is flawed? I’m
thinking either “o555” or “#o555” would be a good improvement over “(identity
#o555), but am open to other suggestions.

All the best,
Timothy

Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

[Daniel Kraus]

Max Nikulin  writes:

> Thank you for contribution. I do not have strong objection any more. I am not
> familiar with babel internals, so I leave further discussion to maintainers.
>
> If you have not signed copyright assignment yet, likely you should do it to
> proceed (I am unsure concerning precise rules concerning line counting). See
> https://orgmode.org/contribute.html and
> https://orgmode.org/worg/org-contribute.html for details.

Thank you very much for your insights.
I filled out the copyright assignment and waiting for them.
I'll mail again when it's done.
(Maybe this is even small enough to count as tinychange if the
assignment should take a long time).

Cheers,
  Daniel