Re: [ANN] org-ql 0.4 released

[Michael Alan Dorman]

Adam,

I do recognize that melpa-stable is not in any practical way curated,
guaranteed, cross-tested, etc.---and that emacs' packaging doesn't even
necessarily provide what might be required for anyone to try to do any
of that.

On the other hand, I *also* don't assume that maintainers are incapable
of making a reasonable assessment of the stability of their packages, or
of making a personal choice to try to maintain API compatibility in some
sensible way, and so forth.

And you know what: my personal experience over the last five years
hasn't been subject to the problems you identify; perhaps I'm just
lucky.

Nevertheless, my experience leads me to be of the opinion that
abolishing melpa-stable would reek of making the perfect the enemy of
the good---breakage can happen, and some things on it are no better than
whatever happens to be up on melpa, and it's unlikely to ever improve to
be a perfectly curated set of package versions, and got knows some stuff
lags behind enormously...but I think that it is still an improvement to
give maintainers *some* strategy for trying to manage their packages and
their dependencies and communicate all this to their users, rather than
consigning every emacs user to doing individual curation for every
single package they ever use.

Given your position, though, could I suggest that you at least remove
dependencies from your packgaes that feature versions that can only make
sense with melpa-stable?  That's what ultimately started this: the fact
that your new release of org-ql depends on a version of org-super-agenda
that *looks* like you care about melpa stable.

Mike.

Adam Porter  writes:
> Michael Alan Dorman  writes:
>
>>> Hi friends,
>>>
>>> FYI, I've released org-ql 0.4.  It includes many improvements since 0.3.
>>>
>>> https://github.com/alphapapa/org-ql
>>
>> It would be nice if you could do a stable release of org-super-agenda so
>> that it could be installed from melpa-stable...
>
> Comments like yours lead me to the conclusion that MELPA Stable needs to
> be abolished.  I have been a proponent of the idea of MELPA Stable, so I
> don't say that lightly.
>
> I'll assume that you don't know what the technical issues are and offer
> an explanation.  Briefly:
>
> + MELPA Stable is nothing like what one might assume it's intended to be
>   like, e.g. Debian Stable or Debian Testing.  It provides none of the
>   benefits that Debian Stable and Testing provide.
>
> + MELPA Stable is, just like "regular" MELPA, a "rolling" collection of
>   packages developed without any coordination between maintainers.
>
> + The only difference is that MELPA Stable contains whatever versions of
>   packages that their maintainers have decided to tag with a version
>   number, rather than the latest commit to the master branch.  These
>   versions are not necessarily better, more stable, more reliable, or
>   more trustworthy than the untagged versions which appear in "regular"
>   MELPA.
>
> + Due to the lack of coordination between dependencies and their APIs,
>   version conflicts and breakage are a regular occurrence.  For example,
>   if package A depends on package B, and package B makes an API change
>   and tags a new MELPA Stable release, users of package A's MELPA Stable
>   version will see package A cease to work properly until package A, not
>   only commits a fix, but tags a new MELPA Stable version containing the
>   fix.  Since packages A and B do not share the same development
>   schedule, it is likely that their tagged-version release schedules
>   will not synchronize well.
>
>   If you are familiar with Debian, imagine if any upstream changes were
>   automatically pushed to Testing despite any freeze that might be in
>   place.  It would be virtually impossible to complete a freeze and make
>   a new stable release, and Testing and Stable would cease to be useful,
>   leaving only Unstable as a usable target.  This is the situation
>   between "regular" MELPA and MELPA Stable.
>
> For my packages, I tag stable versions for a few reasons:
>
> + To help users track changes in the changelog.
>
> + To help me separate new, possibly bug-introducing changes from
>   working, debugged code.
>
> + To help packagers in systems like Debian and Guix, who package stable
>   versions of some Elisp packages--and who, in so doing, take
>   responsibility for breakage.
>
> Now, I sympathize with not wanting to be vulnerable to potential
> breakage caused by the uncoordinated release of changes to packages on
> "regular" MELPA.  That is a real problem.  But the solution is not to
> use MELPA Stable.  The solution is to take charge of what packages you
> upgrade and when, rather than being at

Re: [ANN] org-ql 0.4 released

[Michael Alan Dorman]

Adam Porter  writes:

