Re: [O] Remove Org from Emacs repository?

[Maria Shinoto]

Some thoughts from a beginner:


Now that Emacs has had package.el for some years, and Org is
installable directly from GNU ELPA, would it be a good idea to remove
Org from Emacs's source repository?


Beginners are overwhelmed with the options and traps, to do something 
wrong. It is almost impossible to start with Emacs, despite the good 
documentation. This list helped me out in the beginning, and I am glad.


I started using Emacs without deep technological background and without 
any help around. I started using it because of org-mode, and I was _so_ 
happy that org-mode was included.


"All inclusive" packages are the best for beginners. Download, use as is 
and get used to it. After that, one may start with Elisp and packages.



I think the fact that this is an issue at all is an indication of a
shortcoming in Emacs' package-management system. I wish package
management happened "invisibly" (ie, (package-initialize) happened all
by itself). Emacs then would come bundled with certain packages -- Org,
Dired, Gnus, Tramp, etc.


The package manager is not difficult as soon as one has got used to 
Emacs. But it is certainly not a good idea to ask people to use it when 
they start trying Emacs. I am collecting my impressions on my way 
getting used to Emacs and would like to write a short list of ideas to 
make the package manager easier to use, if you like.


Best,
Maria

Re: [O] Remove Org from Emacs repository?

[Eric Abrahamsen]

Reuben Thomas  writes:

> Now that Emacs has had package.el for some years, and Org is
> installable directly from GNU ELPA, would it be a good idea to remove
> Org from Emacs's source repository?

I think the fact that this is an issue at all is an indication of a
shortcoming in Emacs' package-management system. I wish package
management happened "invisibly" (ie, (package-initialize) happened all
by itself). Emacs then would come bundled with certain packages -- Org,
Dired, Gnus, Tramp, etc.

If a user were totally unaware of the existence of packages, those
packages would only get updated when Emacs was updated.

If a user were package-savvy, he/she could open up the package manager,
which would provide the option to update those packages, or remove them
altogether. My personal opinion is that Emacs should lean more towards
"batteries included", but offer a slimming option for users who
understand packages.

Right now I apparently have two copies of Org installed -- the Emacs
bundle, and org-plus-contrib from the package repos. Actually, I have a
third: the plain old Org package from the package repos, because I've
installed other packages that require it. (Another gripe: why isn't the
loading of a file containing (provide 'org) enough to tell the package
manager not to install another one?)

And actually a fourth: Org from git. Again, if the package manager were
satisfied by finding a (provide 'org) in my loaded code-base, this might
be the only copy necessary.

All this is just to say, I wish this were an argument we didn't have to
have.

E

Re: [O] Remove Org from Emacs repository?

[MaDhAt2r]

I am for leaving it to the users discretion as to weather or not they
have Org installed. I think if anyone out there wants to open an .org
file, more than likely, they know what it is and how to get it. If not
there is a plethora of information out there to point them in the right
direction.

After all, isn't free software, at least somewhat, about choices? :)


On Dec 18 at 11:32 PM, Reuben Thomas said thus:
> On 18 December 2016 at 19:21, Samuel Wales  wrote:
>
>> auto-mode-alist has more than 200 entries.  we're gonna remove .org?
>>
>
> ​Org is nearly 90kLOC, or about 6.5% of the total ELisp code currently in
> Emacs. It's bigger than CEDET, smaller than GNUS.
>
> It's a project of its own with its own release cadence. It would be good to
> make Emacs less of a monolithic entity, which needs lengthy debugging
> cycles between releases, and has to choose between being out of date with
> various upstreams, or delaying to test integration of big packages.
>
> Now that package.el is mature, there's no need for Emacs to include all
> this stuff in its source releases.
>
> What emacs -Q does is a different matter: there's plenty of scope to ship a
> variety of packages "out of the box". Various customised Emacs
> "distributions" already do this.
>
> "you must install org to view this format" is a bit too minimal for my
>> taste.  :)  sounds like adobe flash.  :)
>>
>
> ​I'm sure plenty of Emacs users never open an Org-mode file. Why​ should
> they have to install it?
>
> surely this topic was raised to have a bit of fun seeing all the
>> responses?  :)
>>
>
> ​No, I was just testing the waters to see if a more modern approach to
> development and distribution might be popular. Apparently the answer is, at
> least, not yet!
>
> -- 
> http://rrt.sc3d.org

