Re: Agenda follow mode + indirect window settings
Thanks a lot for this. Will think about it. El mar., 17 nov. 2020 a las 6:52, Kyle Meyer () escribió: > Gerardo Moro writes: > > > Hi, > > > > I want my agenda to have follow-mode active when starting Emacs. > > I suppose this would do the trick? > > > > (setq org-agenda-start-with-follow-mode t) > > (setq org-agenda-follow-indirect t) > > > > 1) Do I need both? I have observed that having only the second one does > not > > work. > > The first one causes new agenda buffers to start with > org-agenda-follow-mode enabled. Even if it's not enabled initially, you > can toggle it with F. > > The second is in effect when org-agenda-follow-mode is enabled. > > > 2) Is there a way to make the "indirect" window populate the vertically > > existing window (I always work with the frame split in two vertically). > > Right now it shows in a very small window beneath the agenda. > > I think with the way things are written at the moment you're best bet > would be to try to rearrange afterwards (say with advice after > org-agenda-tree-to-indirect-buffer). Ideally the current behavior would > be achieved in a way that would allow the user to control the result > with things like display-buffer-overriding-action and > display-buffer-alist, but I suspect that'd take a substantial rework. >
Re: Re: Agenda follow mode + indirect window settings
Very nice! I don't know much elisp as I am a new Emacs user. What in short would this code do? :) Thanks a million! El mar., 17 nov. 2020 a las 6:56, tumashu () escribió: > > > > > > > > > > > > > > > > > > At 2020-11-17 12:52:06, "Kyle Meyer" wrote: > >Gerardo Moro writes: > > > >> Hi, > >> > >> I want my agenda to have follow-mode active when starting Emacs. > >> I suppose this would do the trick? > >> > >> (setq org-agenda-start-with-follow-mode t) > >> (setq org-agenda-follow-indirect t) > >> > >> 1) Do I need both? I have observed that having only the second one does > not > >> work. > > > >The first one causes new agenda buffers to start with > >org-agenda-follow-mode enabled. Even if it's not enabled initially, you > >can toggle it with F. > > > >The second is in effect when org-agenda-follow-mode is enabled. > > > >> 2) Is there a way to make the "indirect" window populate the vertically > >> existing window (I always work with the frame split in two vertically). > >> Right now it shows in a very small window beneath the agenda. > > > >I think with the way things are written at the moment you're best bet > >would be to try to rearrange afterwards (say with advice after > >org-agenda-tree-to-indirect-buffer). Ideally the current behavior would > >be achieved in a way that would allow the user to control the result > >with things like display-buffer-overriding-action and > >display-buffer-alist, but I suspect that'd take a substantial rework. > > I use the below config, maybe useful... > > > (define-key org-agenda-mode-map (kbd "SPC") > 'eh-org-agenda-show-and-scroll-up) > (define-key org-agenda-mode-map (kbd "") > 'eh-org-agenda-show-and-scroll-up) > > (defvar eh-org-agenda-show-window-point nil) > (defun eh-org-agenda-show-and-scroll-up (&optional arg) > (interactive "P") > (let ((win (selected-window))) > (if (and (window-live-p org-agenda-show-window) > (eq this-command last-command)) > (progn > (select-window org-agenda-show-window) > (if (eq eh-org-agenda-show-window-point (window-point)) > (progn > (goto-char (point-min)) > (message "已经滚动到底，返回第一行！")) > (ignore-errors (scroll-up)) > (setq eh-org-agenda-show-window-point (window-point > (org-agenda-goto t) > (org-show-entry) > (let ((org-indirect-buffer-display 'current-window)) > (org-tree-to-indirect-buffer) > ;; 隐藏 indirect buffer > (rename-buffer (concat " " (buffer-name > (if arg (org-cycle-hide-drawers 'children) > (org-with-wide-buffer > (narrow-to-region (org-entry-beginning-position) >(org-entry-end-position)) > (org-show-all '(drawers > (setq org-agenda-show-window (selected-window))) > (select-window win))) > >
Re: Changed list indentation behavior: how to revert?
Am Tue, 17 Nov 2020 01:11:38 +0100 schrieb "Dr. Arne Babenhauserheide" : > The only way that works is to avoid breakage on update — except for > the few cases where it is truly unavoidable. Well, and as long as the change can be reverted when the community has a thoughtful discussion with those who did the work, the world is wonderful. Even if the devels insist they did the right thing, but the discussion brought up way to mitigate the fallout, all is fine. I even get the feeling of being part of a great community through this very discussion! So ...civilized. A warm fire in the wild net. It is *impossible* to force users to be informed. Think about us: We all hang around on this list and missed the information. What would reasonably be expected from a casual user? Often it is not even clear what the consequences are, even if you read the NEWS. "Org now uses electric-indent" only is meaningful to very few people who can guess what that will mean for their workflow. It *seems* impossible to me to be backward compatible forever via code snippets or any other mechanism. You can maybe skip one or two update cycles, but then it will be like pinning a specific git version. One can do that already, but it should not increase the burden of the devels. If those don't have fun anymore, we are lost :-) So we have to live with a breakage from time to time, I guess, but org has very few of those. And it always comes out of these breakages better! Detlef
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Hi again, I actually now realized that your function will not unfortunately archive each logged item (those located in the logbook) in its corresponding date (!). What it will do is to archive the whole tree under today's date without deleting it from the original org file. For instance, * TODO REPEATED TASK SAMPLE SCHEDULED: <2020-11-30 Mon +20d> :PROPERTIES: :STYLE:habit :LAST_REPEAT: [2020-11-09 Mon 22:28] :END: :LOGBOOK: - State "DONE" from "TODO" [2020-11-15 Sun 22:28] - State "DONE" from "STARTED"[2020-11-14 Sat 22:17] - State "DONE" from "STARTED"[2020-11-13 Fri 22:17] - State "DONE" from "STARTED"[2020-11-11 Wed 22:17] If I position myself in any point in this entry, when I execute the function it will archive the whole tree+subtree under today's date (the date when it was archived). The behaviour I was expecting is to archive each of the logged tasks under their corresponding date (on the 11th, 13th, 14th and 15th of November). Just to be clear :) G El lun., 16 nov. 2020 a las 17:21, Gerardo Moro () escribió: > Wow, I’m impressed by your help, you are very kind! > I am also impressed by your researching skills, I gave a long go at trying > to find some code online unsuccessfully. > > Yes, I agree that the agenda is a nice way to go to visualize my past > events (with v A). > My idea of not relying on the agenda interface is just to be free and have > an archive org file with all my entries, easier to scroll from any device > without the need of Emacs. > > As for the function to archive the individual repeated tasks into their > corresponding tree: > I’m not an emacs lisp programmer (or any kind of!). As I see, this > function works only “at point”. > The way I work is I mark tasks as DONE during a couple weeks, and then I > call this function that tracks all my org file and archives all DONE / > CANCELLED items. > This is great because I don’t have to do it one by one. > > (defun my/org-archive-done-tasks-file () > (interactive) > (org-map-entries >(lambda () > (org-archive-subtree) > (setq org-map-continue-from (outline-previous-heading))) > "TODO=\"DONE\"|TODO=\"CANCELED\\"" 'file)) > > Do you think there is a way to combine these two functions so that when I > call the fucntion, I get to archive all DONE/CANCELLED & repeated > DONE/CANCELLED tasks (the latter without deleting the logged task or its > respective heading)? > > Best, > G. > > El jue., 12 nov. 2020 a las 12:28, Ihor Radchenko () > escribió: > >> > Hope it is clear now, thanks so much for any help! >> >> Sorry for not making my previous email more clear. I actually understood >> what you want to achieve. My suggestion was rather an alternative >> approach to "revisit the past" - you can always build agenda view for a >> specific date (or range of dates) in the past. That way, you would not >> need to look into archive file manually at all. >> >> On your actual question, I think I found some old reddit comment [1] that >> may be relevant. The code provides a new command to archive an org >> headline without actually deleting it. That way, you will get a copy of >> your headline on the date of archival. Below is the original code with >> me adding docstrings for more clarity. >> >> (defun my/org-archive-delete-logbook () >> "Delete LOGBOOK of the entry at point. It is obsolete once the copy of >> the item is moved to the archive file." >> (save-excursion >>(org-end-of-meta-data) >>(let ((elm (org-element-at-point))) >> (when (and >> (equal (org-element-type elm) 'drawer) >> (equal (org-element-property :drawer-name elm) "LOGBOOK")) >>(delete-region (org-element-property :begin elm) >> (org-element-property :end elm)) >> >> (defun my/org-archive-without-delete () >> "Archive item at point, but do not actually delete it." >> (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil))) >> (org-archive-subtree))) >> >> (defun my/org-archive-logbook () >> "Create an archive copy of subtree at point and delete LOGBOOK in the >> first headline of the subtree." >> (interactive) >> (my/org-archive-without-delete) >> (my/org-archive-delete-logbook)) >> >> I think you can modify the last function and call it in >> org-trigger-hook, so that repeating items would be archived without >> deleting every time you mark the item DONE. >> >> [1] >> https://old.reddit.com/r/orgmode/comments/dg43hs/can_i_archive_a_property_drawer/f3frk2n/ >> >> Best, >> Ihor >> >> Gerardo Moro writes: >> >> > Thanks, Ihor. >> > Indeed, that is an excellent feature of agenda. I use it sometimes to >> > visualize what I have DONE during the week on the sopt. >> > What I aim to accomplish however is a more systematic log of all the >> DONE >> > tasks, this is, to have an archive file where to archive all tasks. >> > This file is in the format: >> > >> > 2020 >> >2020-01-01 DONE task1 >> >2020-01-
Re: Changed list indentation behavior: how to revert?
"Dr. Arne Babenhauserheide" writes: > Sad story short:... I'm with you - last weekend I upgrade my OS and had quite some trouble to get everything working again and still have some nasty hoops to jump through. But on the other side: What are we talking about? Org had a given default configuration for quite some time. To be clear: THIS DID NOT CHANGE! But some people are upset now. Why? Because the emergent behaviour changed. Not the underlying default configuration, but in the context and details of how each individual uses Org for some users the default configuration was emergent and evident, but some other users did not perceive this default configuration. Now a simple setting, syncing Org with the defaults of Emacs and other modes with respect to RET and electric-indent-mode, make the OLD, UNCHANGED default configuration emergent for almost all users. These are very subtle effects inside a very complex environment. How should maintainers be able to foresee all possible environments and use cases and the resulting emergent behaviour? I'm really surprised that such a simple and insignificant breaking change results in such a uproar. If a new Org version make all old files completely unusable or a bunch of important features is totally broken, say nothing of babel works anymore - yes, is such a case I would understand the uproar. But ranting so loudly and insistent and continuously over such a minor details is really beyond me. And nobody has to read all NEWS and Changelogs for every single peace of software they are using. If nothing breaks maybe there is nothing to worry about. If some minor detail like the new emergent indentation behaviour annoys you - just have a quick look in the NEWS file of the new version. Is this really that hard? On the other hand: What's the alternative? Never change anything again? Maybe some users rely on the emergent behaviour of some bad bug (that has bad consequences for some other users). Should it never be changed, because it may annoy some users and they could be forced to read the NEWS file? You cannot have the cookie and eat it! So, everyone, please calm down and try not to overreact over really simple, negligible details. -- Until the next mail..., Stefan.
Re: Changed list indentation behavior: how to revert?
Stefan Nobis writes: > "Dr. Arne Babenhauserheide" writes: > >> Sad story short:... > > I'm with you - last weekend I upgrade my OS and had quite some trouble > to get everything working again and still have some nasty hoops to > jump through. > > But on the other side: What are we talking about? > > Org had a given default configuration for quite some time. To be > clear: THIS DID NOT CHANGE! > > But some people are upset now. Why? Because the emergent behaviour > changed. Not the underlying default configuration, but in the context > and details of how each individual uses Org for some users the default > configuration was emergent and evident, but some other users did not > perceive this default configuration. > > Now a simple setting, syncing Org with the defaults of Emacs and other > modes with respect to RET and electric-indent-mode, make the OLD, > UNCHANGED default configuration emergent for almost all users. > > These are very subtle effects inside a very complex environment. > > How should maintainers be able to foresee all possible environments > and use cases and the resulting emergent behaviour? > > I'm really surprised that such a simple and insignificant breaking > change results in such a uproar. If a new Org version make all old > files completely unusable or a bunch of important features is totally > broken, say nothing of babel works anymore - yes, is such a case I > would understand the uproar. > > But ranting so loudly and insistent and continuously over such a minor > details is really beyond me. > > And nobody has to read all NEWS and Changelogs for every single peace > of software they are using. If nothing breaks maybe there is nothing > to worry about. If some minor detail like the new emergent indentation > behaviour annoys you - just have a quick look in the NEWS file of the > new version. Is this really that hard? > > On the other hand: What's the alternative? Never change anything > again? Maybe some users rely on the emergent behaviour of some bad > bug (that has bad consequences for some other users). Should it never > be changed, because it may annoy some users and they could be forced > to read the NEWS file? > > You cannot have the cookie and eat it! > > So, everyone, please calm down and try not to overreact over really > simple, negligible details. To quote Randall Munroe: "Every change breaks someone's workflow"[1] Footnotes: [1] https://xkcd.com/1172/ -- This signature is currently under construction.
Re: Changed list indentation behavior: how to revert?
On Tue, Nov 17, 2020 at 10:06 AM Stefan Nobis wrote: > But on the other side: What are we talking about? > ... > But ranting so loudly and insistent and continuously over such a minor > details is really beyond me. > ... > So, everyone, please calm down and try not to overreact over really > simple, negligible details. > +100 - nicely put Stefan. This extremely long thread really puzzles me. --Diego
Re: Archiving repeated tasks under corresponding date tree for each repeated item
> I actually now realized that your function will not unfortunately archive > each logged item (those located in the logbook) in its corresponding date > (!). > What it will do is to archive the whole tree under today's date without > deleting it from the original org file. You are right. It is expected behaviour. That's why I suggested to run it in org-trigger-hook, which will trigger at the day and time when you mark the task DONE. Best, Ihor Gerardo Moro writes: > Hi again, > > I actually now realized that your function will not unfortunately archive > each logged item (those located in the logbook) in its corresponding date > (!). > What it will do is to archive the whole tree under today's date without > deleting it from the original org file. > > For instance, > > * TODO REPEATED TASK SAMPLE > SCHEDULED: <2020-11-30 Mon +20d> > :PROPERTIES: > :STYLE:habit > :LAST_REPEAT: [2020-11-09 Mon 22:28] > :END: > :LOGBOOK: > - State "DONE" from "TODO" [2020-11-15 Sun 22:28] > - State "DONE" from "STARTED"[2020-11-14 Sat 22:17] > - State "DONE" from "STARTED"[2020-11-13 Fri 22:17] > - State "DONE" from "STARTED"[2020-11-11 Wed 22:17] > > If I position myself in any point in this entry, when I execute the > function it will archive the whole tree+subtree under today's date (the > date when it was archived). > The behaviour I was expecting is to archive each of the logged tasks under > their corresponding date (on the 11th, 13th, 14th and 15th of November). > Just to be clear :) > G > > El lun., 16 nov. 2020 a las 17:21, Gerardo Moro () > escribió: >
Re: Changed list indentation behavior: how to revert?
* Detlef Steuer [2020-11-17 11:47]: :PROPERTIES: :CREATED: [2020-11-17 Tue 12:41] :ID: 2bc18302-d009-4751-b062-b3cf2aa44d18 :END: > It is *impossible* to force users to be informed. Think about us: We > all hang around on this list and missed the information. What would > reasonably be expected from a casual user? Often it is not even clear > what the consequences are, even if you read the NEWS. "Org now uses > electric-indent" only is meaningful to very few people who can guess > what that will mean for their workflow. News in Org mode is already very prominent, but I never read it. It is in the Org Menu documentation sub menu that leads to the website. But I would say it is much better having NEWS locally as not everybody has Internet with Org mode. News for specific user should refer to changes from previous version of that user. Not every user will have same Org version. They will not understand news if it refers to higher version which they may not have. Org is distributed over many communication channels together with Emacs. Users of many GNU/Linux distributions and FreeBSD and other BSD derivatives are getting it packaged, there are many different versions. NEWS could be made more prominent by adding NEWS links to Org Info file. I could not find any. So it is not hyperlinks. Logically the Org documentation should link to Org news and hereby I do not mean to link to the website but to link to the relevant news pertaining to specific version of Org, and such file should be together with the Org distribution. It is on my side in: /package/text/emacs-2020-11-14/share/emacs/28.0.50/etc/ORG-NEWS But does ANYTHING within Org mode points there to that file? I do not think user will find the relevant news. How is user to find the reference if reference is not given? I am using Emacs development version from 2020-11-14, 3 days ago. The ORG-NEWS is explaining about Org version 9.3 as that is what I wish to read as I am on that version (probably). Org menu, submenu Documentation is pointing to Browse News that is showing me Org news for version 9.4. That is not consistent as version 9.3 should not show me news for version 9.4. But then if I look into newer Org package installed I can even see news for version 9.5 and it says there "not yet released". >From my personal view point this is all fine. I am speaking from interface design and consistency. The link from Org menu could maybe point to the specific local file ORG-NEWS for the specific version installed. That way users on version 9.2 would see news for version 9.2. Those for version 9.3 see for 9.3 and so on. It makes things consistent. Users on this mailing list are power users. There are thousands of users who may not have neither power nor Internet to install new packages or update packages. They get it delivered through Emacs and use Emacs on the multi user system. Emacs is part of GNU system. That means somebody as administrator installs the OS and OS is used for example in multi user environment. Such environment need not have Internet access neither would install new versions of Org as the version of Emacs from GNU Linux distribution "just works". We have to think of all those users and design should drive itself for developers or power users only. Emacs version on GNU Hyperbola/Linux-libre is 25.3-3.hyperbola2 and I do not know which Org version is inside. This version I have installed in multi user environment. Why should a staff member using that version, which is functional, be looking into news pertaining to version 9.4 on the website which does not relate to version on the system? It is not consistent. And such member would not be even able to see the news on the website because computer is not connected to Internet. NEWS could be made more prominent to system administrators who install the package by placing some notices in commentary of the package, or where exactly? When I install the package or in package description there could be link to the news or notice that NEWS shall be read.
Re: Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
On Tue, 17 Nov 2020 at 02:54, Kyle Meyer wrote: Gustavo Barros writes: Hi All, The toggling of Archives mode in the agenda, the one which includes archive files, called with "v A", can be turned on, but turning it off with "v A" does not currently work. An ECM to reproduce the issue is: Thanks for the report and reproducer. Should be fixed by 104d92199. Wow, that was fast! Thank you very much, Kyle.
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Thanks, I don't know how to go about doing that, so I would have to rely on others wanting to help me if they consider this to be also useful to them (which I definitely think it is!). El mar., 17 nov. 2020 a las 11:32, Ihor Radchenko () escribió: > > I actually now realized that your function will not unfortunately archive > > each logged item (those located in the logbook) in its corresponding date > > (!). > > What it will do is to archive the whole tree under today's date without > > deleting it from the original org file. > > You are right. It is expected behaviour. That's why I suggested to run > it in org-trigger-hook, which will trigger at the day and time when you > mark the task DONE. > > Best, > Ihor > > Gerardo Moro writes: > > > Hi again, > > > > I actually now realized that your function will not unfortunately archive > > each logged item (those located in the logbook) in its corresponding date > > (!). > > What it will do is to archive the whole tree under today's date without > > deleting it from the original org file. > > > > For instance, > > > > * TODO REPEATED TASK SAMPLE > > SCHEDULED: <2020-11-30 Mon +20d> > > :PROPERTIES: > > :STYLE:habit > > :LAST_REPEAT: [2020-11-09 Mon 22:28] > > :END: > > :LOGBOOK: > > - State "DONE" from "TODO" [2020-11-15 Sun 22:28] > > - State "DONE" from "STARTED"[2020-11-14 Sat 22:17] > > - State "DONE" from "STARTED"[2020-11-13 Fri 22:17] > > - State "DONE" from "STARTED"[2020-11-11 Wed 22:17] > > > > If I position myself in any point in this entry, when I execute the > > function it will archive the whole tree+subtree under today's date (the > > date when it was archived). > > The behaviour I was expecting is to archive each of the logged tasks > under > > their corresponding date (on the 11th, 13th, 14th and 15th of November). > > Just to be clear :) > > G > > > > El lun., 16 nov. 2020 a las 17:21, Gerardo Moro (< > gerardomor...@gmail.com>) > > escribió: > > >
Re: [PATCH] ob-java
On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri wrote: > > >> > It seems that you have changed some classloader settings in the new > >> > code. I have examples which used to work perfectly; now they still > >> > compile, but fail to run, throwing exception > >> > > >> > java.lang.NoClassDefFoundError > >> This should be fixed with 93087e0b3a. Thanks for reporting, and sorry I missed your first email. I found it. It went to spam for some reason. Also I added two sections to the doc: one that explains the current defaults and tells how to change them [1], and another that explains where source and class files go [2]. [1] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#orgb4194fe [2] https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org0948fdf
Re: Archiving repeated tasks under corresponding date tree for each repeated item
> Thanks, I don't know how to go about doing that, so I would have to rely on > others wanting to help me if they consider this to be also useful to them > (which I definitely think it is!). Try the following code. It should archive any repeated task once it is marked DONE. (defun org-archive-repeated-task (arg) "Add a copy of the recurring task marked DONE to archive." (when (and (eq (plist-get arg :type) 'todo-state-change) (string= (plist-get arg :to) "DONE")) ;; The state is changed to DONE (let* ((pos (plist-get arg :position)) (repeater (org-with-point-at pos (org-get-repeat (when repeater ;; Only consider tasks with repeater timestamp anywhere in the task body (my/org-archive-without-delete) (add-hook 'org-trigger-hook #'org-trigger-doing) Best, Ihor Gerardo Moro writes: > Thanks, I don't know how to go about doing that, so I would have to rely on > others wanting to help me if they consider this to be also useful to them > (which I definitely think it is!). > > El mar., 17 nov. 2020 a las 11:32, Ihor Radchenko () > escribió: > >> > I actually now realized that your function will not unfortunately archive >> > each logged item (those located in the logbook) in its corresponding date >> > (!). >> > What it will do is to archive the whole tree under today's date without >> > deleting it from the original org file. >> >> You are right. It is expected behaviour. That's why I suggested to run >> it in org-trigger-hook, which will trigger at the day and time when you >> mark the task DONE. >> >> Best, >> Ihor >> >> Gerardo Moro writes: >> >> > Hi again, >> > >> > I actually now realized that your function will not unfortunately archive >> > each logged item (those located in the logbook) in its corresponding date >> > (!). >> > What it will do is to archive the whole tree under today's date without >> > deleting it from the original org file. >> > >> > For instance, >> > >> > * TODO REPEATED TASK SAMPLE >> > SCHEDULED: <2020-11-30 Mon +20d> >> > :PROPERTIES: >> > :STYLE:habit >> > :LAST_REPEAT: [2020-11-09 Mon 22:28] >> > :END: >> > :LOGBOOK: >> > - State "DONE" from "TODO" [2020-11-15 Sun 22:28] >> > - State "DONE" from "STARTED"[2020-11-14 Sat 22:17] >> > - State "DONE" from "STARTED"[2020-11-13 Fri 22:17] >> > - State "DONE" from "STARTED"[2020-11-11 Wed 22:17] >> > >> > If I position myself in any point in this entry, when I execute the >> > function it will archive the whole tree+subtree under today's date (the >> > date when it was archived). >> > The behaviour I was expecting is to archive each of the logged tasks >> under >> > their corresponding date (on the 11th, 13th, 14th and 15th of November). >> > Just to be clear :) >> > G >> > >> > El lun., 16 nov. 2020 a las 17:21, Gerardo Moro (< >> gerardomor...@gmail.com>) >> > escribió: >> > >>
Re: default :results
On Sat, Nov 14, 2020 at 5:27 AM ian martins wrote: > > On Wed, Nov 11, 2020 at 3:04 AM Bastien wrote: > > > > The default for ob-shell execution was to use the output, not the > > value. Then we had a long discussion, leading to this: > > > > - The default (no :result) is to display the functional value > > > > - For some languages, it may break expectations, so in this case we > > allow a variable that let the default (no :result) use the output > > instead of the functional value. > > > > This is what is being done for ob-shell.el where we have > > `org-babel-shell-results-defaults-to-output' set to `t'. > > > > See https://orgmode.org/list/877dt5trjr@bzg.fr/ for the conclusion > > of the discussion. > > I agree with your reasoning. I already reverted the behavior, but > Instead of adding a `org-babel-java-results-defaults-to-output > variable' I set the default in `org-babel-default-header-args:java'. > It was better because it didn't add a new variable, but worse because > it isn't customizable. Should I change it? shortly after sending this I reverted another change I'd made to default behavior by setting it in `org-babel-default-header-args:java'. Another benefit of doing it here is that this variable becomes a list of ways in which a language doesn't follow normal babel default conventions, making it easy to find.
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Thanks for the prompt reply! I tried this but I get: "symbol's function definition is void: org-trigger-doing" El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko () escribió: > > Thanks, I don't know how to go about doing that, so I would have to rely > on > > others wanting to help me if they consider this to be also useful to them > > (which I definitely think it is!). > > Try the following code. It should archive any repeated task once it is > marked DONE. > > (defun org-archive-repeated-task (arg) > "Add a copy of the recurring task marked DONE to archive." > (when (and (eq (plist-get arg :type) 'todo-state-change) > (string= (plist-get arg :to) "DONE")) ;; The state is changed > to DONE > (let* ((pos (plist-get arg :position)) >(repeater (org-with-point-at pos (org-get-repeat > (when repeater ;; Only consider tasks with repeater timestamp > anywhere in the task body > (my/org-archive-without-delete) > (add-hook 'org-trigger-hook #'org-trigger-doing) > > Best, > Ihor > > Gerardo Moro writes: > > > Thanks, I don't know how to go about doing that, so I would have to rely > on > > others wanting to help me if they consider this to be also useful to them > > (which I definitely think it is!). > > > > El mar., 17 nov. 2020 a las 11:32, Ihor Radchenko () > > escribió: > > > >> > I actually now realized that your function will not unfortunately > archive > >> > each logged item (those located in the logbook) in its corresponding > date > >> > (!). > >> > What it will do is to archive the whole tree under today's date > without > >> > deleting it from the original org file. > >> > >> You are right. It is expected behaviour. That's why I suggested to run > >> it in org-trigger-hook, which will trigger at the day and time when you > >> mark the task DONE. > >> > >> Best, > >> Ihor > >> > >> Gerardo Moro writes: > >> > >> > Hi again, > >> > > >> > I actually now realized that your function will not unfortunately > archive > >> > each logged item (those located in the logbook) in its corresponding > date > >> > (!). > >> > What it will do is to archive the whole tree under today's date > without > >> > deleting it from the original org file. > >> > > >> > For instance, > >> > > >> > * TODO REPEATED TASK SAMPLE > >> > SCHEDULED: <2020-11-30 Mon +20d> > >> > :PROPERTIES: > >> > :STYLE:habit > >> > :LAST_REPEAT: [2020-11-09 Mon 22:28] > >> > :END: > >> > :LOGBOOK: > >> > - State "DONE" from "TODO" [2020-11-15 Sun 22:28] > >> > - State "DONE" from "STARTED"[2020-11-14 Sat 22:17] > >> > - State "DONE" from "STARTED"[2020-11-13 Fri 22:17] > >> > - State "DONE" from "STARTED"[2020-11-11 Wed 22:17] > >> > > >> > If I position myself in any point in this entry, when I execute the > >> > function it will archive the whole tree+subtree under today's date > (the > >> > date when it was archived). > >> > The behaviour I was expecting is to archive each of the logged tasks > >> under > >> > their corresponding date (on the 11th, 13th, 14th and 15th of > November). > >> > Just to be clear :) > >> > G > >> > > >> > El lun., 16 nov. 2020 a las 17:21, Gerardo Moro (< > >> gerardomor...@gmail.com>) > >> > escribió: > >> > > >> >
Re: Archiving repeated tasks under corresponding date tree for each repeated item
> I tried this but I get: "symbol's function definition is void: > org-trigger-doing" Oops. That's the old function name. Should be (add-hook 'org-trigger-hook #'org-archive-repeated-task) Best, Ihor Gerardo Moro writes: > Thanks for the prompt reply! > I tried this but I get: "symbol's function definition is void: > org-trigger-doing" > > El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko () > escribió: > >> > Thanks, I don't know how to go about doing that, so I would have to rely >> on >> > others wanting to help me if they consider this to be also useful to them >> > (which I definitely think it is!). >> >> Try the following code. It should archive any repeated task once it is >> marked DONE. >> >> (defun org-archive-repeated-task (arg) >> "Add a copy of the recurring task marked DONE to archive." >> (when (and (eq (plist-get arg :type) 'todo-state-change) >> (string= (plist-get arg :to) "DONE")) ;; The state is changed >> to DONE >> (let* ((pos (plist-get arg :position)) >>(repeater (org-with-point-at pos (org-get-repeat >> (when repeater ;; Only consider tasks with repeater timestamp >> anywhere in the task body >> (my/org-archive-without-delete) >> (add-hook 'org-trigger-hook #'org-trigger-doing) >> >> Best, >> Ihor >>
Re: Changed list indentation behavior: how to revert?
Tim, thanks. my tests were in a src block inside the main buffer. like you, i normally edit in an Org Src... buffer. but, it's nice when it basically "works" even in the main buffer (for minor edits, etc.). and, yes, setting org-adapt-indentation to either 'headline-data or nil seems likely to make many of us that much happier. cheers, Greg
patch to change org-adapt-indentation customization documentation
for some reason, i was motivated to look at changing
org-adapt-indentation. i found that the help text talked about values
t, 'headline-data, and nil, but that the customization text didn't
(though, of course, it *set* those values). the following might make it
clearer.
diff --git a/lisp/org.el b/lisp/org.el
index 2b50f94ee..5bb48c2fd 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1605,10 +1605,10 @@ level-dependent indentation in a virtual way, i.e. at
display
time in Emacs."
:group 'org-edit-structure
:type '(choice
- (const :tag "Adapt indentation for all lines" t)
- (const :tag "Adapt indentation for headline data lines"
+ (const :tag "(t) Adapt indentation for all lines" t)
+ (const :tag "('headline-data) Adapt indentation for headline data
lines"
'headline-data)
- (const :tag "Do not adapt indentation at all" nil))
+ (const :tag "(nil) Do not adapt indentation at all" nil))
:safe #'booleanp)
(defvaralias 'org-special-ctrl-a 'org-special-ctrl-a/e)
Re: patch to change org-adapt-indentation customization documentation
Greg Minshall writes: > for some reason, i was motivated to look at changing > org-adapt-indentation. i found that the help text talked about values > t, 'headline-data, and nil, but that the customization text didn't > (though, of course, it *set* those values). the following might make it > clearer. > The whole point of customize is that you shouldn't have to worry about what the actual lisp value is. The actual lisp value only matters if you directly set the value without using customize. Robert
Re: patch to change org-adapt-indentation customization documentation
Robert, > The whole point of customize is that you shouldn't have to worry about > what the actual lisp value is. The actual lisp value only matters if > you directly set the value without using customize. thanks for the response. i've included the documentation for org-adapt-indentation below. since the documentation talks about values and associated behaviors, it might be helpful to mention the values in the customization dialog. an alternative maybe would be to re-do the documentation to highlight the three customization phrases: "Adapt indentation for all lines" "Adapt indentation for headline data lines" "Do not adapt indentation at all" and not change the customization dialog? i, anyway, was very uncertain, even after several rounds, as to which customization option would give me the behavior i had read about in the documentation. cheers, Greg org-adapt-indentation is a variable defined in ‘org.el’. Its value is 'headline-data Original value was t This variable is safe as a file local variable if its value satisfies the predicate ‘booleanp’. You can customize this variable. Documentation: Non-nil means adapt indentation to outline node level. When this variable is set to t, Org assumes that you write outlines by indenting text in each node to align with the headline (after the stars). When this variable is set to ’headline-data, only adapt the indentation of the data lines right below the headline, such as planning/clock lines and property/logbook drawers. The following issues are influenced by this variable: - The indentation is increased by one space in a demotion command, and decreased by one in a promotion command. However, in the latter case, if shifting some line in the entry body would alter document structure (e.g., insert a new headline), indentation is not changed at all. - Property drawers and planning information is inserted indented when this variable is set. When nil, they will not be indented. - TAB indents a line relative to current level. The lines below a headline will be indented when this variable is set to t. Note that this is all about true indentation, by adding and removing space characters. See also "org-indent.el" which does level-dependent indentation in a virtual way, i.e. at display time in Emacs. [back]
Re: Changed list indentation behavior: how to revert?
Stefan Nobis writes: > "Dr. Arne Babenhauserheide" writes: > >> Sad story short:... > > I'm with you - last weekend I upgrade my OS and had quite some trouble > to get everything working again and still have some nasty hoops to > jump through. > > But on the other side: … … > I'm really surprised that such a simple and insignificant breaking > change results in such a uproar. I have seen no uproar here. Discussions here were friendly and constructive. The discusssions are long, because there aren’t easy solutions to managing changes in UX in central places. And a significant share of the discussion was about the question whether the new interaction is better or worse and whether this actually is insignificant. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
patch to add mention of org-table-transpose-table-at-point to doc
hi. this adds the minimal mention of transpose. cheers.
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 040fccc21..33d32b8f5 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -1649,6 +1649,12 @@ you, configure the option ~org-table-auto-blank-field~.
the buffer. You can activate this minor mode by default by setting
the option ~org-table-header-line-p~ to ~t~.
+- {{{kbd(M-x org-table-transpose-table-at-point)}}} ::
+
+ #+findex: org-table-header-line-mode
+ #+vindex: org-table-header-line-p
+ Transpose the table at point and eliminate hlines.
+
** Column Width and Alignment
:PROPERTIES:
:DESCRIPTION: Overrule the automatic settings.
Re: Changed list indentation behavior: how to revert?
2020-11-16 Dr. Arne Babenhauserheide wrote: I would like to agree, because I wish people would also read NEWS for my projects, but since I use at least 10-20 programs daily which depend on hundreds of libraries that might change their behavior, that’s unrealistic. I cannot read NEWS entries whenever my distro updates org-mode, therefore I depend on org-mode not breaking during updates. The problem is partially with absence of convenient interface for reviewing of updates. E.g. apt-listchanges from debian extracts news (major changes) or both news and debian changelog entries from downloaded packages before installing them. Similar GUI from ubuntu is less convenient due to it fetches changes after selecting particular entry causing delays and grouping of packages built from the same source works not well enough. P.S. Maybe I missed that, but it seems org-indent-mode (#+STARTUP: indent) has not mentioned in this long thread. There is a footnote in the manual related to hard indentation: This works, but requires extra effort. Org Indent mode is more convenient for most applications.
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Now I get the error: "wrong number of arguments..." :D El mar., 17 nov. 2020 a las 15:13, Ihor Radchenko () escribió: > > I tried this but I get: "symbol's function definition is void: > > org-trigger-doing" > > Oops. That's the old function name. Should be > > (add-hook 'org-trigger-hook #'org-archive-repeated-task) > > Best, > Ihor > > > Gerardo Moro writes: > > > Thanks for the prompt reply! > > I tried this but I get: "symbol's function definition is void: > > org-trigger-doing" > > > > El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko () > > escribió: > > > >> > Thanks, I don't know how to go about doing that, so I would have to > rely > >> on > >> > others wanting to help me if they consider this to be also useful to > them > >> > (which I definitely think it is!). > >> > >> Try the following code. It should archive any repeated task once it is > >> marked DONE. > >> > >> (defun org-archive-repeated-task (arg) > >> "Add a copy of the recurring task marked DONE to archive." > >> (when (and (eq (plist-get arg :type) 'todo-state-change) > >> (string= (plist-get arg :to) "DONE")) ;; The state is > changed > >> to DONE > >> (let* ((pos (plist-get arg :position)) > >>(repeater (org-with-point-at pos (org-get-repeat > >> (when repeater ;; Only consider tasks with repeater timestamp > >> anywhere in the task body > >> (my/org-archive-without-delete) > >> (add-hook 'org-trigger-hook #'org-trigger-doing) > >> > >> Best, > >> Ihor > >> >
Re: Archiving repeated tasks under corresponding date tree for each repeated item
> Now I get the error: "wrong number of arguments..." :D It does not happen in my Emacs. It would be helpful if you shared the whole error message. I used the following code for testing: (defun my/org-archive-without-delete () "Archive item at point, but do not actually delete it." (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil))) (org-archive-subtree))) (defun org-archive-repeated-task (arg) "Add a copy of the recurring task marked DONE to archive." (when (and (eq (plist-get arg :type) 'todo-state-change) (string= (plist-get arg :to) "DONE")) ;; The state is changed to DONE (let* ((pos (plist-get arg :position)) (repeater (org-with-point-at pos (org-get-repeat (when repeater ;; Only consider tasks with repeater timestamp anywhere in the task body (my/org-archive-without-delete) (add-hook 'org-trigger-hook #'org-archive-repeated-task) Best, Ihor Gerardo Moro writes: > Now I get the error: "wrong number of arguments..." :D > > El mar., 17 nov. 2020 a las 15:13, Ihor Radchenko () > escribió: > >> > I tried this but I get: "symbol's function definition is void: >> > org-trigger-doing" >> >> Oops. That's the old function name. Should be >> >> (add-hook 'org-trigger-hook #'org-archive-repeated-task) >> >> Best, >> Ihor >> >> >> Gerardo Moro writes: >> >> > Thanks for the prompt reply! >> > I tried this but I get: "symbol's function definition is void: >> > org-trigger-doing" >> > >> > El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko () >> > escribió: >> > >> >> > Thanks, I don't know how to go about doing that, so I would have to >> rely >> >> on >> >> > others wanting to help me if they consider this to be also useful to >> them >> >> > (which I definitely think it is!). >> >> >> >> Try the following code. It should archive any repeated task once it is >> >> marked DONE. >> >> >> >> (defun org-archive-repeated-task (arg) >> >> "Add a copy of the recurring task marked DONE to archive." >> >> (when (and (eq (plist-get arg :type) 'todo-state-change) >> >> (string= (plist-get arg :to) "DONE")) ;; The state is >> changed >> >> to DONE >> >> (let* ((pos (plist-get arg :position)) >> >>(repeater (org-with-point-at pos (org-get-repeat >> >> (when repeater ;; Only consider tasks with repeater timestamp >> >> anywhere in the task body >> >> (my/org-archive-without-delete) >> >> (add-hook 'org-trigger-hook #'org-trigger-doing) >> >> >> >> Best, >> >> Ihor >> >> >>
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Thank you! Ok, now it works. I had to restart my Emacs, probably that was the problem. So from now on, all the DONE tasks would be archived straight away on the day they are DONE. What about the previously LOGGED tasks? Is there a way to do the same with all the logged items under the :LOGBOOK: that have been DONE before? I have thousands of such instances, and I wonder if a function would find all those items inside the LOGBOOKS and archive them individually under their own DONE date in the org archive file. Maybe too much to ask! :) GM El mar., 17 nov. 2020 a las 18:00, Ihor Radchenko () escribió: > > Now I get the error: "wrong number of arguments..." :D > > It does not happen in my Emacs. It would be helpful if you shared the > whole error message. > > I used the following code for testing: > > (defun my/org-archive-without-delete () > "Archive item at point, but do not actually delete it." > (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil))) > (org-archive-subtree))) > > (defun org-archive-repeated-task (arg) > "Add a copy of the recurring task marked DONE to archive." > (when (and (eq (plist-get arg :type) 'todo-state-change) > (string= (plist-get arg :to) "DONE")) ;; The state is changed > to DONE > (let* ((pos (plist-get arg :position)) >(repeater (org-with-point-at pos (org-get-repeat > (when repeater ;; Only consider tasks with repeater timestamp > anywhere in the task body > (my/org-archive-without-delete) > > (add-hook 'org-trigger-hook #'org-archive-repeated-task) > > Best, > Ihor > > Gerardo Moro writes: > > > Now I get the error: "wrong number of arguments..." :D > > > > El mar., 17 nov. 2020 a las 15:13, Ihor Radchenko () > > escribió: > > > >> > I tried this but I get: "symbol's function definition is void: > >> > org-trigger-doing" > >> > >> Oops. That's the old function name. Should be > >> > >> (add-hook 'org-trigger-hook #'org-archive-repeated-task) > >> > >> Best, > >> Ihor > >> > >> > >> Gerardo Moro writes: > >> > >> > Thanks for the prompt reply! > >> > I tried this but I get: "symbol's function definition is void: > >> > org-trigger-doing" > >> > > >> > El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko (< > yanta...@gmail.com>) > >> > escribió: > >> > > >> >> > Thanks, I don't know how to go about doing that, so I would have to > >> rely > >> >> on > >> >> > others wanting to help me if they consider this to be also useful > to > >> them > >> >> > (which I definitely think it is!). > >> >> > >> >> Try the following code. It should archive any repeated task once it > is > >> >> marked DONE. > >> >> > >> >> (defun org-archive-repeated-task (arg) > >> >> "Add a copy of the recurring task marked DONE to archive." > >> >> (when (and (eq (plist-get arg :type) 'todo-state-change) > >> >> (string= (plist-get arg :to) "DONE")) ;; The state is > >> changed > >> >> to DONE > >> >> (let* ((pos (plist-get arg :position)) > >> >>(repeater (org-with-point-at pos (org-get-repeat > >> >> (when repeater ;; Only consider tasks with repeater timestamp > >> >> anywhere in the task body > >> >> (my/org-archive-without-delete) > >> >> (add-hook 'org-trigger-hook #'org-trigger-doing) > >> >> > >> >> Best, > >> >> Ihor > >> >> > >> >
Re: Changed list indentation behavior: how to revert?
"Dr. Arne Babenhauserheide" writes: > I have seen no uproar here. Discussions here were friendly and > constructive. The discusssions are long, because there aren’t easy > solutions to managing changes in UX in central places. > > And a significant share of the discussion was about the question whether > the new interaction is better or worse and whether this actually is > insignificant. Iʼll add my 0.02€ and say that I donʼt know if this change affected me, since Iʼm lazy enough that I always do C-RET to start a new headline, as it frees me from having to worry about the number of stars to add. Robert
[PATCH] Remove redundant 'function's around lambda
I've been working on removing redundant `function' around `lambda' in Emacs core, so here is a patch which does the same for Org-mode. Note that Info node `(elisp) Anonymous Functions' says that: The read syntax ‘#'’ is a short-hand for using ‘function’. The following forms are all equivalent: (lambda (x) (* x x)) (function (lambda (x) (* x x))) #'(lambda (x) (* x x)) IOW, we can safely remove the wrapped `function' form. Please see the attached. (My copyright assignment is on file.) From 7604ccc02a60334ef5c2135c5fb3abae4bed2468 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Tue, 17 Nov 2020 17:35:49 +0100 Subject: [PATCH] Remove redundant 'function's around lambda * contrib/lisp/org-secretary.el (join): * contrib/lisp/ox-taskjuggler.el (org-taskjuggler-project-plan): * lisp/org-clock.el (org-resolve-clocks): * lisp/org-element.el (org-element--interpret-affiliated-keywords): * lisp/org-list.el (org-list-struct, org-list-get-item-number) (org-list-separating-blank-lines-number) (org-list-struct-fix-bul, org-list-struct-apply-struct): * lisp/org.el (org-agenda-files, org-toggle-heading): * lisp/ox-ascii.el (org-ascii-table-row): * lisp/ox-beamer.el (org-beamer--format-section) (org-beamer-template): * lisp/ox-odt.el (org-odt--image-size) (org-odt--render-image/formula): * testing/org-batch-test-init.el (load-path): Remove redundant 'function's around lambda. --- contrib/lisp/org-secretary.el | 2 +- contrib/lisp/ox-taskjuggler.el | 5 +- lisp/org-clock.el | 13 +- lisp/org-element.el| 25 ++- lisp/org-list.el | 326 - lisp/org.el| 22 +-- lisp/ox-ascii.el | 53 +++--- lisp/ox-beamer.el | 32 ++-- lisp/ox-odt.el | 25 ++- testing/org-batch-test-init.el | 6 +- 10 files changed, 246 insertions(+), 263 deletions(-) diff --git a/contrib/lisp/org-secretary.el b/contrib/lisp/org-secretary.el index babfb7539..654fcc1a0 100644 --- a/contrib/lisp/org-secretary.el +++ b/contrib/lisp/org-secretary.el @@ -177,7 +177,7 @@ (global-set-key "\C-cj" 'org-sec-tag-entry) (defun join (lst sep &optional pre post) - (mapconcat (function (lambda (x) (concat pre x post))) lst sep)) + (mapconcat (lambda (x) (concat pre x post)) lst sep)) (defun org-sec-get-with () (if org-sec-with diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 8c43b0629..93088144c 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -720,9 +720,8 @@ Return complete project plan as a string in TaskJuggler syntax." (mapconcat 'org-element-normalize-string (mapcar - (function - (lambda (report) - (replace-regexp-in-string "%title" report-title report t t))) + (lambda (report) + (replace-regexp-in-string "%title" report-title report t t)) org-taskjuggler-default-reports) "") (defun org-taskjuggler--build-project (project info) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 9efd99be8..6c7a797ff 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1164,13 +1164,12 @@ If `only-dangling-p' is non-nil, only ask to resolve dangling (org-clock-resolve clock (or prompt-fn - (function - (lambda (clock) - (format - "Dangling clock started %d mins ago" - (floor (org-time-convert-to-integer - (org-time-since (cdr clock))) - 60) + (lambda (clock) + (format + "Dangling clock started %d mins ago" + (floor (org-time-convert-to-integer + (org-time-since (cdr clock))) + 60 (or last-valid (cdr clock))) diff --git a/lisp/org-element.el b/lisp/org-element.el index 2ad557d21..a2582b822 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -4655,19 +4655,18 @@ to interpret. Return Org syntax as a string." "Return ELEMENT's affiliated keywords as Org syntax. If there is no affiliated keyword, return the empty string." (let ((keyword-to-org - (function - (lambda (key value) - (let (dual) - (when (member key org-element-dual-keywords) - (setq dual (cdr value) value (car value))) - (concat "#+" (downcase key) - (and dual - (format "[%s]" (org-element-interpret-data dual))) - ": " - (if (member key org-element-parsed-keywords) - (org-element-interpret-data value) - value) - "\n")) + (lambda (key value) + (let (dual) + (when (member key org-element-dual-keywords) + (setq dual (cdr value) value (car value))) + (concat "#+" (downcase key) + (and dual + (format "[%s]" (org-element-interpret-data dual))) + ": " + (if (member key org-element-parsed-keywords) + (org-element-interpret-data value) + value) + "\n") (mapconcat (lambda (prop) (let ((v
Ignored bugs
A little over a month ago, I submitted several bug reports related to org-mode, and sor most of them haven't seen any action whatsoever, not even an indication that they were noticed. In many cases, I provided either a total solution or a suggested implementation of a solution. BUG REPORT: 42484 + This is of particular concern to me because when it was submitted it was summarily closed AND ANRCHIVED. When I complained, it was unarchived so that I could provide a solution and patch of my own, but it has since been archived AGAIN, so I can't submit an updated patch. Further, it was never removed from the closed state, so it could easily be overlooked. (Do I need to explicitly complain that this is awful management behavior?) So, I have an updated patch that I tried to submit a few minutes ago that was bounced because the thread is in read-only archived state. BUG REPORT: 43954 BUG REPORT: 43955 + code included BUG REPORT: 44133 + code included -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: Ignored bugs
On 17/11/2020 19:41, Boruch Baum wrote: > A little over a month ago, I submitted several bug reports related to > org-mode, and sor most of them haven't seen any action whatsoever, not > even an indication that they were noticed. In many cases, I provided > either a total solution or a suggested implementation of a solution. > > BUG REPORT: 42484 I haven't investigated further than reading this email, but the fact that you are including what look like debbug numbers suggests that you reported those bugs against Emacs. Org is mostly developed outside Emacs and has an independent release cycle. Emacs syncs irregularly with the latest released version of Org. Bug report affecting the latest release of Org can be submitted to this mailing list. This is also the best way to make them known to the Org developers and maintainer. I don't think anyone here really looks into bugs reported to the Emacs debbugs instance: time is limited and the version of Org distributed with Emacs is very often not the most current one, thus the bug reports may anyhow not be relevant anyhow. I suggest you to try to reproduce these bugs with the latest Org release (or the latest snapshot from Org ELPA) and report on this list if the problems persist, see `org-submit-bug-report'. Please complain with the Emacs maintainers about their handling of the bugs on the Emacs bug tracking system, I don't think it a discussion relevant to this mailing list. Cheers, Dan
Re: Ignored bugs
On 2020-11-17 20:51, Daniele Nicolodi wrote: > Please complain with the Emacs maintainers about their handling of the > bugs on the Emacs bug tracking system, How do I know it was "their handling" and not "your handling"? It's unclear from my view of the thread who performed the actions but all the other actions on that thread were from a fellow called "Bastien" - is he one of "theirs" or one of "yours" (or both)? In any event, it should be of concern to people on this list to make contributing to org-mode as open and hurdle-free as possible instead of piling on supplemental demands / requirements. As a case study, you can review the submissions that I referenced and the elisp content there that seems would have gone lost had I not taken the extra steps of engaging on this list. Who knows how many other contributions and contributors you've "lost" this way... -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: Ignored bugs
On 17/11/2020 21:15, Boruch Baum wrote: > On 2020-11-17 20:51, Daniele Nicolodi wrote: >> Please complain with the Emacs maintainers about their handling of the >> bugs on the Emacs bug tracking system, > > How do I know it was "their handling" and not "your handling"? It's > unclear from my view of the thread who performed the actions but all the > other actions on that thread were from a fellow called "Bastien" - is he > one of "theirs" or one of "yours" (or both)? > > In any event, it should be of concern to people on this list to make > contributing to org-mode as open and hurdle-free as possible instead of > piling on supplemental demands / requirements. As a case study, you > can review the submissions that I referenced and the elisp content there > that seems would have gone lost had I not taken the extra steps of > engaging on this list. Who knows how many other contributions and > contributors you've "lost" this way... The page that introduces the Emacs bug tracker already reports that this mailing list is the right place where to report Org bugs (or feature request, as is the case for at least one of the bug you reported), and not the Emacs bug tracker. I went and read the exchange on bug #42484 and already Bastien told you that this mailing list is the right place where to report bugs and submit patches. You are deliberately ignoring these instructions. What do you expect? Would you like to elaborate on why making it easy for you to contribute something to org-mode that solves your problems should be of concerns to the people of this list, especialy if this comes at extra cost to them? Cheers, Dan
Re: Ignored bugs
On 2020-11-17 21:27, Daniele Nicolodi wrote: > The page that introduces the Emacs bug tracker already reports that this > ... The way emacs users behave isn't to go search and find and read that web page. It's to perform M-x report-emacs-bug. For people using a command completion program, while they type they see similar alternatives but org-mode has gone its own way also in its naming convention for report-*-bug so its 'submit' function would not appear (nor c nor ffap). > mailing list is the right place where to report Org bugs (or feature > request, as is the case for at least one of the bug you reported), and > not the Emacs bug tracker. That cuts off anyone not wanting to be a subscriber to your mailing list / not wanting all the clutter of all the other conversations and threads of your mailing list (I certainly don't). That imposes upon them the burden of taking the steps to apply to join the list, confirm, post, and then unsubscribe any time they want to make a contribution or submit a report. But, let's try out your suggested method of reporting. Here I am on your mailing list, reporting that function org-submit-bug-report should either be renamed or aliased to something more consistent with function report-emacs-bug, possibly report-emacs-org-bug. > I went and read the exchange on bug #42484 and already Bastien told you > that this mailing list is the right place where to report bugs and > submit patches. Lost that, as probably have others. Ultimately, it's your choice to make your eco-system friendly or not, convenient or not, considerate or not. > You are deliberately ignoring these instructions. What do you expect? For one, I expect you to not unjustly impute to me motive, and not to take that 'what do you expect' attitude with me (or with anyone else). > Would you like to elaborate on why making it easy for you to contribute > something to org-mode that solves your problems should be of concerns to > the people of this list, especialy if this comes at extra cost to them? That is such a classic and revealing paragraph you wrote about yourself! Maybe paste it on your bathroom mirror and read over every once in a while. Maybe publicize that paragraph as a policy document for the project? > Cheers, Not. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Re: Ignored bugs
* Boruch Baum [2020-11-17 23:57]: > On 2020-11-17 21:27, Daniele Nicolodi wrote: > > The page that introduces the Emacs bug tracker already reports that this > > ... > > The way emacs users behave isn't to go search and find and read that web > page. It's to perform M-x report-emacs-bug. For people using a command > completion program, while they type they see similar alternatives but > org-mode has gone its own way also in its naming convention for > report-*-bug so its 'submit' function would not appear (nor c nor ffap). > > > mailing list is the right place where to report Org bugs (or feature > > request, as is the case for at least one of the bug you reported), and > > not the Emacs bug tracker. > > That cuts off anyone not wanting to be a subscriber to your mailing list > / not wanting all the clutter of all the other conversations and threads > of your mailing list (I certainly don't). That imposes upon them the > burden of taking the steps to apply to join the list, confirm, post, and > then unsubscribe any time they want to make a contribution or submit a > report. As Org is part of Emacs one has to understand Boruch's point as valid. This means it is part of Emacs and M-x report-emacs-bug should not be ignored. Managers of the mailing list or Org developers could make sure to read those bug reports as well. A cron job to grep report for Org bugs can help there. It is quite clear when user finds out about M-x org-submit-bug-report that such will rather use that. But there is plethora of users who may not find that option and they will simply reach to Help menu to submit the bug. There is menu item Org and Submit bug report. But user may not find that menu item as first thing to reach could be simply "Help" and submit bug report. > But, let's try out your suggested method of reporting. Here I am on your > mailing list, reporting that function org-submit-bug-report should > either be renamed or aliased to something more consistent with function > report-emacs-bug, possibly report-emacs-org-bug. I may join and say I support that alignment with the other function. Personally as Org is part of Emacs, I think it should not have special bug reporting, but it should rather be in M-x report-emacs-bug together. I say this as I see that bugs sent to mailing list may not have its proper action cycles, or proper tracking. But I am unsure of it. You could develop the function report-emacs-bug to have users say clearly it is Org bug. One could detect if user is invoking report-emacs-bug from Org mode and only then ask user "Is this Org mode bug?" and provide that little different instructions for Org mode. As if that it not acceptable I would then propose these functions: M-x report-org-bug and M-x report-emacs-bug As those are more aligned to each other or just as Boruch said. > > You are deliberately ignoring these instructions. What do you expect? > > For one, I expect you to not unjustly impute to me motive, and not to > take that 'what do you expect' attitude with me (or with anyone else). It is good to be considerate for reason that we should be, and to consider good faith especially by those reporting bugs. GNU Kind Communications Guidelines https://www.gnu.org/philosophy/kind-communication.html
Re: Ignored bugs
Jean Louis writes: > > As Org is part of Emacs one has to understand Boruch's point as > valid. This means it is part of Emacs and M-x report-emacs-bug should > not be ignored. Managers of the mailing list or Org developers could > make sure to read those bug reports as well. A cron job to grep report > for Org bugs can help there. > > It is quite clear when user finds out about M-x org-submit-bug-report > that such will rather use that. But there is plethora of users who may > not find that option and they will simply reach to Help menu to submit > the bug. > > There is menu item Org and Submit bug report. But user may not find > that menu item as first thing to reach could be simply "Help" and > submit bug report. > > > I may join and say I support that alignment with the other function. > > Personally as Org is part of Emacs, I think it should not have special > bug reporting, but it should rather be in M-x report-emacs-bug > together. I say this as I see that bugs sent to mailing list may not > have its proper action cycles, or proper tracking. But I am unsure of > it. You could develop the function report-emacs-bug to have users say > clearly it is Org bug. > > One could detect if user is invoking report-emacs-bug from Org mode > and only then ask user "Is this Org mode bug?" and provide that little > different instructions for Org mode. > > As if that it not acceptable I would then propose these functions: > > M-x report-org-bug > > and > > M-x report-emacs-bug > > As those are more aligned to each other or just as Boruch said. > I agree the bug submission functionality for Emacs needs revision. This is something which really needs to be taken up on the emacs devel list. It isn't just org-mode that is faced with this challenge. As Emacs moves towards greater reliance on ELPA packages and with the addition of the Non-GNU ELPA repository, this situation is only going to get worse. M-x report-emacs-bug comes from a time when the majority of code was in Emacs and any which was not was installed manually by the user. It was clear to the user what was core and what they had installed. However, things have moved on now. It isn't a clear to users anymore what is core emacs and what is not - for them, it is all emacs. For example, I have over 370 additional ELPA based packages in my configuration. Many are from repositories other than the official GNU ELPA repository and have a wide variety of approaches for issue tracking. I'm not sure that existing M-x submit-emacs-bug is actually up to the task or if even the Emacs bug tracker is. I suspect the current tracker receives bugs for many packages which are from repositories like melpa. How are Emacs developers supposed to manage such bugs (they don't necessarily know where that package tracks issues or how to pass those issues on etc). Things become even more complicated when it comes to org as there are effectively two distinct user bases. You have those org users who just use the version of org which is bundled with Emacs and those who prefer to use the current release from org (either via the org repository or MELPA). Essentially, org has to maintain two versions and bugs reported in one version may not exist in the other (or more likely, have been fixed in the older). This is a very complex issue with many moving parts. Improvements are likely to be incremental in small steps. I do think we need to fix some information that is out there. When you google org-mode bug tracking, you get the following link https://orgmode.org/worg/org-issues.html The information on that page is completely out of date. The link to the bug tracking RSS feed gives a 504 error, the list of old issues are for 2013. This page should probably be removed or replaced with more current information. I'm assuming all org bugs are tracked in the Emacs bug tracker? All org bugs should be tracked in a single repository. While submitting bugs via this list is probably OK, there does need to be (and probably is?) a mechanism to ensure they are also added to 'the' bug tracker. We need to support those 'good' citizens who first try to determine if a bug is known and then add to it rather than create another issue which is just a repeat of a known issue. Likewise, we don't want people donating valuable time resources working on a bug which has already been resolved (particularly likely when you have two maintained versions). -- Tim Cross
Re: Ignored bugs
Daniele Nicolodi writes: > On 17/11/2020 19:41, Boruch Baum wrote: >> A little over a month ago, I submitted several bug reports related to >> org-mode, and sor most of them haven't seen any action whatsoever, not >> even an indication that they were noticed. In many cases, I provided >> either a total solution or a suggested implementation of a solution. >> >> BUG REPORT: 42484 > > I haven't investigated further than reading this email, but the fact > that you are including what look like debbug numbers suggests that you > reported those bugs against Emacs. > > Org is mostly developed outside Emacs and has an independent release > cycle. Emacs syncs irregularly with the latest released version of Org. I was completely unaware of this. I also used to report bugs via emacs' report-emacs-bug fascility. Moreover, I am building emacs from `master' everyday and assuming everything is latest on this. If Org is a different beast then probably we should do two things: 1. Remove Org from built-in packages and distribute only via ELPA 2. And have a completely separate infrastructure for development, mailing-lists, bug reports. This we already have. But we should follow convention so that it is easier for user to report-org-bugs. > Bug report affecting the latest release of Org can be submitted to this > mailing list. This is also the best way to make them known to the Org > developers and maintainer. I don't know how the tracking works if bugs are reported in a mailing list. > I don't think anyone here really looks into > bugs reported to the Emacs debbugs instance: time is limited and the > version of Org distributed with Emacs is very often not the most current > one, thus the bug reports may anyhow not be relevant anyhow. > > I suggest you to try to reproduce these bugs with the latest Org release > (or the latest snapshot from Org ELPA) and report on this list if the > problems persist, see `org-submit-bug-report'. I am trying to use `use-package' for package management via the init file. And when I do (use-package org :ensure t) it doesn't install the latest. It uses the builtin package only. Is this a bug in emacs, use-package or elpa?
Re: Ignored bugs
Pankaj Jangid writes:
> Daniele Nicolodi writes:
>
>> On 17/11/2020 19:41, Boruch Baum wrote:
>>> A little over a month ago, I submitted several bug reports related to
>>> org-mode, and sor most of them haven't seen any action whatsoever, not
>>> even an indication that they were noticed. In many cases, I provided
>>> either a total solution or a suggested implementation of a solution.
>>>
>>> BUG REPORT: 42484
>>
>> I haven't investigated further than reading this email, but the fact
>> that you are including what look like debbug numbers suggests that you
>> reported those bugs against Emacs.
>>
>> Org is mostly developed outside Emacs and has an independent release
>> cycle. Emacs syncs irregularly with the latest released version of Org.
>
> I was completely unaware of this. I also used to report bugs via emacs'
> report-emacs-bug fascility.
>
> Moreover, I am building emacs from `master' everyday and assuming
> everything is latest on this. If Org is a different beast then probably
> we should do two things:
>
> 1. Remove Org from built-in packages and distribute only via ELPA
>
> 2. And have a completely separate infrastructure for development,
> mailing-lists, bug reports. This we already have. But we should follow
> convention so that it is easier for user to report-org-bugs.
>
Org mode is now an official part of Emacs, so that boat has sailed.
If we wanted to have only one official version, it would have to be the
one bundled with Emacs (or in the ELPA repository I think?). However,
that would also slow down the releases to fit with the GNU Emacs release
policy. When I last built Emacs 28 (9th Nov), org was still at 9.3.
Latest version taken from org repository is 9.4
While org development is on-going, most of the changes are refinements
rather than new features. For most people, there will be little
functional difference between 9.3 and 9.4. I started using the org repo
version ages ago, when there were features in the latest version not in
the bundled version. If I was starting again from now, I would be
tempted to stick with the built-in version and prioritise stability over
bleeding edge.
>> Bug report affecting the latest release of Org can be submitted to this
>> mailing list. This is also the best way to make them known to the Org
>> developers and maintainer.
>
> I don't know how the tracking works if bugs are reported in a mailing
> list.
>
>> I don't think anyone here really looks into
>> bugs reported to the Emacs debbugs instance: time is limited and the
>> version of Org distributed with Emacs is very often not the most current
>> one, thus the bug reports may anyhow not be relevant anyhow.
>>
>> I suggest you to try to reproduce these bugs with the latest Org release
>> (or the latest snapshot from Org ELPA) and report on this list if the
>> problems persist, see `org-submit-bug-report'.
>
> I am trying to use `use-package' for package management via the init
> file. And when I do (use-package org :ensure t) it doesn't install the
> latest. It uses the builtin package only. Is this a bug in emacs,
> use-package or elpa?
Not a bug at all. You have to configure your emacs to obtain the latest
version from the org (or MELPA?) repository.
If you really want the most recent org version, you need to add the org
ELPA repository to your packages.el repository list. I have the
following in my setup -
(add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/";))
(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/";))
If you also want to get the org-plus-contrib version and your using
'use-package', you need something like
(use-package org
:ensure org-plus-contrib
)
because the package is 'org' but is in org-plus-contrib (there is also
just an 'org' package that does not include all the contrib libs).
Note that it is CRITICAL that the code to load the org package is run
*before* any org functionality is loaded. If you fail to do this, you
will end up with a mixed (and broken) environment where some of the
version bundled with emacs is loaded and some which is part of the newer
version is loaded. Provided nothing has loaded any org stuff before the
use-package stanza for org is run, everything will be OK. For this
reason, it is good to load the package early (first) in case other
packages you load try to load org etc).
--
Tim Cross
Re: Ignored bugs
> As if that it not acceptable I would then propose these functions: > > M-x report-org-bug > > and > > M-x report-emacs-bug This issue has been discussed in the past in this maillist as well as in the emacs-devel: https://orgmode.org/list/87zhfntkwm@gmail.com/ https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00011.html I think making the alias you proposed was in Bastein's todo-list, according to that earlier discussion. I guess, there should be no issue accepting relevant patches here (not sure about emacs-devel) if you provide them. Best, Ihor Jean Louis writes: > * Boruch Baum [2020-11-17 23:57]: >> On 2020-11-17 21:27, Daniele Nicolodi wrote: >> > The page that introduces the Emacs bug tracker already reports that this >> > ... >> >> The way emacs users behave isn't to go search and find and read that web >> page. It's to perform M-x report-emacs-bug. For people using a command >> completion program, while they type they see similar alternatives but >> org-mode has gone its own way also in its naming convention for >> report-*-bug so its 'submit' function would not appear (nor c nor ffap). >> >> > mailing list is the right place where to report Org bugs (or feature >> > request, as is the case for at least one of the bug you reported), and >> > not the Emacs bug tracker. >> >> That cuts off anyone not wanting to be a subscriber to your mailing list >> / not wanting all the clutter of all the other conversations and threads >> of your mailing list (I certainly don't). That imposes upon them the >> burden of taking the steps to apply to join the list, confirm, post, and >> then unsubscribe any time they want to make a contribution or submit a >> report. > > As Org is part of Emacs one has to understand Boruch's point as > valid. This means it is part of Emacs and M-x report-emacs-bug should > not be ignored. Managers of the mailing list or Org developers could > make sure to read those bug reports as well. A cron job to grep report > for Org bugs can help there. > > It is quite clear when user finds out about M-x org-submit-bug-report > that such will rather use that. But there is plethora of users who may > not find that option and they will simply reach to Help menu to submit > the bug. > > There is menu item Org and Submit bug report. But user may not find > that menu item as first thing to reach could be simply "Help" and > submit bug report. > >> But, let's try out your suggested method of reporting. Here I am on your >> mailing list, reporting that function org-submit-bug-report should >> either be renamed or aliased to something more consistent with function >> report-emacs-bug, possibly report-emacs-org-bug. > > I may join and say I support that alignment with the other function. > > Personally as Org is part of Emacs, I think it should not have special > bug reporting, but it should rather be in M-x report-emacs-bug > together. I say this as I see that bugs sent to mailing list may not > have its proper action cycles, or proper tracking. But I am unsure of > it. You could develop the function report-emacs-bug to have users say > clearly it is Org bug. > > One could detect if user is invoking report-emacs-bug from Org mode > and only then ask user "Is this Org mode bug?" and provide that little > different instructions for Org mode. > > As if that it not acceptable I would then propose these functions: > > M-x report-org-bug > > and > > M-x report-emacs-bug > > As those are more aligned to each other or just as Boruch said. > >> > You are deliberately ignoring these instructions. What do you expect? >> >> For one, I expect you to not unjustly impute to me motive, and not to >> take that 'what do you expect' attitude with me (or with anyone else). > > It is good to be considerate for reason that we should be, and to > consider good faith especially by those reporting bugs. > > GNU Kind Communications Guidelines > https://www.gnu.org/philosophy/kind-communication.html
Re: Archiving repeated tasks under corresponding date tree for each repeated item
> So from now on, all the DONE tasks would be archived straight away on the > day they are DONE. Not all the tasks, but all the tasks with repeater. > Is there a way to do the same with all the logged items under the :LOGBOOK: > that have been DONE before? It is certainly possible, but require more complicated function. Best, Ihor Gerardo Moro writes: > Thank you! Ok, now it works. I had to restart my Emacs, probably that was > the problem. > > So from now on, all the DONE tasks would be archived straight away on the > day they are DONE. What about the previously LOGGED tasks? > Is there a way to do the same with all the logged items under the :LOGBOOK: > that have been DONE before? > > I have thousands of such instances, and I wonder if a function would find > all those items inside the LOGBOOKS and archive them individually under > their own DONE date in the org archive file. Maybe too much to ask! :) > GM > > > El mar., 17 nov. 2020 a las 18:00, Ihor Radchenko () > escribió: > >> > Now I get the error: "wrong number of arguments..." :D >> >> It does not happen in my Emacs. It would be helpful if you shared the >> whole error message. >> >> I used the following code for testing: >> >> (defun my/org-archive-without-delete () >> "Archive item at point, but do not actually delete it." >> (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil))) >> (org-archive-subtree))) >> >> (defun org-archive-repeated-task (arg) >> "Add a copy of the recurring task marked DONE to archive." >> (when (and (eq (plist-get arg :type) 'todo-state-change) >> (string= (plist-get arg :to) "DONE")) ;; The state is changed >> to DONE >> (let* ((pos (plist-get arg :position)) >>(repeater (org-with-point-at pos (org-get-repeat >> (when repeater ;; Only consider tasks with repeater timestamp >> anywhere in the task body >> (my/org-archive-without-delete) >> >> (add-hook 'org-trigger-hook #'org-archive-repeated-task) >> >> Best, >> Ihor >> >> Gerardo Moro writes: >> >> > Now I get the error: "wrong number of arguments..." :D >> > >> > El mar., 17 nov. 2020 a las 15:13, Ihor Radchenko () >> > escribió: >> > >> >> > I tried this but I get: "symbol's function definition is void: >> >> > org-trigger-doing" >> >> >> >> Oops. That's the old function name. Should be >> >> >> >> (add-hook 'org-trigger-hook #'org-archive-repeated-task) >> >> >> >> Best, >> >> Ihor >> >> >> >> >> >> Gerardo Moro writes: >> >> >> >> > Thanks for the prompt reply! >> >> > I tried this but I get: "symbol's function definition is void: >> >> > org-trigger-doing" >> >> > >> >> > El mar., 17 nov. 2020 a las 14:32, Ihor Radchenko (< >> yanta...@gmail.com>) >> >> > escribió: >> >> > >> >> >> > Thanks, I don't know how to go about doing that, so I would have to >> >> rely >> >> >> on >> >> >> > others wanting to help me if they consider this to be also useful >> to >> >> them >> >> >> > (which I definitely think it is!). >> >> >> >> >> >> Try the following code. It should archive any repeated task once it >> is >> >> >> marked DONE. >> >> >> >> >> >> (defun org-archive-repeated-task (arg) >> >> >> "Add a copy of the recurring task marked DONE to archive." >> >> >> (when (and (eq (plist-get arg :type) 'todo-state-change) >> >> >> (string= (plist-get arg :to) "DONE")) ;; The state is >> >> changed >> >> >> to DONE >> >> >> (let* ((pos (plist-get arg :position)) >> >> >>(repeater (org-with-point-at pos (org-get-repeat >> >> >> (when repeater ;; Only consider tasks with repeater timestamp >> >> >> anywhere in the task body >> >> >> (my/org-archive-without-delete) >> >> >> (add-hook 'org-trigger-hook #'org-trigger-doing) >> >> >> >> >> >> Best, >> >> >> Ihor >> >> >> >> >> >>
Re: Ignored bugs
* Pankaj Jangid [2020-11-18 05:51]: > Daniele Nicolodi writes: > > > On 17/11/2020 19:41, Boruch Baum wrote: > >> A little over a month ago, I submitted several bug reports related to > >> org-mode, and sor most of them haven't seen any action whatsoever, not > >> even an indication that they were noticed. In many cases, I provided > >> either a total solution or a suggested implementation of a solution. > >> > >> BUG REPORT: 42484 > > > > I haven't investigated further than reading this email, but the fact > > that you are including what look like debbug numbers suggests that you > > reported those bugs against Emacs. > > > > Org is mostly developed outside Emacs and has an independent release > > cycle. Emacs syncs irregularly with the latest released version of Org. > > I was completely unaware of this. I also used to report bugs via emacs' > report-emacs-bug fascility. > > Moreover, I am building emacs from `master' everyday and assuming > everything is latest on this. If Org is a different beast then probably > we should do two things: > > 1. Remove Org from built-in packages and distribute only via ELPA No, please that would be detrimental. Please note how many users use Org who do not have Internet or possibility to update Org. Don't forget that Emacs run on multi user computers. Please see example here of who is using Debian GNU/Linux: https://www.debian.org/users/ I hope you may see many educational institutions and understand that not every computer may be connected to Internet but many will be used by multiple users. > 2. And have a completely separate infrastructure for development, > mailing-lists, bug reports. This we already have. But we should follow > convention so that it is easier for user to report-org-bugs. As long as M-x report-emacs-bug is watched out for Org mode and handled properly and users nicely and considerately transitioned to Org mailing list (warmly welcomed), there is no serious problem there. > > I don't think anyone here really looks into bugs reported to the > > Emacs debbugs instance: time is limited and the version of Org > > distributed with Emacs is very often not the most current one, > > thus the bug reports may anyhow not be relevant anyhow. Those who do not have time, do not have. There are those who do have time and who will help users.
Re: Ignored bugs
Tim Cross writes:
>> I am trying to use `use-package' for package management via the init
>> file. And when I do (use-package org :ensure t) it doesn't install the
>> latest. It uses the builtin package only. Is this a bug in emacs,
>> use-package or elpa?
>
> Not a bug at all. You have to configure your emacs to obtain the latest
> version from the org (or MELPA?) repository.
>
> If you really want the most recent org version, you need to add the org
> ELPA repository to your packages.el repository list. I have the
> following in my setup -
>
> (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/";))
> (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/";))
Okay. I don't have org-elpa in my list. But Org 9.4 is visible in the
`gnu' archive. I have this in my configuration
(custom-set-variables
'(package-archives '(("melpa" . "https://melpa.org/packages/";)
("gnu" . "https://elpa.gnu.org/packages/";
When I install it manually via package-install it gets installed. But
(use-package org :ensure t) doesn't install it. Probably the order is
affecting it.
Re: Ignored bugs
Jean Louis writes: >> I was completely unaware of this. I also used to report bugs via >> emacs' report-emacs-bug fascility. >> >> Moreover, I am building emacs from `master' everyday and assuming >> everything is latest on this. If Org is a different beast then >> probably we should do two things: >> >> 1. Remove Org from built-in packages and distribute only via ELPA > > No, please that would be detrimental. Please note how many users use > Org who do not have Internet or possibility to update Org. Don't > forget that Emacs run on multi user computers. > > Please see example here of who is using Debian GNU/Linux: > https://www.debian.org/users/ > > I hope you may see many educational institutions and understand that > not every computer may be connected to Internet but many will be used > by multiple users. I completely agree with you. It is important to ship Org along with Emacs. I was replying to the thought process that insists that org cannot follow the emacs process. Which was kind of a setback to me. >> > I don't think anyone here really looks into bugs reported to the >> > Emacs debbugs instance: time is limited and the version of Org >> > distributed with Emacs is very often not the most current one, thus >> > the bug reports may anyhow not be relevant anyhow. > > Those who do not have time, do not have. > > There are those who do have time and who will help users. Yes. This one. Like it.
Re: Ignored bugs
* Pankaj Jangid [2020-11-18 09:47]:
> Tim Cross writes:
>
> >> I am trying to use `use-package' for package management via the init
> >> file. And when I do (use-package org :ensure t) it doesn't install the
> >> latest. It uses the builtin package only. Is this a bug in emacs,
> >> use-package or elpa?
> >
> > Not a bug at all. You have to configure your emacs to obtain the latest
> > version from the org (or MELPA?) repository.
> >
> > If you really want the most recent org version, you need to add the org
> > ELPA repository to your packages.el repository list. I have the
> > following in my setup -
> >
> > (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/";))
> > (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/";))
>
> Okay. I don't have org-elpa in my list. But Org 9.4 is visible in the
> `gnu' archive. I have this in my configuration
>
> (custom-set-variables
> '(package-archives '(("melpa" . "https://melpa.org/packages/";)
> ("gnu" . "https://elpa.gnu.org/packages/";
>
> When I install it manually via package-install it gets installed. But
> (use-package org :ensure t) doesn't install it. Probably the order is
> affecting it.
You may try by using Org ELPA:
("org" . "https://orgmode.org/elpa/";)
Re: Ignored bugs
Pankaj Jangid writes:
> Tim Cross writes:
>
>>> I am trying to use `use-package' for package management via the init
>>> file. And when I do (use-package org :ensure t) it doesn't install the
>>> latest. It uses the builtin package only. Is this a bug in emacs,
>>> use-package or elpa?
>>
>> Not a bug at all. You have to configure your emacs to obtain the latest
>> version from the org (or MELPA?) repository.
>>
>> If you really want the most recent org version, you need to add the org
>> ELPA repository to your packages.el repository list. I have the
>> following in my setup -
>>
>> (add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/";))
>> (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/";))
>
> Okay. I don't have org-elpa in my list. But Org 9.4 is visible in the
> `gnu' archive. I have this in my configuration
>
> (custom-set-variables
> '(package-archives '(("melpa" . "https://melpa.org/packages/";)
> ("gnu" . "https://elpa.gnu.org/packages/";
>
> When I install it manually via package-install it gets installed. But
> (use-package org :ensure t) doesn't install it. Probably the order is
> affecting it.
Have a look at the package.el docs. You can 'pin' a package to a
specific repository and version and you can set repository priorities. I
would also check to see when the custom section is actually loaded. It
could be that your customization is not loaded until after your call to
use-package. As I call add-to-lis and that adds entries to the start of
the list, I know both melpa and the org repositories are before the gnu
one and as I do this in my init file, I know it is processed before the
call to use-package, but I also set repository priorities to help
protect against reliance on order in the list.
My full package config is below. Note that things changed in Emacs 27
and I'm not 100% sure it is correct (actually, I recently switched to
using spacemacs, so I don't use that setup anymore!)
#+begin_src emacs-lisp :tangle tangle-init.el
(require 'package)
(setq package-enable-at-startup nil
package-archive-priorities '(("org" . 2) ("melpa" . 1) ("gnu" . 0)))
(add-to-list 'package-archives `("melpa" . "https://melpa.org/packages/";))
(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/";))
(when (< emacs-major-version 27)
(package-initialize))
#+end_src
--
Tim Cross