> Hi friends,
>
> FYI, I've released org-ql 0.4.  It includes many improvements since 0.3.
>
> https://github.com/alphapapa/org-ql

It would be nice if you could do a stable release of org-super-agenda so
that it could be installed from melpa-stable...

Mike.

Re: [O] Regression? Clocktable no longer includes TODO keywords

[Michael Alan Dorman]

Thanks for your reply (and all the work you do on org), Nicolas.

> This doesn't ring a bell. Anyway, the current behaviour sounds right,
> since you can get TODO state with the "TODO" special property anyway.

But that will actually end up in another column, won't it?

As a bit of background: I have, historically, harvested the "Headline"
column for a weekly report, which depends on the state of the headline
being included---not including it there, even if it can be in a separate
column, dramatically decreases the utility of the clocktable for me
because it becomes a lot more work to produce that report.

Of course maybe the answer is that I should just write the elisp to
generate the report, but that's a big chunk of work, too. :()

For the moment, I guess I'll just stick with 9.05

Mike.

[O] Regression? Clocktable no longer includes TODO keywords

[Michael Alan Dorman]

Given the following document:

* TODO Thingy
** TODO Sub-Thingy 1
   :LOGBOOK:
   CLOCK: [2017-07-12 Wed 07:15]--[2017-07-12 Wed 07:25] =>  0:10
   :END:
** DONE Sub-Thingy 2
   :LOGBOOK:
   CLOCK: [2017-07-12 Wed 07:25]--[2017-07-12 Wed 07:31] =>  0:06
   :END:

I would previously get a clocktable like (simulated):

#+BEGIN: clocktable
#+CAPTION: Clock summary at [2017-07-12 Wed 07:32]
| Headline  | Time   |  |
|---++--|
| *Total time*  | *0:16* |  |
|---++--|
| TODO Thingy   | 0:16   |  |
| \_  TODO Sub-Thingy 1 || 0:10 |
| \_  DONE Sub-Thingy 2 || 0:06 |
#+END:

Starting with (I believe) org 9.05, I get

#+BEGIN: clocktable
#+CAPTION: Clock summary at [2017-07-12 Wed 07:32]
| Headline | Time   |  |
|--++--|
| *Total time* | *0:16* |  |
|--++--|
| Thingy   | 0:16   |  |
| \_  Sub-Thingy 1 || 0:10 |
| \_  Sub-Thingy 2 || 0:06 |
#+END:

I don't see any note of this in ORG-NEWS, so I assume it's a
regression.  I haven't had a chance to really dig into it yet.

Mike.

Re: [O] stable org-plus-contrib

[Michael Alan Dorman]

phillip.l...@russet.org.uk (Phillip Lord) writes:
> I would like to use some of the packages in org-plus-contrib. So, I've
> added orgmode's ELPA archive. But I find being on the bleeding edge a
> little buggy.
>
> As far as I can see, there is no "stable" ELPA package archive, so I
> have to fall back installation from git. This seems somewhat backward to
> me; installing stable with git, an unstable from package.el.
>
> Is there any way of getting stable Org that I am missing?

FWIW, the versions in the org ELPA repository, though date-versioned,
appear to only be generated for tagged versions.

Mike.

[O] org ELPA broken (was: Re: Bug: bug for org-compile-file on Windows)

[Michael Alan Dorman]

Has the URL for Org ELPA moved?  Because if I look at
http://orgmode.org/elpa/, I don't see any updates since 11/18?

Assuming the build-org-pkg.txt file is intended to be a record of the
build process, it would appear there is an error preventing the code
from building correctly.

Mike.

Nicolas Goaziou  writes:

> Hello,
>
> Mirko Vukovic  writes:
>
>> I was not able to preview latex fragments using
>> org-toggle-latex-fragment (C-c C-x C-l)
>>
>> I traced the problem to the (shell-command ...) in org-compile-file
>> during the dvipng step.
>>
>> The problem was in the formatting of the destination file (the -o switch).
>> It consists
>> of the directory and filename.  Both were enclosed in double quotes, so
>> that when concatenated the string looked like this:
>> \"path\"\"filename\".extension
>
> Thanks. However, this issue was fixed a few days ago. The fix should be
> available in today's Org ELPA, or in the yet to be released Org 9.0.2.
>
> Regards,

Re: [O] org-blog 0.9 release

[Michael Alan Dorman]