Re: [O] org.texi edits, patch attached

[Nicolas Goaziou]

Hello,

Lambda Coder  writes:

> I have more. I've just finished the Exporting chapter. See the attached
> patch file against current maint branch.

Thank you!

Usual comments and questions follow.

> +Org has export facilities for printing, format conversions, and general
> +sharing of Org documents with the outside world.  Org export supports
> +pretty-printing, web publishing, slide shows, and quick exports of lists and
> +tables to many foreign formats while retaining as much structure
> +(@pxref{Document structure}) and markup (@pxref{Markup}) as possible.  The
> +many features of Org exports are constantly being improved and expanded and
> +they are all explained in this chapter.

I would remove "are constantly being improved and expanded and they"

> +@noindent Org also uses additional libraries located in @code{contrib/}
> +directory (@pxref{Installation}).  Users can install even more specialized
> +libraries from the Emacs packaging system.  

Nitpick: libraries from the Emacs packaging system may not be "more
specialized", but just different.

What about dropping "specialized"?

> +Invokes the export dispatcher interface.  The options show default settings.
> +The @kbd{C-u} prefix argument preserves options from the previous export,
> +including any sub-tree selections as long as buffer contents have not changed
> +since the last export.

The last part of the sentence above is incorrect. Buffer contents may
have changed between two exports. Otherwise, there is not much interest
in exporting the same thing twice, even with a shortcut.

> -Toggle subtree export.  The top heading becomes the document title.
> +Toggle sub-tree export.  When turned on, Org exports only the sub-tree 
> starting
> +from the cursor position at the time the export dispatcher was invoked.  Org
> +uses the top heading of this sub-tree as the document's title.  If the cursor
> +is not on a heading, Org uses the nearest enclosing header.  If the cursor is
> +in the document preamble, Org signals an error and aborts export.

I wonder if the last sentence isn't too technical for a manual.
Shouldn't we leave that for a docstring?

> +Options set through properties
> +(@pxref{Properties and columns}) apply to that specific heading and its
> +subheadings.  Properties are inherited in the hierarchy, and, in case of
> +overlap, options set at the specific level override those set at the more
> +general and global levels.

This is not correct. Options set through properties apply only when
doing a sub-tree export. Besides, even in this case, properties are not
necessarily inherited. It depens on `org-use-property-inheritance'.

> -A date or a time-stamp@footnote{The variable
> -@code{org-export-date-timestamp-format} defines how this time-stamp will be
> -exported.}.
> +A date or a time-stamp@footnote{The export format is specified in 
> +@code{org-export-date-timestamp-format}.}.

`org-export-date-timestamp-format' has an effect only when DATE is
a time-stamp. It isn't obvious by reading the above.

