Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

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

[Joon Ro]

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/)]

[John Kitchin]

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 

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Adam Porter]

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

[Allen Li]

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/)]

[Nicolas Goaziou]

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]

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/)]

[Melleus]

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/)]

[Nicolas Goaziou]

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/)]

[Michel Schinz]

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

[Nicolas Goaziou]

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/)]

[Nicolas Goaziou]

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

[Nicolas Goaziou]

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.

[Eric Abrahamsen]

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

[Nicolas Goaziou]

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.

[Eric S Fraga]

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

[Fabrice Popineau]

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/)]

[Michel Schinz]

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

[Allen Li]

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.

[Nicolas Goaziou]

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

[Nicolas Goaziou]

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

[Michael Maurer]

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.