Matt Price mopto...@gmail.com writes:
 On Wed, May 1, 2013 at 7:04 AM, Puneeth Chaganti puncha...@gmail.com wrote:
 On Wed, May 1, 2013 at 4:18 PM, Michael Alan Dorman
 If you don't mind, I will start looking at the org2blog code and seeing
 how cleanly I can implement these additional capabilities as handlers or
 filters for the exporter---and then maybe we could look for that
 back-end to live in contrib, and both our codebases could take advantage
 of it?

 That seems like a good plan.  I've been meaning to get this going for
 some time, but have been quite busy off-late.  I'll try to make some
 time for it, soon.

 Was there ever any progress on this?  I code so slowly I'd not likely
 be much help with the actual implementation but would be happy to pull
 from git and do some testing if that's of any use.

Well, it's not an ex-parrot---which is to say, I still have the
intention to work on it---but 1) my $DAYJOB has gotten busy, and 2) with
many of the additional features being Wordpress-specific, it demands
that I do some significant refactoring of my code for me to do it in a
way that doesn't tie the whole thing to Wordpress.

That said: Puneeth, it seems like most of your additional features are
currently implemented as post-processing bits---could you just grab the
new-exporter-based code that I have now and use that?  It's not an
all-singing, all-dancing solution, but it might get your users able to
use 8.0 sooner.

Mike.

Re: [O] org-blog 0.9 release

[Michael Alan Dorman]

Rafael rvf0...@gmail.com writes:
 Thanks a lot for your work! I just tried it and it worked for me, to
 post a basic org-mode file.

Thanks for trying it---it's always nice to hear that it works for
someone else, too.

I'm hopeful that, by having a fairly fleshed-out test suite included, if
it doesn't work for someone, the user and I should be able to track down
the issue fairly easily.

 Are you aware of https://github.com/punchagan/org2blog? It also has
 the purpose to post to wordpress from org, however its author has been
 busy lately, and apparently major work is going to be needed to make
 all its features to work with the new exporter. I hope that you could
 find the time and motivation to make your package deal with:

Yep, I'm aware of org2blog---I even used it for a while.  There were
various things about it for which I did not care, and they seemed fairly
fundamental and unlikely to change.

I suspect writing a blogging addition for org-mode is today's equivalent
of writing your own templating engine for Perl: the bar for entry is low
enough that the slightest disagreement with an existing one is cause for
writing your own. ;)

 - inclusion of image files
 - matematical symbols (that is, wordpress can display LaTeX stuff like
   $latex a^2+b^2=c^2$ nicely.
 - syntax code highlighting, native to wordpress. 

I do want to add more sophisticated content handling capabilities.

Image (or other) attachments is an item I want myself.  While I support
the idea of other, more sophisticated formatting, since I don't have a
direct stake in most of them, I'm not sure what the best way to present
them is.  If org2blog's presentation seems sensible, I will probably
follow that just to be compatible.

Incidentally, I've tagged 0.10 which has converted to the org-8.0
exporter.

In fact, it's probably good that you brought this up now: I do need to
implement some additional processing of the exported content (even when
you present it with full HTML input, where whitespace shouldn't matter,
stupid WordPress inserts line breaks whereever there are newlines).

I figure if I design it correctly, the additional processing should be
extensible to support the sort of rich content you're talking about as
well.

Mike.

Re: [O] org-blog 0.9 release

[Michael Alan Dorman]

Puneeth Chaganti puncha...@gmail.com writes:
 Or, if it seems reasonable, we could club the two projects into a
 single one to give the users something that's better than a sum of the
 parts!

Hi, Puneeth,

While I'm not sure the structure of the two tools is really amenable to
being joined---the code is very, very different, and I am, of course,
biased toward mine ;)---it seems to me *that* a common ox-blog (or
whatever) back-end could be a good point of collaboration: it would help
jump-start getting org2blog to where it work with 8.0, and it would get
org-blog the more sophisticated export capabilities that Rafael seeks.

What I'm imagining is an exporter derived from org-html (of which I've
already got the basics done) that adds on the additional features you've
implemented in org2blog.

If you don't mind, I will start looking at the org2blog code and seeing
how cleanly I can implement these additional capabilities as handlers or
filters for the exporter---and then maybe we could look for that
back-end to live in contrib, and both our codebases could take advantage
of it?

Cheers,

Mike.