>  @item EMAIL
>  @cindex #+EMAIL
> @@ -10436,46 +10465,47 @@ The email address (@code{user-mail-address}).
>  @item LANGUAGE
>  @cindex #+LANGUAGE
>  @vindex org-export-default-language
> -The language used for translating some strings
> -(@code{org-export-default-language}).  E.g., @samp{#+LANGUAGE: fr} will tell
> -Org to translate @emph{File} (english) into @emph{Fichier} (french) in the
> -clocktable.
> +Language to use for translating certain strings
> +(@code{org-export-default-language}).  With @samp{#+LANGUAGE: fr}, for
> +example for the clocktable, Org translates the English @emph{File} to the
> +French @emph{Fichier}.

The example needs to be changed (so did the old one).
`org-export-default-language' has no effect on the Clock Table.
I suggest to replace it with a real example, e.g.

  With @samp{#+LANGUAGE: fr}, for example, Org translates @emph{Table of
  contents} to the French @emph{Table des matières}.

> +The default value is @code{:export:}.  When a tree is tagged with
> +@code{:export:} (@code{org-export-select-tags}), Org selects that tree and
> +its sub-trees for export.  Org excludes trees with @code{:noexport:} tags 
> (see
> +below).  

Usual nitpick:

  tags---see below.

> -Toggle inclusion of drawers, or list drawers to include
> +Toggle inclusion of drawers, or list-drawers to include

Is this a typo? `org-export-with-drawers' can contain a list of drawers
to include (or not).

> +``Planning information'' comes from lines containing any combination of these
> +cookies: @code{SCHEDULED:}, @code{DEADLINE:}, or @code{CLOSED:}.

and located right after the headline.

> +Org converts the first three outline levels into headlines for ASCII export.
> +The remaining levels are turned into lists.  To change this cut-off point
> +where levels become lists, (@pxref{Export settings}).

You should remove the parenthesis above.

>  @subheading Quoting ASCII text
>  
> -You can insert text that will 

Re: [O] Remove Org from Emacs repository?

[Reuben Thomas]

On 18 December 2016 at 19:21, Samuel Wales  wrote:

> auto-mode-alist has more than 200 entries.  we're gonna remove .org?
>

​Org is nearly 90kLOC, or about 6.5% of the total ELisp code currently in
Emacs. It's bigger than CEDET, smaller than GNUS.

It's a project of its own with its own release cadence. It would be good to
make Emacs less of a monolithic entity, which needs lengthy debugging
cycles between releases, and has to choose between being out of date with
various upstreams, or delaying to test integration of big packages.

Now that package.el is mature, there's no need for Emacs to include all
this stuff in its source releases.

What emacs -Q does is a different matter: there's plenty of scope to ship a
variety of packages "out of the box". Various customised Emacs
"distributions" already do this.

"you must install org to view this format" is a bit too minimal for my
> taste.  :)  sounds like adobe flash.  :)
>

​I'm sure plenty of Emacs users never open an Org-mode file. Why​ should
they have to install it?

surely this topic was raised to have a bit of fun seeing all the
> responses?  :)
>

​No, I was just testing the waters to see if a more modern approach to
development and distribution might be popular. Apparently the answer is, at
least, not yet!

-- 
http://rrt.sc3d.org

Re: [O] Bug: Regexp matcher stack overflow in org-indent initialization [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.1/lisp/org/)]

[Vasilij Schneidermann]

> I slightly simplified the regexp. Does it solve the issue?

This looks good, unfortunately it's hard to prove the issue won't ever
happen again, so I'll just leave it at that.  Thanks for your efforts!

Re: [O] Automatically Generating IDs From Title and Date

[Samuel Wales]

On 12/18/16, Karl Voit  wrote:
>   Usually, my IDs start with the current ISO day to enforce uniqueness
>   and look like this:

my understanding, which might be incorrect, is that custom id is for
human-readable purposes, while id is for uuid.  although you could
prepend to uuid.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Re: [O] org-depend: dependencies between TODO entries in different files

[Samuel Wales]

lovely that we are thinking of new stuff for org-depend.

On 12/12/16, Karl Voit  wrote:
>> it can make a remote task get scheduled upon doneifying current task?

for me this would be the killer feature.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Re: [O] Remove Org from Emacs repository?

[Samuel Wales]

auto-mode-alist has more than 200 entries.  we're gonna remove .org?

"you must install org to view this format" is a bit too minimal for my
taste.  :)  sounds like adobe flash.  :)

surely this topic was raised to have a bit of fun seeing all the responses?  :)

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Re: [O] Remove Org from Emacs repository?

[Lambda Coder]

+1 (keep it in)

On Sun, Dec 18, 2016 at 10:46 AM, Xebar Saram  wrote:

> +1 for keeping it in
>
> i often debug my org based init config by launching emacs -Q and its great
> to have org built in for that :)
>
> Z
>
> On Sun, Dec 18, 2016 at 7:11 PM, Christian Moe 
> wrote:
>
>>
>> +1.
>>
>> (= Keep it in.)
>>
>> Yours,
>> Christian
>>
>> Carsten Dominik writes:
>>
>> > Dear all,
>> >
>> > I'd hate to see Org removed from Emacs.  It took a lot of work to get it
>> > in, and I believe that the vast majority of Emacs users does not install
>> > packages.  For a newbie to get to Emacs and to be able to open a .org
>> file
>> > is a big plus.  So my vote goes toward keeping it in.
>> >
>> > Carsten
>> >
>> > On Sun, Dec 18, 2016 at 10:22 AM,  wrote:
>> >
>> >> 2 cents from me...
>> >>
>> >> Besides I continuously see many users praising Emacs just for Org
>> >> presence (they even may be completely non-technical users), I'm
>> >> personally think Org may be removed from Emacs distribution because:
>> >>
>> >> 1) all Reuben's argument seems sane;
>> >> 2) there are situations when someone wants particular version of Org,
>> >>and it may be not tne one bundled with Emacs. In this case someone
>> >>should perform extra steps to ensure things are going the right way.
>> >>When Org will be available only from ELPA, it will be SPOT for such
>> >> cases.
>> >>
>> >> Reuben Thomas  writes:
>> >>
>> >> > Now that Emacs has had package.el for some years, and Org is
>> installable
>> >> > directly from GNU ELPA, would it be a good idea to remove Org from
>> >> Emacs's
>> >> > source repository?
>> >> >
>> >> > The current situation is left over from before Emacs had package.el,
>> and
>> >> I
>> >> > see no compelling reason to keep it. Org is too big and distinct to
>> be
>> >> > swallowed by Emacs; it doesn't make much sense to keep its current
>> >> half-in,
>> >> > half-out state; so logically it seems sensible to take it out.
>> >> >
>> >> > I am asking this question from an Org point of view; I will ask the
>> Emacs
>> >> > maintainers separately for their perspective.
>> >> >
>> >> > I think it would benefit Emacs too, as there would be less code to
>> >> maintain
>> >> > (even though Org is quasi-external at present, it still has to build
>> >> > successfully as part of an Emacs build), and the Emacs distribution
>> would
>> >> > be slimmer for non-Org users.
>> >> >
>> >> > Of course, Emacs "distributions" would still be able to include Org
>> >> > out-of-the box if they wished.
>> >> >
>> >> > --
>> >> > http://rrt.sc3d.org
>> >>
>>
>>
>>
>

Re: [O] Remove Org from Emacs repository?

[Xebar Saram]

+1 for keeping it in

i often debug my org based init config by launching emacs -Q and its great
to have org built in for that :)

Z

On Sun, Dec 18, 2016 at 7:11 PM, Christian Moe 
wrote:

>
> +1.
>
> (= Keep it in.)
>
> Yours,
> Christian
>
> Carsten Dominik writes:
>
> > Dear all,
> >
> > I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> > in, and I believe that the vast majority of Emacs users does not install
> > packages.  For a newbie to get to Emacs and to be able to open a .org
> file
> > is a big plus.  So my vote goes toward keeping it in.
> >
> > Carsten
> >
> > On Sun, Dec 18, 2016 at 10:22 AM,  wrote:
> >
> >> 2 cents from me...
> >>
> >> Besides I continuously see many users praising Emacs just for Org
> >> presence (they even may be completely non-technical users), I'm
> >> personally think Org may be removed from Emacs distribution because:
> >>
> >> 1) all Reuben's argument seems sane;
> >> 2) there are situations when someone wants particular version of Org,
> >>and it may be not tne one bundled with Emacs. In this case someone
> >>should perform extra steps to ensure things are going the right way.
> >>When Org will be available only from ELPA, it will be SPOT for such
> >> cases.
> >>
> >> Reuben Thomas  writes:
> >>
> >> > Now that Emacs has had package.el for some years, and Org is
> installable
> >> > directly from GNU ELPA, would it be a good idea to remove Org from
> >> Emacs's
> >> > source repository?
> >> >
> >> > The current situation is left over from before Emacs had package.el,
> and
> >> I
> >> > see no compelling reason to keep it. Org is too big and distinct to be
> >> > swallowed by Emacs; it doesn't make much sense to keep its current
> >> half-in,
> >> > half-out state; so logically it seems sensible to take it out.
> >> >
> >> > I am asking this question from an Org point of view; I will ask the
> Emacs
> >> > maintainers separately for their perspective.
> >> >
> >> > I think it would benefit Emacs too, as there would be less code to
> >> maintain
> >> > (even though Org is quasi-external at present, it still has to build
> >> > successfully as part of an Emacs build), and the Emacs distribution
> would
> >> > be slimmer for non-Org users.
> >> >
> >> > Of course, Emacs "distributions" would still be able to include Org
> >> > out-of-the box if they wished.
> >> >
> >> > --
> >> > http://rrt.sc3d.org
> >>
>
>
>

