[-- Attachment #1: Type: text/plain, Size: 736 bytes --] Markdown uses backticks to denote inline code which should get special (typically monospace) formatting, org uses the tilde character. Now I know that org is not markdown, is far more powerful than markdown, and is not (mostly) the same use cases as markdown. But this one use case *does* overlap. And the backticks thing is becoming so ingrained that not only do I reach for it all the time, but I've seen it crop up on this very mailing list and even in some README.org documents. I would like to submit that org consider adopting backticks as an alternate way of denoting inline code. Aside from any official movement, I would like to add this to my own files - is there a straightforward way to extend the org parser to do this? [-- Attachment #2: Type: text/html, Size: 848 bytes --]
Hi, George> Aside from any official movement, I would like to add this to my own files - is there a straightforward way to extend the org parser to do this? Quick and Dirty: Bind key '`' to ~ in Emacs? (I guess it is clear I haven't thought about the consequences.) Cheers Rasmus
autofrettage <autofrettage@protonmail.ch> writes:
> Quick and Dirty: Bind key '`' to ~ in Emacs?
>
> (I guess it is clear I haven't thought about the consequences.)
You can add that just to the Org-mode map. That wouldn't be too bad,
there's always C-q.
--
Timothy
George Mauer writes: > is there a straightforward way to extend the org parser to do this? I don't think so. It seems the emphasis markers are hard-coded in various places. From a quick look at the code, you'd have to customize `org-emphasis-alist` and redefine `org-set-emph-re` and `org-do-emphasis-faces`. Maybe that'd be enough. For the cosmetic part, there's this piece of code from https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html that displays org's `=` and `~` markers as ```. -- Sébastien Miquel
George Mauer <gmauer@gmail.com> writes:
> I would like to submit that org consider adopting backticks as an alternate
> way of denoting inline code.
Just FYI, this is almost certainly not going to happen.
--
Timothy
> > I would like to submit that org consider adopting backticks as an alternate
> > way of denoting inline code.
>
> Just FYI, this is almost certainly not going to happen.
Perhaps as unlikely as Python adopts 'i' instead of 'j' in complex numbers? It looks awful for all but electrical and electronics engineers.
Cheers
Rasmus
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --] The approach I've taken is to try and stop using Markdown altogether and write everything in Org, exporting to Markdown for those destinations that need it. You could even use https://github.com/tecosaur/org-pandoc-import to automatically convert/reconvert other formats as needed, and https://github.com/tecosaur/emacs-everywhere to do it even in other applications. It's not perfect - I still have to type Markdown sometimes, but you can eventually start losing the ingrained backtick habit :) --Diego On Wed, Mar 31, 2021 at 8:49 PM George Mauer <gmauer@gmail.com> wrote: > Markdown uses backticks to denote inline code which should get special > (typically monospace) formatting, org uses the tilde character. > > Now I know that org is not markdown, is far more powerful than markdown, > and is not (mostly) the same use cases as markdown. But this one use case > *does* overlap. And the backticks thing is becoming so ingrained that not > only do I reach for it all the time, but I've seen it crop up on this very > mailing list and even in some README.org documents. > > I would like to submit that org consider adopting backticks as an > alternate way of denoting inline code. > > Aside from any official movement, I would like to add this to my own files > - is there a straightforward way to extend the org parser to do this? > [-- Attachment #2: Type: text/html, Size: 1950 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2906 bytes --] The point I'm making is that this is already the de-facto thing. People on this email list do it, people in talking in irc and in forums do it. I don't think it has so much to do with markdown documents as it does with Slack, Discord, Teams, even google chat adopting that convention. All our fingers are getting trained to backticks everywhere *except* org documents. As those already have trained us to use this construction, it might be a good idea to just swallow the pill. I don't think there's much of a slippery slope here. Most popular chat programs don't support making headings markdown-style for example, and even if they did I don't see many people attempting to use that. Trying to enumerate syntax that I feel falls squarely in this category I come up with only a few - lists with dashes, org supports that just fine *bold text* with stars, again org already does this `backtick code`, org doesn't handle this and actually uses the tilde as a delimeter which is extra jarring since its a strikethrough in many chat apps That's really it. You could maybe also argue > gt for quotation - that would be be nice as we're used to it from email as well, but I don't see people using it all that much but that's really it as far as common usage right now. Sure that list might grow as different usages become common, but I would hope org is not against evolving in small and reasonable ways as the expectations of users shift. On Wed, Mar 31, 2021 at 3:31 PM Diego Zamboni <diego@zzamboni.org> wrote: > The approach I've taken is to try and stop using Markdown altogether and > write everything in Org, exporting to Markdown for those destinations that > need it. > > You could even use https://github.com/tecosaur/org-pandoc-import to > automatically convert/reconvert other formats as needed, and > https://github.com/tecosaur/emacs-everywhere to do it even in other > applications. > > It's not perfect - I still have to type Markdown sometimes, but you > can eventually start losing the ingrained backtick habit :) > > --Diego > > > > On Wed, Mar 31, 2021 at 8:49 PM George Mauer <gmauer@gmail.com> wrote: > >> Markdown uses backticks to denote inline code which should get special >> (typically monospace) formatting, org uses the tilde character. >> >> Now I know that org is not markdown, is far more powerful than markdown, >> and is not (mostly) the same use cases as markdown. But this one use case >> *does* overlap. And the backticks thing is becoming so ingrained that not >> only do I reach for it all the time, but I've seen it crop up on this very >> mailing list and even in some README.org documents. >> >> I would like to submit that org consider adopting backticks as an >> alternate way of denoting inline code. >> >> Aside from any official movement, I would like to add this to my own >> files - is there a straightforward way to extend the org parser to do this? >> > [-- Attachment #2: Type: text/html, Size: 3970 bytes --]
[-- Attachment #1: Type: text/plain, Size: 740 bytes --] George Mauer <gmauer@gmail.com> writes: > - lists with dashes, org supports that just fine or stars (not possible with org) or plus (in org). > *bold text* with stars, again org already does this Note that this does not match markdown: Markdown uses *emphasis* and **strong**. > `backtick code`, org doesn't handle this and actually uses the tilde as a > delimeter which is extra jarring since its a strikethrough in many chat apps tilde or equals. - list *bold* =code= Adding more syntax is a slippery slope, because then `foo` can never be used for anything else, and there is a limited amount of usable syntax elements. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> George Mauer <gmauer@gmail.com> writes:
>> - lists with dashes, org supports that just fine
>
> or stars (not possible with org) or plus (in org).
>
>> *bold text* with stars, again org already does this
>
> Note that this does not match markdown: Markdown uses *emphasis* and **strong**.
>
>> `backtick code`, org doesn't handle this and actually uses the tilde as a
>> delimeter which is extra jarring since its a strikethrough in many chat apps
>
> tilde or equals.
>
> - list
> *bold*
> =code=
>
> Adding more syntax is a slippery slope, because then `foo` can never be
> used for anything else, and there is a limited amount of usable syntax
> elements.
>
Yes, I think this is potentially a bad idea. Org parsing is already slow
enough without adding yet more syntax and font-locking complexity.
I also suspect this is not as simple as just adding this to org parsing
- all backends and many contributed packages would likely also need to
be updated to understand the new syntax. So probably not a trivial
change and a change which is likely to have real impact wrt backwards
compatibility.
Part of the issue here is that there is no markdown 'standard'. There
are a number of markdown 'flavors' or dialects. Org is just another one
(and one of the older ones at that).
--
Tim Cross
just personal opinion but i wouldn't want org's syntax to get more heterogeneous and non-orthogonal/non-factored. i could see room for an orthogonal/factored flexible syntax, like "parsing risk" and "extensible syntax" threads on this ml. this would be the one syntax to rule them all, /vaguely/ similar to how you can do stuff with cl's parser.... ...which here would require user-definability so that the user can specify that $[emphasis :type 'code :hide t :marker ?`] shows as `. the general idea would be desirable if new syntax is needed, but if it is only used for this purpose it would imo be overkill*n. On 3/31/21, Tim Cross <theophilusx@gmail.com> wrote: > > "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: > >> George Mauer <gmauer@gmail.com> writes: >>> - lists with dashes, org supports that just fine >> >> or stars (not possible with org) or plus (in org). >> >>> *bold text* with stars, again org already does this >> >> Note that this does not match markdown: Markdown uses *emphasis* and >> **strong**. >> >>> `backtick code`, org doesn't handle this and actually uses the tilde as >>> a >>> delimeter which is extra jarring since its a strikethrough in many chat >>> apps >> >> tilde or equals. >> >> - list >> *bold* >> =code= >> >> Adding more syntax is a slippery slope, because then `foo` can never be >> used for anything else, and there is a limited amount of usable syntax >> elements. >> > > Yes, I think this is potentially a bad idea. Org parsing is already slow > enough without adding yet more syntax and font-locking complexity. > > I also suspect this is not as simple as just adding this to org parsing > - all backends and many contributed packages would likely also need to > be updated to understand the new syntax. So probably not a trivial > change and a change which is likely to have real impact wrt backwards > compatibility. > > Part of the issue here is that there is no markdown 'standard'. There > are a number of markdown 'flavors' or dialects. Org is just another one > (and one of the older ones at that). > > -- > Tim Cross > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
[-- Attachment #1: Type: text/plain, Size: 1482 bytes --] Grepping for src_ in *.el in the org distro shows 11 hits over 3 files: ob-core.el, ob-exp.el, and org-element.el. That's where you can start working if you want to copy those functions into your init files and modify them for yourself, or you can see if maybe using function advice is sufficient. It's your emacs config, you can modify it however you want, if what you want is to write the code yourself. If you want someone else to write the code for you, however, you'll have to convince someone to do it. If you want someone else to write the code for you and also adopt it into the main distro, that's an even tougher task... -- Bill On Wed, Mar 31, 2021 at 1:50 PM George Mauer <gmauer@gmail.com> wrote: > Markdown uses backticks to denote inline code which should get special > (typically monospace) formatting, org uses the tilde character. > > Now I know that org is not markdown, is far more powerful than markdown, > and is not (mostly) the same use cases as markdown. But this one use case > *does* overlap. And the backticks thing is becoming so ingrained that not > only do I reach for it all the time, but I've seen it crop up on this very > mailing list and even in some README.org documents. > > I would like to submit that org consider adopting backticks as an > alternate way of denoting inline code. > > Aside from any official movement, I would like to add this to my own files > - is there a straightforward way to extend the org parser to do this? > [-- Attachment #2: Type: text/html, Size: 2142 bytes --]
George and all, whether it's the right thing to do or not, i don't know. but, i'm very sympathetic to the urge. even when posting to the list, the reflex to use back ticks is strong. Greg
On 2021-03-31, at 21:19, Timothy <tecosaur@gmail.com> wrote: > autofrettage <autofrettage@protonmail.ch> writes: > >> Quick and Dirty: Bind key '`' to ~ in Emacs? My first thought exactly. And I'd definitely use it - I need to use Markdown more often than I'd like to (chat, wikis, (cloud-based) task management system...). >> (I guess it is clear I haven't thought about the consequences.) > > You can add that just to the Org-mode map. That wouldn't be too bad, > there's always C-q. and you can also make it that pressing the backtick /twice/ yields a normal backtick (and that can be actually coded in more than one way). Or, you can make /three/ backticks in a row enter a src block (which would be even more Markdown-y). Best, -- Marcin Borkowski http://mbork.pl
I vote against backticks, since I think we can learn to live with some diversity. Running with the crowd, the latest fashion, would, in the end, leave us with something like Word and Windows, that is, something which is seductively easy to use the first two days, but a pain in the neck the rest of your life. Unfortunately, I have seen these tendencies in Linux, in Emacs -- yes, live-move-visual is now default, which makes Emacs less consistent, but more like Word -- and even in my favourite window manager. Please evaluate the design of Org Mode (and other things) without putting a value on how similar it is to other things. A bicycle would appear more familiar to a car driver if we replaced the handlebar with a steering wheel, but it wouldn't make the bike any better. If someones fingers cannot adjust, let him/her customise a bit. Just my two cents. Rasmus
On 01/04/2021 02:24, Sébastien Miquel wrote:
> George Mauer writes:
>> is there a straightforward way to extend the org parser to do this?
>
> For the cosmetic part, there's this piece of code from
> https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html
Personally, I consider marker appearance as a minor issue. The real pain
is that, besides thinking on content, it is necessary to concentrate
which type of plain text markup must be used at every moment. Switching
between chat with markdown and bug tracker with a flavor of wiki markup,
it requires additional efforts to avoid incorrect formatting. I do not
mind to have backticks for code snippets in org but unfortunately the
choice was done many years ago, so such change is unrealistic.
Remapping "`" is rather intrusive. Would not be better to define a
command and key binding that fix markers on the current line or in the
current paragraph?
A strange idea. If logic were perfectly decoupled from formatting it
would be possible to have org actions with various formats (markdown,
reStructured text, etc.) with some extensions to markup and limitations
in respect to org functionality. I know that is unfeasible.
Maxim Nikulin <manikulin@gmail.com> writes: > On 01/04/2021 02:24, Sébastien Miquel wrote: >> George Mauer writes: >>> is there a straightforward way to extend the org parser to do this? >> For the cosmetic part, there's this piece of code from >> https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html > > Personally, I consider marker appearance as a minor issue. The real pain is > that, besides thinking on content, it is necessary to concentrate which type of > plain text markup must be used at every moment. Switching between chat with > markdown and bug tracker with a flavor of wiki markup, it requires additional > efforts to avoid incorrect formatting. I do not mind to have backticks for code > snippets in org but unfortunately the choice was done many years ago, so such > change is unrealistic. > > Remapping "`" is rather intrusive. Would not be better to define a command and > key binding that fix markers on the current line or in the current paragraph? > > A strange idea. If logic were perfectly decoupled from formatting it would be > possible to have org actions with various formats (markdown, reStructured text, > etc.) with some extensions to markup and limitations in respect to org > functionality. I know that is unfeasible. This whole issue is why I made https://github.com/tecosaur/emacs-everywhere and https://github.com/tecosaur/org-pandoc-import :P -- Timothy
n.b. everybody knows better in this thread, but the docstring of org-emphasis-alist seemed to me like `test` + reload would fontify.
Samuel Wales <samologist@gmail.com> writes:
> n.b. everybody knows better in this thread, but the docstring of
> org-emphasis-alist seemed to me like `test` + reload would fontify.
Getting backticks to font-lock correctly is relatively easy. Getting the
exporters to understand the new syntax is more of a challenge as is how
to deal with backwards compatibility so that all your existing org files
don't need to be modified.
--
Tim Cross
On Fri, Apr 02 2021, Tim Cross wrote:
> Getting backticks to font-lock correctly is relatively easy. Getting the
> exporters to understand the new syntax is more of a challenge
Don't the exporters work off of some intermediate representation, like Pandoc
does? I kinda thought that was what `org-element.el` was all about...
And of course I meant to type ~org-element.el~ there... :D
--
Joost Kremers
Life has its moments
Joost Kremers <joostkremers@fastmail.fm> writes:
> On Fri, Apr 02 2021, Tim Cross wrote:
>> Getting backticks to font-lock correctly is relatively easy. Getting the
>> exporters to understand the new syntax is more of a challenge
>
> Don't the exporters work off of some intermediate representation, like Pandoc
> does? I kinda thought that was what `org-element.el` was all about...
>
> And of course I meant to type ~org-element.el~ there... :D
Yes, at least most of the core ones should. However, I would still
expect some surprises and of course there are no guarantees regarding
the contrib and other external ones. Despite attempts to abstract the
syntax to make it 'flexible', I would be surprised if there is not
functionality in some of the exporters which has implicit assumptions
regarding the syntax being used and is not isolated from such changes.
Note that I'm not saying this cannot be done or even that is should not
be done. I just want to highlight that just making changes to how org
deals with it at the 'presentation' layer may not be sufficient and that
you would have to verify there are no unexpected side effects in any of
the exporters. If you wanted to keep backwards compatibility or make
using ` and alternative to ~, you would also need to decide/verify
things like `word~ (i.e. mixed delimiters) are handled correctly (i.e.
simple regex with alternatives would not be sufficient - would need to
be a match which allowed both but ensured matching values).
Of course, there is a big difference between making a change to org and
making a change to an individual's own org instance. So if we are
talking about how someone can hack their own org instance to use `
instead of ~, it can be much simpler as they don't have to worry about
the bits they don't use or backwards compatibility. The downside then
becomes just the hassle of maintaining your hacks over subsequent org
releases. One reason why I would probbly go with a method which just
changes how I input data. For example, I would define a function which
inserts ~ or if a region is marked, surrounds it in ~ and then just bind
that to a key, never using ~ or ` directly to mark text.
--
Tim Cross
On Do 01 Apr 2021 at 09:32, autofrettage <autofrettage@protonmail.ch> wrote:
> I vote against backticks, since I think we can learn to live with some
> diversity. Running with the crowd, the latest fashion, would, in the
> end, leave us with something like Word and Windows, that is, something
> which is seductively easy to use the first two days, but a pain in the
> neck the rest of your life.
>
> Unfortunately, I have seen these tendencies in Linux, in Emacs -- yes, live-move-visual is now default, which makes Emacs less consistent, but more like Word -- and even in my favourite window manager.
>
> Please evaluate the design of Org Mode (and other things) without
> putting a value on how similar it is to other things. A bicycle would
> appear more familiar to a car driver if we replaced the handlebar with
> a steering wheel, but it wouldn't make the bike any better.
>
> If someones fingers cannot adjust, let him/her customise a bit.
>
> Just my two cents.
>
> Rasmus
+1
'Andreas
Is there any reason why folks couldn't just customize org-emphasis-alist using a file local variable? Just add ("`" org-code verbatim) and see what happens. Knowing a bit about the codebase this will probably lead to trouble during export because the backends are likely unaware, but at least it can be specified in the file. In general adding a token that duplicates the function of an existing token is a bad idea. For a similar reason mixed delimiters cannot be allowed, they make the grammar completely ambiguous. Best, Tom
On Sat, Apr 03 2021, Tom Gillespie wrote:
> Is there any reason why folks couldn't just customize
> org-emphasis-alist using a file local variable? Just add ("`" org-code
> verbatim) and see what happens. Knowing a bit about the codebase this
> will probably lead to trouble during export because the backends are
> likely unaware,
Yes, I tried this at one time because /.../ is used in linguistics to denote
phonological representations. So I removed the entry for `/` in
`org-emphasis-alist` and replaced it with something else. It worked up until the
point where you start exporting.
If all exporters worked off an internal representation such as what is
returned by `org-element-parse-buffer`, it should be easier to modify the
front-end syntax.
--
Joost Kremers
Life has its moments
Hello, Joost Kremers <joostkremers@fastmail.fm> writes: > On Sat, Apr 03 2021, Tom Gillespie wrote: >> Is there any reason why folks couldn't just customize >> org-emphasis-alist using a file local variable? [...] > If all exporters worked off an internal representation such as what is > returned by `org-element-parse-buffer`, it should be easier to modify the > front-end syntax. I think they do. Anyway, one of the goals of Org is to provide a universal document format. It is not there yet, but allowing local modifications of the syntax certainly goes against that goal. Regards, -- Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 551 bytes --] On Sun, Apr 4, 2021 at 7:21 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Anyway, one of the goals of Org is to provide a universal document > format. It is not there yet, but allowing local modifications of the > syntax certainly goes against that goal. > Allowing local modifications lets people experiment and share their impressions. So rather than going against the goal of a universal document format, it is crucial for progress towards it. Unless the org-mode format is perfect for universal needs now and into the future? -- Bill [-- Attachment #2: Type: text/html, Size: 927 bytes --]
On 02/04/2021 18:23, Andreas Eder wrote:
> On Do 01 Apr 2021 at 09:32, autofrettage wrote:
>>
>> Please evaluate the design of Org Mode (and other things) without
>> putting a value on how similar it is to other things. A bicycle would
>> appear more familiar to a car driver if we replaced the handlebar with
>> a steering wheel, but it wouldn't make the bike any better.
>>
>> If someones fingers cannot adjust, let him/her customise a bit.
>
> +1
I think, for a part of people in this thread another comparison is more
appropriate. Bike handlebars are quite specialized and each type of bike
has its own shape to be more convenient. And steering wheel is more
suitable when wider range of angles is required. Choices of characters
to denote code snippets are quite arbitrary. Imagine that you have to
drive at the right lane while you are around the office. But as soon as
you cross the river on your everyday trip to home, you have to stick to
the left side of the road... There is no apparent advantage or defect of
any of these rules. The mix is rather dangerous.
"Emacs everywhere" suggested in another message could be a rescue in
some cases. Unless original formatting is already broken by another
external tool.
Customization becames a pain when communication is involved.
OK, what might be a reason why org does not use backticks is that
backticks around lisp expressions could be confusing.
Hello, Bill Burdick <bill.burdick@gmail.com> writes: > Allowing local modifications lets people experiment and share > their impressions. Local modifications are allowed, this is Elisp after all. I don't see a good reason to make it easier, tho. > Unless the org-mode format is perfect for universal needs now and into the > future? I think you misunderstood me. I'm not against Org syntax evolving somehow if necessary, but I see no good in users cooking their own pet Org syntax. IMO, Markdown syntax is an example not to follow. Therefore, I would not recommend digging in that direction. Regards, -- Nicolas Goaziou
On Sun, Apr 04 2021, Nicolas Goaziou wrote: > Joost Kremers <joostkremers@fastmail.fm> writes: > >> On Sat, Apr 03 2021, Tom Gillespie wrote: >>> Is there any reason why folks couldn't just customize >>> org-emphasis-alist using a file local variable? > > [...] > >> If all exporters worked off an internal representation such as what is >> returned by `org-element-parse-buffer`, it should be easier to modify the >> front-end syntax. > > I think they do. So if I were so inclined, I could write a parser for Markdown that produces this internal format and get all the export targets that Org has? (Not that I'm so inclined... Just wondering. ;-) ) > Anyway, one of the goals of Org is to provide a universal document > format. It is not there yet, but allowing local modifications of the > syntax certainly goes against that goal. I tend to agree that allowing local modifications of Org's syntax is pretty much pointless, but then why is `org-emphasis-alist` a user option? I originally thought its purpose was to customise Org's syntax, until I found that the exporters didn't play ball. ;-) -- Joost Kremers Life has its moments
Hello, Joost Kremers <joostkremers@fastmail.fm> writes: > So if I were so inclined, I could write a parser for Markdown that produces this > internal format and get all the export targets that Org has? (Not that I'm so > inclined... Just wondering. ;-) ) You can turn this internal format back to Org syntax with `org-element-interpret-data' and you can do anything with it, including exporting it. >> Anyway, one of the goals of Org is to provide a universal document >> format. It is not there yet, but allowing local modifications of the >> syntax certainly goes against that goal. > > I tend to agree that allowing local modifications of Org's syntax is pretty much > pointless, but then why is `org-emphasis-alist` a user option? In practice, the faces, i.e., the values, are meant to be customizable, not the keys. Regards, -- Nicolas Goaziou
On 05/04/2021 06:06, Nicolas Goaziou wrote:
> Joost Kremers writes:
>
>> I tend to agree that allowing local modifications of Org's syntax is pretty much
>> pointless, but then why is `org-emphasis-alist` a user option?
>
> In practice, the faces, i.e., the values, are meant to be customizable,
> not the keys.
It would be great to have more clear statement in the doc string. Even
in the manual it could be stressed stronger. Unsure if the current
phrase really forbids extension, I would rather tend to interpret it as
invitation to customize the list: "To narrow down the list of available
markup syntax, you can customize ~org-emphasis-alist~."
Maybe the code interpreting this variable could spit a warning on
attempt to add new emphasizing characters.
Hello, Maxim Nikulin <manikulin@gmail.com> writes: > On 05/04/2021 06:06, Nicolas Goaziou wrote: >> Joost Kremers writes: >> >>> I tend to agree that allowing local modifications of Org's syntax is pretty much >>> pointless, but then why is `org-emphasis-alist` a user option? >> In practice, the faces, i.e., the values, are meant to be >> customizable, >> not the keys. > > It would be great to have more clear statement in the doc string. Even > in the manual it could be stressed stronger. Patch welcome! > Unsure if the current phrase really forbids extension, I would rather > tend to interpret it as invitation to customize the list: "To narrow > down the list of available markup syntax, you can customize > ~org-emphasis-alist~." It depends. IMO, narrowing down the list means removing some markup from fontification, i.e., setting a nil face. However, it shouldn't prevent Org from interpreting such syntax. You can use zero-width space for that. > Maybe the code interpreting this variable could spit a warning on > attempt to add new emphasizing characters. As a first step, the type of the defcustom shouldn't be '(repeat ...), but a fixed list. Regards, -- Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 934 bytes --] On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, <tecosaur@gmail.com> wrote: > > autofrettage <autofrettage@protonmail.ch> writes: > > > Quick and Dirty: Bind key '`' to ~ in Emacs? > > > > (I guess it is clear I haven't thought about the consequences.) > > You can add that just to the Org-mode map. That wouldn't be too bad, > there's always C-q. > Is it possible to bind a key in org-mode but bind it back to another character if you're in a special environment, eg a code block? That would probably be my preference. So "`" inserts "~" when you're writing text but "`" in an elisp or markdown SRC block, for instance. I guess just write a function that checks context? Presumably all the overloaded keybindings do this already but I guess I don't really know how they do so. I do in general wish it were easier to switch between writing markdown and writing org, since I often have to write markdown for work. > > -- > Timothy > > [-- Attachment #2: Type: text/html, Size: 1720 bytes --]
I have used an approach like the one here https://endlessparentheses.com/define-context-aware-keys-in-emacs.html to make context aware key-bindings. Matt Price <moptop99@gmail.com> writes: > On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, <tecosaur@gmail.com> wrote: > >> >> autofrettage <autofrettage@protonmail.ch> writes: >> >> > Quick and Dirty: Bind key '`' to ~ in Emacs? >> > >> > (I guess it is clear I haven't thought about the consequences.) >> >> You can add that just to the Org-mode map. That wouldn't be too bad, >> there's always C-q. >> > > Is it possible to bind a key in org-mode but bind it back to another > character if you're in a special environment, eg a code block? That would > probably be my preference. So "`" inserts "~" when you're writing text but > "`" in an elisp or markdown SRC block, for instance. > > I guess just write a function that checks context? Presumably all the > overloaded keybindings do this already but I guess I don't really know how > they do so. > > I do in general wish it were easier to switch between writing markdown and > writing org, since I often have to write markdown for work. > >> >> -- >> Timothy >> >> -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
Matt Price <moptop99@gmail.com> writes: > On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, <tecosaur@gmail.com> wrote: > > autofrettage <autofrettage@protonmail.ch> writes: > > > Quick and Dirty: Bind key '`' to ~ in Emacs? > > > > (I guess it is clear I haven't thought about the consequences.) > > You can add that just to the Org-mode map. That wouldn't be too bad, > there's always C-q. > > Is it possible to bind a key in org-mode but bind it back to another character if you're in a special environment, eg a code block? That would > probably be my preference. So "`" inserts "~" when you're writing text but "`" in an elisp or markdown SRC block, for instance. > > I guess just write a function that checks context? Presumably all the overloaded keybindings do this already but I guess I don't really know how they > do so. > Yes, you can do that. However, results can vary. The 'bottleneck' is in determining context. If that is easy, typically no problems. However, if you need something complex or need to scan a large part of the buffer to determine the context, then it can be problematic. > I do in general wish it were easier to switch between writing markdown and writing org, since I often have to write markdown for work. > Sounds like what you really need to do is define a set of key bindings which use the same bindings in both org and markup modes (different bound functions obviously). Instead of entering the character for 'code' using org syntax when in org and markdown syntax when in markdown, you just train your fingers to hit the key binding you have defined for entering 'code'. One nice advantage of this approach is that you can define functions such that if you hit that key binding it will insert the mode specific character if no region is selected, but if a region is selected, wrap that region using the nominated character. This is handy when editing a document because if you come across a section and want to have it rendered has code, bold, underlined etc, you can just select the target region and hit the appropriate key and job done. The other nice thing about this approach is you can generalise this further to other modes, even HTML. You then think in terms of either formatting or semantics (depending on how you define the bindings) and not the lower level syntax. The challenge can be in identifying the most appropriate key bindings. This can depend on the platform you use as well. When I was only using Linux, I used the 'super' key for this and it was great. However, when I also started using a mac, I had to define a new scheme. It can take a bit of work to setup initially, but I think it is worth the effort. I now have the same bindings in multiple modes, so regardless of whether I'm writing markdown, org, html, rich text, etc, I just hit the same key bindings to mark content as code, bold, italic, etc. -- Tim Cross
> The challenge can be in identifying the most appropriate key bindings. > This can depend on the platform you use as well. When I was only using > Linux, I used the 'super' key for this and it was great. However, when I > also started using a mac, I had to define a new scheme. It can take a > bit of work to setup initially, but I think it is worth the effort. I > now have the same bindings in multiple modes, so regardless of whether > I'm writing markdown, org, html, rich text, etc, I just hit the same key > bindings to mark content as code, bold, italic, etc. On a Mac, you might find these useful. I don't use the right command and option keys, so I redefine them as hyper and super. they are right under my thumb, and convenient. (setq mac-right-command-modifier 'hyper) (setq mac-right-option-modifier 'super) -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
John Kitchin <jkitchin@andrew.cmu.edu> writes:
>> The challenge can be in identifying the most appropriate key bindings.
>> This can depend on the platform you use as well. When I was only using
>> Linux, I used the 'super' key for this and it was great. However, when I
>> also started using a mac, I had to define a new scheme. It can take a
>> bit of work to setup initially, but I think it is worth the effort. I
>> now have the same bindings in multiple modes, so regardless of whether
>> I'm writing markdown, org, html, rich text, etc, I just hit the same key
>> bindings to mark content as code, bold, italic, etc.
>
> On a Mac, you might find these useful. I don't use the right command and
> option keys, so I redefine them as hyper and super. they are right under
> my thumb, and convenient.
>
> (setq mac-right-command-modifier 'hyper)
> (setq mac-right-option-modifier 'super)
That is useful information. The 'hyper key is certainly overlooked and
provides a very useful mechanism to create a whole set of new, possibly
short, key bindings. I like the idea of re-tasking the right hand
command/option keys as it is very rare I use them (command/option is
most used via left hand side for me).
--
Tim Cross
[-- Attachment #1: Type: text/plain, Size: 443 bytes --] On Tue, Apr 20, 2021 at 4:24 PM John Kitchin <jkitchin@andrew.cmu.edu> wrote: > I have used an approach like the one here > https://endlessparentheses.com/define-context-aware-keys-in-emacs.html > > to make context aware key-bindings. > > THanks John. That post was very helpful -- really all I was looking for was (org-in-src-block-p), but the larger infrastructure is cool and I'll keep it around for a while to see if I end up reusing it. [-- Attachment #2: Type: text/html, Size: 934 bytes --]
[-- Attachment #1: Type: text/plain, Size: 4480 bytes --] > George Mauer writes: >> is there a straightforward way to extend the org parser to do this? > I don't think so. It seems the emphasis markers are hard-coded > in various places. > > From a quick look at the code, you'd have to customize > `org-emphasis-alist` and redefine `org-set-emph-re` and > `org-do-emphasis-faces`. Maybe that'd be enough. > I did just what you said, and I've inserted what's bellow, somewhere in my `init.org` / `init.el`, before anything `org-mode` related (save for two `hook`): (Note it is an almost exact copy from `org.el`, I've only changed a few characters. And added the `advice-add override`.) #+begin_src emacs-lisp (defun org-set-emph-re-fixed (var val) "Set variable and compute the emphasis regular expression." (set var val) (when (and (boundp 'org-emphasis-alist) (boundp 'org-emphasis-regexp-components) org-emphasis-alist org-emphasis-regexp-components) (pcase-let* ((`(,pre ,post ,border ,body ,nl) org-emphasis-regexp-components) (body (if (<= nl 0) body (format "%s*?\\(?:\n%s*?\\)\\{0,%d\\}" body body nl))) (template (format (concat "\\([%s]\\|^\\)" ;before markers "\\(\\([%%s]\\)\\([^%s]\\|[^%s]%s[^%s]\\)\\3\\)" "\\([%s]\\|$\\)") ;after markers pre border border body border post))) (setq org-emph-re (format template "*/_+")) (setq org-verbatim-re (format template "=~`"))))) (advice-add 'org-set-emph-re :override #'org-set-emph-re-fixed) #+end_src #+begin_src emacs-lisp (defun org-do-emphasis-faces-fixed (limit) "Run through the buffer and emphasize strings." (let ((quick-re (format "\\([%s]\\|^\\)\\([~`=*/_+]\\)" (car org-emphasis-regexp-components)))) (catch :exit (while (re-search-forward quick-re limit t) (let* ((marker (match-string 2)) (verbatim? (member marker '("~" "`" "=")))) (when (save-excursion (goto-char (match-beginning 0)) (and ;; Do not match table hlines. (not (and (equal marker "+") (org-match-line "[ \t]*\\(|[-+]+|?\\|\\+[-+]+\\+\\)[ \t]*$"))) ;; Do not match headline stars. Do not consider ;; stars of a headline as closing marker for bold ;; markup either. (not (and (equal marker "*") (save-excursion (forward-char) (skip-chars-backward "*") (looking-at-p org-outline-regexp-bol)))) ;; Match full emphasis markup regexp. (looking-at (if verbatim? org-verbatim-re org-emph-re)) ;; Do not span over paragraph boundaries. (not (string-match-p org-element-paragraph-separate (match-string 2))) ;; Do not span over cells in table rows. (not (and (save-match-data (org-match-line "[ \t]*|")) (string-match-p "|" (match-string 4)))))) (pcase-let ((`(,_ ,face ,_) (assoc marker org-emphasis-alist)) (m (if org-hide-emphasis-markers 4 2))) (font-lock-prepend-text-property (match-beginning m) (match-end m) 'face face) (when verbatim? (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0)) (remove-text-properties (match-beginning 2) (match-end 2) '(display t invisible t intangible t))) (add-text-properties (match-beginning 2) (match-end 2) '(font-lock-multiline t org-emphasis t)) (when (and org-hide-emphasis-markers (not (org-at-comment-p))) (add-text-properties (match-end 4) (match-beginning 5) '(invisible t)) (add-text-properties (match-beginning 3) (match-end 3) '(invisible t))) (throw :exit t)))))))) [-- Attachment #2: Type: text/html, Size: 21198 bytes --]
email got truncated the 1st time, hope it's bee better this time. > George Mauer writes: >> is there a straightforward way to extend the org parser to do this? > I don't think so. It seems the emphasis markers are hard-coded > in various places. > > From a quick look at the code, you'd have to customize > `org-emphasis-alist` and redefine `org-set-emph-re` and > `org-do-emphasis-faces`. Maybe that'd be enough. > I did just what you said, and I've inserted what's bellow, somewhere in my `init.org` / `init.el`, before anything `org-mode` related (save for two `hook`): (Note it is an almost exact copy from `org.el`, I've only changed a few characters. And added the `advice-add override`.) #+begin_src emacs-lisp (defun org-set-emph-re-fixed (var val) "Set variable and compute the emphasis regular expression." (set var val) (when (and (boundp 'org-emphasis-alist) (boundp 'org-emphasis-regexp-components) org-emphasis-alist org-emphasis-regexp-components) (pcase-let* ((`(,pre ,post ,border ,body ,nl) org-emphasis-regexp-components) (body (if (<= nl 0) body (format "%s*?\\(?:\n%s*?\\)\\{0,%d\\}" body body nl))) (template (format (concat "\\([%s]\\|^\\)" ;before markers "\\(\\([%%s]\\)\\([^%s]\\|[^%s]%s[^%s]\\)\\3\\)" "\\([%s]\\|$\\)") ;after markers pre border border body border post))) (setq org-emph-re (format template "*/_+")) (setq org-verbatim-re (format template "=~`"))))) (advice-add 'org-set-emph-re :override #'org-set-emph-re-fixed) #+end_src #+begin_src emacs-lisp (defun org-do-emphasis-faces-fixed (limit) "Run through the buffer and emphasize strings." (let ((quick-re (format "\\([%s]\\|^\\)\\([~`=*/_+]\\)" (car org-emphasis-regexp-components)))) (catch :exit (while (re-search-forward quick-re limit t) (let* ((marker (match-string 2)) (verbatim? (member marker '("~" "`" "=")))) (when (save-excursion (goto-char (match-beginning 0)) (and ;; Do not match table hlines. (not (and (equal marker "+") (org-match-line "[ \t]*\\(|[-+]+|?\\|\\+[-+]+\\+\\)[ \t]*$"))) ;; Do not match headline stars. Do not consider ;; stars of a headline as closing marker for bold ;; markup either. (not (and (equal marker "*") (save-excursion (forward-char) (skip-chars-backward "*") (looking-at-p org-outline-regexp-bol)))) ;; Match full emphasis markup regexp. (looking-at (if verbatim? org-verbatim-re org-emph-re)) ;; Do not span over paragraph boundaries. (not (string-match-p org-element-paragraph-separate (match-string 2))) ;; Do not span over cells in table rows. (not (and (save-match-data (org-match-line "[ \t]*|")) (string-match-p "|" (match-string 4)))))) (pcase-let ((`(,_ ,face ,_) (assoc marker org-emphasis-alist)) (m (if org-hide-emphasis-markers 4 2))) (font-lock-prepend-text-property (match-beginning m) (match-end m) 'face face) (when verbatim? (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0)) (remove-text-properties (match-beginning 2) (match-end 2) '(display t invisible t intangible t))) (add-text-properties (match-beginning 2) (match-end 2) '(font-lock-multiline t org-emphasis t)) (when (and org-hide-emphasis-markers (not (org-at-comment-p))) (add-text-properties (match-end 4) (match-beginning 5) '(invisible t)) (add-text-properties (match-beginning 3) (match-end 3) '(invisible t))) (throw :exit t)))))))) (advice-add 'org-do-emphasis-faces :override #'org-do-emphasis-faces-fixed) #+end_src #+begin_src emacs-lisp (custom-set-variables '(org-emphasis-alist '(("*" bold) ("/" italic) ("_" underline) ("=" org-verbatim verbatim) ("`" org-code verbatim) ("~" org-code verbatim) ("+" (:strike-through t))))) #+end_src Just before: #+begin_src emacs-lisp (straight-use-package 'org) #+end_src And it seems it works. I've tried the "cosmetic" version from bellow, but it wasn't working so well, with either `visual-fill-colum` or `org-indent-mode`? Well, it wasn't working well. I don't know if the hack above is playing more nicely. Because I've only tested it on one example. Chris > > For the cosmetic part, there's this piece of code from > https://archive.casouri.cat/note/2020/better-looking-verbatim-markup-in-org-mode/index.html > that displays org's `=` and `~` markers as ```. > > -- > Sébastien Miquel
The code below is working fine as long as I stay in `org-mode`. But it shows
its limitations when I do `M-x org-publish-all`, at which time, instead of
having the text with style verbatim, I get the text within backticks.
Is there any improvement you could think of that would fix that?
Thanks,
Chris
On Saturday, March 19, 2022 3:17:10 AM UTC you wrote:
> > George Mauer writes:
> >> is there a straightforward way to extend the org parser to do this?
> >
> > I don't think so. It seems the emphasis markers are hard-coded
> > in various places.
> >
> > From a quick look at the code, you'd have to customize
> > `org-emphasis-alist` and redefine `org-set-emph-re` and
> > `org-do-emphasis-faces`. Maybe that'd be enough.
>
> I did just what you said, and I've inserted what's bellow, somewhere in my
> `init.org` / `init.el`, before anything `org-mode` related (save for two
> `hook`): (Note it is an almost exact copy from `org.el`, I've only changed
> a few characters. And added the `advice-add override`.)
>
> #+begin_src emacs-lisp
> (defun org-set-emph-re-fixed (var val)
> "Set variable and compute the emphasis regular expression."
> (set var val)
> (when (and (boundp 'org-emphasis-alist)
> (boundp 'org-emphasis-regexp-components)
> org-emphasis-alist org-emphasis-regexp-components)
> (pcase-let*
> ((`(,pre ,post ,border ,body ,nl) org-emphasis-regexp-components)
> (body (if (<= nl 0) body
> (format "%s*?\\(?:\n%s*?\\)\\{0,%d\\}" body body nl)))
> (template
> (format (concat "\\([%s]\\|^\\)" ;before markers
> "\\(\\([%%s]\\)\\([^%s]\\|[^%s]%s[^%s]\\)\\3\\)"
> "\\([%s]\\|$\\)") ;after markers
> pre border border body border post)))
> (setq org-emph-re (format template "*/_+"))
> (setq org-verbatim-re (format template "=~`")))))
>
> (advice-add 'org-set-emph-re :override #'org-set-emph-re-fixed)
> #+end_src
>
> #+begin_src emacs-lisp
> (defun org-do-emphasis-faces-fixed (limit)
> "Run through the buffer and emphasize strings."
> (let ((quick-re (format "\\([%s]\\|^\\)\\([~`=*/_+]\\)"
> (car org-emphasis-regexp-components))))
> (catch :exit
> (while (re-search-forward quick-re limit t)
> (let* ((marker (match-string 2))
> (verbatim? (member marker '("~" "`" "="))))
> (when (save-excursion
> (goto-char (match-beginning 0))
> (and
> ;; Do not match table hlines.
> (not (and (equal marker "+")
> (org-match-line
> "[ \t]*\\(|[-+]+|?\\|\\+[-+]+\\+\\)[
> \t]*$"))) ;; Do not match headline stars. Do not consider ;; stars of a
> headline as closing marker for bold ;; markup either.
> (not (and (equal marker "*")
> (save-excursion
> (forward-char)
> (skip-chars-backward "*")
> (looking-at-p org-outline-regexp-bol))))
> ;; Match full emphasis markup regexp.
> (looking-at (if verbatim? org-verbatim-re org-emph-re))
> ;; Do not span over paragraph boundaries.
> (not (string-match-p org-element-paragraph-separate
> (match-string 2)))
> ;; Do not span over cells in table rows.
> (not (and (save-match-data (org-match-line "[ \t]*|"))
> (string-match-p "|" (match-string 4))))))
> (pcase-let ((`(,_ ,face ,_) (assoc marker org-emphasis-alist))
> (m (if org-hide-emphasis-markers 4 2)))
> (font-lock-prepend-text-property
> (match-beginning m) (match-end m) 'face face)
> (when verbatim?
> (org-remove-flyspell-overlays-in
> (match-beginning 0) (match-end 0))
> (remove-text-properties (match-beginning 2) (match-end 2)
> '(display t invisible t intangible
> t))) (add-text-properties (match-beginning 2) (match-end 2)
> '(font-lock-multiline t org-emphasis t)) (when (and
> org-hide-emphasis-markers
> (not (org-at-comment-p)))
> (add-text-properties (match-end 4) (match-beginning 5)
> '(invisible t))
> (add-text-properties (match-beginning 3) (match-end 3)
> '(invisible t)))
> (throw :exit t))))))))
chris <inkbottle007@gmail.com> writes: > The code below is working fine as long as I stay in `org-mode`. But it shows > its limitations when I do `M-x org-publish-all`, at which time, instead of > having the text with style verbatim, I get the text within backticks. > > Is there any improvement you could think of that would fix that? You will need to patch the parser in org-element.el. We do not officially support extending markup syntax. So, even changing org-element may still leave other bugs. Caveat emptor. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
On Monday, December 4, 2023 1:06:37 PM UTC you wrote: > chris <inkbottle007@gmail.com> writes: > > The code below is working fine as long as I stay in `org-mode`. But it > > shows its limitations when I do `M-x org-publish-all`, at which time, > > instead of having the text with style verbatim, I get the text within > > backticks. > > > > Is there any improvement you could think of that would fix that? > > You will need to patch the parser in org-element.el. Yes, that seems a very good idea. I've never "patched" emacs before: in the hack I've been using so far I was doing some `(advice-add 'org-do-emphasis-faces :override #'org-do-emphasis- faces-fixed)` thing. In any case the problem (or part of it) lies in `org-element.el` because I've observed the backticks constructions were not recognised as an "element". But okay, patch emacs, no worries. Since I'm using NixOS, it will take a bit of time for me to figure out how to do it the NixOS way. > > We do not officially support extending markup syntax. So, even changing > org-element may still leave other bugs. Caveat emptor. The backticks for inline code or verbatim are very pleasing to the eye, and are used literally universally.
chris <inkbottle007@gmail.com> writes: >> You will need to patch the parser in org-element.el. > > Yes, that seems a very good idea. > I've never "patched" emacs before: in the hack I've been using so far I was > doing some `(advice-add 'org-do-emphasis-faces :override #'org-do-emphasis- > faces-fixed)` thing. This is an equivalent. Also, you may check out https://github.com/radian-software/el-patch -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>