Re: (Feature Request) customise LaTeX-preview regex
Hello,
Timothy writes:
> This time, I'm wanting to be able to use the lovely org latex preview
> functionality for more than just the default blocks.
> For instance, I'm interested in applying it to mhchem \ce{ … }
> fragments, as well as siunitx \SI{ … }{ … }.
I think you can preview \ce{...} just fine, with appropriate LaTeX
headers.
> I thought modifying org-latex-regexps may do the trick, yet despite
> trying a few different things, I was confused when unable to get it to
> work. It looks like I'm being confounded by the fact that
> org-format-latex doesn't even reference org-latex-regexps, and instead
> uses it's own hard-coded regexps.
> Hopefully it may be possible to tweak this so that once can preview
> more than just the defaults hardcoded into org-format-latex.
This should not be possible. Org cannot recognize all LaTeX syntax. If
you cannot preview it, Org does not understand it. IOW, it would be
a poor experience if you preview something that doesn't exist, e.g.,
upon exporting the document.
OTOH, nothing prevents an external library to allow previewing any LaTeX
code (probably re-using AucTeX facilities).
Regards,
--
Nicolas Goaziou
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello, Timothy writes: > I love the first-class LaTeX support in Org-mode, and discovering that > org-edit-special worked inside LaTeX environments was a joyous moment for me. > Shortly after that though, I was disappoint to discover that this > didn't work with inline LaTeX equations \( … \) or LaTeX display > equations \[ … \]. If it would be possible to account for this form of > LaTeX too, that would be marvellous! Luckily, this is trivial to implement. One needs to write a `org-edit-latex-fragment' function in "org-src.el", which would be a mix between `org-edit-latex-environment' and `org-edit-inline-src-code' (without all the Babel stuff). The new function can then be installed in `org-edit-special' from "org.el". Unfortunately, no one so far volunteered to do it (*hint*). > First email to this mailing list, so please let me know if I'm not > quite following protocol or anything like that. Welcome! > I'm also a uni student a few weeks off from exams so I am not able to > really need to resist the urge to jump in and work on implementing > these ideas. I should have significantly more time late june though :) Great. For non-trivial (more than 15 locs) contributions to Org mode (and more generally, to GNU projects), you need to sign FSF papers. You might want to consider signing them beforehand. Regards, -- Nicolas Goaziou
Re: `#+author:' stopped setting the author to empty string
Hello, Kyle Meyer writes: > It bisects to b4e91b7e9 (New function: org-collect-keywords, > 2020-04-26). I haven't done much digging, but I was able to restore the > behavior with the change below, which may be a bad idea for other > reasons. > > diff --git a/lisp/org.el b/lisp/org.el > index 0e1e05239..a8db4c2bf 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -4501,7 +4501,6 @@ (defun org--collect-keywords-1 (keywords uniques files > alist) > (push (cons key value) alist) > (setq keywords (remove key keywords)) > (setq regexp (org-make-options-regexp keywords))) > - ((not (org-string-nw-p value)) nil) >((null entry) (push (list key value) alist)) >(t (push value (cdr entry))) At first glance, it looks harmless. If the test suite passes, we can apply it. Thank you. Regards, -- Nicolas Goaziou
Re: (Feature Request) add more entry points to configure some export functionality
Hello, Timothy writes: > We're now onto email 2/4. This one is a wish-list of entry points for > customising export functionality (well, styling). Export framework has *many* entry points already. See (info "(org)Advanced Export Configuration") > I'm a big fan of trying to make my documents look snazzy with minimal > work (i.e. by cramming all the snazzyness in the back-end), which is > why I was thrilled to be able to make use of customisations like > org-html-checkbox-types (see > https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type > for my use of it). > > However, there are a two areas where I am really interested in seeing > similar customisations, ideally without the need to advice-override > org functions. In the hope that these may be developed, I'll detail > them below. > LaTeX Export: Checkboxes > - I also want to be able to tweak the checkboxes here. This is trivial with an item filter. Regards, -- Nicolas Goaziou
Re: issue tracker?
On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote: > Doesn’t Gogs have a nice issue tracker functionality? I looked up Gogs. Needs javascript *and* cookies. Wake me up when there's a plain, straight service which works without any of them. Cheers -- t signature.asc Description: Digital signature
Re: Status of syntax specification
> It would need proof reading, and comparing with "org-element.el", the > actual implementation of the syntax. Formalization may be better better, > too. I didn't know that there was a single point of entry to parse elements. I think my first step will be to try to write spec tests in elisp then. Hopefully I can cover most cases in the draft, and then see if org-element returns the tree that I expect for a cursor in various positions. Spec tests should use ERT too right ? If I try to write those, I might as well make them in a suitable way for integration in org-mode codebase. Thanks for the draft at least, it is a very helpful kickstart ! Gerry Agbobada
Re: (Feature Request) customise LaTeX-preview regex
Hi Nicolas,
Thanks for getting back to me on this. With regard to
> I think you can preview \ce{...} just fine, with appropriate LaTeX headers.
I'm entirely likely to be missing something, however from a minimal test in a
document I'm unable to get org-latex-preview to do anything with the following:
#+LATEX_HEADER: \usepackage{mhchem}
\ce{CO2} @@latex:\ce{CO2}@@
> This should not be possible. Org cannot recognize all LaTeX syntax. If
> you cannot preview it, Org does not understand it. IOW, it would be
> a poor experience if you preview something that doesn't exist, e.g.,
> upon exporting the document.
in a doc
My thoughts were that perhaps what works for \( ... \) and \[ ... \] (in terms
of org-latex-preview) could be extended to other forms of inline LaTeX as well?
Given your response I'm guessing there are technical challenges with this?
FYI it seems to work fine for exporting (see image below), I'd just quite like
to benefit from the visual tidiness achieved by the current LaTeX maths
fragment rendering.
Oh, it just comes to mind that you may be referring to non-TeX-based output
formats, where I can see that this could be a huge hassle.
Once again, (at this point in time) I am very loosely familiar with the innards
of org (I've just stumbled around loking for specifics with C-h f / C-h v),
so if I look like I'm making any strange/outragous statements, please apply a
substantial pinch of salt :D
Timothy
On May 19 2020, at 3:26 pm, Nicolas Goaziou wrote:
> Hello, Timothy writes: > This time, I'm wanting to be able to use the lovely
> org latex preview functionality for more than just the default blocks. > For
> instance, I'm interested in applying it to mhchem \ce{ … } > fragments, as
> well as siunitx \SI{ … }{ … }. I think you can preview \ce{...} just fine,
> with appropriate LaTeX headers. > I thought modifying org-latex-regexps may
> do the trick, yet despite > trying a few different things, I was confused
> when unable to get it to > work. It looks like I'm being confounded by the
> fact that > org-format-latex doesn't even reference org-latex-regexps, and
> instead > uses it's own hard-coded regexps. > Hopefully it may be possible to
> tweak this so that once can preview > more than just the defaults hardcoded
> into org-format-latex. This should not be possible. Org cannot recognize all
> LaTeX syntax. If you cannot preview it, Org does not understand it. IOW, it
> would be a poor experience if you preview something that doesn't exist, e.g.,
> upon exporting the document. OTOH, nothing prevents an external library to
> allow previewing any LaTeX code (probably re-using AucTeX facilities).
> Regards, -- Nicolas Goaziou
Re: (Feature Request) add more entry points to configure some export functionality
Timothy writes:
> Once again, thanks for taking the time to respond. I can assure you
> that it's much appreciated :)
You're welcome.
> By item filter, I assume you are referring to
> org-export-filter-item-functions. That looks quite promising. I just tried a
> minimal function to testit
> (defun tec/org-export-latex-fancy-item-checkboxes (text backend info)
> (pp text)
> "")
> However, I must admit I find myself somewhat overwhelmed by the
> output:
You asked for it, though, using `pp'.
#("string" X Y (properties))
is just a string, with properties attached. If you simply return `text',
you will only see
"string"
> I've tried applying a simple regex replace, which produces
> a satisfactory output though, so perhaps I'll just ignore all the
> 'extra stuff' above.
Exactly. The "extra stuff" is there for more advanced uses, when you
need information about the surrounding of the string you are going to
change.
> *
> I still feel that it would be nicer to have the body of this cl-case (from
> org-latex-item) be a variable, but I'm quite happy to have a working solution!
>(checkbox (cl-case (org-element-property :checkbox item)
>(on "$\\boxtimes$")
>(off "$\\square$")
>(trans "$\\boxminus$")))
Maybe. OTOH, Org has already so many variables…
> Lastly, might you be able to shed any light on the feasibility of my desire
> to adjust the generation of HTML headers? I'm specifically looking to insert
> an element like this within the ... block:m
> aria-hidden="true" href="#theHeaderID">(Link Icon)
I don't know HTML enough to help you. You may want to look into headline
and section filters.
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hi Nicolas, Thanks for the pointers. Taking your hint :P I took a look to see what I might be in for. With your comments in mind I started by looking at org-edit-special, and managed to get as far as org-element--current-element: but at this point I'm stumped. I'll look into getting FSF papers signed, it sounds like they may come in handy :) Timothy On May 19 2020, at 3:47 pm, Nicolas Goaziou wrote: > Hello, Timothy writes: > I love the first-class LaTeX support in Org-mode, > and discovering that org-edit-special worked inside LaTeX environments was a > joyous moment for me. > Shortly after that though, I was disappoint to > discover that this > didn't work with inline LaTeX equations \( … \) or LaTeX > display > equations \[ … \]. If it would be possible to account for this form > of > LaTeX too, that would be marvellous! Luckily, this is trivial to > implement. One needs to write a `org-edit-latex-fragment' function in > "org-src.el", which would be a mix between `org-edit-latex-environment' and > `org-edit-inline-src-code' (without all the Babel stuff). The new function > can then be installed in `org-edit-special' from "org.el". Unfortunately, no > one so far volunteered to do it (*hint*). > First email to this mailing list, > so please let me know if I'm not > quite following protocol or anything like > that. Welcome! > I'm also a uni student a few weeks off from exams so I am > not able to > really need to resist the urge to jump in and work on > implementing > these ideas. I should have significantly more time late june > though :) Great. For non-trivial (more than 15 locs) contributions to Org > mode (and more generally, to GNU projects), you need to sign FSF papers. You > might want to consider signing them beforehand. Regards, -- Nicolas Goaziou
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Timothy writes: > With your comments in mind I started by looking at org-edit-special, > and managed to get as far as org-element--current-element: but at this > point I'm stumped. It sounds like you took the opposite route. I suggested to first write a function, `org-edit-latex-fragment'. Once done, you can insert it in `org-edit-special', but it boils down to adding a line there, right below (`inline-src-block ...): (`latex-fragment (org-edit-latex-fragments)) You really don't need to mess with `org-element--current-element' for this task. > I'll look into getting FSF papers signed, it sounds like they may come > in handy :) Great!
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Yes, the behavior changed. Now the author macro expands to blank despite the variable user-full-name is set. Note I use #OPTIONS: author:nil, which is necessary to prevent that the export is concluded by an author line. The expected behavior is to expand to the value of user-full-name. Am Mo., 18. Mai 2020 um 18:01 Uhr schrieb Nicolas Goaziou < m...@nicolasgoaziou.fr>: > Hello, > > "Dauer, Michael" writes: > > > According to my tests this is not fixed. Same use case as originally > > reported still fails: Undefined Org macro: author; aborting > > > > I also use #OPTIONS: author:nil, which is necessary to prevent that the > > export is concluded by an author line. > > > > Would you please verify the fix. Maybe I did something wrong by checking > > out commit 965cdbfd4b3316cc9044854b0e5eb5cf69927ce6 > > I cannot reproduce the problem using master branch. > > Regards, > > -- > Nicolas Goaziou >
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Nicolas, > It sounds like you took the opposite route. I suggested to first write a > function, `org-edit-latex-fragment'. I wanted to see how it would fit in first ¯\_(ツ)_/¯ > Once done, you can insert it in `org-edit-special', but it boils down to > adding a line there, right below (`inline-src-block ...): For that to work though, i.e. adding something of the form (latex-fragment ...) I'd want a `latex-fragment type to be returned from org-element-at-point wouldn't I? At the moment running (org-element-at-point) inside \( … \) yields paragraph. Can I really get away without modifying anything more than org-edit-special and writing org-edit-latex-fragment ? Timothy On May 19 2020, at 5:39 pm, Nicolas Goaziou wrote: > Timothy writes: > With your comments in mind I started by looking at > org-edit-special, > and managed to get as far as > org-element--current-element: but at this > point I'm stumped. It sounds like > you took the opposite route. I suggested to first write a function, > `org-edit-latex-fragment'. Once done, you can insert it in > `org-edit-special', but it boils down to adding a line there, right below > (`inline-src-block ...): (`latex-fragment (org-edit-latex-fragments)) You > really don't need to mess with `org-element--current-element' for this task. > > I'll look into getting FSF papers signed, it sounds like they may come > in > handy :) Great!
How to defint functions for other org link parameters like :face :display etc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm write an extension to beautify org link with colors and unicode icons for better intuitive looks. But I don't know how to write those functions. I checked out this info page ([[info:org#Adding Hyperlink Types][info:org#Adding Hyperlink Types]]) of org mode. But have not found ~org-link-set-parameters~ other parameters code examples. I hope some examples can be added for the all other parameters. - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7DuYkUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsMMRAf/dkXg9kxbgTeCdjfcl2koeJkBmfNj xFGkuM0MlAc1oCIvGAeZ23GZ/B9cgtbfarGdZy1FJl9r7ehFx10Qg9w5keSIptA6 mplEeCeKNgTwzyHIMQhI4xS+a80YliJNc8MgFi2o9tImKqavVV2eqwHPZDNE8HXt NEN+tfi8k2Sg7J7XhkdQD1YiNPTnKD8OXfzaR6162l5qSo3YuwoAegGmuULie2Ti fci2pFO56g46xLp1tWvI6z+Zxabyff/IjKkSWSNTHuQ5lhvYsmuFKF1JDfS/DHJV zy3Rr6sXK+MY1YWMMh2uLvmigL/BYl5HvjzC/Sq6wXcqVi0FuryeEfDWzg== =HMJr -END PGP SIGNATURE-
Re: How to defint functions for other org link parameters like :face :display etc?
My go to reference is https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/ J On Tue, May 19, 2020 at 6:56 AM stardiviner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > I'm write an extension to beautify org link with colors and unicode icons > for > better intuitive looks. But I don't know how to write those functions. > > I checked out this info page ([[info:org#Adding Hyperlink > Types][info:org#Adding Hyperlink Types]]) of org mode. > > But have not found ~org-link-set-parameters~ other parameters code > examples. I > hope some examples can be added for the all other parameters. > > - -- > [ stardiviner ] >I try to make every word tell the meaning that I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > > -BEGIN PGP SIGNATURE- > > iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7DuYkUHG51bWJjaGls > ZEBnbWFpbC5jb20ACgkQG13xyVromsMMRAf/dkXg9kxbgTeCdjfcl2koeJkBmfNj > xFGkuM0MlAc1oCIvGAeZ23GZ/B9cgtbfarGdZy1FJl9r7ehFx10Qg9w5keSIptA6 > mplEeCeKNgTwzyHIMQhI4xS+a80YliJNc8MgFi2o9tImKqavVV2eqwHPZDNE8HXt > NEN+tfi8k2Sg7J7XhkdQD1YiNPTnKD8OXfzaR6162l5qSo3YuwoAegGmuULie2Ti > fci2pFO56g46xLp1tWvI6z+Zxabyff/IjKkSWSNTHuQ5lhvYsmuFKF1JDfS/DHJV > zy3Rr6sXK+MY1YWMMh2uLvmigL/BYl5HvjzC/Sq6wXcqVi0FuryeEfDWzg== > =HMJr > -END PGP SIGNATURE- > > -- 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
Re: (Feature to Potentially Upstream) extending org-plot.el: some work done, more to go
On Tuesday, 19 May 2020 at 10:02, Timothy wrote: > As this currently stands, with the below table and plot line I can > produce this plot https://media.githubusercontent.com/media/tecosaur/ > emacs-config/master/misc/document-format-comparison.png. This looks very nice and I would use it if it were incorporated into org. You may wish to sign the FSF copyright assignment and submit a patch? I normally use tikz for generating radar plots but for some use cases, using org-plot would be ideal. Thank you. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
Re: (Feature to Potentially Upstream) extending org-plot.el: some work done, more to go
I don't have any specific comments, but it looks great in general, and I'd use it!
Re: (Feature Request) customise LaTeX-preview regex
On Tuesday, 19 May 2020 at 15:49, Timothy wrote:
> #+LATEX_HEADER: \usepackage{mhchem}
> \ce{CO2} @@latex:\ce{CO2}@@
You probably need to add this to =org-latex-packages-alist= in your
emacs configuration:
(add-to-list 'org-latex-packages-alist '("version=3" "mhchem"))
Also, you might be interested in using the org-fragtog MELPA package.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello All! I love the first-class LaTeX support in Org-mode, and discovering that org-edit-special worked inside LaTeX environments was a joyous moment for me. Shortly after that though, I was disappoint to discover that this didn't work with inline LaTeX equations \( … \) or LaTeX display equations \[ … \]. If it would be possible to account for this form of inline LaTeX too, that would be marvellous! A brief note on me Hola! Love the work that's gone on here, so first of all: thanks to all those who have helped make Org-mode so great . I'm a new-ish Emacs user (~5 months old) currently using Doom (which I'm finding very comfortable), and my only regret is not getting into this all earlier First email to this mailing list, so please let me know if I'm not quite following protocol or anything like that. Otherwise, this is the first of a few emails that I've been meaning to send off for a while now. I'm also a uni student a few weeks off from exams so I am not able to really need to resist the urge to jump in and work on implementing these ideas. I should have significantly more time late june though :) All the best, tecosaur
(Feature Request) customise LaTeX-preview regex
Another email, another request
Hoping that you aren't tired of me yet, I have … (drum-roll) another feature
request!
This time, I'm wanting to be able to use the lovely org latex preview
functionality for more than just the default blocks.
For instance, I'm interested in applying it to mhchem \ce{ … } fragments, as
well as siunitx \SI{ … }{ … }.
I thought modifying org-latex-regexps may do the trick, yet despite trying a
few different things, I was confused when unable to get it to work. It looks
like I'm being confounded by the fact that org-format-latex doesn't even
reference org-latex-regexps, and instead uses it's own hard-coded regexps.
Hopefully it may be possible to tweak this so that once can preview more than
just the defaults hardcoded into org-format-latex.
Warm regards,
tecosaur
(Feature Request) add more entry points to configure some export functionality
It's me again! We're now onto email 2/4. This one is a wish-list of entry points for customising export functionality (well, styling). I'm a big fan of trying to make my documents look snazzy with minimal work (i.e. by cramming all the snazzyness in the back-end), which is why I was thrilled to be able to make use of customisations like org-html-checkbox-types (see https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type for my use of it). However, there are a two areas where I am really interested in seeing similar customisations, ideally without the need to advice-override org functions. In the hope that these may be developed, I'll detail them below. LaTeX Export: Checkboxes - I also want to be able to tweak the checkboxes here. HTML Export: Headers - I'd quite like to customise the generation of headers This is with the aim of adding the rather nice github-style to easily copy a link to that position to the clipboard. From memory modifying this would require overriding a large function, which I didn't like the look of. Best wishes, tecosaur
(Feature to Potentially Upstream) extending org-plot.el
Good news! This is the last of my "things I want to contact the mailing list about" backlog So, I recently wanted to be able to create a radar chart in org, using #+PLOT without a 500 character #+PLOT line. I started with advice-override, but quickly realised it would be better just to switch out org-plot.el with a modified version, which can be found here: https://github.com/tecosaur/emacs-config/blob/master/lisp/org-plot.el As this currently stands, with the below table and plot line I can produce this plot https://media.githubusercontent.com/media/tecosaur/emacs-config/master/misc/document-format-comparison.png. (https://media.githubusercontent.com/media/tecosaur/emacs-config/master/misc/document-format-comparison.png) #+PLOT: transpose:yes type:radar min:0 max:4 file:"misc/document-format-comparison.png" | Format | Fine-grained-control | Initial Effort | Syntax simplicity | Editor Support | Integrations | Ease-of-referencing | Versatility | |---+--++---++--+-+-| | Word | 2 | 4 | 4 | 2 | 3 | 2 | 2 | | LaTeX | 4 | 1 | 1 | 3 | 2 | 4 | 3 | | Org Mode | 4 | 2 | 3.5 | 1 | 4 | 4 | 4 | | Markdown | 1 | 3 | 3 | 4 | 3 | 3 | 1 | | Markdown + Pandoc | 2.5 | 2.5 | 2.5 | 3 | 3 | 3 | 2 | The colours are a doom-specific bit, because I draw them from the current doom theme. I figure this could just be replaced with a general purpose entry point into the plot generation script where the user can add a 'custom preamble' function. I'm also interested in refactoring the type:XXX bit so that it's more general, less hardcoded. I don't know what may be involved, but I'm thinking something similar to org export when you can define a new export function could be nice (hough I imagine that example is far more complicated than this would be). I'm hoping that someone may be interested enough to provide feedback, and idealy help me extend org-plot in this manner, with the goal of having this functionality upstreamed (assuming interest in doing so). Please let me know! All the best, tecosaur (p.s. as mentioned in my first email, I am going to try getting dragged down this rabbit-hole again till late june)
Re: (Feature Request) add more entry points to configure some export functionality
Nicolas,
> You asked for it, though, using `pp'.
I guess I did, didn't I
> is just a string, with properties attached. If you simply return `text', you
> will only see "string"
Good to know, thanks :)
>> I still feel that it would be nicer to have the body of this cl-case (from
>> org-latex-item) be a variable
> Maybe. OTOH, Org has already so many variables…
Indeed. Though my 2c on this sort of thing that the most important factor is
consistency. IMO if org-html-checkbox-types exists, then an equivalent should
also exist for other primary/default export backends.
> I don't know HTML enough to help you. You may want to look into headline and
> section filters.
Looks like this can do it for me! I still prefer doing this at-generation, but
I'll take this too.
Seems to be working :)
https://tecosaur.github.io/emacs-config/config.html#header-anchors
Timothy
On May 19 2020, at 5:29 pm, Nicolas Goaziou wrote:
> Timothy writes: > Once again, thanks for taking the time to respond. I can
> assure you > that it's much appreciated :) You're welcome. > By item filter,
> I assume you are referring to org-export-filter-item-functions. That looks
> quite promising. I just tried a minimal function to testit > (defun
> tec/org-export-latex-fancy-item-checkboxes (text backend info) > (pp text) >
> "") > However, I must admit I find myself somewhat overwhelmed by the >
> output: You asked for it, though, using `pp'. #("string" X Y (properties)) is
> just a string, with properties attached. If you simply return `text', you
> will only see "string" > I've tried applying a simple regex replace, which
> produces > a satisfactory output though, so perhaps I'll just ignore all the
> > 'extra stuff' above. Exactly. The "extra stuff" is there for more advanced
> uses, when you need information about the surrounding of the string you are
> going to change. > * > I still feel that it would be nicer to have the body
> of this cl-case (from org-latex-item) be a variable, but I'm quite happy to
> have a working solution! > (checkbox (cl-case (org-element-property :checkbox
> item) > (on "$\\boxtimes$") > (off "$\\square$") > (trans "$\\boxminus$")))
> Maybe. OTOH, Org has already so many variables… > Lastly, might you be able
> to shed any light on the feasibility of my desire to adjust the generation of
> HTML headers? I'm specifically looking to insert an element like this within
> the ... block:m > aria-hidden="true" href="#theHeaderID">(Link Icon) I don't
> know HTML enough to help you. You may want to look into headline and section
> filters.
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Hello, Ihor Radchenko writes: >> As you noticed, using Org Element is a no-go, unfortunately. Parsing an >> element is a O(N) operation by the number of elements before it in >> a section. In particular, it is not bounded, and not mitigated by >> a cache. For large documents, it is going to be unbearably slow, too. > > Ouch. I thought it is faster. > What do you mean by "not mitigated by a cache"? Parsing starts from the closest headline, every time. So, if Org parses the Nth element in the entry two times, it really parses 2N elements. With a cache, assuming the buffer wasn't modified, Org would parse N elements only. With a smarter cache, with fine grained cache invalidation, it could also reduce the number of subsequent parsed elements. > The reason I would like to utilise org-element parser to make tracking > modifications more robust. Using details of the syntax would make the > code fragile if any modifications are made to syntax in future. I don't think the code would be more fragile. Also, the syntax we're talking about is not going to be modified anytime soon. Moreover, if folding breaks, it is usually visible, so the bug will not be unnoticed. This code is going to be as low-level as it can be. > Debugging bugs in modification functions is not easy, according to my > experience. No, it's not. But this is not really related to whether you use Element or not. > One possible way to avoid performance issues during modification is > running parser in advance. For example, folding an element may > as well add information about the element to its text properties. > This will not degrade performance of folding since we are already > parsing the element during folding (at least, in > org-hide-drawer-toggle). We can use this information stored at fold time. But I'm not even sure we need it. > The problem with parsing an element during folding is that we cannot > easily detect changes like below without re-parsing. Of course we can. It is only necessary to focus on changes that would break the structure of the element. This does not entail a full parsing. > :PROPERTIES: > :CREATED: [2020-05-18 Mon] > :END: <- added line > :ID: test > :END: > > or even > > :PROPERTIES: > :CREATED: [2020-05-18 Mon] > :ID: test > :END: <- delete this line > > :DRAWER: > test > :END: Please have a look at the "sensitive parts" I wrote about. This takes care of this kind of breakage. > The re-parsing can be done via regexp, as you suggested, but I don't > like this idea, because it will end up re-implementing > org-element-*-parser. You may have misunderstood my suggestion. See below. > Would it be acceptable to run org-element-*-parser > in after-change-functions? I'd rather not do that. This is unnecessary consing, and matching, etc. > If I understand correctly, it is not as easy. > Consider the following example: > > :PROPERTIES: > :CREATED: [2020-05-18 Mon] > > :ID: example > :END: > > <... a lot of text, maybe containing other drawers ...> > > Nullam rutrum. > Pellentesque dapibus suscipit ligula. > > Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. > > If the region gets deleted, the modification hooks from chars inside > drawer will be called as (hook-function > ). So, there is still a need to find the drawer somehow to > mark it as about to be modified (modification hooks are ran before > actual modification). If we can stick with `after-change-functions' (or local equivalent), that's better. It is more predictable than `before-change-functions' and alike. If it is a deletion, here is the kind of checks we could do, depending on when they are performed. Before actual changes : 1. The deletion is happening within a folded drawer (unnecessary step in local functions). 2. The change deleted the sensitive line ":END:". 3. Conclusion : unfold. Or, after actual changes : 1. The deletion involves a drawer. 2. Text properties indicate that the beginning of the propertized part of the buffer start with org-drawer-regexp, but doesn't end with `org-property-end-re'. A "sensitive part" disappeared! 3. Conclusion : unfold This is far away from parsing. IMO, a few checks cover all cases. Let me know if you have questions about it. Also, note that the kind of change you describe will happen perhaps 0.01% of the time. Most change are about one character, or a single line, long. > The only difference between using modification hooks and > before-change-functions is that modification hooks will trigger less > frequently. Exactly. Much less frequently. But extra care is required, as you noted already. > Considering the performance of org-element-at-point, it is > probably worth doing. Initially, I wanted to avoid it because setting a > single before-change-functions hook sounded cleaner than setting > modification-hooks, insert-behind-hooks, and insert-in-front-hooks. Well, `before-change-fuctions' and `after-change-functions' are not clean at all: you
[Question] why my org-link-set-parameters :face function does not work?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bellowing is my source code, it does not work. I'm wondering why?
#+begin_src emacs-lisp
(defun org-link-beautify-face (link)
"Set link face colors."
(let ((raw-link (org-element-property :raw-link link))
(type (org-element-property :type link))
(path (org-element-property :path link)))
(pcase type
;; ("https" )
;; ("http" )
("file"
(if (and (not (file-remote-p path))
(file-exists-p (expand-file-name path)))
'org-link 'org-warning)
;;; DEBUG
(org-link-set-parameters
"file"
:face #'org-link-beautify-face)
#+end_src
- --
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-
iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D2xkUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsMfHAgAjnoQlzdHlcKL/rBVBLlkmMITh7f5
6SxRw9sS1BagIma+APiuy+A4O4fSDLyzUMDg+Sg/C+vNu3QC2BM7ipBYNXtWcX1M
oPZj8loMrnISTIK51j2+9Pg0iOP1aZSvZqwA0p1mK2aZURBXWl7qDkVxD2oWji5P
qCBVr9ZFUloGSl7PtZTlOtsCgTCGHvnfvnk7vqxY4beuavQgaRSWUCsVDDO0c/M6
5CSzxobElB3Y68fQ2awuQwRGCzfEvRkGShHp3Raug+EJ5Ew+MYEi6wILfPxYF2WR
VJjuxAxseBuiIjYjF91xzbR7mSZQsvB1gNttLYb3uQ/jrgj0HOQDo5Jmtg==
=4fE9
-END PGP SIGNATURE-
Re: (Feature Request) add more entry points to configure some export functionality
Timothy writes: As a side note, I think sending plain text messages, instead of HTML, is better, at least on a (this?) mailing list. > Indeed. Though my 2c on this sort of thing that the most important > factor is consistency. IMO if org-html-checkbox-types exists, then an > equivalent should also exist for other primary/default export > backends. This argument doesn't scale. There's no guarantee an equivalent is meaningful in every export back end. E.g., what is the HTML equivalent for `org-latex-classes', or `org-latex-default-table-environment'? In any case, if a "consistency patrol" wants to look into export back ends and handle "fixable" inconsistencies, why not. I assume this requires a good knowledge in every output format so as to make sure this is consistent everywhere.
Re: How to defint functions for other org link parameters like :face :display etc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John Kitchin writes: > My go to reference is > https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/ Really thanks, John. I have read your blog article. Found most of link parameters examples. But still confused me, I'm wandering how to define a function for link parameter ":display" to append an all-the-icons unicode icon on link. I only found one ~:display 'full~ example in your article. an you show an example using a function for ~:display~? Thanks in advanced. > > On Tue, May 19, 2020 at 6:56 AM stardiviner wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> >> I'm write an extension to beautify org link with colors and unicode icons >> for >> better intuitive looks. But I don't know how to write those functions. >> >> I checked out this info page ([[info:org#Adding Hyperlink >> Types][info:org#Adding Hyperlink Types]]) of org mode. >> >> But have not found ~org-link-set-parameters~ other parameters code >> examples. I >> hope some examples can be added for the all other parameters. >> >> - -- >> [ stardiviner ] >>I try to make every word tell the meaning that I want to express. >> >>Blog: https://stardiviner.github.io/ >>IRC(freenode): stardiviner, Matrix: stardiviner >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >> >> -BEGIN PGP SIGNATURE- >> >> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7DuYkUHG51bWJjaGls >> ZEBnbWFpbC5jb20ACgkQG13xyVromsMMRAf/dkXg9kxbgTeCdjfcl2koeJkBmfNj >> xFGkuM0MlAc1oCIvGAeZ23GZ/B9cgtbfarGdZy1FJl9r7ehFx10Qg9w5keSIptA6 >> mplEeCeKNgTwzyHIMQhI4xS+a80YliJNc8MgFi2o9tImKqavVV2eqwHPZDNE8HXt >> NEN+tfi8k2Sg7J7XhkdQD1YiNPTnKD8OXfzaR6162l5qSo3YuwoAegGmuULie2Ti >> fci2pFO56g46xLp1tWvI6z+Zxabyff/IjKkSWSNTHuQ5lhvYsmuFKF1JDfS/DHJV >> zy3Rr6sXK+MY1YWMMh2uLvmigL/BYl5HvjzC/Sq6wXcqVi0FuryeEfDWzg== >> =HMJr >> -END PGP SIGNATURE- >> >> -- > 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 - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D3TMUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPoCQf/TrUtyBtPUYGtNiJeXWk0oQNbwggf 6FHX3wsvBS3O9A2VpKuzWTdnKSFR7dVUF8NkBwHbvU+599LqT5XxGtF2iDX+jgiz t0G2207sczHtiwsE/KLGAxXmEI4tGESLv+4Jui3kjp8JJJCusDcjzTIXQ6O9sb91 PmSbQhj4dbUz/3zk+utLb3YBMUPDnsr4H+eon+ko+EQOxTL48O4x7xvjj07XrnX3 DawQG0qs9SnenkMsK2HzQBRDqCf0DfrVPmajWYUQJ62j2ocah8oXij6WH5/rgCpA xtt2sXJrQd2TFpCxcGWn5PsyEUMWjxAx1dia8pcMkBLvnb2SQkM6204jWQ== =SVJD -END PGP SIGNATURE-
Re: (Feature Request) add more entry points to configure some export functionality
Nicolas Goaziou writes: > As a side note, I think sending plain text messages, instead of HTML, > is better, at least on a (this?) mailing list. Good news on that front --- I didn't think my mail client did that, turns out that it does :) > This argument doesn't scale. There's no guarantee an equivalent is > meaningful in every export back end. E.g., what is the HTML equivalent > for `org-latex-classes', or `org-latex-default-table-environment'? Oh nothing like this should be applied blindly, it just seems /somewhat/ sensible to me that if the same feature exists in two commonly used export backends, that you'd want to either be able to configure it in both or neither ¯\_(ツ)_/¯ > In any case, if a "consistency patrol" wants to look into export back > ends and handle "fixable" inconsistencies, why not. I assume this > requires a good knowledge in every output format so as to make sure this > is consistent everywhere. I like consistancy, but not enough to sign up for that :P Timothy. On May 19 2020, at 9:17 pm, Nicolas Goaziou wrote: > Timothy writes: > > As a side note, I think sending plain text messages, instead of HTML, is > better, at least on a (this?) mailing list. > >> Indeed. Though my 2c on this sort of thing that the most important >> factor is consistency. IMO if org-html-checkbox-types exists, then an >> equivalent should also exist for other primary/default export >> backends. > > This argument doesn't scale. There's no guarantee an equivalent is > meaningful in every export back end. E.g., what is the HTML equivalent > for `org-latex-classes', or `org-latex-default-table-environment'? > > In any case, if a "consistency patrol" wants to look into export back > ends and handle "fixable" inconsistencies, why not. I assume this > requires a good knowledge in every output format so as to make sure this > is consistent everywhere. >
Re: How to defint functions for other org link parameters like :face :display etc?
I don't know if :display is for that, I think it is mostly related to should a link with description only show the description, or should it be full and show link and description. You probably want the :activate option, where you could use something like an overlay on the link. I don't have time to make an example for that right now. the gist is you make an activate function, and you can add a text-property or overlay display on the link. You probably need to check that the property isn't there already to avoid adding overlays on every fontification. https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/#org069cbfa 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, May 19, 2020 at 9:21 AM stardiviner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > John Kitchin writes: > > > My go to reference is > > > https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/ > > Really thanks, John. I have read your blog article. Found most of link > parameters examples. But still confused me, I'm wandering how to define a > function for link parameter ":display" to append an all-the-icons unicode > icon > on link. I only found one ~:display 'full~ example in your article. > > an you show an example using a function for ~:display~? Thanks in advanced. > > > > > On Tue, May 19, 2020 at 6:56 AM stardiviner wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA256 > >> > >> > >> I'm write an extension to beautify org link with colors and unicode > icons > >> for > >> better intuitive looks. But I don't know how to write those functions. > >> > >> I checked out this info page ([[info:org#Adding Hyperlink > >> Types][info:org#Adding Hyperlink Types]]) of org mode. > >> > >> But have not found ~org-link-set-parameters~ other parameters code > >> examples. I > >> hope some examples can be added for the all other parameters. > >> > >> - -- > >> [ stardiviner ] > >>I try to make every word tell the meaning that I want to express. > >> > >>Blog: https://stardiviner.github.io/ > >>IRC(freenode): stardiviner, Matrix: stardiviner > >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > >> > >> -BEGIN PGP SIGNATURE- > >> > >> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7DuYkUHG51bWJjaGls > >> ZEBnbWFpbC5jb20ACgkQG13xyVromsMMRAf/dkXg9kxbgTeCdjfcl2koeJkBmfNj > >> xFGkuM0MlAc1oCIvGAeZ23GZ/B9cgtbfarGdZy1FJl9r7ehFx10Qg9w5keSIptA6 > >> mplEeCeKNgTwzyHIMQhI4xS+a80YliJNc8MgFi2o9tImKqavVV2eqwHPZDNE8HXt > >> NEN+tfi8k2Sg7J7XhkdQD1YiNPTnKD8OXfzaR6162l5qSo3YuwoAegGmuULie2Ti > >> fci2pFO56g46xLp1tWvI6z+Zxabyff/IjKkSWSNTHuQ5lhvYsmuFKF1JDfS/DHJV > >> zy3Rr6sXK+MY1YWMMh2uLvmigL/BYl5HvjzC/Sq6wXcqVi0FuryeEfDWzg== > >> =HMJr > >> -END PGP SIGNATURE- > >> > >> -- > > 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 > > > - -- > [ stardiviner ] >I try to make every word tell the meaning that I want to express. > >Blog: https://stardiviner.github.io/ >IRC(freenode): stardiviner, Matrix: stardiviner >GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 > > -BEGIN PGP SIGNATURE- > > iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D3TMUHG51bWJjaGls > ZEBnbWFpbC5jb20ACgkQG13xyVromsPoCQf/TrUtyBtPUYGtNiJeXWk0oQNbwggf > 6FHX3wsvBS3O9A2VpKuzWTdnKSFR7dVUF8NkBwHbvU+599LqT5XxGtF2iDX+jgiz > t0G2207sczHtiwsE/KLGAxXmEI4tGESLv+4Jui3kjp8JJJCusDcjzTIXQ6O9sb91 > PmSbQhj4dbUz/3zk+utLb3YBMUPDnsr4H+eon+ko+EQOxTL48O4x7xvjj07XrnX3 > DawQG0qs9SnenkMsK2HzQBRDqCf0DfrVPmajWYUQJ62j2ocah8oXij6WH5/rgCpA > xtt2sXJrQd2TFpCxcGWn5PsyEUMWjxAx1dia8pcMkBLvnb2SQkM6204jWQ== > =SVJD > -END PGP SIGNATURE- > >
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Nicolas Goaziou writes: > LaTeX fragments are at a lower level than plain "elements", so > `org-element-at-point' does not see them. I see. Might you be willing to do & show me the modifications needed to use the `latex-fragment case? >> Can I really get away without modifying anything more than >> org-edit-special and writing org-edit-latex-fragment ? > Yes, you (we) can! Fantastic! In other news, I have sent off am email to ass...@gnu.org, so hopefully you'll be able to accept >15 loc patches from me in the (near?) future :) > Timothy writes: > >>> It sounds like you took the opposite route. I suggested to first >>> write a function, `org-edit-latex-fragment'. >> I wanted to see how it would fit in first ¯\_(ツ)_/¯ > > Sure. That's a good way to learn stuff. In this case, it's not the > easiest one, though. > >>> Once done, you can insert it in `org-edit-special', but it boils >>> down to adding a line there, right below (`inline-src-block ...): > >> For that to work though, i.e. adding something of the form >> (latex-fragment ...) I'd want a `latex-fragment type to be returned >> from org-element-at-point wouldn't I? > > This is already done a few lines above in `org-edit-special', when > `org-element-context' is called. > > LaTeX fragments are at a lower level than plain "elements", so > `org-element-at-point' does not see them. > >> At the moment running (org-element-at-point) inside \( … \) yields >> paragraph. > > See above. > >> Can I really get away without modifying anything more than >> org-edit-special and writing org-edit-latex-fragment ? > > Yes, you (we) can! >
Re: issue tracker?
(I also don’t understand the knee jerk response away from cookies / JavaScript). Those are just parts of the modern web... Cookies for state and persistent login and JavaScript for making the web page interactive. Are you saying you’d want some sort of REST api instead and the website would just be a view into that? -- James Miller james.ryland.mil...@gmail.com
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Timothy writes: > I see. Might you be willing to do & show me the modifications needed to > use the `latex-fragment case? I don't understand your question.
Re: (Feature Request) customise LaTeX-preview regex
On May 19 2020, at 7:45 pm, Eric S Fraga wrote:
> You probably need to add this to =org-latex-packages-alist= in your
emacs configuration:
> (add-to-list 'org-latex-packages-alist '("version=3" "mhchem"))
I tried adding that. Didn't change anything.
> Also, you might be interested in using the org-fragtog MELPA package.
I'm already using it :P
https://tecosaur.github.io/emacs-config/config.html#visuals
> On Tuesday, 19 May 2020 at 15:49, Timothy wrote:
>> #+LATEX_HEADER: \usepackage{mhchem}
>> \ce{CO2} @@latex:\ce{CO2}@@
>
> You probably need to add this to =org-latex-packages-alist= in your
> emacs configuration:
>
> (add-to-list 'org-latex-packages-alist '("version=3" "mhchem"))
>
> Also, you might be interested in using the org-fragtog MELPA package.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
>
Re: Email rendered equation
Thanks Eric, I will give it a try Cheers, M > On May 19, 2020, at 10:14 AM, Eric S Fraga wrote: > > On Tuesday, 19 May 2020 at 09:19, Marvin M. Doyley wrote: >> I have decided to take the plunge and switch to mu4e. I have also >> installed the org-mu4e package. Most stuff works pretty well, except >> latex equations are not rendered when I send them. >> >> Does anybody know how to solve this problem? > > I don't use mu4e so I don't know what org-mu4e actually brings to the > table. In gnus, if I want to send an email with LaTeX fragments > (e.g. equations) shown as images, I invoke org-mime-htmlize on the > message once written. This creates an HTML message with org processing > (links, tables, LaTeX, images). Works well the infrequent times I do > it. > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
Re: Org-list: Add back fancy description list indentation
Hello, "James R Miller" writes: > This just might be the functionality that makes me learn elisp. :) See. You'll soon thank me for removing the feature you liked ;) Regards, -- Nicolas Goaziou
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Timothy writes: > In your original email you wrote > The new function can then be installed in `org-edit-special' from > "org.el" > > I can't quite see how I would insert this. Since it sounds relatively > simple, if you would be willing to cook up the necessary modification > for me that would be a great help. I already did, didn't I? In `org-edit-special', near the end (that is _after_ call to `org-element-context') there's a line: (`inline-src-block (org-edit-inline-src-code)) Right after this line, i.e., as another case in the `pcase' pattern, you would simply add: (`latex-fragment (org-edit-latex-fragment)) That's all for the changes required in `org-edit-special'. Of course, you need to write `org-edit-latex-fragment' function in "org-src.el" beforehand. I suggested examples to look at.
Re: issue tracker?
Regardless, doing issue tracking, discussion, and patch submission on a ML in 2020 is pretty odd and inefficient. I would have submitted feedback here 6-12 months earlier than I did if org had a proper issue tracker. On Tue, May 19, 2020, 3:35 AM wrote: > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote: > > Doesn’t Gogs have a nice issue tracker functionality? > > I looked up Gogs. Needs javascript *and* cookies. Wake me up when > there's a plain, straight service which works without any of them. > > Cheers > -- t >
Re: issue tracker?
I can't help but chime in here. Using email for project management, patches, testing, etc is not difficult or unusual. In fact, the Linux kernel uses email for this purpose. They have a variety of reasons which were recently covered in some articles. Clearly their code base and number of developers is overwhelmingly larger than Org, so we must be doing something right. https://lwn.net/Articles/702177/ https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/ My personal opinion is I'd always prefer to use my mail client over some website. I've personally chosen what I think is the best mail client, where I can easily sort and read mail from mailing lists. It has a fast interface, easy to read, and is incredibly consistent (yay Mutt!). I can also rapidly edit (in Emacs!) my replies. I can send an email in a matter of keystrokes, blindly typing. Compare that to most websites where I have to wait forever for all the crap javascript to load, forfeit my privacy to all the trackers and cookies, and then manage to figure out how their site works. Once done I'm thrown into a significantly inferior editor box to try and type or paste information in. From that point, I can only use their website to manage my submission. The irony that these websites will often notify me *by email* that something has occurred. I clearly don't agree that adding a website somehow makes issue tracking or patch submission magically easier to manage or submit bug information compared to email. If you have feedback, please don't hesitate to just send an email to the list with your questions or comments. This is easily one of my favorite lists and very welcoming even to controversial opinions. On Tue, May 19, 2020 at 10:58:26AM -0400, Bruce D'Arcus wrote: > Regardless, doing issue tracking, discussion, and patch submission on a ML > in 2020 is pretty odd and inefficient. > > I would have submitted feedback here 6-12 months earlier than I did if org > had a proper issue tracker. > > On Tue, May 19, 2020, 3:35 AM wrote: > > > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote: > > > Doesn’t Gogs have a nice issue tracker functionality? > > > > I looked up Gogs. Needs javascript *and* cookies. Wake me up when > > there's a plain, straight service which works without any of them. > > > > Cheers > > -- t > > -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: issue tracker?
My apologies. I thought Gogs was the repository for org as I that is what is linked from the homepage. -- James Miller james.ryland.mil...@gmail.com
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello,
"Dauer, Michael" writes:
> Yes, the behavior changed. Now the author macro expands to blank despite
> the variable user-full-name is set.
> Note I use #OPTIONS: author:nil, which is necessary to prevent that the export
> is concluded by an author line.
>
> The expected behavior is to expand to the value of user-full-name.
You lost me. Would you mind writing an ECM demonstrating the currently
observed defect in {{{author}}} macro from master branch?
Regards,
--
Nicolas Goaziou
Re: issue tracker?
On Tue, May 19, 2020 at 09:05:33AM -0500, James R Miller wrote: > (I also don’t understand the knee jerk response away from > cookies / JavaScript). Mine isn't a knee-jerk reaction. It's worse: it's well thought-out. Discussing that in detail would be far off-topic for this list, though. > Those are just parts of the modern web... Cookies for state and persistent > login and JavaScript for making the web page interactive. There are many things which are "parts of modern X", for many values of X, which I dislike. I tend to avoid them. > Are you saying you’d want some sort of REST api instead and the website would > just be a view into that? All well and fine (as long as it is documented). But falling back to Plain Old HTML just works too. Cheers -- t signature.asc Description: Digital signature
Re: Email rendered equation
Hi Eric, This works like a charm. Thanks, M > On May 19, 2020, at 10:14 AM, Eric S Fraga wrote: > > On Tuesday, 19 May 2020 at 09:19, Marvin M. Doyley wrote: >> I have decided to take the plunge and switch to mu4e. I have also >> installed the org-mu4e package. Most stuff works pretty well, except >> latex equations are not rendered when I send them. >> >> Does anybody know how to solve this problem? > > I don't use mu4e so I don't know what org-mu4e actually brings to the > table. In gnus, if I want to send an email with LaTeX fragments > (e.g. equations) shown as images, I invoke org-mime-htmlize on the > message once written. This creates an HTML message with org processing > (links, tables, LaTeX, images). Works well the infrequent times I do > it. > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
Re: issue tracker?
My 2c: Having a github-esque pubic issue tracker is good for accessibility — in the sense of ease of access to new-comers. Personally, this is the first time I've engaged in technical discussions on a mailing list, and needing to use a ML did feel like an extra hurdle. I wouldn't imagine that a Gogs issue tracker would prevent anyone from using the mailing list, but might encourage more people to get involved. Is there any reason why we can't have both? Timothy. On May 19 2020, at 10:58 pm, Bruce D'Arcus wrote: > Regardless, doing issue tracking, discussion, and patch submission on a ML in > 2020 is pretty odd and inefficient. > > I would have submitted feedback here 6-12 months earlier than I did if org > had a proper issue tracker. > On Tue, May 19, 2020, 3:35 AM mailto:to...@tuxteam.de)> > wrote: > > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote: > > > Doesn’t Gogs have a nice issue tracker functionality? > > > > I looked up Gogs. Needs javascript *and* cookies. Wake me up when > > there's a plain, straight service which works without any of them. > > > > Cheers > > -- t > >
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Nicolas Goaziou writes: > I already did, didn't I? > ... > That's all for the changes required in `org-edit-special'. Oh ':) I thought that was just you saying 'it would be something along the lines of...' Thanks! I'll let you know when I have something. > Timothy writes: > >> In your original email you wrote >> The new function can then be installed in `org-edit-special' from >> "org.el" >> >> I can't quite see how I would insert this. Since it sounds relatively >> simple, if you would be willing to cook up the necessary modification >> for me that would be a great help. > > I already did, didn't I? > > In `org-edit-special', near the end (that is _after_ call to > `org-element-context') there's a line: > > (`inline-src-block (org-edit-inline-src-code)) > > Right after this line, i.e., as another case in the `pcase' pattern, you > would simply add: > > (`latex-fragment (org-edit-latex-fragment)) > > That's all for the changes required in `org-edit-special'. > > Of course, you need to write `org-edit-latex-fragment' function in > "org-src.el" beforehand. I suggested examples to look at. >
Re: `#+author:' stopped setting the author to empty string
On Mon, May 18, 2020 at 7:30 PM Kyle Meyer wrote: > > It bisects to b4e91b7e9 (New function: org-collect-keywords, > 2020-04-26). I haven't done much digging, but I was able to restore the > behavior with the change below, which may be a bad idea for other > reasons. > Thanks for that bisect! If the current tests (and the new test with blank author "#+author:") pass, then we should be good :)
Email rendered equation
Hi there, I have decided to take the plunge and switch to mu4e. I have also installed the org-mu4e package. Most stuff works pretty well, except latex equations are not rendered when I send them. Does anybody know how to solve this problem? Thanks, M
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Timothy writes: >> It sounds like you took the opposite route. I suggested to first write a >> function, `org-edit-latex-fragment'. > I wanted to see how it would fit in first ¯\_(ツ)_/¯ Sure. That's a good way to learn stuff. In this case, it's not the easiest one, though. >> Once done, you can insert it in `org-edit-special', but it boils down to >> adding a line there, right below (`inline-src-block ...): > For that to work though, i.e. adding something of the form > (latex-fragment ...) I'd want a `latex-fragment type to be returned > from org-element-at-point wouldn't I? This is already done a few lines above in `org-edit-special', when `org-element-context' is called. LaTeX fragments are at a lower level than plain "elements", so `org-element-at-point' does not see them. > At the moment running (org-element-at-point) inside \( … \) yields > paragraph. See above. > Can I really get away without modifying anything more than org-edit-special > and writing org-edit-latex-fragment ? Yes, you (we) can!
Re: Email rendered equation
On Tuesday, 19 May 2020 at 09:19, Marvin M. Doyley wrote: > I have decided to take the plunge and switch to mu4e. I have also > installed the org-mu4e package. Most stuff works pretty well, except > latex equations are not rendered when I send them. > > Does anybody know how to solve this problem? I don't use mu4e so I don't know what org-mu4e actually brings to the table. In gnus, if I want to send an email with LaTeX fragments (e.g. equations) shown as images, I invoke org-mime-htmlize on the message once written. This creates an HTML message with org processing (links, tables, LaTeX, images). Works well the infrequent times I do it. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
mist.org>>>
* test
foo {{{author}}} bar {{{keyword(AUTHOR)}}}
{{{title}}}
{{{date}}}
{{{time}}}
{{{input-file}}}
{{{n}}}
<<<
ascii output buffer>>>
Michael Dauer
Table of Contents
_
1. test
1 test
==
foo bar
mist.org
1
<<<
Am Di., 19. Mai 2020 um 16:11 Uhr schrieb Nicolas Goaziou <
m...@nicolasgoaziou.fr>:
> Hello,
>
> "Dauer, Michael" writes:
>
> > Yes, the behavior changed. Now the author macro expands to blank despite
> > the variable user-full-name is set.
> > Note I use #OPTIONS: author:nil, which is necessary to prevent that the
> export
> > is concluded by an author line.
> >
> > The expected behavior is to expand to the value of user-full-name.
>
> You lost me. Would you mind writing an ECM demonstrating the currently
> observed defect in {{{author}}} macro from master branch?
>
> Regards,
>
> --
> Nicolas Goaziou
>
Re: [Question] why my org-link-set-parameters :face function does not work?
The face function only takes the link path, which is a string. you cannot
use org-element-property on it.
Maybe you want something like this:
#+begin_src emacs-lisp
(defun org-link-beautify-face (path)
"Set link face colors."
(message "beautifying")
(if (and (not (file-remote-p path))
(file-exists-p (expand-file-name path)))
'org-link
'org-warning))
;;; DEBUG
(org-link-set-parameters
"file"
:face #'org-link-beautify-face)
#+end_src
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, May 19, 2020 at 9:12 AM stardiviner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Bellowing is my source code, it does not work. I'm wondering why?
>
> #+begin_src emacs-lisp
> (defun org-link-beautify-face (link)
> "Set link face colors."
> (let ((raw-link (org-element-property :raw-link link))
> (type (org-element-property :type link))
> (path (org-element-property :path link)))
> (pcase type
> ;; ("https" )
> ;; ("http" )
> ("file"
>(if (and (not (file-remote-p path))
> (file-exists-p (expand-file-name path)))
>'org-link 'org-warning)
>
> ;;; DEBUG
> (org-link-set-parameters
> "file"
> :face #'org-link-beautify-face)
> #+end_src
>
> - --
> [ stardiviner ]
>I try to make every word tell the meaning that I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>
> -BEGIN PGP SIGNATURE-
>
> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D2xkUHG51bWJjaGls
> ZEBnbWFpbC5jb20ACgkQG13xyVromsMfHAgAjnoQlzdHlcKL/rBVBLlkmMITh7f5
> 6SxRw9sS1BagIma+APiuy+A4O4fSDLyzUMDg+Sg/C+vNu3QC2BM7ipBYNXtWcX1M
> oPZj8loMrnISTIK51j2+9Pg0iOP1aZSvZqwA0p1mK2aZURBXWl7qDkVxD2oWji5P
> qCBVr9ZFUloGSl7PtZTlOtsCgTCGHvnfvnk7vqxY4beuavQgaRSWUCsVDDO0c/M6
> 5CSzxobElB3Y68fQ2awuQwRGCzfEvRkGShHp3Raug+EJ5Ew+MYEi6wILfPxYF2WR
> VJjuxAxseBuiIjYjF91xzbR7mSZQsvB1gNttLYb3uQ/jrgj0HOQDo5Jmtg==
> =4fE9
> -END PGP SIGNATURE-
>
>
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Nicolas Goaziou writes: >> I see. Might you be willing to do & show me the modifications needed to >> use the `latex-fragment case? > I don't understand your question. In your original email you wrote The new function can then be installed in `org-edit-special' from "org.el" I can't quite see how I would insert this. Since it sounds relatively simple, if you would be willing to cook up the necessary modification for me that would be a great help. On May 19 2020, at 10:09 pm, Nicolas Goaziou wrote: > Timothy writes: > >> I see. Might you be willing to do & show me the modifications needed to >> use the `latex-fragment case? > > I don't understand your question. >
Re: issue tracker?
"James R Miller" writes: > So, I definitely agree that using Github / Gitlab does expose you to > tracking messes and that is something to shun. I figured a self-hosted > Gogs instance (which is already being hosted at > https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue. > > I think an actual issue tracker has merit to large projects. I've been going around doing proselytizing for sr.ht (sourcehut, aka "Sir Hat"), which is a forge-like site that is very much in line with Emacs' principles. No tracking (barely any javascript at all), everything can be driven via email -- it's pretty nice. Could be a good solution here. (Not affiliated, though I do give them money.) Eric
Re: issue tracker?
On Wed, May 20, 2020 at 01:03:50AM +0800, Timothy wrote: > If you don't mind me adding 2 more cents :P I don't think that email > should be given up in favour of a web client, or that it isn't better in > many ways. > > However, if it were possible to have the best of both worlds, is there a > reason why we'd say no? Just taking a guess here, but I imagine it > should be possible to sync up a public issue tracker to the mailing list. I can't object to different viewers of list content. It's archived in many places already, and perhaps those interfaces could filter for bugs or feature requests. I think there are potential issues though with trying to add any form of web submission. - Who sets up and maintains this new web interface? - Where is it hosted? - Does this add additional time and effort for the project maintainers? - Does this conflict with or supersede the mailing list, thus causing maintainers to have to maintain two parallel environments? While it may sound easy to add, and I understand you may prefer a web interface, it's a volunteer run project and email is very low effort, low maintenance, and universally accessible. > On May 20 2020, at 12:57 am, Russell Adams wrote: > > I clearly don't agree that adding a website somehow makes issue > > tracking or > > patch submission magically easier to manage or submit bug information > > compared > > to email. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: issue tracker?
If you don't mind me adding 2 more cents :P I don't think that email should be given up in favour of a web client, or that it isn't better in many ways. However, if it were possible to have the best of both worlds, is there a reason why we'd say no? Just taking a guess here, but I imagine it should be possible to sync up a public issue tracker to the mailing list. I may have missed something, or be barking up the wrong tree, but those are my current thoughts :) On May 20 2020, at 12:57 am, Russell Adams wrote: > I can't help but chime in here. Using email for project management, patches, > testing, etc is not difficult or unusual. > > In fact, the Linux kernel uses email for this purpose. They have a > variety of > reasons which were recently covered in some articles. Clearly their > code base > and number of developers is overwhelmingly larger than Org, so we must > be doing > something right. > > https://lwn.net/Articles/702177/ > > https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/ > > My personal opinion is I'd always prefer to use my mail client over some > website. I've personally chosen what I think is the best mail client, > where I > can easily sort and read mail from mailing lists. It has a fast > interface, easy > to read, and is incredibly consistent (yay Mutt!). I can also rapidly > edit (in > Emacs!) my replies. I can send an email in a matter of keystrokes, blindly > typing. > > Compare that to most websites where I have to wait forever for all the crap > javascript to load, forfeit my privacy to all the trackers and > cookies, and then > manage to figure out how their site works. Once done I'm thrown into a > significantly inferior editor box to try and type or paste information > in. From > that point, I can only use their website to manage my submission. > > The irony that these websites will often notify me *by email* that > something has > occurred. > > I clearly don't agree that adding a website somehow makes issue > tracking or > patch submission magically easier to manage or submit bug information compared > to email. > > If you have feedback, please don't hesitate to just send an email to > the list > with your questions or comments. This is easily one of my favorite > lists and > very welcoming even to controversial opinions. > > On Tue, May 19, 2020 at 10:58:26AM -0400, Bruce D'Arcus wrote: >> Regardless, doing issue tracking, discussion, and patch submission on >> a ML >> in 2020 is pretty odd and inefficient. >> >> I would have submitted feedback here 6-12 months earlier than I did >> if org >> had a proper issue tracker. >> >> On Tue, May 19, 2020, 3:35 AM wrote: >> >> > On Mon, May 18, 2020 at 06:13:38PM -0500, James R Miller wrote: >> > > Doesn’t Gogs have a nice issue tracker functionality? >> > >> > I looked up Gogs. Needs javascript *and* cookies. Wake me up when >> > there's a plain, straight service which works without any of them. >> > >> > Cheers >> > -- t >> > > > > -- > Russell Adamsrlad...@adamsinfoserv.com > > PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ > > Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 > >
Re: issue tracker?
So, I definitely agree that using Github / Gitlab does expose you to tracking messes and that is something to shun. I figured a self-hosted Gogs instance (which is already being hosted at https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue. I think an actual issue tracker has merit to large projects. And I don't think simply saying "we've always done it through a ML" or "$FOO project is bigger than us and uses a ML" is good enough. $FOO project may very well increase efficiency, code quality, and/or participation by implementing an issue tracker. A project to consider then, might be some sort of system that interfaces with the ML (as well as a simple REST api so that issues could be submitted from inside emacs directly), that creates some sort of org-based issue tracker, and then ox-html exports to a static web page or pages. -- James Miller james.ryland.mil...@gmail.com
Re: (Feature to Potentially Upstream) extending org-plot.el
+1 Le 18/05/2020 à 09:23, Timothy a écrit : Good news! This is the last of my "things I want to contact the mailing list about" backlog So, I recently wanted to be able to create a radar chart in org, using #+PLOT without a 500 character #+PLOT line. I started with advice-override, but quickly realised it would be better just to switch out org-plot.el with a modified version, which can be found here: https://github.com/tecosaur/emacs-config/blob/master/lisp/org-plot.el As this currently stands, with the below table and plot line I can produce this plot https://media.githubusercontent.com/media/tecosaur/emacs-config/master/misc/document-format-comparison.png. #+PLOT: transpose:yes type:radar min:0 max:4 file:"misc/document-format-comparison.png" | Format | Fine-grained-control | Initial Effort | Syntax simplicity | Editor Support | Integrations | Ease-of-referencing | Versatility | |---+--++---++--+-+-| | Word | 2 | 4 | 4 | 2 | 3 | 2 | 2 | | LaTeX | 4 | 1 | 1 | 3 | 2 | 4 | 3 | | Org Mode | 4 | 2 | 3.5 | 1 | 4 | 4 | 4 | | Markdown | 1 | 3 | 3 | 4 | 3 | 3 | 1 | | Markdown + Pandoc | 2.5 | 2.5 | 2.5 | 3 | 3 | 3 | 2 | The colours are a doom-specific bit, because I draw them from the current doom theme. I figure this could just be replaced with a general purpose entry point into the plot generation script where the user can add a 'custom preamble' function. I'm also interested in refactoring the type:XXX bit so that it's more general, less hardcoded. I don't know what may be involved, but I'm thinking something similar to org export when you can define a new export function could be nice (hough I imagine that example is far more complicated than this would be). I'm hoping that someone may be interested enough to provide feedback, and idealy help me extend org-plot in this manner, with the goal of having this functionality upstreamed (assuming interest in doing so). Please let me know! All the best, tecosaur (p.s. as mentioned in my first email, I am going to try getting dragged down this rabbit-hole again till late june)
Re: issue tracker?
On Tue, May 19, 2020 at 15:49 Russell Adams wrote: > Is there a problem with submitting issues via the mailing list? Has > something > gone unaddressed? Do you have any statistics to show that there is > decreased > participation because you have to use email? Is something really > inefficient at > the moment? Did you have patches ignored? I think you have the null hypothesis backwards here. Do you have any statistics to show that issues _are not_ dropping through the cracks? Sending a “ping?” message on a ML is generally considered poor netiquette, and even if it were expected here, would make many requesters uncomfortable. That’s one of the fundamental things any tracker does—keeps statistics on and forces every issue to _some_ resolution, even if it’s “will not fix” or “on hold”. Things don’t just peter out and get forgotten like on email threads. (I have not done the exercise of perusing old email threads to see if I can find issues being dropped on the floor. But I’ve already found several apparent existence proofs. Whether they’re common or rare is a question I can’t answer without doing tedious manual work that is the entire raison d’être of a tracker.) I wouldn’t dispute that the Linux kernel ML, for the most part, works. But the Linux kernel mailing list is a rather different beast than the potential users of an issue tracker for any other software project I can imagine—the technical acumen expected of contributors is high, quotidian back-and-forth user-assistance exchanges with non-contributors are not tolerated, people are usually expected to offer fixes as working code and not simply prose bug reports or feature requests (except for critical or security issues), and patches and pull requests on the mailing list are dealt with using a distributed version-control system that was purpose-built for the task (though happens to have worked well enough to because the most widely-used DVCS period).
Re: issue tracker?
Sourcehut seams interesting. Did you know if importing github/gitlab projects, with issues and merge requests (opened and closed) is supported at the moment? I noticed it is in alpha, so I don't expect to see all the features of any of those forges yet. Before I forget, Does magit+forge works well with sourcehut, especially the latter, as the former shouldn't have any problem? Regards, Roland. On Tue, May 19, 2020 at 9:43 PM Eric Abrahamsen wrote: > "James R Miller" writes: > > > So, I definitely agree that using Github / Gitlab does expose you to > > tracking messes and that is something to shun. I figured a self-hosted > > Gogs instance (which is already being hosted at > > https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue. > > > > I think an actual issue tracker has merit to large projects. > > I've been going around doing proselytizing for sr.ht (sourcehut, aka > "Sir Hat"), which is a forge-like site that is very much in line with > Emacs' principles. No tracking (barely any javascript at all), > everything can be driven via email -- it's pretty nice. Could be a good > solution here. > > (Not affiliated, though I do give them money.) > > Eric > >
Re: issue tracker?
On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote: > I think an actual issue tracker has merit to large projects. > > And I don't think simply saying "we've always done it through a ML" or "$FOO > project is bigger than us and uses a ML" is good enough. $FOO project may very > well increase efficiency, code quality, and/or participation by implementing > an issue tracker. > > A project to consider then, might be some sort of system that interfaces with > the ML (as well as a simple REST api so that issues could be submitted from > inside emacs directly), that creates some sort of org-based issue tracker, and > then ox-html exports to a static web page or pages. My point about duplication of effort stands. Who/how/which solution? Who has to maintain it, and does that make two places to check while managing bugs/patches? Please note I'm not a complete luddite, nor have I any real influence in any decision. However I'll point out that with limited resources, the onus to sufficiently justify a major change falls on the person(s) making the recommendation. Change "just because" or "it's prettier" tend to fall on deaf ears in technical communities. I'd argue that code quality is more improved by the proper application of version control than whether bug reports are web based. This appears to already be the case. If email is unmanageable, I'd assert that perhaps the user has a poor quality mail reader that lacks threading support, and perhaps they should find a better one. Is there a problem with submitting issues via the mailing list? Has something gone unaddressed? Do you have any statistics to show that there is decreased participation because you have to use email? Is something really inefficient at the moment? Did you have patches ignored? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: issue tracker?
Roland Everaert writes: > Sourcehut seams interesting. Did you know if importing github/gitlab > projects, with issues and merge requests (opened and closed) is supported > at the moment? I did a bit of googling, and couldn't find anything, no. The developer is very responsive, though, and might be worth contacting him directly. Though I guess Org doesn't have any existing issues to import (unless it's from Nicolas' development machine). > I noticed it is in alpha, so I don't expect to see all the features of any > of those forges yet. Here are details on "alpha": https://sourcehut.org/alpha-details/ One issue is that, while payment isn't currently required, it will be eventually. Perhaps the developer would be willing to make an exception for Org, or perhaps we should get what we pay for :) I guess I wouldn't expect Org to migrate away from gnu.org as a mailing list host, but the option is there. > Before I forget, Does magit+forge works well with sourcehut, especially the > latter, as the former shouldn't have any problem? Forge notes Sourcehut: https://magit.vc/manual/forge/Supported-Forges-and-Hosts.html#Supported-Semi_002dForges The thing is that Sourcehut doesn't really do pull requests, which I think is the tricky part of any "forge". It really is dead simple, and I think would be most useful as a mirror of Org's code, and an issue tracker. Eric
Re: [Question] why my org-link-set-parameters :face function does not work?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John Kitchin writes:
> The face function only takes the link path, which is a string. you cannot
> use org-element-property on it.
>
> Maybe you want something like this:
>
> #+begin_src emacs-lisp
> (defun org-link-beautify-face (path)
> "Set link face colors."
> (message "beautifying")
> (if (and (not (file-remote-p path))
> (file-exists-p (expand-file-name path)))
> 'org-link
> 'org-warning))
>
> ;;; DEBUG
> (org-link-set-parameters
> "file"
> :face #'org-link-beautify-face)
> #+end_src
I actually borrowed code from your code example, Because I want to do the
following:
#+begin_src emacs-lisp
(defun org-link-beautify-face (link)
"Set link face colors."
(let ((raw-link (org-element-property :raw-link link))
(type (org-element-property :type link))
(path (org-element-property :path link)))
(pcase type
;; ("https" )
;; ("http" )
("file"
(if (and (not (file-remote-p path))
(file-exists-p (expand-file-name path)))
'org-link 'org-warning)
(dolist (link-type (mapcar 'car org-link-parameters))
(org-link-set-parameters link-type
:face #'org-link-beautify-face))
#+end_src
In this way, I can put my code in a union function.
I guess the issue is on the let-binding which invoked ~org-element-property~.
But
I can't edebug this function. When I =C-u C-M-x= set edebug on the function, and
toggle ~font-lock-mode~ on Org Mode buffer, this function is not entering
edebug.
Don't know how to make Emacs enter this function edebug status.
>
> 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, May 19, 2020 at 9:12 AM stardiviner wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>> Bellowing is my source code, it does not work. I'm wondering why?
>>
>> #+begin_src emacs-lisp
>> (defun org-link-beautify-face (link)
>> "Set link face colors."
>> (let ((raw-link (org-element-property :raw-link link))
>> (type (org-element-property :type link))
>> (path (org-element-property :path link)))
>> (pcase type
>> ;; ("https" )
>> ;; ("http" )
>> ("file"
>>(if (and (not (file-remote-p path))
>> (file-exists-p (expand-file-name path)))
>>'org-link 'org-warning)
>>
>> ;;; DEBUG
>> (org-link-set-parameters
>> "file"
>> :face #'org-link-beautify-face)
>> #+end_src
>>
>> - --
>> [ stardiviner ]
>>I try to make every word tell the meaning that I want to express.
>>
>>Blog: https://stardiviner.github.io/
>>IRC(freenode): stardiviner, Matrix: stardiviner
>>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>>
>> -BEGIN PGP SIGNATURE-
>>
>> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D2xkUHG51bWJjaGls
>> ZEBnbWFpbC5jb20ACgkQG13xyVromsMfHAgAjnoQlzdHlcKL/rBVBLlkmMITh7f5
>> 6SxRw9sS1BagIma+APiuy+A4O4fSDLyzUMDg+Sg/C+vNu3QC2BM7ipBYNXtWcX1M
>> oPZj8loMrnISTIK51j2+9Pg0iOP1aZSvZqwA0p1mK2aZURBXWl7qDkVxD2oWji5P
>> qCBVr9ZFUloGSl7PtZTlOtsCgTCGHvnfvnk7vqxY4beuavQgaRSWUCsVDDO0c/M6
>> 5CSzxobElB3Y68fQ2awuQwRGCzfEvRkGShHp3Raug+EJ5Ew+MYEi6wILfPxYF2WR
>> VJjuxAxseBuiIjYjF91xzbR7mSZQsvB1gNttLYb3uQ/jrgj0HOQDo5Jmtg==
>> =4fE9
>> -END PGP SIGNATURE-
>>
>>
- --
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-
iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7EYtkUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOnbwf/f5zAf2fh+vUg7ikwtXpzCL+cjeUt
vyyHH9R32K5nb0FTqeyL/rjw6AhHRsTR7sFSUkb++Q8uWRJyxT2Kt7bgujRsL/cb
bnmArq4HFWw7ysxYjhDSknwzhc4xFzUJpSmnZuNHEItIuV5Ghg/FnEJokcTurop2
jN4dw28ladHMLel2hjhIRQni3ugQwfKOuyBZa8U3SCPENfnK8uPbMoxkONgdmDQu
wG3qw8NvMFnD5Vr81qVb/ytGJyMv+34wD/unZ1TK7BaTGsOVvg/l8ssj5h3EsDeX
yilYhc2yZmbG9DHiL94L7ggXJFnVD9GY01xreZXz+JLyJdVQy3K+Rmow1w==
=OU9d
-END PGP SIGNATURE-
Re: issue tracker?
Hi all, Interesting discussion. I have also wondered about this - I have not yet contributed to the Org codebase, but I have wondered if patches and bug fixes can sometimes get lost among other discussions. However, ultimately the best tracking system is the one that works for the developers and their workflow. A full-featured issue tracking system is useless if the developers don't have the habit of using it. So, whatever works for Nicolas and all the other wonderful people who maintain this amazing piece of software for free, works for me :) Best, --Diego On Tue, May 19, 2020 at 10:18 PM Roland Everaert wrote: > > Sourcehut seams interesting. Did you know if importing github/gitlab > projects, with issues and merge requests (opened and closed) is supported at > the moment? > > I noticed it is in alpha, so I don't expect to see all the features of any of > those forges yet. > > Before I forget, Does magit+forge works well with sourcehut, especially the > latter, as the former shouldn't have any problem? > > > Regards, > > Roland. > > > On Tue, May 19, 2020 at 9:43 PM Eric Abrahamsen > wrote: >> >> "James R Miller" writes: >> >> > So, I definitely agree that using Github / Gitlab does expose you to >> > tracking messes and that is something to shun. I figured a self-hosted >> > Gogs instance (which is already being hosted at >> > https://code.orgmode.org/bzg/org-mode) would fix the "tracking" issue. >> > >> > I think an actual issue tracker has merit to large projects. >> >> I've been going around doing proselytizing for sr.ht (sourcehut, aka >> "Sir Hat"), which is a forge-like site that is very much in line with >> Emacs' principles. No tracking (barely any javascript at all), >> everything can be driven via email -- it's pretty nice. Could be a good >> solution here. >> >> (Not affiliated, though I do give them money.) >> >> Eric >>
Re: How to defint functions for other org link parameters like :face :display etc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John Kitchin writes: > I don't know if :display is for that, I think it is mostly related to > should a link with description only show the description, or should it be > full and show link and description. > > You probably want the :activate option, where you could use something like > an overlay on the link. I don't have time to make an example for that right > now. the gist is you make an activate function, and you can add a > text-property or overlay display on the link. You probably need to check > that the property isn't there already to avoid adding overlays on > every fontification. > > > https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/#org069cbfa > John I see, let me take a try on ~:active-func~ parameter. Thanks a lot, John. Regards > > --- > 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, May 19, 2020 at 9:21 AM stardiviner wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> >> John Kitchin writes: >> >> > My go to reference is >> > >> https://kitchingroup.cheme.cmu.edu/blog/2016/11/04/New-link-features-in-org-9/ >> >> Really thanks, John. I have read your blog article. Found most of link >> parameters examples. But still confused me, I'm wandering how to define a >> function for link parameter ":display" to append an all-the-icons unicode >> icon >> on link. I only found one ~:display 'full~ example in your article. >> >> an you show an example using a function for ~:display~? Thanks in advanced. >> >> > >> > On Tue, May 19, 2020 at 6:56 AM stardiviner wrote: >> > >> >> -BEGIN PGP SIGNED MESSAGE- >> >> Hash: SHA256 >> >> >> >> >> >> I'm write an extension to beautify org link with colors and unicode >> icons >> >> for >> >> better intuitive looks. But I don't know how to write those functions. >> >> >> >> I checked out this info page ([[info:org#Adding Hyperlink >> >> Types][info:org#Adding Hyperlink Types]]) of org mode. >> >> >> >> But have not found ~org-link-set-parameters~ other parameters code >> >> examples. I >> >> hope some examples can be added for the all other parameters. >> >> >> >> - -- >> >> [ stardiviner ] >> >>I try to make every word tell the meaning that I want to express. >> >> >> >>Blog: https://stardiviner.github.io/ >> >>IRC(freenode): stardiviner, Matrix: stardiviner >> >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >> >> >> >> -BEGIN PGP SIGNATURE- >> >> >> >> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7DuYkUHG51bWJjaGls >> >> ZEBnbWFpbC5jb20ACgkQG13xyVromsMMRAf/dkXg9kxbgTeCdjfcl2koeJkBmfNj >> >> xFGkuM0MlAc1oCIvGAeZ23GZ/B9cgtbfarGdZy1FJl9r7ehFx10Qg9w5keSIptA6 >> >> mplEeCeKNgTwzyHIMQhI4xS+a80YliJNc8MgFi2o9tImKqavVV2eqwHPZDNE8HXt >> >> NEN+tfi8k2Sg7J7XhkdQD1YiNPTnKD8OXfzaR6162l5qSo3YuwoAegGmuULie2Ti >> >> fci2pFO56g46xLp1tWvI6z+Zxabyff/IjKkSWSNTHuQ5lhvYsmuFKF1JDfS/DHJV >> >> zy3Rr6sXK+MY1YWMMh2uLvmigL/BYl5HvjzC/Sq6wXcqVi0FuryeEfDWzg== >> >> =HMJr >> >> -END PGP SIGNATURE- >> >> >> >> -- >> > 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 >> >> >> - -- >> [ stardiviner ] >>I try to make every word tell the meaning that I want to express. >> >>Blog: https://stardiviner.github.io/ >>IRC(freenode): stardiviner, Matrix: stardiviner >>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 >> >> -BEGIN PGP SIGNATURE- >> >> iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7D3TMUHG51bWJjaGls >> ZEBnbWFpbC5jb20ACgkQG13xyVromsPoCQf/TrUtyBtPUYGtNiJeXWk0oQNbwggf >> 6FHX3wsvBS3O9A2VpKuzWTdnKSFR7dVUF8NkBwHbvU+599LqT5XxGtF2iDX+jgiz >> t0G2207sczHtiwsE/KLGAxXmEI4tGESLv+4Jui3kjp8JJJCusDcjzTIXQ6O9sb91 >> PmSbQhj4dbUz/3zk+utLb3YBMUPDnsr4H+eon+ko+EQOxTL48O4x7xvjj07XrnX3 >> DawQG0qs9SnenkMsK2HzQBRDqCf0DfrVPmajWYUQJ62j2ocah8oXij6WH5/rgCpA >> xtt2sXJrQd2TFpCxcGWn5PsyEUMWjxAx1dia8pcMkBLvnb2SQkM6204jWQ== >> =SVJD >> -END PGP SIGNATURE- >> >> - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7EY3EUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsMlVQgAge5MxPWefabFQfvcM1fHNgSVf4B3 vsPJmXqaVHRGmhUq2ug8wakYDoDIpdXX0M6VzVxm29ImmYsKM/JgpgEgZGR81DLI RMyra/MvKC414klP4UZNHEqjcbpKxh2OxpnmfuDXvkve6epnSBGoX70wlRQIC1NN BY3c1Gt44usVY1VwHnAaK+htlPU8CWc0Nn/0peOuB5qSJkjc60Pu9HKTx5EsJ0uD
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello,
"Dauer, Michael" writes:
> mist.org>>>
>
> * test
> foo {{{author}}} bar {{{keyword(AUTHOR)}}}
> {{{title}}}
> {{{date}}}
> {{{time}}}
> {{{input-file}}}
> {{{n}}}
> <<<
>
> ascii output buffer>>>
> Michael Dauer
>
>
> Table of Contents
> _
>
> 1. test
>
>
> 1 test
> ==
>
> foo bar
>
>
>
> mist.org
> 1
> <<<
This looks correct. AFACT, {{{author}}} never returned user-full-name.
{{{author}}} is just a shortcut for {{{keyword(AUTHOR)}}}.
See (info "(org) Macro Replacement") for more information.
Regards,
--
Nicolas Goaziou
Re: issue tracker?
On 5/19/2020 1:48 PM, Russell Adams wrote: > On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote: >> I think an actual issue tracker has merit to large projects. >> >> And I don't think simply saying "we've always done it through a ML" or "$FOO >> project is bigger than us and uses a ML" is good enough. $FOO project may >> very >> well increase efficiency, code quality, and/or participation by implementing >> an issue tracker. >> >> A project to consider then, might be some sort of system that interfaces with >> the ML (as well as a simple REST api so that issues could be submitted from >> inside emacs directly), that creates some sort of org-based issue tracker, >> and >> then ox-html exports to a static web page or pages. > > My point about duplication of effort stands. Who/how/which solution? Who has > to > maintain it, and does that make two places to check while managing > bugs/patches? > > Please note I'm not a complete luddite, nor have I any real influence in any > decision. > > However I'll point out that with limited resources, the onus to sufficiently > justify a major change falls on the person(s) making the recommendation. > Change > "just because" or "it's prettier" tend to fall on deaf ears in technical > communities. > > I'd argue that code quality is more improved by the proper application of > version control than whether bug reports are web based. This appears to > already > be the case. > > If email is unmanageable, I'd assert that perhaps the user has a poor quality > mail reader that lacks threading support, and perhaps they should find a > better > one. > > Is there a problem with submitting issues via the mailing list? Has something > gone unaddressed? Do you have any statistics to show that there is decreased > participation because you have to use email? Is something really inefficient > at > the moment? Did you have patches ignored? > This idea that the tools used by a potential contributor are inadequate misses the point. If the intention is to keep a project going, or better yet increase the number of contributors, tools have to be used that will be convenient and familiar to those thinking about contributing. For better or worse, the workflows embodied by Github and Gitlab are familiar to the current generation of potential contributors upon which sustaining a project will depend. Holding up the 'Linux uses email for development and thus any project doing similar is right' fails to recognize the peculiar nature of the Linux kernel (and its developers) and neglects the thousands of projects that have increased their visibility and participation by using tools such as Github. I agree that Github/Gitlab may not be the best choice owing to their stance or implementation related to software freedom, but an honest discussion of alternatives seems prudent. -gyro pEpkey.asc Description: application/pgp-keys
Re: Capture Template Diary Entry: file+datetree+prompt use the prompted timestamp including the time when time is specified
Nils Schween writes:
> ("d" "Diary entry" entry (file+datetree+prompt
> "~/MPIK-Nextcloud/emacs/.org/kalender.org")
> "* %i%?\n %T")
>
> And it works as expected: When calling the capture template, I am prompted
> for a
> date and I can also type a time, and on saving everything is stored at the
> correct location in the datetree. Perfect. But in case I do not enter a time,
> 00:00 is inserted. This is unfortunate. Okay, I can replace "%T" in the
> template
> with "%t", but then any specification of time is ignored.
>
> Instead, I would love to mimic the behaviour of the function
> "org-time-stamp". Calling it
> prompts for a date, and if I do not specify a time, only the date is inserted.
> In case I specify a time or a range (i.e. 10:00-12:00) the timestamp is
> supplemented with this additional information.
>
> I tried a lot to get the desired behaviour by testing variants of the
> following
> combination of org-mode functions and variables.
> %(org-insert-time-stamp (org-read-date nil t org-read-date-final-answer) t)
>
> I was not able to produce what I wanted.
>
> Does anyone have a workaround or an idea how I could implement the described
> and
> wished behaviour? Thanks.
I'm not aware of any built-in way to do what you want. For either
implementing or working around, org-capture-set-target-location and
org-capture-fill-template are the two places you'd probably want to
look. As a start of a hacky workaround, with an entry like
("d" "Diary entry" entry (file+datetree "/tmp/scratch.org")
"* %i%?\n %T" :time-prompt t)
you should be able to get the time/no time behavior you're after with
(advice-add 'org-capture-fill-template :around
(lambda (fn template args)
(let ((template (and (not org-time-was-given)
(replace-regexp-in-string
"%T" "%t"
(org-capture-get :template) t
(apply fn template args)))
'((name . "org-capture-hack")))
Re: issue tracker?
> This idea that the tools used by a potential contributor are inadequate > misses the point. If the intention is to keep a project going, or better > yet increase the number of contributors, tools have to be used that will > be convenient and familiar to those thinking about contributing. > > For better or worse, the workflows embodied by Github and Gitlab are > familiar to the current generation of potential contributors upon which > sustaining a project will depend. > > Holding up the 'Linux uses email for development and thus any project > doing similar is right' fails to recognize the peculiar nature of the > Linux kernel (and its developers) and neglects the thousands of projects > that have increased their visibility and participation by using tools > such as Github. I agree that Github/Gitlab may not be the best choice > owing to their stance or implementation related to software freedom, but > an honest discussion of alternatives seems prudent. This is the point I am trying to (un-eloquently) make. I'm seeing a bunch of younger coders interested in emacs (mostly spacemacs and doom); but, they get frustrated with the ancient (to them) dev practices. I'm not advocating any rash decisions; simply, whether the project would benefit from incorporating some sort of simple issue tracker, so that new contributors could readily see open tasks / issues / submit bug reports. My biggest issue with a ML only approach is that it's not easy to see what's an open issue unless you spend a long time searching and reading the ML. And I feel that that time could be better spent learning the code base instead of reading the ML. -- James Miller james.ryland.mil...@gmail.com
Re: `#+author:' stopped setting the author to empty string
Nicolas Goaziou writes: > At first glance, it looks harmless. If the test suite passes, we can > apply it. The test suite does pass with the change. Pushed, along with a regression test (962b8e765). Thanks.
Re: [PATCH] ob-haskell: Line Continuations Mangle Block Output
Nick Daly writes:
> Attached is an updated patch that makes output trimming work with
> blocks that do and don't produce results. The old patch creates a
> =let: Wrong type argument: arrayp, nil= error when evaluating blocks
> that don't produce output. This necessarily incorporates yesterday's
> patch.
Thanks for the patch.
> diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
> index bea162528..cb581fe3b 100644
> --- a/lisp/ob-haskell.el
> +++ b/lisp/ob-haskell.el
> @@ -83,12 +83,16 @@
> (cdr (member org-babel-haskell-eoe
> (reverse (mapcar #'org-trim raw)))
> (org-babel-reassemble-table
> - (let ((result
> + (let* ((result
> (pcase result-type
>(`output (mapconcat #'identity (reverse results) "\n"))
> - (`value (car results)
> + (`value (car results
> +(result
> + (if (stringp result)
> + (replace-regexp-in-string "Prelude[|>] " "" result)
> + result)))
Oy, it's pretty nasty that those leak through. I know ob-python (and
probably other languages) also suffers from similar brittleness. It'd
be nice of course to figure out how to prevent the prompts leakage in
the first place, but, short of that, I think we should at least make the
regexp stricter so that it matches just the start of the string.
And that (stringp result) check is for the same reason as the one from
your first patch from yesterday which is now included ...
> (org-babel-result-cond (cdr (assq :result-params params))
> - result (org-babel-script-escape result)))
> + result (if (stringp result) (org-babel-script-escape result
... here. I believe result is nil in the problematic case, so this
could be
(and result (org-babel-script-escape result))
However, based on stepping through the example in your patch from
yesterday, I think these two issues might be more closely related than
you realize. In the
(cdr (member org-babel-haskell-eoe
(reverse (mapcar #'org-trim raw
bit visible as a context line above, this is what I see for raw when I
step through org-babel-execute:haskell:
("Prelude| Prelude| Prelude| Prelude> \"org-babel-haskell-eoe\"" "")
So it looks like the member call above is returning nil because the
prompt markers are corrupting the element. If that's the case, it seems
like the output cleansing should happen upstream of that call.
What do you think?