Re: [O] org-depend improvements: ID picker

[Eric Abrahamsen]

Karl Voit  writes:

> * Karl Voit  wrote:
>> * Carsten Dominik  wrote:
>>
>>> Since ord-depend was only proof of concept, we could also think a bit more
>>> broadly about what it should be able to do.  Is there specific
>>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>>> it has right now?

[...]

> 1 Improvement: ID Picker
> 
>
>   First of all, I'd like to see some kind of ID picker when defining
>   `:TRIGGER:' and `:BLOCKER:' dependencies.
>
>   This should work like this: after setting up the task in headings and
>   giving them IDs, I'd like to invoke a "I want to define a
>   dependency"-command. It first asks me what property I want to set:
>   `:TRIGGER:' or `:BLOCKER:'.
>
>   Then I get asked to select any ID which could be found within the same
>   sub-hierarchy (or even in all files?).
>
>   After being asked for the KEYWORD to be set for `:TRIGGER:'
>   dependencies (if applicable), the property is added to the current
>   heading accordingly.
>
>   This would drastically improve creating dependency definitions and
>   prevent typing errors in the first place.

I like this a lot, for more uses than just org-depend, and it would be
very easy to implement. We've got `org-property-set-functions-alist' for
using special functions to read the values of special properties, and
we've got `org-id-get-with-outline-(drilling|path-completion), so it's
pretty much already done!


