Re: Using backticks for the inline code delimeter?

Re: Using backticks for the inline code delimeter?

[chris]

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

Re: Using backticks for the inline code delimeter?

[chris]

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

Re: Using backticks for the inline code delimiter? (now with `org-publish-all`)

[chris]

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

Re: Using backticks for the inline code delimiter? (now with `org-publish-all`)

[Ihor Radchenko]

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>

Re: Using backticks for the inline code delimiter? (now with `org-publish-all`)

[chris]

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.

Re: Using backticks for the inline code delimiter? (now with `org-publish-all`)

[Ihor Radchenko]

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>

Using backticks for the inline code delimeter?

[George Mauer]

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

Re: Using backticks for the inline code delimeter?

[autofrettage]

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

Re: Using backticks for the inline code delimeter?

[Timothy]

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

Re: Using backticks for the inline code delimeter?

[Marcin Borkowski]

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

Re: Using backticks for the inline code delimeter?

[Matt Price]

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

Re: Using backticks for the inline code delimeter?

[John Kitchin]

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

Re: Using backticks for the inline code delimeter?

[Matt Price]

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

Re: Using backticks for the inline code delimeter?

[Tim Cross]

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

Re: Using backticks for the inline code delimeter?

[John Kitchin]

> 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

Re: Using backticks for the inline code delimeter?

[Tim Cross]

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

Re: Using backticks for the inline code delimeter?

[Sébastien Miquel]

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

Re: Using backticks for the inline code delimeter?

[Maxim Nikulin]

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.

Re: Using backticks for the inline code delimeter?

[Timothy]

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

Re: Using backticks for the inline code delimeter?

[Samuel Wales]

n.b. everybody knows better in this thread, but the docstring of
org-emphasis-alist seemed to me like `test` + reload would fontify.

Re: Using backticks for the inline code delimeter?

[Tim Cross]

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

Re: Using backticks for the inline code delimeter?

[Joost Kremers]

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

Re: Using backticks for the inline code delimeter?

[Tim Cross]

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

Re: Using backticks for the inline code delimeter?

[Tom Gillespie]

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

Re: Using backticks for the inline code delimeter?

[Joost Kremers]

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

Re: Using backticks for the inline code delimeter?

[Nicolas Goaziou]

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

Re: Using backticks for the inline code delimeter?

[Bill Burdick]

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

Re: Using backticks for the inline code delimeter?

[Nicolas Goaziou]

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

Re: Using backticks for the inline code delimeter?

[Joost Kremers]

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

Re: Using backticks for the inline code delimeter?

[Nicolas Goaziou]

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

Re: Using backticks for the inline code delimeter?

[Maxim Nikulin]

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.

Re: Using backticks for the inline code delimeter?

[Nicolas Goaziou]

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

Re: Using backticks for the inline code delimeter?

[Timothy]

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

Re: Using backticks for the inline code delimeter?

[autofrettage]

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

Re: Using backticks for the inline code delimeter?

[Diego Zamboni]

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

Re: Using backticks for the inline code delimeter?

[George Mauer]

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

Re: Using backticks for the inline code delimeter?

[Dr. Arne Babenhauserheide]

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

Re: Using backticks for the inline code delimeter?

[Tim Cross]

"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

Re: Using backticks for the inline code delimeter?

[Samuel Wales]

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

Re: Using backticks for the inline code delimeter?

[Bill Burdick]

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

Re: Using backticks for the inline code delimeter?

[Greg Minshall]

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

Re: Using backticks for the inline code delimeter?

[autofrettage]

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

Re: Using backticks for the inline code delimeter?

[Andreas Eder]

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

Re: Using backticks for the inline code delimeter?

[Maxim Nikulin]

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.