Re: [O] New feature? Remove duplicate subheadings, preserving order
On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter wrote: > Allen Li writes: > >> I don’t know if a more intelligent way of handling tags and todo >> keywords is worth the extra complexity, but in the use case that I >> imagine it makes sense to match using only the heading/list item: >> >> * Things to buy >> ** TODO cabbage >> ** DONE milk :store1: >>Maybe I forgot a tag here. Oh well, I already bought the milk. >> ** TODO carrots >> ** TODO milk :store1:store2: >> >> ... >> >> It doesn’t make sense to include the contents because I see this as >> primarily being useful for list items. In particular, we would want >> to ignore log entries and properties for the sake of matching >> (intelligent property or logbook merging might be useful, but adds >> complexity). > > I think such a command should check all heading data by default, > because that's the safest option. A user who commonly needs to ignore > one or more types of data could use a custom function that calls the > command with arguments to disable checking of certain types. I don’t see a use case for checking all heading data. >> Since the point would be remove duplicates from lists, I don’t think >> warning is very useful. I would want to remove the duplicate list >> items, not get a warning about it and delete them manually. Perhaps >> that would be a useful additional feature however (like uniq -d). > > I think warning or asking for confirmation should be the default action, > because it's the safest option. Users who want to skip that could use a > prefix argument or call it from a custom command. There is always undo and automatic Emacs file backups. >> I don’t think doing a full text check is useful, but if someone has a >> use case for that, please speak up. > > An example where this would be useful is if the user has copied and > pasted subtrees and accidentally pasted one more than once. In that case, the user should use undo instead of a remove duplicates command. > I argue here for the safest behavior by default because I've found that, > in very large Org buffers, it's easy to lose my place in the file, and > it's easy to accidentally do something that I didn't mean to, without > noticing. IMO this is simply a consequence of Org buffers still being > plain-text. I don’t agree with this philosophy. Org and Emacs already has lots of commands that can cause damage, for example org-sort-entries which my remove duplicates command is modeled after (both modify the direct children under the heading at point irreversibly ignoring undo). If this command should warn, then org-sort-entries should also warn. If org-sort-entries does not need to warn, then this command does not need to warn. Emacs makes backups by default and supports undo, which under my philosophy is good enough; we shouldn’t be constantly asking for confirmation to prevent user error. That just causes pop-up dialog fatigue. For example, everyone clicks OK on pop-up confirmation boxes without reading them. These kinds of confirmation prompts are worse than useless; they slow down and annoy the user without providing any protection. Undo is the better solution. > So it is quite conceivable to me that a user might intentionally give > two headings the same name (e.g. a user who captures quotations to an > inbox file might have two "Quote" headings that are completely > different), or might accidentally duplicate a subtree and then make a > desired change to one of them without realizing there was a > duplicate--then he might use this deduplication command and accidentally > delete a subtree he didn't mean to, resulting in data loss. I think it would be more useful for list members to post actual use cases than hypothesize about what people want. For me, the use case is filtering out duplicates from a list, e.g. groceries to buy or links to read captured with timestamps and other metadata, so checking the tags, todo, or body text is not useful, warning is not useful. Based on the responses I have gotten, it sounds like this feature is too specialized to be worth including in Org mode, so I will stop pursuing this unless people post actual use cases/desire for the feature.
[O] org-open-link-from-string truncates file path at spaces
Hi, With current org version (Org mode version 9.1.8 (9.1.8-elpaplus @ c:/Users/joon/.emacs.d/elpa/org-plus-contrib-20171228/)), org-open-link-from-string does not work with a path string if it includes a space. For example, (org-open-link-from-string "file:test test.hmtl") yields user-error: No such file: c:/Users/joon/test Best Regards, Joon
Re: [O] Bug: Org table alignment, horrible failures [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /Users/genovese/.emacs.d/elpa/org-plus-contrib-20171225/)]
No answer, but something like this was also posted on SO: https://emacs.stackexchange.com/questions/37828/org-mode-doesnt-align-column-bars-properly John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Jan 1, 2018 at 8:01 PM, Christopher Genovese wrote: > I make heavy use of org tables, often relying on the automatic realignment > with C-c C-c or TAB. But after updating org-mode to 9.1.5, this realignment > has started to lead to quite significant problems in the tables' > appearances. > I'm on Mac OS X 10.12.6, running Gnu Emacs 26.0.50 installed via homebrew. > I installed org-mode 9.1.5 using the org-plus-contrib package with the > standard > package mechanism. > > I've run all these examples using emacs -Q with a minimal load of > org-plus-contrib (configuration #1 below) as well as my own set up > (configuration #2 below). Same results both ways. > > I've attached images to this email to show the results, but I'll try to > reproduce them here as well in a fixed-width typeface. > > Here is a sample table as a baseline, put in a file by itself. > > | Date | Time | Aerobic | > Lifting | Strengthening | > Stretching | Other | Notes | > | 2017 01 01 | 1100 | True:34, Ladder:10, Bike:10 | Light biceps, light > forearms | Light Shoulders, Wrist | Calf, Hamstring, Groin | | | > > With certain changes to these fields, automatic alignment of the columns > with either C-c C-c or TAB fails horribly in several ways. The baseline > table > image is align-Q-baseline.png. > > 1. Change Time column from 1100 to any alphanumeric string *that >includes a letter* and the alignment works as normal. >(Image: align-Q-baseline.png). Note that 1100 also keeps the alignment >normal (align-Q-equal-number.png) but only because it is the same length >as Time. > > 2. Change Time to a short number, like 11, and the table appears as > > | Date | Time | Aerobic | > Lifting | Strengthening | > Stretching | Other | Notes | > | 2017 01 01 | T e 4 L der:10, Bike:10 | Light biceps, light forearms > | Light Shoulders, Wrist | Calf, Hamstring, Groin | | | > >(Image: align-Q-short-number.png) > > 3. Change Time to a long number, like 111000, and the table appears as > > | Date | m | e b | > Lifting | Strengthening | > Stretching | Other | Notes | > | 2017 01 01 | 111000 | True:34, Ladder:10, Bike:10 | Light biceps, light > forearms | Light Shoulders, Wrist | Calf, Hamstring, Groin | | | > >(Image: align-Q-long-number.png, similarly align-Q-confirm.png with > 11000 instead.) > > 4. Change Date to include -'s (2017-01-01) and the table appears as > > | Date | Time | Aerobic | > Lifting | Strengthening | > Stretching | Other | Notes | > | 2017-01-01 | 1100 | True:34, Ladder:10, Bike:10 | Light biceps, light > forearms | Light Shoulders, Wrist | Calf, Hamstring, Groin | | | > > Other similar problems occur as well. > > Again, these appear after either C-c C-c or a TAB in a field, nothing else. > The contents are not changed only the appearance and cannot > be fixed by editing. Killing the buffer and reopening makes the > table look correct, but any additional realignment messes it up again. > > And just to be clear, this did not occur prior to installing 9.1.5, > even a few days back. I don't recall the previous version I had > installed. It was relatively recent but could have been a few > steps back. > > Thanks, Chris > > > Configuration #1: > > Emacs : GNU Emacs 26.0.50 (build 1, x86_64-apple-darwin16.7.0, NS > appkit-1504.83 Version 10.12.6 (Build 16G29)) > of 2017-08-29 > Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ > /Users/genovese/.emacs.d/elpa/org-plus-contrib-20171225/) > > current state: > == > (setq > org-src-mode-hook '(org-src-babel-configure-edit-buffer > org-src-mode-configure-edit-buffer) > org-after-todo-state-change-hook '(org-clock-out-if-current) > org-metadown-hook '(org-babel-pop-to-session-maybe) > org-clock-out-hook '(org-clock-remove-empty-clock-drawer) > org-mode-hook '(#[0 "\300\301\302\303\304$\207" >[add-hook change-major-mode-hook org-show-block-all append > local] 5] > #[0 "\300\301\302\303\304$\207" >[add-hook change-major-mode-hook org-babel-show-result-all > append local] >5] > org-babel-result-hide-spec org-babel-hide-all-hashes > org-eldoc-load) > org-archive-hook '(org-attach-archive-delete-maybe) > org-confirm-elisp-link-function 'yes-or-no-p > org
Re: [O] New feature? Remove duplicate subheadings, preserving order
Allen Li writes: > I don’t know if a more intelligent way of handling tags and todo > keywords is worth the extra complexity, but in the use case that I > imagine it makes sense to match using only the heading/list item: > > * Things to buy > ** TODO cabbage > ** DONE milk :store1: >Maybe I forgot a tag here. Oh well, I already bought the milk. > ** TODO carrots > ** TODO milk :store1:store2: > > ... > > It doesn’t make sense to include the contents because I see this as > primarily being useful for list items. In particular, we would want > to ignore log entries and properties for the sake of matching > (intelligent property or logbook merging might be useful, but adds > complexity). I think such a command should check all heading data by default, because that's the safest option. A user who commonly needs to ignore one or more types of data could use a custom function that calls the command with arguments to disable checking of certain types. > Since the point would be remove duplicates from lists, I don’t think > warning is very useful. I would want to remove the duplicate list > items, not get a warning about it and delete them manually. Perhaps > that would be a useful additional feature however (like uniq -d). I think warning or asking for confirmation should be the default action, because it's the safest option. Users who want to skip that could use a prefix argument or call it from a custom command. > I don’t think doing a full text check is useful, but if someone has a > use case for that, please speak up. An example where this would be useful is if the user has copied and pasted subtrees and accidentally pasted one more than once. I argue here for the safest behavior by default because I've found that, in very large Org buffers, it's easy to lose my place in the file, and it's easy to accidentally do something that I didn't mean to, without noticing. IMO this is simply a consequence of Org buffers still being plain-text. So it is quite conceivable to me that a user might intentionally give two headings the same name (e.g. a user who captures quotations to an inbox file might have two "Quote" headings that are completely different), or might accidentally duplicate a subtree and then make a desired change to one of them without realizing there was a duplicate--then he might use this deduplication command and accidentally delete a subtree he didn't mean to, resulting in data loss.
Re: [O] New feature? Remove duplicate subheadings, preserving order
On Mon, Jan 1, 2018 at 10:26 AM, Nicolas Goaziou wrote: > Allen Li writes: > >> Org mode is fundamentally an outliner, and one often makes lists with >> an outliner. Filtering out duplicates from a list seems to me like a >> common need. > > AFAIK, this is the first time this need is expressed on this ML. There > is no equivalent in "org-list.el" either. > > Anyway, I'm not questioning the usefulness of the feature in your > workflow. AIUI, in your implementation, duplicates are headlines with > the same title, but without considering TODO keyword, priority, comment > status, tags or contents. So, > > * DONE Summary :Alice: > * TODO Summary :Bob: > > are duplicates. Isn't it a bit too tolerant? We may be able to find > a more general function that still suits you. I see this feature as primarily being useful on lists. So for example: * Things to buy ** cabbage ** milk ** carrots ** milk I don’t know if a more intelligent way of handling tags and todo keywords is worth the extra complexity, but in the use case that I imagine it makes sense to match using only the heading/list item: * Things to buy ** TODO cabbage ** DONE milk :store1: Maybe I forgot a tag here. Oh well, I already bought the milk. ** TODO carrots ** TODO milk :store1:store2: > >> I wrote such a command to support some of my work flows, and I posted >> this here because I think there is a possibility that other Org users >> might also find it useful. > > You didn't answer to any of my suggestions, tho. Are they fundamentally > wrong? I.e., wouldn't warning instead of deleting more useful? Or would > it make more sense to include contents when looking for duplicates ? In > the latter case, maybe a prefix argument could toggle headline check and > full check. Since the point would be remove duplicates from lists, I don’t think warning is very useful. I would want to remove the duplicate list items, not get a warning about it and delete them manually. Perhaps that would be a useful additional feature however (like uniq -d). It doesn’t make sense to include the contents because I see this as primarily being useful for list items. In particular, we would want to ignore log entries and properties for the sake of matching (intelligent property or logbook merging might be useful, but adds complexity). I don’t think doing a full text check is useful, but if someone has a use case for that, please speak up.
Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
Hello, Melleus writes: > Melleus writes: > >> I also have Org mode version 9.1.8 and the problem with broken >> tables. Now it looks like this: >> >> |+--+---| >> | Суб'єкт| Завдання >>| | >> |+--+---| >> | Головний бухгалтер | На початковому етапі формування облікової політики >> використовують досвід | | >> | та бухгалтерська | >>| | >> | служба | >>| | >> >> And I must say that a couple of updates ago it was working perfectly. > > Very stange, this table was looking messy when I sent the message. But > here it looks Ok except the extra column that I had not created. There > are only two first columns that should be there. I can't understand > what's happening. And in my file the table remains messy. This is probably related to commit 401890986cf7e4a08c76be4c291b45278c2ac89b. You need to update Org to get it. Regards, -- Nicolas Goaziou
Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
Melleus writes: > I also have Org mode version 9.1.8 and the problem with broken > tables. Now it looks like this: > > |+--+---| > | Суб'єкт| Завдання > | | > |+--+---| > | Головний бухгалтер | На початковому етапі формування облікової політики > використовують досвід | | > | та бухгалтерська | > | | > | служба | > | | > > And I must say that a couple of updates ago it was working perfectly. Very stange, this table was looking messy when I sent the message. But here it looks Ok except the extra column that I had not created. There are only two first columns that should be there. I can't understand what's happening. And in my file the table remains messy.
Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
I also have Org mode version 9.1.8 and the problem with broken tables. Now it looks like this: |+--+---| | Суб'єкт| Завдання | | |+--+---| | Головний бухгалтер | На початковому етапі формування облікової політики використовують досвід | | | та бухгалтерська | | | | служба | | | And I must say that a couple of updates ago it was working perfectly.
Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
Michel Schinz writes: > Ok, I will gladly do this, but I just want to point out that Org 9.1.8 is > what one currently gets from Org's own ELPA. You can check it out by > downloading the latest archive from https://orgmode.org/elpa/, namely: > > https://orgmode.org/elpa/org-20171228.tar > > The file org-version.el in that archive contains the following definition: > > (defun org-release () > "The release version of Org. > Inserted by installing Org mode or when a release is made." >(let ((org-release "9.1.8")) > org-release)) > > Did I make a mistake, or is there a problem with Org ELPA? I think this is an issue with Org ELPA. I'm cc'ing Bastien. Thank you for letting us know.
Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
Hello, On Mon, Jan 1, 2018, at 19:37, Nicolas Goaziou wrote: > There is no such thing as Org version 9.1.8. Latest stable release is > Org 9.1.5. > > As I cannot reproduce it (I'm not on macOS) on maint (stable branch), > I suggest to update Org and try again. It may be related to a bug > recently fixed. Ok, I will gladly do this, but I just want to point out that Org 9.1.8 is what one currently gets from Org's own ELPA. You can check it out by downloading the latest archive from https://orgmode.org/elpa/, namely: https://orgmode.org/elpa/org-20171228.tar The file org-version.el in that archive contains the following definition: (defun org-release () "The release version of Org. Inserted by installing Org mode or when a release is made." (let ((org-release "9.1.8")) org-release)) Did I make a mistake, or is there a problem with Org ELPA? Michel.
Re: [O] top headline's visibility property blocked by subheadline's property
Hello, Michael Maurer writes: > I'm not sure if this is a feature, or I'm missing something, but if I > set up an outline like this: > > * 2017 > :PROPERTIES: > :VISIBILITY: folded > :END: > ** december > :PROPERTIES: > :VISIBILITY: folded > :END: > *** 31 > *** 30 > ** november > :PROPERTIES: > :VISIBILITY: folded > :END: > > > > the headlines underneath 2016 don't get folded. I'm not sure to understand. Where is headline "2016"? What do you get upon opening the document (or pressing C-u C-u )? What did you expect instead? Regards, -- Nicolas Goaziou
Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
Hello, Michel Schinz writes: > The latest version(s) of Org have a weird display issue (at least on > macOS) when tables are aligned. To see it, launch Emacs with "-Q" and > then add the directory containing the latest Org to the load-path. Then, > open an empty Org file (e.g. /tmp/foo.org) and paste the following > partial table into it: > > |xxx|zzz > |0 > > Then, with the cursor on the "0" (e.g.), hit C-c C-c to realign the > table. Visually, the result will look like this: > > | xxx | zzz | > | | | > > That is, the 0 will have disappeared, and the vertical lines will not be > aligned. Then save the file, kill the buffer, and reload the file. What > now appears is the correct table, i.e. > > | xxx | zzz | > | 0 | | > > I am able to reproduce this bug both when Emacs is launched as graphical > application, and in the terminal when launched with "-nw". > > Michel. > > Emacs : GNU Emacs 25.3.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 > Version 10.9.5 (Build 13F1911)) > of 2017-09-12 > Package: Org mode version 9.1.8 (9.1.8-elpa @ > /Users/michelschinz/.emacs.d/elpa/org-20171228/) There is no such thing as Org version 9.1.8. Latest stable release is Org 9.1.5. As I cannot reproduce it (I'm not on macOS) on maint (stable branch), I suggest to update Org and try again. It may be related to a bug recently fixed. Regards, -- Nicolas Goaziou
Re: [O] New feature? Remove duplicate subheadings, preserving order
Allen Li writes: > Org mode is fundamentally an outliner, and one often makes lists with > an outliner. Filtering out duplicates from a list seems to me like a > common need. AFAIK, this is the first time this need is expressed on this ML. There is no equivalent in "org-list.el" either. Anyway, I'm not questioning the usefulness of the feature in your workflow. AIUI, in your implementation, duplicates are headlines with the same title, but without considering TODO keyword, priority, comment status, tags or contents. So, * DONE Summary :Alice: * TODO Summary :Bob: are duplicates. Isn't it a bit too tolerant? We may be able to find a more general function that still suits you. > I wrote such a command to support some of my work flows, and I posted > this here because I think there is a possibility that other Org users > might also find it useful. You didn't answer to any of my suggestions, tho. Are they fundamentally wrong? I.e., wouldn't warning instead of deleting more useful? Or would it make more sense to include contents when looking for duplicates ? In the latter case, maybe a prefix argument could toggle headline check and full check.
Re: [O] [ANN] OrgStruct is dead. Long live Orgalist.
Nicolas Goaziou writes: > Hello, > > Eric S Fraga writes: > >> Not sure what kind of ECM you would like? I simply type in a line like >> this: >> >> 2. this is an item that has a lot of text, text that will eventually >> auto fill onto next line. > > I see. Here comes the 2018 release. Works great for me -- glad to have this back!
Re: [O] Datetrees and tags
Hello, Fabrice Popineau writes: > Actually, looking at org-datetree.el, the several regex here do not take > possible tags into account, so this is expected. > > So my question: would it make sense to enhance datetrees entries with > optional tags? > Or would that introduce some kind of inconsistency elsewhere? It's probably an omission in "org-datetree.el". Do you want to provide a patch for that (along with a couple of tests)? Thank you, Regards, -- Nicolas Goaziou
Re: [O] [ANN] OrgStruct is dead. Long live Orgalist.
On Monday, 1 Jan 2018 at 11:15, Nicolas Goaziou wrote: > I see. Here comes the 2018 release. Happy new year! 2018 is obviously going to be a good year: this version of orgalist works very well now. Thanks, eric -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.5-269-g144451 signature.asc Description: PGP signature
[O] Datetrees and tags
Hi, It seems that currently, datetrees do not support tags. IE if I add a tag to some datetree and I try to add another item to the same date, then another date is insereted: *** 2017-12-29 vendredi :perso: [2017-12-29 ven.] - Bla-bla-bla-bla *** 2017-12-29 vendredi [2017-12-29 ven.] - Actually, looking at org-datetree.el, the several regex here do not take possible tags into account, so this is expected. So my question: would it make sense to enhance datetrees entries with optional tags? Or would that introduce some kind of inconsistency elsewhere? Happy New Year to everybody. Fabrice
[O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]
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 http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. The latest version(s) of Org have a weird display issue (at least on macOS) when tables are aligned. To see it, launch Emacs with "-Q" and then add the directory containing the latest Org to the load-path. Then, open an empty Org file (e.g. /tmp/foo.org) and paste the following partial table into it: |xxx|zzz |0 Then, with the cursor on the "0" (e.g.), hit C-c C-c to realign the table. Visually, the result will look like this: | xxx | zzz | | | | That is, the 0 will have disappeared, and the vertical lines will not be aligned. Then save the file, kill the buffer, and reload the file. What now appears is the correct table, i.e. | xxx | zzz | | 0 | | I am able to reproduce this bug both when Emacs is launched as graphical application, and in the terminal when launched with "-nw". Michel. Emacs : GNU Emacs 25.3.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2017-09-12 Package: Org mode version 9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/) current state: == (setq org-tab-first-hook '(org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-activate org-babel-speed-command-activate) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-shell-link-function 'yes-or-no-p org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-show-block-all append local] 5] #[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn ENTRY)"] org-archive-hook '(org-attach-archive-delete-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-link-parameters '(("id" :follow org-id-open) ("rmail" :follow org-rmail-open :store org-rmail-store-link) ("mhe" :follow org-mhe-open :store org-mhe-store-link) ("irc" :follow org-irc-visit :store org-irc-store-link) ("info" :follow org-info-open :export org-info-export :store org-info-store-link) ("gnus" :follow org-gnus-open :store org-gnus-store-link) ("docview" :follow org-docview-open :export org-docview-export :store org-docview-store-link) ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link) ("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete org-bbdb-complete-link :store org-bbdb-store-link) ("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs") ("doi" :follow org--open-doi-link) ("elisp" :follow org--open-elisp-link) ("file" :complete org-file-complete-link) ("ftp" :follow (lambda (path) (browse-url (concat "ftp:" path ("help" :follow org--open-help-link) ("http" :follow (lambda (path) (browse-url (concat "http:" path ("https" :follow (lambda (path) (browse-url (concat "https:" path ("mailto" :follow (lambda (path) (browse-url (concat "mailto:"; path ("news" :follow (lambda (path) (browse-url (concat "news:"; path ("shell" :follow org--open-shell-link)) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) )
Re: [O] New feature? Remove duplicate subheadings, preserving order
On Mon, Jan 1, 2018 at 2:04 AM, Nicolas Goaziou wrote: > Duplicates headings are not necessarily wrong. I think this is too > specific to be integrated in Org proper. > > Maybe we could add a check for duplicates headings in Org Lint instead, > and add this to Worg, in a "tools" page. > > Or we could check for duplicate headings _including contents_, which are > more likely to be an error. > > WDYT? Org mode is fundamentally an outliner, and one often makes lists with an outliner. Filtering out duplicates from a list seems to me like a common need. I wrote such a command to support some of my work flows, and I posted this here because I think there is a possibility that other Org users might also find it useful. If this is not so, I’m perfectly okay just keeping this in my personal config.
Re: [O] [ANN] OrgStruct is dead. Long live Orgalist.
Hello, Eric S Fraga writes: > Not sure what kind of ECM you would like? I simply type in a line like > this: > > 2. this is an item that has a lot of text, text that will eventually > auto fill onto next line. I see. Here comes the 2018 release. Regards, -- Nicolas Goaziou orgalist.el Description: Orgalist minor mode v2
Re: [O] New feature? Remove duplicate subheadings, preserving order
Hello, Allen Li writes: > I wrote a command to remove duplicate subheadings, which I use to > remove duplicate captured links among other things. Would this be a > useful addition to Org mode? > > I have included it below for reference. I will clean it up a bit if > it's a worthy feature. > > (defun mir-org-uniq () > "Remove duplicate subheadings, preserving order." > (interactive) > (let ((seen (make-hash-table :test 'equal)) > (removed 0)) > (save-excursion > (org-map-entries (lambda () > (let ((heading (org-get-heading t t t t))) >(if (not (gethash heading seen)) >(puthash heading t seen) > (org-cut-subtree) > (org-backward-heading-same-level 1) > (setq removed (1+ removed) >(format "LEVEL=%s" (1+ (org-current-level))) >'tree)) > (message "Removed %d duplicates" removed))) Duplicates headings are not necessarily wrong. I think this is too specific to be integrated in Org proper. Maybe we could add a check for duplicates headings in Org Lint instead, and add this to Worg, in a "tools" page. Or we could check for duplicate headings _including contents_, which are more likely to be an error. WDYT? Regards, -- Nicolas Goaziou
[O] top headline's visibility property blocked by subheadline's property
hello, I'm not sure if this is a feature, or I'm missing something, but if I set up an outline like this: * 2017 :PROPERTIES: :VISIBILITY: folded :END: ** december :PROPERTIES: :VISIBILITY: folded :END: *** 31 *** 30 ** november :PROPERTIES: :VISIBILITY: folded :END: the headlines underneath 2016 don't get folded. If I manually delete the visibility property of the months, it gets folded. Reason for this setup is that after each done year, I'd like to hide all its children without manually going through each month and deleting the property.