Re: Using backticks for the inline code delimeter?
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)
Re: Using backticks for the inline code delimeter?
> 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 delimeter?
On Tue, Apr 20, 2021 at 4:24 PM John Kitchin 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.
Re: Using backticks for the inline code delimeter?
John Kitchin 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?
> 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?
Matt Price writes: > On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, wrote: > > autofrettage 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?
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 writes: > On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, wrote: > >> >> autofrettage 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?
On Wed., Mar. 31, 2021, 3:22 p.m. Timothy, wrote: > > autofrettage 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 > >
Re: Using backticks for the inline code delimeter?
Hello, Maxim Nikulin 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?
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?
Hello, Joost Kremers 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?
On Sun, Apr 04 2021, Nicolas Goaziou wrote: > Joost Kremers 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?
Hello, Bill Burdick 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?
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.
Re: Using backticks for the inline code delimeter?
On Sun, Apr 4, 2021 at 7:21 AM Nicolas Goaziou 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
Re: Using backticks for the inline code delimeter?
Hello, Joost Kremers 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?
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?
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?
On Do 01 Apr 2021 at 09:32, autofrettage 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?
Joost Kremers 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?
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?
Samuel Wales 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?
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?
Maxim Nikulin 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?
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?
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?
On 2021-03-31, at 21:19, Timothy wrote: > autofrettage 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?
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?
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 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? >
Re: Using backticks for the inline code delimeter?
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 wrote: > > "Dr. Arne Babenhauserheide" writes: > >> George Mauer 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?
"Dr. Arne Babenhauserheide" writes: > George Mauer 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?
George Mauer 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 signature.asc Description: PGP signature
Re: Using backticks for the inline code delimeter?
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 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 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? >> >
Re: Using backticks for the inline code delimeter?
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 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? >
Re: Using backticks for the inline code delimeter?
> > 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?
George Mauer 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?
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?
autofrettage 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?
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
Using backticks for the inline code delimeter?
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?