[O] org-blog 0.9 release

[Michael Alan Dorman]

Dear org-mode users,

I've just tagged version 0.90 of my org-blog minor mode on github[1].

This is intended to be a simple but powerful assistant to using Org for
writing blog posts---there's only two commands at this point, and I
don't anticipate that number going beyond three anytime soon (though I
do have that third one planned! ;)

At the moment it only supports WordPress blogs, but the design is very
modular, and adding support for other back-ends (including, I hope,
static publishing back-ends) should be relatively painless.  If it's
not, I would be happy to change things to make it so, once I understand
the issues.

I have one outstanding bug[2], that timestamps get mangled.  I thought
I'd squashed it, but apparently not.  I need to create a test and track
that down.

The only other immediate issue I see is that it is still using the 7.8.x
exporter---converting to (or supporting in parallel if possible) the 8.0
exporter is next on my list of things to do.

I wrote a series of posts going through the implementation on my
blog[3]---all authored with org-blog itself.

Although this is the first thing I've written for Emacs outside of
hacking on my .emacs.d, I think the code is fairly clear.  I would
appreciate feedback, and would enjoy and even solicit assitance with
some things: for instance, as a Debian user, I turn out to not know
MELPA/Marmalade from a hole in the ground---so if someone was motivated
to create the changes to support package installation though emacs, I
would be quite happy to merge it. ;)

There's a TODO list of things I hope to work on, and I would be happy to
add to that as well; knowing that people are using it is going to be the
greatest motivation for things to happen---otherwise I will probably
plod along doing things in my own sweet time, since it's working pretty
well for me so far.

Cheers,

Mike.

[1] https://github.com/mdorman/org-blog
[2] https://github.com/mdorman/org-blog/issues/16
[2] http://doyouevenlisp.com/tag/org-blog/

Re: [O] BUG: coderef labels not stripped when tangling

[Michael Alan Dorman]

Bastien,

 Indeed.  This show now be fixed (both in maint and master).
 Please let us know if not.

Thanks so much for this and all the work you do on org.  I've finally
taken the plunge to learn emacs lisp, so perhaps before long I'll be
able to contribute as well. ;)

Mike.

Re: [O] BUG: coderef labels not stripped when tangling

[Michael Alan Dorman]

Hi, Sebastien,

Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
 Or a feature, with the consequence that you should put those refs as comments
 (with the appropriate syntax in your language).

That is an excellent suggestion for resolving my immediate issue that
had not occured to me at all.  It believe it does mean that the
presentation of the code ends up with seemingly empty comments where the
coderefs were, but that's a relatively minor thing.

 But, yes, those comments stay as well in your tangled code, which you may not
 like.

It seems counter-intuitive to me that text that is regarded as
meta-information when rendering for presentation is not treated
similarly when tangling---a needless mismatch between the two processes.

But thanks for your workaround suggestion, I will definitely take
advantage of it.

Mike.

[O] BUG: coderef labels not stripped when tangling

[Michael Alan Dorman]

Using Org-mode to write in a literate style is a lot of fun.  When I
read about coderef labels, they seemed likely to make it even better.

The only problem is that they aren't stripped during tangling. If you
tangle this:

#+BEGIN_SRC sh -n -r :noweb tangle :shebang #!/bin/sh :tangle tangle-test.sh
echo Working (ref:working) 
#+END_SRC

You end up with:

#!/bin/sh

echo Working (ref:working)

That seems like a bug.

Mike.

[O] Tangle won't strip coderef labels?

[Michael Alan Dorman]

I've recently started to use Org-mode to write some small utilities in a
literate style.

I then stumbled upon the docs about coderef labels, which seemed like a
great way to minimize having to basically repeat the content of code in
the documentation about the utility's design.

The only problem is that they aren't stripped during tangling.  So if
you have a doc like:

#+BEGIN_SRC sh -n -r :noweb tangle :shebang #!/bin/sh :tangle test.sh
echo Working (ref:working) 
#+END_SRC

When you tangle the doc, you'll end up with:

#!/bin/sh

echo Working (ref:working)

I'm assuming this isn't intended behavior, since I can't find anything
in the docs about it.

I appreciate any help---I've done some spelunking around the source, but
it's not at all obvious to me how this all fits together, so I'm afraid
I'm not able to offer a patch, assuming it's a bug.

Mike.