[PATCH] ox-md.el/markdown-hyperlink
exporting to markdown loses radio target hyperlinks. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! >From bbe8ef631467f9f5f097412a946a82d38e96235c Mon Sep 17 00:00:00 2001 From: "turbo.c...@clovermail.net" Date: Tue, 3 Nov 2020 22:24:03 +0200 Subject: [PATCH] ox-md.el/markdown-hyperlink * ox-md.el (org-md-link): format markdown hyperlink from org radio target --- lisp/ox-md.el | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lisp/ox-md.el b/lisp/ox-md.el index 1d20c04f4..a63815e43 100644 --- a/lisp/ox-md.el +++ b/lisp/ox-md.el @@ -543,7 +543,13 @@ INFO is a plist holding contextual information. See ((string= type "coderef") (format (org-export-get-coderef-format path desc) (org-export-resolve-coderef path info))) - ((equal type "radio") desc) + ((string= type "radio") + (let ((destination (org-export-resolve-radio-link link info))) + (if (not destination) desc + (format "%s" + (org-export-get-reference destination info) + "" + desc (t (if (not desc) (format "<%s>" path) (format "[%s](%s)" desc path)) -- 2.29.1
Re: Org mode fontification error in # in python and ipython source blocks
Thanks for noting. :) I added that in my Emacs config now.
[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter: @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
On Tue, Nov 3, 2020 at 5:53 PM Sebastian Gimeno
wrote:
> Dear Stardiviner,
>
> I used the "scimax" configuration. Scimax's maintainer, John Kitchin,
> helped me out to find the root cause of the problem, i.e. the following
> addition to " python-font-lock-keywords":
>
> (setq python-font-lock-keywords
> (append python-font-lock-keywords
> '(;; this is the full string.
> ;; group 1 is the quote type and a closing quote is matched
> ;; group 2 is the string part
> (
> ;; "f\\(['\"]\\{1,3\\}\\)\\([^\\1]+?\\)\\1"
> "f\\(['\"]\\{1,3\\}\\)\\(.+?\\)\\1"
> ;; these are the {keywords}
> ("{[^}]*?}"
> ;; Pre-match form
> (progn (goto-char (match-beginning 0)) (match-end 0))
> ;; Post-match form
> (goto-char (match-end 0))
> ;; face for this match
> (0 font-lock-variable-name-face t))
>
> Commenting out this code snippet, the fontfying / HTML-export problem goes
> away.
>
> Cheers,
> sebastian
>
>
>
>
> On Tue, Nov 3, 2020 at 6:50 AM stardiviner wrote:
>
>> I have same problem sometimes in different babel languages.
>> I would like to know what caused this problem too.
>> Can you send me a message after you solved problem? Thanks in advance. :)
>> smile
>>
>> [stardiviner] GPG key ID: 47C32433
>> IRC(freeenode): stardiviner Twitter: @numbchild
>> Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
>> Blog: http://stardiviner.github.io/
>>
>>
>> On Mon, Nov 2, 2020 at 2:26 AM Sebastian Gimeno
>> wrote:
>>
>>> Hi,
>>>
>>> I am using emacs 27.1 and org-plus-contrib 20201026.
>>>
>>> I am having problems with the fontification of python and ipython
>>> source blocks when the code contains curly brackets "{}" (other course
>>> blocks are ok). For instance, the following snippet
>>>
>>> #+BEGIN_SRC python :results drawer
>>> import matplotlib.pyplot as plt
>>> plt.plot([1,2,3])
>>> plt.show()
>>> a=1
>>> print("a={}".format{a})
>>> #+END_SRC
>>>
>>> does not fontify correctly in either python or ipython source blocks.
>>>
>>> As a consequence, when exporting the org file to HTML (C-c C-e h h), it
>>> fails with the following message:
>>>
>>> font-lock-fontify-keywords-region: Invalid function: #
>>>
>>> If changing the code snippet to:
>>>
>>> #+BEGIN_SRC python :results drawer
>>> import matplotlib.pyplot as plt
>>> plt.plot([1,2,3])
>>> plt.show()
>>> a=1
>>> print("a=%s" % a)
>>> #+END_SRC
>>>
>>> the block fontifies and the file is exported to HTML correctly.
>>>
>>> Can you reproduce this behaviour?
>>>
>>> Many thanks in advance!
>>>
>>
Re: Org mode fontification error in # in python and ipython source blocks
John Kitchin writes:
>> (setq python-font-lock-keywords
>> (append python-font-lock-keywords
>> '(;; this is the full string.
>> ;; group 1 is the quote type and a closing quote is matched
>> ;; group 2 is the string part
>> (
>> ;; "f\\(['\"]\\{1,3\\}\\)\\([^\\1]+?\\)\\1"
>> "f\\(['\"]\\{1,3\\}\\)\\(.+?\\)\\1"
>> ;; these are the {keywords}
>> ("{[^}]*?}"
>> ;; Pre-match form
>> (progn (goto-char (match-beginning 0)) (match-end 0))
>> ;; Post-match form
>> (goto-char (match-end 0))
>> ;; face for this match
>> (0 font-lock-variable-name-face t))
> Does anyone see anything wrong with that snippet? All it should do is
> improve font-lock on Python f-strings, and it used to work fine, but now it
> doesn't. It isn't real critical for me, so I don't mind commenting it out,
> but I neither understand why it stopped working!
I haven't tested to confirm, but I'd guess that is due to the
restructuring of python-font-lock-keywords in 36b64e087e (Add
'font-lock-maximum-decoration' levels for Python, 2018-07-19), which was
included in Emacs 27.
In case it's helpful, here's the compatibility kludge I used in
snakemake-mode:
https://git.kyleam.com/snakemake-mode/commit/snakemake-mode.el?id=5d5bb0109f6a84c0c191559ab71670fae4650e6a
Re: Please help by becoming a maintainer for an Org Babel file
> On Oct 27, 2020, at 3:52 AM, Bastien wrote: > > Hi Palak, > > Palak Mathur writes: > >> I have sent that form to the address listed on the form. > > thank you very much. > Paperwork with FSF is now complete. — Palak Mathur > -- > Bastien
Re: Tables: missing multi-col/row syntax
TEC writes: David Rogers writes: IMO this can (and definitely should) be regarded as a purely cosmetic problem, to be resolved by purely cosmetic methods. I think the idea that each table cell is exactly one unit of information (and can’t be a collection or array of units of information) is more important than this issue. In other words, I think it’s better to ridiculously overload fontification and output formatting, than to sacrifice the main logic of how tables currently work. I just don’t believe that it could be worth it. The appearance of the tables is purely cosmetic ... however when one ends up maintaining three copies of the same table, I don't think that dismissing it offhand as a "cosmetic problem" is a productive approach. I’m not using the word in a dismissive way; I just think fixing the problem “head-on“, solving a display problem by display solutions, is better than disruptively (and permanently) changing the logic in order to improve the display. -- David Rogers
Re: prettify-symbols-mode in org agenda?
> I would like to hear what is the opinion of org maintainter(s) on this > topic. Ok. Marking this thread with X-Woof-Help. William Xu writes: > Ihor Radchenko writes: > >> Feel free to prepare a patch using my code and send it here. >> I think the following function should be sufficient to preserve >> pretty-symbols composition: >> >> (el-patch-defun org-agenda-highlight-todo ... >> >> I have added only 3 lines to the original org-agenda-highlight-todo (see >> el-patch-add instances in the body). >> >> That change simply preserves 'composition text property in agenda. > > Thanks for the info. I'll be happy to prepare the patch. However, I > would like to hear what is the opinion of org maintainter(s) on this > topic. > > -- > William
Re: Thoughts on the standardization of Org
I have collected below some quotations to try to represent the general sentiments expressed so far in the conversation, upon which I would like to express some thoughts. Most of these have been repeated several times in spirit, so they are not just the opinions of the listed authors. Daniele Nicolodi said: > I don't think it is reasonable to expect much of org-mode being implemented in > another environment, because that quickly becomes a task as complex as > implementing Emacs. For example, Org has org-tables, and the formula syntax > allows for Emacs Calc expressions or Elisp functions to be called: should an > hypothetical implementation of Org allow the same formulas to be executed? > Wouldn't that mean that this implementation needs to re-implement a good > fraction of Emacs (or use Emacs itself for interpreting the formulas? > > Maybe the standardization should cover only the "static" parts of Org (IE no > table formulas, no babel, no agenda, no exporters, etc). However, in this > case, what is left is little more of a markup language with an editor that > allows sections folding. You can have this on top of pretty much any markup > language using Emacs' outline-minor-mode. Daniele Nicolodi said: > one of the advantages of Org is that, being implemented in Emacs, it has > infinite potential for customization, thus we would need to agree about what > org mode is before standardizing it: my Org is not your org, and, thank to the > features offered be the Emacs environment, I use different flavors of Org in > different buffers. I 100% agree that much of the power of org mode comes from the infinite customization. However, I do not agree that this fact makes standardization impossible (see below). Additionally, Emacs is not the only customizable tool, though it is a very good one. The org standard would have to be flexible to accommodate that "my org is not your org," but this is not impossible. Ken Mankoff said: > Therefore, if other tools have the ability to do *something* with an Org file > (display most of it well enough, allow editing without breaking things, maybe > implementing a simple Babel interpreter for a few popular languages, > whatever), this would be A Good Thing. TEC said: > I also think it's to our benefit that non-Emacsers become more comfortable > with seeing an org file --- as I see it that improves our chances that we can > directly share Org files with them, which they might be comfortable editing > and sending back for example, or that a generic tool might think to support > Org files. These points are especially important, and while a standard is not the only way to progress these goals, it is a good step. Also, re the MIME type discussion, while there was a long list of steps that need to occur for a MIME registration to be useful, I would like to point out that a standard is the first step towards that goal, and even though there are more steps, many of them difficult, that does not mean that we should not make progress. Greg Minshall > perhaps the standard for e-mail headers (originally, RFC822) might be a useful > way of thinking about this issue. it standardizes what it standardizes, and > then says, "and, by the way, you can put in almost anything else [X-Mailer, > ...], but you can't count on any other node understanding it". over time, new > things are standardized (and, so, moved to, e.g., Mailer, and other things > aren't. > > it seems to me this has worked fairly well, and partly this works because of > the late Jon Postel's admonition for designing internet protocols: be > conservative in what you send, and liberal in what you accept. This is a good precedent for how I would like to standardize org. First, standardize general structure, without the specifics. Then, as ideas around a particular feature stabilize, they can be separately standardized, and incrementally adopted. (Though likely many major implementations (aka Emacs) would have already implemented it, even though it is non standard.) For more details on how I think this should be accomplished, see my original post, and also this reply for clarification: https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg9.html Ken Mankoff said: > The conversation should move from "it can't be done" or "it isn't helpful" > (why so much negativity on this thread?) to > > + What parts can be standardized and re-implemented outside of Emacs. > + How do we define graceful failure for the other parts. > + How do we support 3rd-party implementation in a way that benefits all of us. This post I also find especially important. There seem to be the ideas that (a) an incomplete implementation is not useful and (b) a standard would necessarily either require another implementation to implement all of Emacs or would eliminate the customizability of org. Thanks, Asa
Re: Thoughts on the standardization of Org
Ken Mankoff writes: On 2020-11-03 at 00:24 -08, David Rogers wrote... I disagree (in principle, not just because it would be difficult) with the idea of “expanding beyond Emacs”. Org-mode benefits greatly from current and future Emacs development, and asking to standardize “just the parts that are not Emacs” would cause Org-mode to lose that huge advantage. Org-mode relies heavily on the editor it’s built on, and if it ceased to rely on Emacs, it would be forced to rely on “nothing at all” instead. Not only that, but for Org-mode users being able to count on all of Emacs is a big part of why it works. This means separating Org-mode from Emacs is a “lose-lose” idea. It seems like you have never used Orgzly or read on Org file on GitHub. Those are not ideas, but are actual current real-world win-win implementations of parts of Org outside of Emacs. More of these would be better. Everyone on this thread who says you can't separate Org from Emacs is correct that it is unreasonable to expect a 100 % bit-compatible and keystroke-compatible experience outside of Emacs. I don't think that level of re-implementation was what the OP was suggesting. Again: GitHub. Orgzly. The conversation should move from "it can't be done" or "it isn't helpful" (why so much negativity on this thread?) to + What parts can be standardized and re-implemented outside of Emacs. + How do we define graceful failure for the other parts. + How do we support 3rd-party implementation in a way that benefits all of us. I have used most of what you’re describing. None of what you’re describing does what the OP was discussing, namely to create a clean separation between Emacs and Org-mode in the interest of enabling what might be termed “the full complete official Org-mode” on non-Emacs editors. Orgzly is a very nice implementation of a partial viewer and partial editor for a certain subset of .org files, but it doesn’t aim to be an Emacs replacement or an authoritative standard. More and better partial viewers/partial editors, knowing that “the Org-mode standard” equals “precisely how Emacs Org-mode works at the time the question is asked”, is a great idea IMO. Cleaning up a separation between Org-mode and Emacs would necessarily mean Org-mode would lose the ability to take advantage of future Emacs development - a de facto permanent feature-freeze. One of the main advantages of Org-mode is its extensibility, and leaving that extensibility behind would suddenly remove one of the major actual reasons that it’s attractive (i.e. “Org-mode can’t do that yet? Give me half an hour and maybe it will”). Enabling “the full complete official Org-mode” to run anywhere, would have the eventual effect of it running nowhere, because no one actually needs or wants the “It’s Just Markdown On Steroids” list of how to properly arrange asterisks and pound-signs that would be the result. As far as I’m aware, people are currently free to develop applications that use their personal interpretation of the .org format, and they should do so. The only thing standardization would accomplish would be to halt development of the real thing, or at least impede it. (That’s unless the standardization includes so much detail, and the bar is set so high, that the standard becomes impractical to try to meet anyway.) -- David Rogers
Re: Thoughts on the standardization of Org
Eric S Fraga writes: On Tuesday, 3 Nov 2020 at 05:31, Ken Mankoff wrote: But I'm weary of seeing all my colleagues say "Jupyter" and not "Org" +1 (not to mention the case of MSWord instead of Jupyter) 濫 So, yes, if TEC or others can get us there, I'm all for it but they'll have to prise emacs out of hands when I expire... Hehe. I'll have a look and see how hard it seems. I'm hoping at least someone else finds it interesting enough to reply to my call for help and give me some company . No need to pry Emacs out of anything ... after all, his idea is all about sneakily inserting it into people's workflow . -- Timothy
Re: prettify-symbols-mode in org agenda?
Ihor Radchenko writes: > Feel free to prepare a patch using my code and send it here. > I think the following function should be sufficient to preserve > pretty-symbols composition: > > (el-patch-defun org-agenda-highlight-todo ... > > I have added only 3 lines to the original org-agenda-highlight-todo (see > el-patch-add instances in the body). > > That change simply preserves 'composition text property in agenda. Thanks for the info. I'll be happy to prepare the patch. However, I would like to hear what is the opinion of org maintainter(s) on this topic. -- William
Re: Org mode fontification error in # in python and ipython source blocks
Does anyone see anything wrong with that snippet? All it should do is
improve font-lock on Python f-strings, and it used to work fine, but now it
doesn't. It isn't real critical for me, so I don't mind commenting it out,
but I neither understand why it stopped working!
John
---
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
On Tue, Nov 3, 2020 at 4:55 AM Sebastian Gimeno
wrote:
> Dear Stardiviner,
>
> I used the "scimax" configuration. Scimax's maintainer, John Kitchin,
> helped me out to find the root cause of the problem, i.e. the following
> addition to " python-font-lock-keywords":
>
> (setq python-font-lock-keywords
> (append python-font-lock-keywords
> '(;; this is the full string.
> ;; group 1 is the quote type and a closing quote is matched
> ;; group 2 is the string part
> (
> ;; "f\\(['\"]\\{1,3\\}\\)\\([^\\1]+?\\)\\1"
> "f\\(['\"]\\{1,3\\}\\)\\(.+?\\)\\1"
> ;; these are the {keywords}
> ("{[^}]*?}"
> ;; Pre-match form
> (progn (goto-char (match-beginning 0)) (match-end 0))
> ;; Post-match form
> (goto-char (match-end 0))
> ;; face for this match
> (0 font-lock-variable-name-face t))
>
> Commenting out this code snippet, the fontfying / HTML-export problem goes
> away.
>
> Cheers,
> sebastian
>
>
>
>
> On Tue, Nov 3, 2020 at 6:50 AM stardiviner wrote:
>
>> I have same problem sometimes in different babel languages.
>> I would like to know what caused this problem too.
>> Can you send me a message after you solved problem? Thanks in advance. :)
>> smile
>>
>> [stardiviner] GPG key ID: 47C32433
>> IRC(freeenode): stardiviner Twitter: @numbchild
>> Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
>> Blog: http://stardiviner.github.io/
>>
>>
>> On Mon, Nov 2, 2020 at 2:26 AM Sebastian Gimeno
>> wrote:
>>
>>> Hi,
>>>
>>> I am using emacs 27.1 and org-plus-contrib 20201026.
>>>
>>> I am having problems with the fontification of python and ipython
>>> source blocks when the code contains curly brackets "{}" (other course
>>> blocks are ok). For instance, the following snippet
>>>
>>> #+BEGIN_SRC python :results drawer
>>> import matplotlib.pyplot as plt
>>> plt.plot([1,2,3])
>>> plt.show()
>>> a=1
>>> print("a={}".format{a})
>>> #+END_SRC
>>>
>>> does not fontify correctly in either python or ipython source blocks.
>>>
>>> As a consequence, when exporting the org file to HTML (C-c C-e h h), it
>>> fails with the following message:
>>>
>>> font-lock-fontify-keywords-region: Invalid function: #
>>>
>>> If changing the code snippet to:
>>>
>>> #+BEGIN_SRC python :results drawer
>>> import matplotlib.pyplot as plt
>>> plt.plot([1,2,3])
>>> plt.show()
>>> a=1
>>> print("a=%s" % a)
>>> #+END_SRC
>>>
>>> the block fontifies and the file is exported to HTML correctly.
>>>
>>> Can you reproduce this behaviour?
>>>
>>> Many thanks in advance!
>>>
>>
Re: Bug: ox-html.el: Code blocks extend out of box border
Please note that changes from this patch cause clipping of popups with language labels (pre.src:before). -- Best regards, Vladislav Glinsky signature.asc Description: OpenPGP digital signature
Re: Thoughts on the standardization of Org
I'm coming at this from the viewpoint of accessibility. I am a blind person, who is pretty technical, but not technical enough to bend Emacs to my will as easily as some of you do. But I have begun bending Org-mode to fit what I use it for, and love heading folding and having all things pertaining to work, for example, in one document, and being able to easily find things from there and navigate using folding. I've since moved from Mac, where I used Emacs and Emacspeak, to Windows, where most blind people use VS Code. And I love how streamlined VS Code is. No linter is inaccessible because of using parts of the interface that the TTS extension author hasn't made accessible yet, because the whole UI works with the screen reader. Sure, it's not perfect yet, but Language Tool, Grammarly, all Markdown extensions, all work great with my screen reader in VS Code, and I love using those tools. But no Markdown extension comes close to the power and flexibility of Org-mode in Emacs. Yes, this could be me just wishing Emacs worked better with accessibility tools in Windows and we didn't have to rely on Emacspeak and such in other operating systems, because ultimately Emacspeak pretty much relies on the author or other contributors working around Emacs, to make Emacs' modes work well in an auditory environment. And that works great, until you roam outside of the use cases set forth by the developers. And not all Emacs/Emacspeak users are developers, so cannot then make these use cases, like Hugo-mode and Jekyll-mode, before I asked the maintainer of those modes if there was anything they could do to make their modes work better with Emacspeak, work better. And I'm not saying that we should dumb down Emacs for people like me, but I do think that VS Code and other editors that try to help out the writer or developer and such, have their place, and so Org-mode should have a more prominent place within these editors. Besides, I think bringing Org-mode to VS Code would help bring Org-mode to the web, which would be pretty cool, since VS Code is pretty much built on web technologies. And there is an Emacspeak package for Windows, but it is no longer maintained, and I think most Emacspeak users use Linux or Mac anyways. And one can sort of use Emacs in a Terminal with a screen reader, but you can't use C-N, C-P, or other Emacs-specific keys, defeating one purpose of even having Emacs in the first place. I might just get a virtual machine up and going and just use that, just for Emacs and Org-mode. :) And yes, there are things that Emacspeak can do that current screen readers do not. Emacspeak shows syntax highlighting through speech effects and parameter changes, and has many sounds for common actions, which helps a lot. But the non-standardization of many Emacs packages, and the popularity of VS Code among blind people who want to code, or learn to code, or are more technically inclined like me, make it far easier for me to recommend VS Code with a current screen reader than to recommend blind people switch to Linux or Mac, and use Emacs with Emacspeak. Of course, I'm only one blind person. There are blind people who have mastered Emacs and use it for everything, but I just want things to work for me nowadays, and find myself much more productive on Windows and VS Code, but really miss Org-mode and its simple power that I could actually grasp. Devin Prater On Tue, Nov 3, 2020 at 6:15 AM Ken Mankoff wrote: > > On 2020-11-03 at 00:24 -08, David Rogers > wrote... > > I disagree (in principle, not just because it would be difficult) with > > the idea of “expanding beyond Emacs”. Org-mode benefits greatly from > > current and future Emacs development, and asking to standardize “just > > the parts that are not Emacs” would cause Org-mode to lose that huge > > advantage. Org-mode relies heavily on the editor it’s built on, and if > > it ceased to rely on Emacs, it would be forced to rely on “nothing at > > all” instead. Not only that, but for Org-mode users being able to > > count on all of Emacs is a big part of why it works. This means > > separating Org-mode from Emacs is a “lose-lose” idea. > > It seems like you have never used Orgzly or read on Org file on GitHub. > Those are not ideas, but are actual current real-world win-win > implementations of parts of Org outside of Emacs. > > More of these would be better. > > Everyone on this thread who says you can't separate Org from Emacs is > correct that it is unreasonable to expect a 100 % bit-compatible and > keystroke-compatible experience outside of Emacs. I don't think that level > of re-implementation was what the OP was suggesting. > > Again: GitHub. Orgzly. The conversation should move from "it can't be > done" or "it isn't helpful" (why so much negativity on this thread?) to > > + What parts can be standardized and re-implemented outside of Emacs. > + How do we define graceful failure for the other parts. > + How do we support 3rd-party implementation in a way
Re: Thoughts on the standardization of Org
On Tuesday, 3 Nov 2020 at 05:31, Ken Mankoff wrote: > But I'm weary of seeing all my colleagues say "Jupyter" and not "Org" +1 (not to mention the case of MSWord instead of Jupyter) So, yes, if TEC or others can get us there, I'm all for it but they'll have to prise emacs out of hands when I expire... -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
Re: Thoughts on the standardization of Org
Hi Eric, On 2020-11-03 at 05:00 -08, Eric S Fraga wrote... > The benefits of org mode for me are that it is Emacs. [...] I find it > difficult to see any further standardization that would provide any > real benefits *to me*. If others see those benefits, excellent! All > power to them and I hope there is success in greater use of org > documents outside Emacs which would possibly trickle back benefits > into org mode in Emacs. No need to apologize! I'm similar to you re emacs usage and cannot imagine I'd leave it even if 3rd-party implementations existed. There is no way that 3rd party tool would also read my email, have magit, implement all of Org that I use, edit TeX, etc. But I'm weary of seeing all my colleagues say "Jupyter" and not "Org" when it comes to sharing their code/work. I have a fantasy that in 5 years I tell someone who doesn't use Emacs but uses Atom or some other editor to "pip install org-lsp" and then double-click on this Org file I just emailed you, and then right-click on the code block and select "evaluate" from the popup menu. That sounds horrific to me as a user, except the part where I can interact more powerfully with more colleagues. In this fantasy this adds no additional effort or stress to the current devs, because we're a big diverse community, and if TEC doesn't want to work on Org core code, but does want to make an emacs-lsp or org-lsp, more power to them. -k.
Re: Thoughts on the standardization of Org
On Tuesday, 3 Nov 2020 at 04:14, Ken Mankoff wrote: > Again: GitHub. Orgzly. The conversation should move from "it can't be > done" or "it isn't helpful" (why so much negativity on this thread?) > to Hi Ken, I'm sorry if I came across as being negative. I am not. I just think that there is a clear difference between what some people think org mode is and what others think. I think it's primarily Emacs plus some specific markup, including org babel and some understanding of LaTeX constructs, whereas others maybe think it's markup that happens to be interpreted by Emacs. The two are very different animals. The benefits of org mode for me are that it is Emacs. I could continue to work (maybe not quite as efficiently) without org mode but I would really suffer without Emacs. I've been using Emacs since 1984 and org mode since 2008. And gnus for what feels like forever. ;-) So maybe I'm old skool and fossilised in my views. :-( Apologies if so. I have no problem with a clear syntax definition for org mode documents and Nikolas has gone a long ways in providing that. Beyond that, I find it difficult to see any further standardization that would provide any real benefits *to me*. If others see those benefits, excellent! All power to them and I hope there is success in greater use of org documents outside Emacs which would possibly trickle back benefits into org mode in Emacs. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
Re: Thoughts on the standardization of Org
On Tue, Nov 03, 2020 at 04:14:41AM -0800, Ken Mankoff wrote: > It seems like you have never used Orgzly or read on Org file on > GitHub. Those are not ideas, but are actual current real-world > win-win implementations of parts of Org outside of Emacs. Supporting a subset of trivial formatting options from Org should be that, trivial. Those items are not changing and fairly standardized already. Could an existing Markdown importer be trivially altered to support basic Org formats? I suspect that's what Github did. If that's the case, why are we even arguing? What is missing that so desperately needs standardization? > Again: GitHub. Orgzly. The conversation should move from "it can't > be done" or "it isn't helpful" (why so much negativity on this > thread?) to Not negative for negative sake or dismissing new ideas. However understand there is a lack of resources working on Org as it stands today. Org has grown exponentially in use cases for years, and there's no way to expect our devs to keep up with that, much less tooling for users outside of Emacs. I'm barely involved in the periphery, but I've watched since 2006. It's a thankless job maintaining any popular OSS project. I'm grateful for what has been done already, I have no standing to ask for more or demand time spent on outside software. We are already having to argue over what is core, and what is an addon because every advanced user has extensions they want to make. Org ballooned dramatically and is having to be trimmed. > + What parts can be standardized and re-implemented outside of > Emacs. I'm negative on this because it's outside of Emacs. I like having clear documentation and a good reference for the benefit of Emacs users. Why ask for developer time for external environments? Why contribute to centralized non-free services who exploit our integration for more marketshare? > + How do we support 3rd-party implementation in a way that benefits > all of us. I'd rather invest our time on improving our internal implementation, documentation, and support. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Thoughts on the standardization of Org
On 2020-11-03 at 00:24 -08, David Rogers wrote... > I disagree (in principle, not just because it would be difficult) with > the idea of “expanding beyond Emacs”. Org-mode benefits greatly from > current and future Emacs development, and asking to standardize “just > the parts that are not Emacs” would cause Org-mode to lose that huge > advantage. Org-mode relies heavily on the editor it’s built on, and if > it ceased to rely on Emacs, it would be forced to rely on “nothing at > all” instead. Not only that, but for Org-mode users being able to > count on all of Emacs is a big part of why it works. This means > separating Org-mode from Emacs is a “lose-lose” idea. It seems like you have never used Orgzly or read on Org file on GitHub. Those are not ideas, but are actual current real-world win-win implementations of parts of Org outside of Emacs. More of these would be better. Everyone on this thread who says you can't separate Org from Emacs is correct that it is unreasonable to expect a 100 % bit-compatible and keystroke-compatible experience outside of Emacs. I don't think that level of re-implementation was what the OP was suggesting. Again: GitHub. Orgzly. The conversation should move from "it can't be done" or "it isn't helpful" (why so much negativity on this thread?) to + What parts can be standardized and re-implemented outside of Emacs. + How do we define graceful failure for the other parts. + How do we support 3rd-party implementation in a way that benefits all of us. -k.
Re: Tables: missing multi-col/row syntax
David Rogers writes: IMO this can (and definitely should) be regarded as a purely cosmetic problem, to be resolved by purely cosmetic methods. I think the idea that each table cell is exactly one unit of information (and can’t be a collection or array of units of information) is more important than this issue. In other words, I think it’s better to ridiculously overload fontification and output formatting, than to sacrifice the main logic of how tables currently work. I just don’t believe that it could be worth it. The appearance of the tables is purely cosmetic ... however when one ends up maintaining three copies of the same table, I don't think that dismissing it offhand as a "cosmetic problem" is a productive approach. -- Timothy
Re: Tables: missing multi-col/row syntax
TEC writes: Hi all, This is a pretty major 'feature request', but I think also an important one. When developing large tables, it can often be /necessary/ to start using multi-column/row cells for clarity, and sensible exporting results. IMO this can (and definitely should) be regarded as a purely cosmetic problem, to be resolved by purely cosmetic methods. I think the idea that each table cell is exactly one unit of information (and can’t be a collection or array of units of information) is more important than this issue. In other words, I think it’s better to ridiculously overload fontification and output formatting, than to sacrifice the main logic of how tables currently work. I just don’t believe that it could be worth it. -- David Rogers
Re: Org mode fontification error in # in python and ipython source blocks
Dear Stardiviner,
I used the "scimax" configuration. Scimax's maintainer, John Kitchin,
helped me out to find the root cause of the problem, i.e. the following
addition to " python-font-lock-keywords":
(setq python-font-lock-keywords
(append python-font-lock-keywords
'(;; this is the full string.
;; group 1 is the quote type and a closing quote is matched
;; group 2 is the string part
(
;; "f\\(['\"]\\{1,3\\}\\)\\([^\\1]+?\\)\\1"
"f\\(['\"]\\{1,3\\}\\)\\(.+?\\)\\1"
;; these are the {keywords}
("{[^}]*?}"
;; Pre-match form
(progn (goto-char (match-beginning 0)) (match-end 0))
;; Post-match form
(goto-char (match-end 0))
;; face for this match
(0 font-lock-variable-name-face t))
Commenting out this code snippet, the fontfying / HTML-export problem goes
away.
Cheers,
sebastian
On Tue, Nov 3, 2020 at 6:50 AM stardiviner wrote:
> I have same problem sometimes in different babel languages.
> I would like to know what caused this problem too.
> Can you send me a message after you solved problem? Thanks in advance. :)
> smile
>
> [stardiviner] GPG key ID: 47C32433
> IRC(freeenode): stardiviner Twitter: @numbchild
> Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
> Blog: http://stardiviner.github.io/
>
>
> On Mon, Nov 2, 2020 at 2:26 AM Sebastian Gimeno
> wrote:
>
>> Hi,
>>
>> I am using emacs 27.1 and org-plus-contrib 20201026.
>>
>> I am having problems with the fontification of python and ipython source
>> blocks when the code contains curly brackets "{}" (other course blocks are
>> ok). For instance, the following snippet
>>
>> #+BEGIN_SRC python :results drawer
>> import matplotlib.pyplot as plt
>> plt.plot([1,2,3])
>> plt.show()
>> a=1
>> print("a={}".format{a})
>> #+END_SRC
>>
>> does not fontify correctly in either python or ipython source blocks.
>>
>> As a consequence, when exporting the org file to HTML (C-c C-e h h), it
>> fails with the following message:
>>
>> font-lock-fontify-keywords-region: Invalid function: #
>>
>> If changing the code snippet to:
>>
>> #+BEGIN_SRC python :results drawer
>> import matplotlib.pyplot as plt
>> plt.plot([1,2,3])
>> plt.show()
>> a=1
>> print("a=%s" % a)
>> #+END_SRC
>>
>> the block fontifies and the file is exported to HTML correctly.
>>
>> Can you reproduce this behaviour?
>>
>> Many thanks in advance!
>>
>
[PATCH] lisp/org.el: Use `org-document-info' face for subtitles
Org currently uses `org-meta-line' to display the value of the #+subtitle:
property. However, the subtitle isn’t meta information, but document
information supposed to be displayed in the exported document like title,
author, date, e-mail. The attached patch uses the face `org-document-info' to
display subtitles, which is the same face as for title, author, date, e-mail.
Titus
>From ffb43ad434031ff0ae335711d7ac29c8a4973417 Mon Sep 17 00:00:00 2001
From: Titus von der Malsburg
Date: Tue, 3 Nov 2020 10:32:57 +0100
Subject: [PATCH] lisp/org.el: Use face org-document-info for subtitle
* lisp/org.el: The value for the #+subtitle: property is now displayed
with face `org-document-info' instead of `org-meta-line'.
Like the title, author, e-mail, date, the subtitle is information
that is displayed in the exported document.
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 03df139fb..27f09645b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5307,7 +5307,7 @@ by a #."
(min (point-max) end-of-endline))
'(face org-block-end-line)))
t))
- ((member dc1 '("+title:" "+author:" "+email:" "+date:"))
+ ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
(org-remove-flyspell-overlays-in
(match-beginning 0)
(if (equal "+title:" dc1) (match-end 2) (match-end 0)))
--
2.25.1
Re: Thoughts on the standardization of Org
Asa Zeren writes: Hi, Even though I am new to the org-mode community, I would like to share some thoughts on the specification of org-mode, especially since I have seen some recent discussion of it in relation to registering org as a MIME type. First, I would like to repeat the importance of developing standards for org-mode. If we want to expand the influence of org, tooling must expand beyond Emacs. While Emacs is an amazing tool, ... I disagree (in principle, not just because it would be difficult) with the idea of “expanding beyond Emacs”. Org-mode benefits greatly from current and future Emacs development, and asking to standardize “just the parts that are not Emacs” would cause Org-mode to lose that huge advantage. Org-mode relies heavily on the editor it’s built on, and if it ceased to rely on Emacs, it would be forced to rely on “nothing at all” instead. Not only that, but for Org-mode users being able to count on all of Emacs is a big part of why it works. This means separating Org-mode from Emacs is a “lose-lose” idea. As far as the level of difficulty, any developer thinking “I want my application to be able to run Org-mode” really just has one item on their to-do list: Duplicate every detail of Emacs, including all the obscure capabilities and all the quirks, especially that everything user-modifiable is in Emacs Lisp, and maintain all future updates in lockstep with whatever the future Emacs developers decide. Sounds like fun. :) If you admire a certain car maker’s engines, you can probably get one somehow to install in a unique car you’re building. But this situation isn’t really like that. This idea is more like wanting to buy just the speed indicator from a fast car and install that, expecting it to improve your car’s acceleration. -- David Rogers
