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
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.
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.
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.
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.
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,
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.
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.
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.
Dear org-mode users, I've just tagged version 0.90 of my org-blog minor mode on github. 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, 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---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.  https://github.com/mdorman/org-blog  https://github.com/mdorman/org-blog/issues/16  http://doyouevenlisp.com/tag/org-blog/
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.
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.
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.
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.