Re: org-startup-truncated default should be nil [legibility 2/6]
On Thursday, 6 Feb 2020 at 10:33, Texas Cyberthal wrote:
> Visual line mode is annoying and unnecessary; Spacemacs users do not
> need it because its defaults offer adequate paragraph navigation.
I'm not sure I understand the conflation of visual-line-mode with
paragraph navigation. Is it because you mean intra-paragraph navigation
as opposed to M-{ and M-} for navigating from paragraph to paragraph?
Maybe auto-fill-mode is what you want?
In any case, the solution may simply be some example org mode hooks
with, say, settings for writing prose and have these in the org mode
manual?
Fundamentally, emacs is challenging because it is both powerful and
completely customizable. I remember a colleague complaining that Linux
was not friendly because you had too much choice. Emacs takes that to
another level. And that's why many of us live in it...
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: commit "328c9a1af * bad org.el: Enhance menus" caused error
Bastien writes:
> Hi,
>
> stardiviner writes:
>
>> BTW, the function ~org-insert-dblock-bindings~ is from package
>> =orgtbl-aggregate=.
>
> I don't know this function and this package.
>
> Can you share the minimal Emacs config with which you reproduce
> the problem?
Besides of package =orgtbl-aggregate=, seems another package
=orgtbl-ascii-plot= use
same code to define menu too. Here is its code:
#+begin_src emacs-lisp
;;;###autoload
(defun orgtbl-ascii-plot-bindings ()
(org-defkey org-mode-map "\C-c\"a" 'orgtbl-ascii-plot)
(org-defkey org-mode-map "\C-c\"g" 'org-plot/gnuplot)
(easy-menu-add-item
org-tbl-menu '("Column")
["Ascii plot" orgtbl-ascii-plot t]))
;;;###autoload
(if (functionp 'org-defkey)
(orgtbl-ascii-plot-bindings) ;; org-mode already loaded
(setq org-load-hook;; org-mode will be loaded later
(cons 'orgtbl-ascii-plot-bindings
(if (boundp 'org-load-hook)
org-load-hook
#+end_src
Bastien, might consider add a hook after loaded org menus? Like named
~org-menu-after-loaded-hook~ or something else? So third libraries can define
menu
entries with function added on the hook. I think those packages will have to
updated with patches?
--
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: org-startup-truncated default should be nil [legibility 2/6]
Emacs is the tool that allows a non-technical user to bootstrap to control over his IT environment. Within that, Org is the tool that allows him to bootstrap to control of Emacs. So Org's defaults should allow someone with no experience to learn the basic text manipulation commands in the help-with-tutorial and then log his efforts to learn Emacs. Eventually he will need to turn on truncation in Org to display inline codelike elements properly, but until then he'll need his prose paragraphs wrapped for him. Correction: I started an unmodified Spacemacs to check my memory of its Org defaults. I was correct about Org recognizing single-space sentences by default. I was wrong about Org using variable pitch with word wrapping and without truncation by default. I'll certainly propose that be changed there. On the bright side, truncation is easily M-x discoverable with Helm, and visual line mode is placed in an inferior position to truncation in the keybinds: SPC-t-l for spacemacs/toggle-truncate-lines and SPC-t-L for spacemacs/toggle-visual-line-navigation. Now I'm wondering whether any distro ships an Org whose defaults permit noobs to write prose paragraphs. On Thu, Feb 6, 2020 at 10:33 AM Texas Cyberthal wrote: > > > If I understand correctly, you're arguing that defaults should be changed > > because you don't understand how Emacs works, and since you use Spacemacs, > > you don't even care how it works. > > You understand incorrectly. You incorrectly asserted that all users > must learn how visual line mode works. Visual line mode is annoying > and unnecessary; Spacemacs users do not need it because its defaults > offer adequate paragraph navigation. > > Org's default should be (truncate-lines nil) with paragraph navigation > like Spacemacs, so that non-techie noobs can use it for text editing > out of the box. Requiring them to try to figure out sane defaults for > basic prose editing by trial and error drives too many away. > > To review why Org is so frustrating to new users out of the box, I > turned on my vanilla Emacs and opened an Org file. I was unable to > toggle line truncation from M-x completion, so I enabled > visual-line-mode instead. This wrapped lines as desired, but left > paragraph navigation broken. > > C-a/e org-end-of-line moves point to beginning/end of visual line, as > the mode name suggests. This is not very useful, because C-n/p > next-line also moves by visual lines, which in combination with M-f/b > forward-word allows one to reach any column on the visual line, not > just the beginning and end points. The visual beginning and ends of > lines have no logical significance and thus there is no reason to give > them the extra convenience of dedicated keybinds. > > M-a/e org-backward-sentence only works if one remembers to > double-space after a period to denote the end of a sentence. Noobs are > unlikely to realize this, and will instead wrongly conclude that it > only detects paragraphs, since it does recognize a period followed by > a line break as a sentence. Spacemacs recognizes a single space after > the period as a sentence. Even if a user trains himself to always > double-space after the end of a sentence, much of the text he imports > into Org from other authors will not be formatted correctly. > > Most importantly, there is no keybind for next-logical-line, which is > an important location in a paragraph. And there is no visual cue that > a line break is visual rather than logical. The next paragraph > navigation command level operates on paragraphs. C-down/up > org-forward-paragraph skips multiple adjacent lines as one paragraph, > treating line breaks in visual line mode the same as those in normal > fill mode, even though the former are deliberately inserted as > logically significant demi-paragraphs. > > So if one types a stream of consciousness: > > #+begin_quote > Hm maybe i should do x > or maybe y > I guess I'll think about it further > #+end_quote > > These demi-paragraphs get obliterated by visual line mode, if the > lines are long. > > And that's assuming the noob knows to enable visual-line-mode in the > first place! > > Ok, I just figured out that M-x trunc completion failed because the > command is toggle-truncate-lines. That delivers a sane paragraph > editing experience, except for the sentence detection issue. So > toggle-truncate-lines needs an alias that starts with "truncat" so > that noobs can find it, if it's not going to be enabled in Org by > default. > > truncate-lines nil still doesn't result in readable prose in vanilla. > The fixed pitch font with the continuation marks and the lack of word > wrapping and the narrow line spacing makes a total mess. > > Meanwhile Spacemacs' Org paragraph navigation defaults are perfectly > sane and pleasant. C-a/e runs mwim-beginning-of-code-or-line. Lines > are wrapped and demi-paragraphs are preserved. > > Why does Org inflict such a frustrating experience on non-techie noobs > when they attempt to draf
Re: How to intersperse commands with their output in RESULTS block?
On Wednesday, 5 Feb 2020 at 18:25, Diego Zamboni wrote: > tl;dr: is there a way to have ob-shell (or some similar mode) run commands > one by one and include the commands, interspersed with their output, in the > #+RESULTS block? You haven't said on what type of system but, if Linux, you could try using =script= as a starting point: #+begin_src shell :results output script <
Re: commit "328c9a1af * bad org.el: Enhance menus" caused error
Bastien writes: > Hi, > > stardiviner writes: > >> BTW, the function ~org-insert-dblock-bindings~ is from package >> =orgtbl-aggregate=. > > I don't know this function and this package. > > Can you share the minimal Emacs config with which you reproduce > the problem? Start =emacs -q=, and load Org from source code. Then load package =orgtbl-aggregate=. #+begin_src emacs-lisp (use-package orgtbl-aggregate :ensure t :commands (org-insert-dblock org-insert-dblock:aggregate) :config ;; add `orgtbl-aggregate' dynamic blocks into list. (org-dynamic-block-define "columnview" 'org-insert-dblock:columnview) (org-dynamic-block-define "aggregate" 'org-insert-dblock:aggregate) (org-dynamic-block-define "invoice" 'org-insert-dblock:invoice) (org-dynamic-block-define "join" 'org-insert-dblock:join) (org-dynamic-block-define "org-gantt" 'org-insert-dblock:org-gantt) (org-dynamic-block-define "propview" 'org-insert-dblock:propview) (org-dynamic-block-define "transpose" 'org-insert-dblock:transpose)) #+end_src Actually, it is because this package contains following code cause this problem: #+begin_src emacs-lisp ;;;###autoload (defun org-insert-dblock-bindings () (org-defkey org-mode-map "\C-c\C-xi" 'org-insert-dblock) (easy-menu-add-item org-org-menu '() ["Insert Dynamic Block" org-insert-dblock t] "Agenda Command...")) ;;;###autoload (if (functionp 'org-defkey) (org-insert-dblock-bindings) ;; org-mode already loaded (setq org-load-hook;; org-mode will be loaded later (cons 'org-insert-dblock-bindings (if (boundp 'org-load-hook) org-load-hook #+end_src Maybe because I just use =use-package= autoload for =orgtbl-aggregate= instead of fully required? I tested that now by removing ~:commands~ part so that use-package will not load delayed. Still has this error. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: org-startup-truncated default should be nil [legibility 2/6]
> If I understand correctly, you're arguing that defaults should be changed > because you don't understand how Emacs works, and since you use Spacemacs, > you don't even care how it works. You understand incorrectly. You incorrectly asserted that all users must learn how visual line mode works. Visual line mode is annoying and unnecessary; Spacemacs users do not need it because its defaults offer adequate paragraph navigation. Org's default should be (truncate-lines nil) with paragraph navigation like Spacemacs, so that non-techie noobs can use it for text editing out of the box. Requiring them to try to figure out sane defaults for basic prose editing by trial and error drives too many away. To review why Org is so frustrating to new users out of the box, I turned on my vanilla Emacs and opened an Org file. I was unable to toggle line truncation from M-x completion, so I enabled visual-line-mode instead. This wrapped lines as desired, but left paragraph navigation broken. C-a/e org-end-of-line moves point to beginning/end of visual line, as the mode name suggests. This is not very useful, because C-n/p next-line also moves by visual lines, which in combination with M-f/b forward-word allows one to reach any column on the visual line, not just the beginning and end points. The visual beginning and ends of lines have no logical significance and thus there is no reason to give them the extra convenience of dedicated keybinds. M-a/e org-backward-sentence only works if one remembers to double-space after a period to denote the end of a sentence. Noobs are unlikely to realize this, and will instead wrongly conclude that it only detects paragraphs, since it does recognize a period followed by a line break as a sentence. Spacemacs recognizes a single space after the period as a sentence. Even if a user trains himself to always double-space after the end of a sentence, much of the text he imports into Org from other authors will not be formatted correctly. Most importantly, there is no keybind for next-logical-line, which is an important location in a paragraph. And there is no visual cue that a line break is visual rather than logical. The next paragraph navigation command level operates on paragraphs. C-down/up org-forward-paragraph skips multiple adjacent lines as one paragraph, treating line breaks in visual line mode the same as those in normal fill mode, even though the former are deliberately inserted as logically significant demi-paragraphs. So if one types a stream of consciousness: #+begin_quote Hm maybe i should do x or maybe y I guess I'll think about it further #+end_quote These demi-paragraphs get obliterated by visual line mode, if the lines are long. And that's assuming the noob knows to enable visual-line-mode in the first place! Ok, I just figured out that M-x trunc completion failed because the command is toggle-truncate-lines. That delivers a sane paragraph editing experience, except for the sentence detection issue. So toggle-truncate-lines needs an alias that starts with "truncat" so that noobs can find it, if it's not going to be enabled in Org by default. truncate-lines nil still doesn't result in readable prose in vanilla. The fixed pitch font with the continuation marks and the lack of word wrapping and the narrow line spacing makes a total mess. Meanwhile Spacemacs' Org paragraph navigation defaults are perfectly sane and pleasant. C-a/e runs mwim-beginning-of-code-or-line. Lines are wrapped and demi-paragraphs are preserved. Why does Org inflict such a frustrating experience on non-techie noobs when they attempt to draft their first raw notes into Org? How can this possibly be optimal? If the plan is to prevent consumer adoption of Org as a Personal Info Manager, it's working. > May I suggest that you propose your changes on the Spacemacs repo. In this case, I am suggesting Org adopt what Spacemacs already has. Regarding the assertion that Emacs is doing just fine on noob friendliness, this is false, as I demonstrated in my most recent post: https://cyberthal-ghost.nfshost.com/emacs-needs-a-starter-zone-and-org-is-it/ The existence of B2C tech support for Linux but not Emacs demonstrates that the former is sufficiently noob friendly and the latter isn't. I don't particularly care whether noob intake is delegated to distros or vanilla, but splitting the job between the two isn't working.
Re: latex fragments in html export
Nvm, I found the issue.
make org-insert-dblock:columnview more calendar like?
Usually my tasks I write like this * Amnu #+COLUMNS: %TIMESTAMP %25ITEM ** First contact :Amnu: <2019-02-01 Fri> ** GramSchmidt and Householder:Amnu: <2019-02-08 Fri> ** Finish Householder, start power and QR :Amnu: <2019-02-15 Fri> Which is then converted via org-insert-dblock:columnview to #+BEGIN: columnview :hlines 1 :id local | TIMESTAMP| ITEM | |--+| | | Amnu | | <2019-02-01 Fri> | First contact | | <2019-02-08 Fri> | GramSchmidt and Householder| | <2019-02-15 Fri> | Finish Householder, start power and QR | #+END: Is there any other function, or package which would generate a more calendar like view? Thanks and regards Uwe Brauer * Amnu #+COLUMNS: %TIMESTAMP %25ITEM ** First contact :Amnu: <2019-02-01 Fri> ** GramSchmidt and Householder:Amnu: <2019-02-08 Fri> ** Finish Householder, start power and QR :Amnu:
Re: [BUG] Infinite loop in org-agenda-show-new-time
Hi Bastien, Bastien writes: > > Andrew Hyatt writes: > >> Removing the (beginning-of-line 1) at the end of the time display >> code in that function, and substituting (org-agenda-previous-line) >> seems to fix it. I'm not sure if that's the right approach - the >> previous code didn't use that function for a reason, but I don't know >> what that reason was. > > I think this approach is correct is it will move over visible lines. > > I've pushed a patch, please let me know if it is fixed. I'm finding that this patch (19676dce758038749887a057208ea33d9a1fad57) has the by-product of causing multiple paths to flash in the mini-buffer if org-agenda-show-outline-path is set to t. I believe that is because it calls org-agenda-previous-line, which in turn calls org-agenda-do-context-action. The effect is even more pronounced if org-agenda-follow-mode is on, causing a significant slowdown in rescheduling items. Thanks, Matt
local toc automatic?
i have been using toc for an entire blog post and then #+TOC: headlines 1 local for sections. this local idea is brilliant. i can make the main toc non-intimidating, and then provide a toc for sections. is it possible to do this automatically? that is, supply only one main toc, and specify that if there are any entries that are 2 levels below it, a toc should be created 1 level below it to list them? * a #+TOC: headlines 1 ** b ** c #+TOC: headlines 1 local *** d *** e i am proposing to eliminate the need to manually enter the toc for c in the examlpe above. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.
latex fragments in html export
Hello, Has anyone had success getting the html export to process latex fragments? It's leaving mine completely alone and I can't figure out why. Latex babel source blocks work fine. I've set (setq org-html-with-latex luasvgm) luasvgm is a process-alist element I defined. I went through ox-html and set up debug points in a bunch of functions meant to process latex fragments, but none of them are being called. Thanks Matt
Re: Folding whitespace at the end of a tree
Hello Bastien, I tried it using a minimal .emacs and version 9.3.3. It behaves the same on a Linux and a Windows installation. -- Kjell Am 03.02.2020 um 19:50 schrieb Bastien: Hi Kjell, I cannot reproduce this problem. What version of Org are you using? M-x org-version RET Thanks,
How to intersperse commands with their output in RESULTS block?
Hi everyone, tl;dr: is there a way to have ob-shell (or some similar mode) run commands one by one and include the commands, interspersed with their output, in the #+RESULTS block? I would like to have examples shown with commands, followed by their output. Something like this: #+begin_src console > echo "hi" hi > echo "bye" bye #+end_src This works well for my use case - "console" blocks are understood nicely by Pygmentize as containing both commands and output. What I would like is to start using org-babel to run the commands and insert their output in the export, so that I can update the examples without having to copy-paste from the terminal. So what I would like is to have something like this: #+begin_src sh :exports results :wrap "src console" echo "hi" echo "bye" #+end_src And when I evaluate the block with C-c C-c, I get: #+results: #+begin_src console > echo "hi" hi > echo "bye" bye #+end_src Before I start building my own, ob-mode I was wondering if anyone knows of any existing way to achieve this. Thanks! --Diego
Re: attachment: link type export to HTML invalid attach dir
Hello, Gustav Wikström writes: > That was kind of what I was trying to do, by allowing subtyping, so > that the parser would be more knowledgeable about particular types of > links, by allowing extended attributes. Maybe not implemented in the > most extensible way though I'll admit. Just to be clear, I firmly believe Element library should be as low-level as possible. Ideally (we're not there yet), it should not depend on any other part of Org. It should be the step (largely) above "re-search-forward". So, extending the parser to include knowledge to some other library in Org is not an option. Element is expected to dumbly stick to Org syntax, without knowing what it means. > My suggestion to the link parser would be to have the following properties as > the catch-all properties for links: > - type :: Which type of link protocol applies. E.g. file, http, ftp, > attachment, duckduckgo (ex. for a custom link abbreviation to search ddg) > - raw-path :: The path to use for the particular protocol. Would contain > everything in the link following "protocol:" > - format :: Which format the link has. Plain, bracket or angular bracket Barring custom link abbreviations, this is already the case. > - description :: The description part of the link > ([[protocol:path][description]]) Description is not meaningful here. This is parsed content. > - begin, end, post-blank :: The default properties used for all elements. Not > sure if contents-begin and contents-end are a part here as well. They are when the link has contents, i.e., a description. > As you've stated previously, from a performance perspective maybe it > will be best to not expand the specific properties and instead let the > expansion of those be handled in code by the link type owner (e.g. > org-attach.el for attachment links). More than performance, this is a design issue. > Ah yes. Just briefly looking at the docview code. Docview doesn't seem > to use the parser when extracting information about that "go to page" > information from the link. Which means docview links doesn't really > care how the link information is encoded in the parser anyways. Indeed. However, higher level functions, e.g., org-open-link, do care about it and ensure that "ol-docview.el" really processes a link. > Maybe if docview were allowed to encode custom docview information > into the parsed link in the parser it and others could reused that > encoded information later? Docview would be able to add > a ":go-to-page" option, for example. Just a thought. I'm quite sure this is a wrong way to go. > Most link types probably won't need custom link properties anyways. > But could maybe let the parser know stuff by use of higher order > functions? Or push for being important enough to be included into Org > and allowed to be known by the parser. Only syntax changes can go into the parser. Attachment links are regular links, not something that requires extending Org's syntax. Note that this is not the case of file links, which have a special syntax, e.g., [[./cat.jpg]]. > Ok, got it. Thanks for explaining. I'll admit it hasn't been totally > clear to me what the best way forward is. After refreshing my > understanding on links the conclusion I came to was that link > abbreviations in its current form was not a fitting concept for > attachment links. Attachments are pretty much similar to file links > though, so even if my intention isn't to blur the meaning they will > and should be treated very similar, since functionality is so similar. Functionality may be familiar, but their syntax is not the same, therefore, the differences should be handled elsewhere. > Speaking from the perspective of attachment links, if there were > a file link type exporter function available that could be used by > attachment links without code duplication. Where would live that function? ox.el is not an option since every exporter treats file links differently. As suggested already (I think) we could add a phase in ox.el that would expand attachment links into their file link counterpart automatically. This would avoid adding specific code in every export back-end. However, export back-end would miss the opportunity to handle attachment links specifically. This is one way or the other. > Yes, and the function that implements that would also need the user > argument as input. In addition to the link path. Patch welcome. I see no objection to extending :follow link parameter in "ol.el". > Anyways, patch attached that makes org-element not know about > attachments any longer, and moves most of the responsibility to > org-attach.el. The exporters still needs to know to use the new > function inside org-attach.el though. Thank you. Please apply it. Now we can try improving the situation for exporters. Regards, -- Nicolas Goaziou
Re: [BUG] Infinite loop in org-agenda-show-new-time
It is fixed, but now the new time that's supposed to be displayed via text-properties does not show up. Let me spend some time and get a small reproducible case, which will help us test this. On Tue, Feb 4, 2020 at 6:38 PM Bastien wrote: > Hi Andrew, > > thanks again. > > Andrew Hyatt writes: > > > Removing the (beginning-of-line 1) at the end of the time display > > code in that function, and substituting (org-agenda-previous-line) > > seems to fix it. I'm not sure if that's the right approach - the > > previous code didn't use that function for a reason, but I don't know > > what that reason was. > > I think this approach is correct is it will move over visible lines. > > I've pushed a patch, please let me know if it is fixed. > > Best, > > -- > Bastien >
Re: commit "328c9a1af * bad org.el: Enhance menus" caused error
Hi, stardiviner writes: > BTW, the function ~org-insert-dblock-bindings~ is from package > =orgtbl-aggregate=. I don't know this function and this package. Can you share the minimal Emacs config with which you reproduce the problem? -- Bastien
Re: org-adapt-indentation default should be nil [legibility 3/6]
Texas Cyberthal writes: >> the default settings do not put blank lines between headings and >> their entry text, > > I don't know what this means. Plain Emacs behaves the same way > Spacemacs does in this regard. Insertion of a blank line after a > heading is voluntary but standrd. I don't know what you mean, either, but you keep mentioning Spacemacs, which isn't very relevant. >> without any indentation, headings and entry text on varying levels >> tends to blend together, making for very poor readability. > > If the goal is to read the body text of headings, then deeply > indenting it is contrary to the goal. If the goal is to see the depth > of headings, then the bodies should be folded. If folded mode doesn't > convey sufficient information, the solution is to rewrite the heading > titles to better summarize the body text. It is not for you to decide what others should do. Your preferences are not mine. It sounds like you should develop your own "Texas Cyberthal Emacs starter kit" that has all the settings you think are best. >> No one is "good at" Emacs and Org when they first come to it. > > UI difficulty is exponential, not linear. Come on, we all know that the Emacs learning curve is a spiral. > The more initially difficult the Emacs UI is acknowledged to be, the > more important it is to reduce that difficulty with noob-friendly > defaults, so that they can eventually reach the point of elitist > unconcern for noobs. The issue here is not whether Emacs can generally be improved, but whether your specific proposals are good ideas. It's unfriendly of you--and incorrect--to imply that we are elitists without concern for new users. Much effort is put into improving documentation, answering questions, writing explanatory articles, giving demonstrations, etc. Some of us even publish code to help others improve their configs, e.g. https://github.com/alphapapa/alpha-org. I suggest that you give those avenues a try, rather than insisting that your preferences are best for others. > The problem with aiming software at noobs is ruining the expert > experience. That is one problem with software that overemphasizes the experience of new users. Another, perhaps more serious, problem is that it inhibits the development of such expertise. I feel like some of ESR's writings are relevant here. > Changing defaults doesn't ruin expert experience because experts have > configuration management. A VCS does not obviate the need to compensate for changes in default behavior. > Noob friendly defaults increases the likelihood there is a long term > for them. Emacs' biggest barrier to adoption is acclimatization. You're not quite wrong, but you're missing the point about long-term users. What makes software attractive in the long-term is not what makes it appeal to new users. Emacs is not called "the editor of a lifetime" for nothing--nor is notepad.exe called that, even though it is very easy for new users to use. Emacs is attractive in the long-term because of its power, flexibility, and potential for mastery. There is a balance to be struck between appealing to new users and empowering the development of expertise; to an extent, the two goals do conflict. > I just read a GTD thread in which they all agreed Org was too hard to > be worth learning, including the guy advocating it: > > https://forum.gettingthingsdone.com/threads/emacs-org-mode-is-the-perfect-tool-for-gtd.15028/page-2 > > To be clear, this is the biggest GTD forum, which Org is the best > implementation of, and it seems most of them are using digital GTD > tools. So what? Emacs and Org do not need to adapt themselves to users who do not like them. They are successful because of what they are. You seem very concerned about new users, thinking that, unless we make Emacs/Org very easy for new users to understand, there will be no new users. This is obviously not the case. Emacs is one of the oldest pieces of software still widely used. It and Org are gaining new users every day; the community is more vibrant than ever. Probably more people use Emacs and Org today than ever before. Consider an analogy: Years ago, Mozilla Firefox was the fastest, most powerful, most popular browser that wasn't imposed on its users. It was the obvious victor in the "browser wars," having led the way in unseating IE and freeing the Web from Microsoft's hegemony. Then Google Chrome arose as a challenger, with certain inherent advantages due to Google's position. Mozilla then chose to stop leading and start following. Every new Firefox release became more like Chrome, with Mozilla thinking that it could win back users. But why would a user who was happy with Chrome want to switch to a poor imitation of it? Mozilla thought it could succeed by abandoning what had made it successful--it thought Firefox would be more popular if it stopped being Firefox. The result was continued decline in Firefox's market share and, eventually, Mozilla's recen
Important request, participation in software development study
Dear Engineers, When I write this message, I think I am writing to the best software developers in the world, or to those who are in the process of being one. I write to ask you a favor. I am a UMA PhD student and I study the use of formal and non-formal models in the software industry. According to 9 investigations, UML is not being used as it should, but the developers use their own models, designed by them or by their companies. However, these investigations have not included professionals like you, so I want to ask you to help me by answering this survey: If you have a Google account: https://docs.google.com/forms/d/e/1FAIpQLSdG4bhNWfU3vzSKwG-0j8NuGW47_xmSY1ftF33gaNAZsU25kA/viewform Reply without logging in: https://docs.google.com/forms/d/e/1FAIpQLSeNm99cxIyT65-5qR6ZCZoDNeFONTf_ODWbXaSxUskkxbWu4g/viewform I also ask you to send this survey to other developers that you know and respect. Please help me, I promise that your contributions will be recognized in the publications that are possible, therefore, as an optional field I have included the name and email. My biggest goal is to unify all non-formal models to create a modeling language that is the heritage of the industry, built by all of us. If you want to know more, you can write to me at ivan.arr...@uma.es, ivandarioarr...@gmail.com or arco...@gmail.com !!THANKS
commit "328c9a1af * bad org.el: Enhance menus" caused error
I use magit-bisect on the latest (currently latest commit is "b14a14c9e")
org-mode repo. The commit "328c9a1af * bad org.el: Enhance menus" caused
bellowing error. I confirmed with a minimal Emacs config testing.
#+begin_example
Debugger entered--Lisp error: (void-variable org-org-menu)
org-insert-dblock-bindings()
run-hooks(org-load-hook)
eval-buffer(# nil
"/home/stardiviner/Code/Emacs/org-mode/lisp/org.el" nil t) ; Reading at buffer
position 832102
load-with-code-conversion("/home/stardiviner/Code/Emacs/org-mode/lisp/org.el"
"/home/stardiviner/Code/Emacs/org-mode/lisp/org.el" nil t)
require(org)
eval-buffer(# nil
"/home/stardiviner/.config/emacs/elpa/org-20190211/..." nil t) ; Reading at
buffer position 1257
load-with-code-conversion("/home/stardiviner/.config/emacs/elpa/org-20190211/..."
"/home/stardiviner/.config/emacs/elpa/org-20190211/..." t t)
require(org-info nil t)
(not (require 'org-info nil t))
(if (not (require 'org-info nil t)) (display-warning 'use-package (format
"Cannot load %s" 'org-info) :error))
(prog1 (if (not (require 'org-info nil t)) (display-warning 'use-package
(format "Cannot load %s" 'org-info) :error)) (let ((elapsed (float-time
(time-subtract (current-time) now (if (> elapsed 0.1) (message "%s...done
(%.3fs)" "Loading package org-info" elapsed) (message "%s...done" "Loading
package org-info"
(let ((now (current-time))) (message "%s..." "Loading package org-info")
(prog1 (if (not (require 'org-info nil t)) (display-warning 'use-package
(format "Cannot load %s" 'org-info) :error)) (let ((elapsed (float-time
(time-subtract (current-time) now (if (> elapsed 0.1) (message "%s...done
(%.3fs)" "Loading package org-info" elapsed) (message "%s...done" "Loading
package org-info")
(condition-case err (let ((now (current-time))) (message "%s..." "Loading
package org-info") (prog1 (if (not (require 'org-info nil t)) (display-warning
'use-package (format "Cannot load %s" 'org-info) :error)) (let ((elapsed
(float-time (time-subtract ... now (if (> elapsed 0.1) (message "%s...done
(%.3fs)" "Loading package org-info" elapsed) (message "%s...done" "Loading
package org-info") ((debug error) (funcall use-package--warning152 :catch
err)))
eval-buffer(# nil
"/home/stardiviner/.config/emacs/init/org-mode/init..." nil t) ; Reading at
buffer position 6453
load-with-code-conversion("/home/stardiviner/.config/emacs/init/org-mode/init..."
"/home/stardiviner/.config/emacs/init/org-mode/init..." nil t)
require(init-org-hyperlink)
eval-buffer(# nil
"/home/stardiviner/.config/emacs/init/org-mode/init..." nil t) ; Reading at
buffer position 518
load-with-code-conversion("/home/stardiviner/.config/emacs/init/org-mode/init..."
"/home/stardiviner/.config/emacs/init/org-mode/init..." nil t)
require(init-org-mode)
eval-buffer(# nil "/home/stardiviner/.config/emacs/init.el"
nil t) ; Reading at buffer position 3704
load-with-code-conversion("/home/stardiviner/.config/emacs/init.el"
"/home/stardiviner/.config/emacs/init.el" t t)
load("/home/stardiviner/.config/emacs/init" noerror nomessage)
startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) t)
command-line()
normal-top-level()
#+end_example
--
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [PATCH] ob-sql.el support auto set sql-product in editing sql-mode src block buffer
About this patch, patch, what do you think? Nicolas and Bastien. stardiviner writes: > I tried to write an alist of all database names. and write an function to used > to match name to possible names. But I found this solution is a little kind of > complicated. > > Another simple solution is just add an duplicate code of "postgresql" for > alias > "postgres". Because I found only one exception "postgresql" is "postgres" in > ~sql-mode~ products alist. Other database names are matched with ~sql-mode~. > > So I decided to take the simpler solution. I attached patch in the email > attachment. > > # > == > > BTW, I'm still not good at Elisp, can't write out a good solution for > translate > and matching for database names. > > Here is my temporary databases alist: > > #+begin_src diff > modified lisp/ob-sql.el > @@ -87,6 +87,52 @@ (defconst org-babel-header-args:sql > (database . :any)) >"SQL-specific header arguments.") > > +(defcustom org-babel-sql-engines-alist nil > + "Alist of engine names for :engine header argument. > + > +It is an alist data structure: ( . (list of alias names)). > +Merged with sql-mode's `sql-product-alist'." > + :type '(alist :key-type symbol :value-type list) > + :group 'org-babel) > + > +;;; initialize `org-babel-sql-engines-alist' > +(dolist (product (mapcar 'car sql-product-alist)) > + (pcase product > +(`ansi > + (add-to-list 'org-babel-sql-engines-alist (cons 'ansi (list 'ansi > +(`sqlite > + (add-to-list 'org-babel-sql-engines-alist (cons 'sqlite (list > 'sqlite > +(`mysql > + (add-to-list 'org-babel-sql-engines-alist (cons 'mysql (list 'mysql > +(`mariadb > + (add-to-list 'org-babel-sql-engines-alist (cons 'mariadb (list 'mariadb > 'maria > +(`postgresql > + (add-to-list 'org-babel-sql-engines-alist (cons 'postgresql (list > 'postgresql 'postgres > +(`oracle > + (add-to-list 'org-babel-sql-engines-alist (cons 'oracle (list > 'oracle > +(`mssql > + (add-to-list 'org-babel-sql-engines-alist (cons 'mssql (list 'mssql > 'ms > +(`dbi > + (add-to-list 'org-babel-sql-engines-alist (cons 'dbi (list 'dbi > +(`monetdb > + (add-to-list 'org-babel-sql-engines-alist (cons 'monetdb (list > 'monetdb > +(`sqsh > + (add-to-list 'org-babel-sql-engines-alist (cons 'sqsh (list 'sqsh > +(`vertica > + (add-to-list 'org-babel-sql-engines-alist (cons 'vertica (list > 'vertica > +(`db2 > + (add-to-list 'org-babel-sql-engines-alist (cons 'db2 (list 'db2 > +(`infomix > + (add-to-list 'org-babel-sql-engines-alist (cons 'infomix (list > 'infomix > +(`ingres > + (add-to-list 'org-babel-sql-engines-alist (cons 'ingres (list > 'ingres > +(`interbase > + (add-to-list 'org-babel-sql-engines-alist (cons 'interbase (list > 'interbase > +(`solid > + (add-to-list 'org-babel-sql-engines-alist (cons 'solid (list 'solid > +(`sybase > + (add-to-list 'org-babel-sql-engines-alist (cons 'sybase (list > 'sybase)) > + > (defun org-babel-expand-body:sql (body params) >"Expand BODY according to the values of PARAMS." >(org-babel-sql-expand-vars > > #+end_src > > I don't know how to write a translation function for alist to be used in > function ~org-babel-execute:sql~. > > #+begin_src emacs-lisp :eval no > (defun org-babel-execute:sql (body params) > "Execute a block of Sql code with Babel. > This function is called by `org-babel-execute-src-block'." > (let* ((result-params (cdr (assq :result-params params))) > (cmdline (cdr (assq :cmdline params))) > (dbhost (org-babel-find-db-connection-param params :dbhost)) > (dbport (org-babel-find-db-connection-param params :dbport)) > (dbuser (org-babel-find-db-connection-param params :dbuser)) > (dbpassword (org-babel-find-db-connection-param params :dbpassword)) > (database (org-babel-find-db-connection-param params :database)) > (engine (cdr (assq :engine params))) > (colnames-p (not (equal "no" (cdr (assq :colnames params) > (in-file (org-babel-temp-file "sql-in-")) > (out-file (or (cdr (assq :out-file params)) >(org-babel-temp-file "sql-out-"))) >(header-delim "") > (command (pcase (intern engine) > (`dbi (format "dbish --batch %s < %s | sed '%s' > %s" > (or cmdline "") > (org-babel-process-file-name in-file) > "/^+/d;s/^|//;s/(NULL)/ /g;$d" > (org-babel-process-file-name out-file))) > (`monetdb (format "mclient -f tab %s < %s > %s" > (or cmdline "") > (org-babel-process-f
Re: org-startup-truncated default should be nil [legibility 2/6]
Texas Cyberthal writes: >> visual-line-mode and toggle-truncate-lines are basic Emacs commands >> that all users should learn early. > > Visual lines, logical lines etc is a complicated mess that Spacemacs > avoids entirely. I recall fiddling with it and never being satisfied, > until adopting Spacemacs solved it. Now I know even less about it than > I did then, because there's no need to know. A brief investigation > shows Spacemacs sets (line-move-visual t) in prosey text modes, so > that C-n next-line operates on visual lines. However commands such as > C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane > default that permits fluid navigation of paragraphs, which is all a > noob wants to do. > > Similarly, I almost never use truncate-lines, to the point that I had > to websearch to recall what it was called within the last week. If I understand correctly, you're arguing that defaults should be changed because you don't understand how Emacs works, and since you use Spacemacs, you don't even care how it works. May I suggest that you propose your changes on the Spacemacs repo.
ob-clojure :var header argument not work when src block is noweb called by another src block
Here is an example: #+NAME: read-in-wxid #+begin_src clojure :var cwd=(file-truename "~/Documents/WeChat/wxid/") (require '[clojure.java.io :as io]) (def directory (io/file cwd)) (def files (filter #(.isFile %) (file-seq directory))) #+end_src #+RESULTS[<2019-08-28 09:12:24> 84a1210d836742ca71c776aaebba0e0224af]: read-in-wxid : #'user/files #+begin_src clojure :noweb yes :results pp <> (take 3 files) #+end_src #+RESULTS[<2019-08-28 09:12:30> 9bbcd9f779f72bdd9b7bb8fb85aa36bbdfee7e3c]: : class clojure.lang.Compiler$CompilerExceptionclass clojure.lang.Compiler$CompilerExceptionSyntax error compiling at (*Org Src Code.org[ clojure ]*:3:16). : Unable to resolve symbol: cwd in this context -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: Defaults for noobs, dotfiles for vets [legibility 1/6]
Texas Cyberthal writes: > Making a vet change a default if he decides he doesn't like a change > upon upgrading won't drive him away, but Emacs' unfriendly defaults > are always driving away noobs. Therefore Org's defaults should be > noob-friendly, not vet-friendly. There is certainly room to improve some Emacs defaults; there are active threads on emacs-devel about it now. However, the question of to what degree Emacs should target certain types of users is a wider one, and answering it one way or the other doesn't necessarily support your proposed changes. > Probably vets should use legible settings as well. I became accustomed > to less-legible Org settings, and thought they were superior. But when > I cleaned up my Spacemacs config, I incidentally restored some default > legibility tweaks I'd disabled. After a brief exposure, I realized the > tweaks were superior, and that my preferences had been wrong. Changing > the defaults can overcome vet inertia and improve their UI. It's neither the spirit nor practice of Emacs to tell users what settings they should use. Emacs exists to empower users to meet their needs according to their preferences. It is not for you, nor us, to decide whether certain users are suffering from "inertia" which we ought to overcome on their behalf for the sake of improving their UI. That is for them to decide, not us. This is Emacs, not Apple, Inc. >> Terminals can display colors, underlines, italics, and bold text > > Proposed legibility changes don't affect those font aspects. I was responding to this claim of yours: >>> Concerns about terminal impact appear to be moot, since terminal >>> ignores most font settings. So your claim has been clarified from "terminals ignore most font settings" to "my proposed changes don't affect the font aspects that terminals display." Please quote enough of the message you're replying to so that the conversation can be easily followed (by me, if no one else).
Re: commit "328c9a1af * bad org.el: Enhance menus" caused error
BTW, the function ~org-insert-dblock-bindings~ is from package =orgtbl-aggregate=. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
New file org-refile.el
Hi all, in the master branch, I've moved Org refile variables and functions to a new org-refile.el file. This may help boost (a tiny bit) the loading of org.el. Please report any strange things that may arise. -- Bastien
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: > Thanks for the clarification. I was not sure if it is intended. > I was mislead about this 2 times because of docstring, though it is > clear from the source code. I fixed the docstring. Thank you. >> Luckily, headlines are exactly where you do _not_ need Element library. >> `org-back-to-heading' and `org-up-heading-safe' will always be faster, >> and as accurate. I.e., the code operating on headlines is usually >> distinct from the code handling other elements. > > Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of > my agenda generation time (I have really huge number of headings + > multiple custom skip functions). I was hoping to use cache for speed > up. Cache will not help you here. `org-up-heading-safe' and `org-back-to-heading' are faster than `org-element-at-point' + cache. Moreover, custom skip functions are a pain. They prevent any form of caching during agenda creation. IMO, Agenda (or its re-implementation) should do without them. >> You can parse the full document and get all the :parent properties >> filled. That's not the job for `org-element-at-point'. > > I once tried to do exactly this, but I did not manage to figure out how > to obtain element at point from full parse tree (from inside an agenda > skip function). Is it possible? It is possible but not implemented. >> Note that `org-element-cache' was disabled a while ago because it could >> introduce freezes. I think this is related to how this part handles >> `before-change-functions' and `after-change-functions'. Anyway, YMMV. > > I see... I don't know how useful the cache is except my idea about > using cache to speed up agenda. But I was stuck with the :parent > property issue and did not play much further since that time. I once started to implement Agenda-specific caching, but stopped as it would have entailed rewriting much of the Agenda code. It would have been a pain. Even switching "org-agenda.el" to lexical binding is difficult (and isn't done yet). Some re-implementation of Agenda (e.g., org-super-agenda + org-ql) may be better wrt caching.
Re: Make code elements in prose unobtrusive [legibility 6/6]
On Tue, Feb 04, 2020 at 09:38:57PM -0600, Matthew Lundin wrote: > Adam Porter writes: > > > There may be improvements to be made, but the defaults shouldn't be set > > to match the preferences of any one user. Remember that people have > > been using Org for years, and theming and faces are very personal. ;) > > I strongly agree. All of the changes mentioned in these legibility > threads could be accomplished through theming and Elpa/Melpa packages I've been monitoring this thread, and I have to agree strongly with the idea of themes. I think if you feel strongly about the newbie experience, maybe you can help setup and maintain a single binary Emacs distro with your theme as the default. I'm the complete opposite of the original poster in all of these threads. I avoid applications with variable width fonts. I treasure that my terminals all have the same fixed width font and it isn't overridden by every document or application. I find variable fonts to be an aesthetic hassle. I wish I could read more items on my terminal or in fixed width in Emacs. It's very high speed and consistent. The modern web is a particular hassle with bright backgrounds and highly inconsistent and illegible fonts. However, if that's what makes you happy in Emacs, feel free to customize it that way. You can always have it your way in your config. ;] -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
> `org-element-at-point' returns only a partial parse tree. It never goes > higher than the current top-level element, i.e., from an element, you > cannot go up to the headline just following :parent. Thanks for the clarification. I was not sure if it is intended. I was mislead about this 2 times because of docstring, though it is clear from the source code. > Luckily, headlines are exactly where you do _not_ need Element library. > `org-back-to-heading' and `org-up-heading-safe' will always be faster, > and as accurate. I.e., the code operating on headlines is usually > distinct from the code handling other elements. Well. `org-back-to-heading` + `org-up-heading-safe` take more than 15% of my agenda generation time (I have really huge number of headings + multiple custom skip functions). I was hoping to use cache for speed up. > You can parse the full document and get all the :parent properties > filled. That's not the job for `org-element-at-point'. I once tried to do exactly this, but I did not manage to figure out how to obtain element at point from full parse tree (from inside an agenda skip function). Is it possible? > Note that `org-element-cache' was disabled a while ago because it could > introduce freezes. I think this is related to how this part handles > `before-change-functions' and `after-change-functions'. Anyway, YMMV. I see... I don't know how useful the cache is except my idea about using cache to speed up agenda. But I was stuck with the :parent property issue and did not play much further since that time. Best, Ihor Nicolas Goaziou writes: > Hello, > > Ihor Radchenko writes: > >>> Probably the docstring needs to be adapted - Nicolas knows this area >>> better than me. >> >> Do you mean that :parent property may not always be present? > > `org-element-at-point' returns only a partial parse tree. It never goes > higher than the current top-level element, i.e., from an element, you > cannot go up to the headline just following :parent. > > Luckily, headlines are exactly where you do _not_ need Element library. > `org-back-to-heading' and `org-up-heading-safe' will always be faster, > and as accurate. I.e., the code operating on headlines is usually > distinct from the code handling other elements. > >> If so, it is quite disappointing. It would be helpful to be able to find >> parent of any element at point (especially, in conjunction with >> org-element-cache). At least, optionally. > > You can parse the full document and get all the :parent properties > filled. That's not the job for `org-element-at-point'. > >> I was counting on this feature to try speeding up my agenda generation >> (using org-element-cache). > > Note that `org-element-cache' was disabled a while ago because it could > introduce freezes. I think this is related to how this part handles > `before-change-functions' and `after-change-functions'. Anyway, YMMV. > > Regards, > > -- > Nicolas Goaziou -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: Defaults for noobs, dotfiles for vets [legibility 1/6]
I started out arguing against my position and wound up with another blog post: https://cyberthal-ghost.nfshost.com/emacs-needs-a-starter-zone-and-org-is-it/
Re: bug: org-table-convert-region-max-lines causes a "Code block produced nop output"
Charles Millar writes: > I have not experienced this problem since I reported it. Thanks for confirming! -- Bastien
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hello, Ihor Radchenko writes: >> Probably the docstring needs to be adapted - Nicolas knows this area >> better than me. > > Do you mean that :parent property may not always be present? `org-element-at-point' returns only a partial parse tree. It never goes higher than the current top-level element, i.e., from an element, you cannot go up to the headline just following :parent. Luckily, headlines are exactly where you do _not_ need Element library. `org-back-to-heading' and `org-up-heading-safe' will always be faster, and as accurate. I.e., the code operating on headlines is usually distinct from the code handling other elements. > If so, it is quite disappointing. It would be helpful to be able to find > parent of any element at point (especially, in conjunction with > org-element-cache). At least, optionally. You can parse the full document and get all the :parent properties filled. That's not the job for `org-element-at-point'. > I was counting on this feature to try speeding up my agenda generation > (using org-element-cache). Note that `org-element-cache' was disabled a while ago because it could introduce freezes. I think this is related to how this part handles `before-change-functions' and `after-change-functions'. Anyway, YMMV. Regards, -- Nicolas Goaziou
Re: bug: org-table-convert-region-max-lines causes a "Code block produced nop output"
On 2/5/20 3:11 AM, Bastien wrote: Hi Charles, Charles Millar via Emacs-orgmode writes: In an org file I have a source code block to convert entries into and generate a recutils file #+begin_src sh?? :file SomeFile.rec cat << EOF # -*- mode: rec -*- Begin recutils file Approximately 770 records in recutils format each with about 20 entries; over 17,000 lines including line feeds or carriage returns #+end_src The following error is produced: Starting new Ispell process /usr/bin/aspell with en_US dictionary... executing Sh code block... Wrote /tmp/babel-k8j93s/ob-input-LL2cYo Error reading results: (user-error Region is longer than ???org-table-convert-region-max-lines??? (999) lines; not converting) Code block produced no output. This bug is quite old -- before I try to digg in, can you confirm it is still present with latest Org version from the maint branch? Thanks! I have not experienced this problem since I reported it. As I recall at a later date you pointed out that I should have inserted the header :results file. Thanks Charlie Millar
Re: Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]
Hi Gustavo, Gustavo Barros writes: >> I managed to reproduce this bug, it is fixed in maint now. > > I can report this issue is gone with the update to Org 9.3.3. > Thank you very much! Thanks for confirming, best, -- Bastien
Re: Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]
Hi Bastien, On Tue, Feb 04 2020, Bastien wrote: I managed to reproduce this bug, it is fixed in maint now. I can report this issue is gone with the update to Org 9.3.3. Thank you very much! Best, Gustavo.
Re: Bug: wsl org-open-at-point [9.1.14 (9.1.14-9-g131531-elpa @ /home/boss5/.emacs.d/elpa/org-20181112/)]
Hi Fabrice, Fabrice Popineau writes: > I am not sure that it is an issue that should be solved by > org-mode. Thanks for taking the time to answer -- I'll leave this "bug" out of my radar for now then. Thanks, -- Bastien
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Ihor Radchenko writes: >> Probably the docstring needs to be adapted - Nicolas knows this area >> better than me. > > Do you mean that :parent property may not always be present? I don't know, I hope Nicolas can handle this. -- Bastien
Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]
"Fraga, Eric" writes: > On Wednesday, 5 Feb 2020 at 09:14, Bastien wrote: > > [...] > >> Org-mode sets: >> >> (modify-syntax-entry ?< "(>") >> (modify-syntax-entry ?> ")<") >> >> should we adapt Org's default syntax? > > Difficult to judge but my gut feeling would be to leave as is. Okay, done :) -- Bastien
Re: Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
> Probably the docstring needs to be adapted - Nicolas knows this area > better than me. Do you mean that :parent property may not always be present? If so, it is quite disappointing. It would be helpful to be able to find parent of any element at point (especially, in conjunction with org-element-cache). At least, optionally. I was counting on this feature to try speeding up my agenda generation (using org-element-cache). Best, Ihor Bastien writes: > Hi Ihor, > > Ihor Radchenko writes: > >> According to org-element-at-point docstring, "Properties depend on >> element or object type, but always include :begin, :end, :parent and >> :post-blank properties.". > > Probably the docstring needs to be adapted - Nicolas knows this area > better than me. > > Best, > > -- > Bastien -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]
On Wednesday, 5 Feb 2020 at 09:14, Bastien wrote: [...] > Org-mode sets: > > (modify-syntax-entry ?< "(>") > (modify-syntax-entry ?> ")<") > > should we adapt Org's default syntax? Difficult to judge but my gut feeling would be to leave as is. My use case involves significant amount of coding, where < and > are logical operators. However, for many, these may make more sense as brackets. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-199-ga557cf
Release 9.3.3
Hi all, Org 9.3.3, a bugfix release, is out. Enjoy! -- Bastien
Re: Bug: org-babel-execute:emacs-lisp does not allow changing window configuration from within code block [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi Ihor, this is fixed in maint now, thanks! -- Bastien
Re: Bug: LaTeX output of numbered TODO plain list items lose numbering. [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/27.0.50/lisp/org/)]
Hi Brian, if you can write a patch for this enhancement, that would be nice. Thanks, -- Bastien
Re: Bug: export html with nice urls [9.1.9 (release_9.1.9-65-g5e4542 @ /gnu/store/djza93lqjcndsldf4794bp8mvipd6fz4-emacs-26.3/share/emacs/26.3/lisp/org/)]
Hi Arne, can you provide a patch for this? Thanks! -- Bastien
Re: Bug: Wrong syntax in org-mode files with babel fragments in src blocks [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20191021/)]
Hi Eric, "Fraga, Eric" writes: > I have the following 2 lines in my org-mode-hook to cater for this issue > which arises when using source blocks. > > (modify-syntax-entry ?< ".") > (modify-syntax-entry ?> ".") Org-mode sets: (modify-syntax-entry ?< "(>") (modify-syntax-entry ?> ")<") should we adapt Org's default syntax? -- Bastien
Re: Bug: wsl org-open-at-point [9.1.14 (9.1.14-9-g131531-elpa @ /home/boss5/.emacs.d/elpa/org-20181112/)]
Le mer. 5 févr. 2020 à 07:25, Bastien a écrit : > Hi Steve, > > thanks for reporting this issue. Can you or Fabrice suggests what > change should be done in Org, if any? Also, perhaps another solution > can be found by adapting `org-file-apps'? > > I am not sure that it is an issue that should be solved by org-mode. It is more a problem of setting up WSL such that it meets well some expectations. Basically, you need an equivalent of xdg-open which redirects requests to the w32 system. The suggestion I made to solve the issue is working for me, but as you see, it is a crude hack: the paths need to be adapted to each individual setting. If someone comes up with a cleaner, more general solution, solution, it should be published somewhere as an example of how to setup things with WSL. Fabrice
Re: bug: org-table-convert-region-max-lines causes a "Code block produced nop output"
Hi Charles, Charles Millar via Emacs-orgmode writes: > In an org file I have a source code block to convert entries into and > generate a recutils file > > #+begin_src sh?? :file SomeFile.rec > cat << EOF > # -*- mode: rec -*- > > Begin recutils file > > Approximately 770 records in recutils format each with about 20 entries; > over 17,000 lines including line feeds or carriage returns > > #+end_src > > The following error is produced: > > Starting new Ispell process /usr/bin/aspell with en_US dictionary... > executing Sh code block... > Wrote /tmp/babel-k8j93s/ob-input-LL2cYo > Error reading results: (user-error Region is longer than > ???org-table-convert-region-max-lines??? (999) lines; not converting) > Code block produced no output. This bug is quite old -- before I try to digg in, can you confirm it is still present with latest Org version from the maint branch? Thanks! -- Bastien
Re: Bug: calling org-agenda-list programatically when starting with emacs --daemon [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hi, rrandr...@gmail.com writes: > Remember to cover the basics, that is, what you expected to happen and > what in fact did happen. You don't know how to make a good report? See > > https://orgmode.org/manual/Feedback.html#Feedback > > Your bug report will be posted to the Org mailing list. > > > Hi. > > I usually start emacs with --daemon. > > At the end of my dot emacs I have a funct that calls or-agenda-list on a > thread. > > When I call emacsclient for opening a frame (the first frame) and try > to visit a buffer (any buffer). I have an opened buffer > *Backtrace* with this content: > > Debugger entered--Lisp error: (error "‘recenter’ing a window that > does not display current-buffer.") Fixed, thanks! -- Bastien