(defun my-trigger-property-prompt ()
  (when (derived-mode-p 'org-mode)
(let ((id (org-id-get-with-outline-drilling))
  (kw (org-completing-read "Keyword: " org-todo-keywords-1)))
  (do-something-with-id-and-kw

(push '("TRIGGER" . my-trigger-property-prompt)
  org-property-set-functions-alist)

I don't actually know how the TRIGGER property is meant to be formatted
(and I didn't really test the above), but something very near to the
above should do what you want.

Eric

Re: [O] Remove Org from Emacs repository?

[Christian Moe]

+1.

(= Keep it in.)

Yours,
Christian

Carsten Dominik writes:

> Dear all,
>
> I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> in, and I believe that the vast majority of Emacs users does not install
> packages.  For a newbie to get to Emacs and to be able to open a .org file
> is a big plus.  So my vote goes toward keeping it in.
>
> Carsten
>
> On Sun, Dec 18, 2016 at 10:22 AM,  wrote:
>
>> 2 cents from me...
>>
>> Besides I continuously see many users praising Emacs just for Org
>> presence (they even may be completely non-technical users), I'm
>> personally think Org may be removed from Emacs distribution because:
>>
>> 1) all Reuben's argument seems sane;
>> 2) there are situations when someone wants particular version of Org,
>>and it may be not tne one bundled with Emacs. In this case someone
>>should perform extra steps to ensure things are going the right way.
>>When Org will be available only from ELPA, it will be SPOT for such
>> cases.
>>
>> Reuben Thomas  writes:
>>
>> > Now that Emacs has had package.el for some years, and Org is installable
>> > directly from GNU ELPA, would it be a good idea to remove Org from
>> Emacs's
>> > source repository?
>> >
>> > The current situation is left over from before Emacs had package.el, and
>> I
>> > see no compelling reason to keep it. Org is too big and distinct to be
>> > swallowed by Emacs; it doesn't make much sense to keep its current
>> half-in,
>> > half-out state; so logically it seems sensible to take it out.
>> >
>> > I am asking this question from an Org point of view; I will ask the Emacs
>> > maintainers separately for their perspective.
>> >
>> > I think it would benefit Emacs too, as there would be less code to
>> maintain
>> > (even though Org is quasi-external at present, it still has to build
>> > successfully as part of an Emacs build), and the Emacs distribution would
>> > be slimmer for non-Org users.
>> >
>> > Of course, Emacs "distributions" would still be able to include Org
>> > out-of-the box if they wished.
>> >
>> > --
>> > http://rrt.sc3d.org
>>

Re: [O] Remove Org from Emacs repository?

[Reuben Thomas]

On 18 December 2016 at 13:20, Carsten Dominik  wrote:

> Dear all,
>
> I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> in, and I believe that the vast majority of Emacs users does not install
> packages.  For a newbie to get to Emacs and to be able to open a .org file
> is a big plus.  So my vote goes toward keeping it in.
>

​Since you're responsible for org-mode, and I guess you're happy with the
coordination between (your) upstream and Emacs, then ​I agree it should
continue to be distributed out of the box.

However, your comments raise a couple of thoughts:

1. Is there something hard about packages that could be made easier? For
example, Atom seems to get along fine without many built-in packages, so
that most users expect to install some.

2. Is there any possibility to make org-mode a build-time dependency of
Emacs, like the C libraries that it requires, or is that a silly idea? That
could permit it to be shipped as built-in, without having its source
duplicated in Emacs's repository.

Re: [O] Remove Org from Emacs repository?

[Kaushal Modi]

Carsten Dominik  writes:

>
> > I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> > in, and I believe that the vast majority of Emacs users does not install
> > packages.  For a newbie to get to Emacs and to be able to open a .org
> file
> > is a big plus.  So my vote goes toward keeping it in.


+1

Even though I build org mode from source, I'd like to keep it packaged with
emacs too. That way, people who do not want to install any package manually
can still reap the benefits of org mode.

Org mode is one of the key features and a very unique one to emacs.
Separating it from emacs would not be good I believe.
-- 

Kaushal Modi

Re: [O] Android org app with sync?

[Eric S Fraga]

On Sunday, 18 Dec 2016 at 01:59, Alasdair McAndrew wrote:

[...]

> Are there any other apps which will allow me to update and edit 
> org files on my android device, and have them sync automatically?

MobileOrg: https://play.google.com/store/apps/details?id=com.matburt.mobileorg

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_9.0.2-104-gf5b7de


signature.asc
Description: PGP signature

Re: [O] Remove Org from Emacs repository?

[Greg Troxel]

Carsten Dominik  writes:

> I'd hate to see Org removed from Emacs.  It took a lot of work to get it
> in, and I believe that the vast majority of Emacs users does not install
> packages.  For a newbie to get to Emacs and to be able to open a .org file
> is a big plus.  So my vote goes toward keeping it in.

I agree.  Even though I have compiled org from git at times, and have
been using emacs since version 16 or 17 in the late 80s (I am fuzzy on
dates), I have never actually learned the package system.  I also look
at org files using the built-in emacs on mac, and various other places.

So I think emacs should continue to have a stable version of org, but
also that it should be relatively easy to install and use a newer
version from a packaging system.

(It should also be easy to use org from git, but it is; it's just
prepending to load path and I've been doing that with no issues for
years.)



signature.asc
Description: PGP signature

Re: [O] Remove Org from Emacs repository?

[Rasmus]

Carsten Dominik  writes:

>  So my vote goes toward keeping it in.

1+

-- 
Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!

Re: [O] Remove Org from Emacs repository?

[Carsten Dominik]

Dear all,

I'd hate to see Org removed from Emacs.  It took a lot of work to get it
in, and I believe that the vast majority of Emacs users does not install
packages.  For a newbie to get to Emacs and to be able to open a .org file
is a big plus.  So my vote goes toward keeping it in.

Carsten

On Sun, Dec 18, 2016 at 10:22 AM,  wrote:

> 2 cents from me...
>
> Besides I continuously see many users praising Emacs just for Org
> presence (they even may be completely non-technical users), I'm
> personally think Org may be removed from Emacs distribution because:
>
> 1) all Reuben's argument seems sane;
> 2) there are situations when someone wants particular version of Org,
>and it may be not tne one bundled with Emacs. In this case someone
>should perform extra steps to ensure things are going the right way.
>When Org will be available only from ELPA, it will be SPOT for such
> cases.
>
> Reuben Thomas  writes:
>
> > Now that Emacs has had package.el for some years, and Org is installable
> > directly from GNU ELPA, would it be a good idea to remove Org from
> Emacs's
> > source repository?
> >
> > The current situation is left over from before Emacs had package.el, and
> I
> > see no compelling reason to keep it. Org is too big and distinct to be
> > swallowed by Emacs; it doesn't make much sense to keep its current
> half-in,
> > half-out state; so logically it seems sensible to take it out.
> >
> > I am asking this question from an Org point of view; I will ask the Emacs
> > maintainers separately for their perspective.
> >
> > I think it would benefit Emacs too, as there would be less code to
> maintain
> > (even though Org is quasi-external at present, it still has to build
> > successfully as part of an Emacs build), and the Emacs distribution would
> > be slimmer for non-Org users.
> >
> > Of course, Emacs "distributions" would still be able to include Org
> > out-of-the box if they wished.
> >
> > --
> > http://rrt.sc3d.org
>

[O] Cannot reach support button on orgmode web page

[Karl Voit]

Hi!

- http://orgmode.org/Changes.html
- Firefox 45.6.0
- Debian GNU/Linux Jessie

When I try to move my mouse over the "Support Org" button in the
lower right corner, the following message gets moved in, making it
impossible to me to reach the button:

"If Emacs is an operating system, Org-mode is the
office/productivity suite. -- Eric Schulte in his screenshot on
Worg"

Maybe someone here knows how to fix this.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

[O] org-depend improvements: TRIGGER in Combination With Set SCHEDULED

[Karl Voit]

* Karl Voit  wrote:
> * Carsten Dominik  wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

http://karl-voit.at/2016/12/18/org-depend/

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:


4 Improvement: TRIGGER in Combination With Set SCHEDULED


  I love the `:TRIGGER:' property because I can mark headings as open
  tasks only if they can be done now. Only headings which are ready to
  be looked at do have the `TODO' keyword.

  One limitation of `org-depend.el' is that I am only to move forward
  scheduled dates to siblings and I am not able to define a different
  scheduled date.

  Assume following syntax:

  ,
  | ** TODO Asking the client about the project
  | :PROPERTIES:
  | :TRIGGER: 2016-12-18-send-offer(TODO,2016-12-23)
  | :END:
  |
  | ** Send offer to client
  | :PROPERTIES:
  | :ID: 2016-12-18-send-offer
  | :END:
  `

  I extended the option of the trigger property so that I added an ISO
  date to the keyword parameter.

  What I'd expect is that on finishing the first task, the heading with
  the ID `2016-12-18-send-offer' not only gets the keyword `TODO' but
  also is scheduled for 2016-12-23 as well.

  Notice that the send-offer heading is not necessarily located in the
  same sub-hierarchy as the ask-client heading. Therefore,
  sibling-operations are not the whole answer here.

  Additional to this, I'd like to have the possibility to define
  relative schedule dates as stated in [manual for the date prompt]:

   `2016-12-18-send-offer(TODO,.)'  the day when marking the asking-task as 
done
   `2016-12-18-send-offer(TODO,+3d)'3 days after the scheduled date of the 
asking-task
   `2016-12-18-send-offer(TODO,.+3d)'   3 days from the day when marking the 
asking-task as done
   `2016-12-18-send-offer(TODO,mon)'nearest Monday from the day when 
marking the asking-task as done
   `2016-12-18-send-offer(TODO,+2tue)'  second Tuesday from the day when 
marking the asking-task as done


[manual for the date prompt]
http://orgmode.org/manual/The-date_002ftime-prompt.html#The-date_002ftime-prompt

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

[O] org-depend improvements: Canceled Tasks Do Cancel Their Dependencies as Well

[Karl Voit]

* Karl Voit  wrote:
> * Carsten Dominik  wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

http://karl-voit.at/2016/12/18/org-depend/

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:


5 Improvement: Canceled Tasks Do Cancel Their Dependencies as Well
==

  Wouldn't it be nice to have a general setting (or a property?) whether
  or not I want to handle canceled tasks differently as tasks marked as
  done?

  Imagine the example from above. Does it really make sense to send an
  offer when I canceled the ask-client task? Many people probably would
  love to cancel all follow-up workflow tasks as well.


-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

[O] Automatically Generating IDs From Title and Date

[Karl Voit]

* Karl Voit  wrote:
> * Carsten Dominik  wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

http://karl-voit.at/2016/12/18/org-depend/

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:

-


2 Improvement: Generating IDs From Heading and Date
===

  So far, I define `:ID:' properties manually. There are settings that
  result in random IDs set for any new heading. I don't like random ID
  numbers because I would like to get a hint what heading this might be
  when I see it.

  Usually, my IDs start with the current ISO day to enforce uniqueness
  and look like this:

   *Title*   *Manual ID*
  ---
   Update notebook   2016-12-18-update-notebook
   Schedule a meeting with Bob   2016-12-18-schedule-meeting-bob
   Add additional URLs to lecture notes  2016-12-18-add-URLs-to-lecture

  Wouldn't it be nice when there is a command which takes the current
  heading title and auto-generates the ID property accordingly? I guess
  this is not that hard to do:

   *Title*   *Auto-generated ID*
  
---
   Update notebook   2016-12-18-Update-notebook
   Schedule a meeting with Bob   2016-12-18-Schedule-a-meeting-with-Bob
   Add additional URLs to lecture notes  
2016-12-18-Add-additional-URLs-to-lecture-notes



-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

[O] org-depend improvements: ID picker

[Karl Voit]

* Karl Voit  wrote:
> * Carsten Dominik  wrote:
>
>> Since ord-depend was only proof of concept, we could also think a bit more
>> broadly about what it should be able to do.  Is there specific
>> functionality it also should support, besides the TRIGGER/BLOCKER functions
>> it has right now?
>
> Oh my goodness - free wishes for org-depend? Christmas is rather
> early this year! ;-)
>
> For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

I thought about some org-depend improvements to take it to the next
level.

Since many Org-mode users do not know or use org-depend.el, I
decided to write a blog post about it and how improvements can easy
my digital life:

http://karl-voit.at/2016/12/18/org-depend/

Some improvements are probably solved with a few lines of Elisp code.
Unfortunately, I am very bad at coding Elisp myself and thus can't
extend Emacs the way I would love to.

For discussion purposes, I now append the improvements as separate
mailinglist emails here as well:

-

1 Improvement: ID Picker


  First of all, I'd like to see some kind of ID picker when defining
  `:TRIGGER:' and `:BLOCKER:' dependencies.

  This should work like this: after setting up the task in headings and
  giving them IDs, I'd like to invoke a "I want to define a
  dependency"-command. It first asks me what property I want to set:
  `:TRIGGER:' or `:BLOCKER:'.

  Then I get asked to select any ID which could be found within the same
  sub-hierarchy (or even in all files?).

  After being asked for the KEYWORD to be set for `:TRIGGER:'
  dependencies (if applicable), the property is added to the current
  heading accordingly.

  This would drastically improve creating dependency definitions and
  prevent typing errors in the first place.


-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] Remove Org from Emacs repository?

[aaermolov]

2 cents from me...

Besides I continuously see many users praising Emacs just for Org
presence (they even may be completely non-technical users), I'm
personally think Org may be removed from Emacs distribution because:

1) all Reuben's argument seems sane;
2) there are situations when someone wants particular version of Org,
   and it may be not tne one bundled with Emacs. In this case someone
   should perform extra steps to ensure things are going the right way.
   When Org will be available only from ELPA, it will be SPOT for such cases.  

Reuben Thomas  writes:

> Now that Emacs has had package.el for some years, and Org is installable
> directly from GNU ELPA, would it be a good idea to remove Org from Emacs's
> source repository?
>
> The current situation is left over from before Emacs had package.el, and I
> see no compelling reason to keep it. Org is too big and distinct to be
> swallowed by Emacs; it doesn't make much sense to keep its current half-in,
> half-out state; so logically it seems sensible to take it out.
>
> I am asking this question from an Org point of view; I will ask the Emacs
> maintainers separately for their perspective.
>
> I think it would benefit Emacs too, as there would be less code to maintain
> (even though Org is quasi-external at present, it still has to build
> successfully as part of an Emacs build), and the Emacs distribution would
> be slimmer for non-Org users.
>
> Of course, Emacs "distributions" would still be able to include Org
> out-of-the box if they wished.
>
> -- 
> http://rrt.sc3d.org


signature.asc
Description: PGP signature