Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation
Gustav, There are a lot of deprecation recommendations in your attached document: > I propose to depricate property-keywords > I propose to depricate the Options-keyword > I propose to relabel these keywords as document keywords > I propose to depricate the #+CATEGORY syntax > I propose to depricate the #+FILETAGS syntax > I propose to depricate the #+COLUMNS syntax > I propose to depricate the #+ARCHIVE syntax > I propose to depricate the TODO-keywords > I propose to depricate the priorities-keyword > I propose to depricate the tags-keyword > I propose to depricate the link-keyword > I propose to depricate the constants-keyword > I propose to depricate the setupfile-keyword > I propose to depricate the Macro-keyword The thoroughness of your investigation is admirable. However, I propose that we don't deprecate any of those. Org has been around for over a decade now. Such drastic changes would not serve users well. Note that I'm taking your use of the word "deprecate" to mean what it's expected to mean in this context: that the software developers recommend against using it, with the intention to eventually remove support for the feature. We shouldn't be removing any such features from Org. Not only would it not serve users well, but it would make the software much more complicated. As it stands, finding, e.g. a #+CATEGORY: keyword and getting its value is as simple as: (save-excursion (goto-char (point-min)) (when (re-search-forward (rx bol "#+CATEGORY:" (1+ blank) (group (1+ nonl))) nil t) (match-string 1))) Hiding those keywords in drawers means that either: a) Eligible drawers must be located, and then the desired property must be searched for inside of them. b) Possibly valid properties must be located, and each one must be confirmed to be inside an eligible drawer. What benefit would this added complexity serve? To put the keywords in one place in the document? There are already multiple ways to achieve that. I can't emphasize enough how important stability and consistency is for Org and its file formats right now. As I've said, there are new implementations in development, which have the potential to bring a lot of publicity and new users to Org. For example, this one was mentioned on a Hacker News post a few days ago: https://github.com/mickael-kerjean/filestash In the same HN post were examples of implementations for Vim and VSCode. Already, especially in the VSCode ones, there were apparent incompatibilities in their implementations of the Org file format. As well, there are now parsers in JavaScript, Python, and Rust. Markdown is by far the most popular plain-text format, and has been for years, but it has long suffered from competing, slightly incompatible flavors and implementations. Reddit has theirs, GitHub has theirs, etc. Org's file format may finally be gaining some momentum. Let's not jeopardize Org's chances by making implementors' job more difficult than it already is.
[O] Bug: org-read-date ignores hours?
When I use (org-read-date t) and type something like "+2m" it works as expected, but for some reason if I type something like "+2h" it returns datetime with no changes. Expected - two hours in the future. Am I missing something?
Re: [O] Scroll Agenda Dispatcher window
Hello Nate,
> Sometimes (recently) I have quite a few custom agenda commands and if
> the window is not large enough, I can't view all of the available
> agenda custom commands - what is the keyboard shortcut to scroll /
> display the lower section of the custom agenda commands?
AFAICS there are no commands for scrolling for that case yet. FWIW in
branch "master" (and "next") C-n, C-p, SPC and DEL work in the agenda
dispatcher like in the export dispatcher, hopefuly.
Possibly { M-x customize-variable RET org-agenda-menu-two-columns }
can help ease your case somewhat if you don't use master.
Ciao,
--
Marco
Re: [O] [RFC] Document level property drawer
Gustav Wikström writes: [...] > Sooo, a separate branch is created in the Org mode repository named > "next". I'm not entirely sure how we're supposed to work with it. But > I've anyways pushed my (non-breaking) patch there. Okay, thanks. I try to follow the development on the 'next' branch. [...] >> Noteworthy observations AFAICT: >> >> 1. I could not translate my personal "#+TODO: . N ~ | x c g >" into a >> respective :TODO: property. > > Yes, that's true. The reason is that there is no TODO-property that > fits in property drawers right now. I.e. special properties such as > TODO, TAGS, priority, scheduling and deadlines that have special > syntax for the outline still have no defined meaning for outline level > 0. I ofc. think that's an oversight ;) But I may also be a bit crazy. > > A conclusion to draw from that, that may be worth writing more about, > is that the property drawer for node level 0 will not be able to > replace all file-level keywords that exist today. Only properties that > currently can also be defined in property drawers in the outline will > work in the property drawer on level 0. Makes sense? Absolutely. > The idea I had for all the other keywords that apply for the whole > file was to create another drawer, what I called a settings drawer. > Because the TODO-keyword you refer to above really is a setting that > you're making for the current file, much the same as when you make > changes in global, folder local or file local variables using the > standard emacs framework. The idea of a settings drawer makes sense AFAICS. For the special case of TODO-keywords one could think about defining them per subtree. Possibly there are some low hanging fruit among the whole-file-properties that have a natural interpretation per subtree. > I've attached an investigation I did of the world of Org mode > keywords. It was done quite a while back and some things in there are > subjective and may not represent my current picture of the "ideal". > Nonetheless, maybe an interesting read for the ... other crazy people > out there? Okay, I'll have a look at your investigation. ;) BTW this document looks great to me at the first glance. Thanks, -- Marco
[O] Exporting noweb-ref's without disabling org-babel processing
Hi, I'm working on a Leanpub Markua exporter (not quite complete yet but already usable, if you are interested: https://github.com/zzamboni/ox-leanpub/tree/book-and-markua) I would like to include the value of :noweb-ref for code blocks in exported output, like noweb originally did, e.g. something like this: #begin_src emacs_lisp :noweb-ref super-duper-code ... #end_src to produce something like this in the export: <>= ... After much poking around, I figured that the :noweb and :noweb-ref header args are removed by org-babel *before* the src block makes it to the exporter. I also discovered that by setting org-export-use-babel to nil I could disable this behavior, which means that my exporter can access the :noweb-ref argument by parsing the :parameters property (see https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-markua.el#L388 ). This was good for my original purpose, but I just realized that this also disables other useful org-babel features on export, such as the processing of the :exports header argument, which means that both code and results are always included in the export regardless of what :exports says :) I have tried using org-babel-exp-code-template, but unfortunately if I try to use "%noweb-ref" as a key in its value, it gets replaced by the value of :noweb followed by "-ref" in every case. Is there some other way of accessing org-babel header arguments like :noweb-ref from the exporter, but without having to disable org-babel processing completely? Any other ideas for achieving what I want? Thanks for any ideas, --Diego
Re: [O] Emacs master, faces with :extend t let cursor vanish at EOL?!
On Tue, Oct 22, 2019 at 3:52 PM Ingo Lohmar wrote: > I am writing to the org-mode list first, because I have only been able > to reproduce this problem in org-mode. > > With a recent Emacs master build, faces can have the :extend t property > to indicated that they should extend after the newline. This is useful > for a user to customize, eg, for `org-block', and it also applies to > default faces like `region', `highlight' or `secondary-selection'. > Hello, I have been seeing this issue too, but I haven't found time to create a proper bug report for it. But now that you have this email, I am forwarding this to the Emacs devel list too. The issue occurs because of the new :extend feature for faces to extend till end of lines. With that enabled, I have also seen that the cursor "hides" automatically only at end of lines inside the Org source blocks. i.e within #+begin_src emacs-lisp (message "hello")X #+end_src Above: X is where the cursor would be, but it would not be visible (with the :extend t added to the org-block face). The cursor would show up again on doing C-b i.e. bringing it to any column position other than the EOL. > Using this with a current elpa pkg of org-mode, and setting :extend t on > faces like `org-block`, "often" the cursor vanishes at the EOL of a line > using such a face. It reliably happens for `org-block', only sometimes > for `secondary-selection'. > > Has anybody else experienced that as well, or do you have any pointers > on how to further investigate this? I think I remember that org-mode does > something with text overlays, but I can't relate that to what I see. > > There might also be an issue with face inheritance and the new :extend > attribute --- I might post on emacs-devel to get a better idea of that > as well. > > Thanks, > Ingo > >
[O] Emacs master, faces with :extend t let cursor vanish at EOL?!
I am writing to the org-mode list first, because I have only been able to reproduce this problem in org-mode. With a recent Emacs master build, faces can have the :extend t property to indicated that they should extend after the newline. This is useful for a user to customize, eg, for `org-block', and it also applies to default faces like `region', `highlight' or `secondary-selection'. Using this with a current elpa pkg of org-mode, and setting :extend t on faces like `org-block`, "often" the cursor vanishes at the EOL of a line using such a face. It reliably happens for `org-block', only sometimes for `secondary-selection'. Has anybody else experienced that as well, or do you have any pointers on how to further investigate this? I think I remember that org-mode does something with text overlays, but I can't relate that to what I see. There might also be an issue with face inheritance and the new :extend attribute --- I might post on emacs-devel to get a better idea of that as well. Thanks, Ingo
[O] Scroll Agenda Dispatcher window
Hello all, Sometimes (recently) I have quite a few custom agenda commands and if the window is not large enough, I can't view all of the available agenda custom commands - what is the keyboard shortcut to scroll / display the lower section of the custom agenda commands? Thanks, --Nate
Re: [O] Question about org-latex-text-markup-alist
>"FE" == Fraga, Eric a écrit : FE> Specifically, as you will see in org-emphasis-alist, == is mapped to FE> verbatim and so you need to change the verbatim syntax in FE> org-latex-text-markup-alist. ~~ is used for code. I realize I wasn't aware of ~~. -- Pascal Quesseveur pques...@gmail.com
Re: [O] Question about org-latex-text-markup-alist
Thanks a lot. -- Pascal Quesseveur pques...@gmail.com
Re: [O] Question about org-latex-text-markup-alist
On Tuesday, 22 Oct 2019 at 11:55, Pascal Quesseveur wrote: >>"FE" == Fraga, Eric writes: > > FE> None, I believe. There is a difference if you export to HTML, however. > > But is not org-latex-text-markup-alist just for latex export? Yes. > My question was to know in which case the code and the verbatim > symbols were used in the latex export. If i want to get style verb > instead of texttt in the latex export for text marked with == in org, > do I have to set verb for code and verbatim, or only for code? Ah, I misunderstood your question. That mapping from symbols to meaning is done by org-emphasis-alist. Then each language provides the mapping from meaning to syntax. Specifically, as you will see in org-emphasis-alist, == is mapped to verbatim and so you need to change the verbatim syntax in org-latex-text-markup-alist. ~~ is used for code. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
Re: [O] Question about org-latex-text-markup-alist
>"FE" == Fraga, Eric writes: FE> None, I believe. There is a difference if you export to HTML, however. But is not org-latex-text-markup-alist just for latex export? My question was to know in which case the code and the verbatim symbols were used in the latex export. If i want to get style verb instead of texttt in the latex export for text marked with == in org, do I have to set verb for code and verbatim, or only for code? -- Pascal Quesseveur pques...@gmail.com
Re: [O] Can different types of graphic be created at the same moment
Op di 22 okt. 2019 om 09:34 schreef Fraga, Eric : > On Sunday, 20 Oct 2019 at 16:05, Cecil Westerhof wrote: > > I would like to generate different types of graphics files at the same > > moment. I tried: > > #+BEGIN_SRC plantuml :file Graphics/rabbitMQ.eps :file > > Graphics/rabbitMQ.jpg :noexport > > > > But that does not work: it only generates the eps file. > > > > Is it possible at all? > > No, I do not think it is possible. However, if you name your source > block, you can invoke the same block with different parameters using > #+call: > > See the info manual: (org) Evaluating Code Blocks > That is good enough for me. I look into it. Thanks. -- Cecil Westerhof
Re: [O] Question about org-latex-text-markup-alist
On Tuesday, 22 Oct 2019 at 10:00, Pascal Quesseveur wrote: > Hello, > > In org-latex-text-markup-alist what is the difference between markup symbols > code and verbatim? None, I believe. There is a difference if you export to HTML, however. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
[O] Question about org-latex-text-markup-alist
Hello, In org-latex-text-markup-alist what is the difference between markup symbols code and verbatim? -- Pascal Quesseveur pques...@gmail.com
Re: [O] Can different types of graphic be created at the same moment
On Sunday, 20 Oct 2019 at 16:05, Cecil Westerhof wrote: > I would like to generate different types of graphics files at the same > moment. I tried: > #+BEGIN_SRC plantuml :file Graphics/rabbitMQ.eps :file > Graphics/rabbitMQ.jpg :noexport > > But that does not work: it only generates the eps file. > > Is it possible at all? No, I do not think it is possible. However, if you name your source block, you can invoke the same block with different parameters using #+call: See the info manual: (org) Evaluating Code Blocks -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78
