Re: [Worg] Proposing a few CSS changes

2021-09-25 Thread Adam Porter
Hi Timothy,

Timothy  writes:

>> I find it frustrating when I’ve configured my browser to […]
>
> I think this is the source of our differences of opinion. I personally haven’t
> touched my browser’s default CSS, and am not a fan of the default styling, but
> clearly you have changed your browser’s default CSS to something that you find
> works well.
>
> This leads me to a slightly conflicted position, because I both like the idea
> that if the user has set up their browser to use a font they like, a text size
> they like etc. that sites would respect that. But I also suspect that very few
> people ever do this, and am not that happy about how things look with 
> unmodified
> browser defaults. Here I lean towards trying to ensure the best average
> experience, and unfortunately I think that means overriding the default CSS.

No, I haven't changed my browser's default CSS, only the font settings
in preferences.  These are standard features, having been present on
browsers for decades, are easily adjusted by any user, and ideally they
should take into account platform defaults as well.  These include both
font family and size.

We should keep in mind that the platforms and systems which view the
site are wide and varied.  Some users may have high-DPI monitors in dim
environments, others may have low-DPI monitors in bright environments;
some users may have perfect eyesight, while others may be legally blind.
Some users may use an OS that uses strong hinting (e.g. MS-Windows),
while others may use one that does little-to-none (e.g. MacOS).  Because
of those factors, there is no good default for us to use; what looks
good on our systems may look very poor or even unreadable to other
users.

So I think it's very important to respect the user's settings,
especially for long texts and documentation (i.e. not the "home page"
parts of Web sites whose purpose is to present projects as a whole).




Re: [BUG] 81c7a2dee8 misaligns time lines in agenda

2021-09-25 Thread Adam Porter
Hi Bastien,

On Sat, Sep 25, 2021 at 2:46 PM Bastien  wrote:

> > Since Bastien made this change, and it's very simple, I'm guessing he'll
> > know what the proper fix is.  :)
>
> The change I made was superceded by Nicolas series of patches:
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/?qt=grep=fix+org-duration-to-minutes+error

Oops, thanks.  I found your commit by searching the log, but I should
have checked blame on the code to see if it had been changed since
then.

> I agree the new alignment looks wrong: the starting time should
> bit right-aligned with other time above/below, and the separating
> dash should not spaces for "HH:MM" time strings on the right, but
> only for " H:MM".
>
> Would you have time to prepare a patch for this?

Unfortunately, I'm unable to reproduce it on my system, even using Org
9.4.6 in a clean Emacs config.  For some reason, it only seems to
happen on the org-super-agenda repo's GitHub Actions CI (which tests
on Emacs 26.3, 27.1, and snapshot versions).  So I'm not sure what's
going on.  :(  Hopefully Nicolas's changes solve the problem for Org
9.5 (if the problem is really one after all).



Re: [Worg] Proposing a few CSS changes

2021-09-25 Thread Adam Porter
Hi Timothy,

Timothy  writes:

> I’m a big fan of the shift to a fixed em-based max width. However, I’m not 
> quite
> sold on a few of the other changes, for instance the font change. While it 
> does
> vary, I must say than in particular I find the default serifed font of 
> browsers
> somewhat unattractive. Have you considered instead a sans-serif system font
> stack? For example, this is what I used on the homepage:
> ┌
> │ -apple-system, BlinkMacSystemFont, San Francisco, Helvetica Neue, 
> Helvetica, Ubuntu, Roboto, Noto, Segoe UI, Arial, sans-serif;
> └

I think the default serif font varies by platform, e.g. MacOS browsers
will use a much different one than Windows ones.  As well,
platform-based differences in font rendering (especially between MacOS,
Windows, and GNU/Linux) have a significant effect on the end result.

IMHO, I prefer not to "chase" issues like this by trying to account for
them in CSS.  This is why I prefer to remove font specifications for
documentation pages: let the user decide.  I find it frustrating when
I've configured my browser to use a readable font for long documents,
but the site "commandeers" the font to something that may only look nice
and readable on the author's system.

As for serif vs sans-serif, I think serif fonts are much easier to read,
and AFAIK "research" backs this up.  :)  That's not the only
consideration, of course, and I wouldn't suggest changing the main Org
site to use a serif font.  But for wiki/documentation sites, I think
serifs are a better choice.

But if we remove the font specification altogether, users who prefer
sans-serif fonts and use that setting in their browsers will see
sans-serif.  I think that, for long texts and documentation, it's
important to let the user control the appearance of main body text as
much as possible.

> Regarding the header colour, while I’m not much of a fan of the original grey,
> perhaps this would be a chance to introduce some visual ties with the rest of
> the site and the logo, for example by setting the heading colour to `#587e72' 
> (the
> dark gree from the Org logo).

I think that'd be nice, yes.

> I also tend to find the default font size slightly to small on most browsers.
> I’d be in favour of bumping up the base fontsize to `1.2rem' and changing the
> width restriction from `60em' to `60rem' so it remains constant.

I'll push back on this change strongly.  :)  I really hate it when sites
increase the default font size for body text.  I've configured my
browsers to use the font size that's most readable and useful for me.
There seems to be an "epidemic" of sites increasing the default font
size nowadays; sometimes only one or two paragraphs are visible on a
single screen of text.  Again, I think this is an attribute we should
leave entirely to the users to configure.

> Lastly, on padding, I feel you may have been a bit over-zealous in your 
> removal
> of padding from headlines. IMO a bit more space helps visually separate 
> sections
> and let them “breath”, and browsers defaults tend to pack things a bit more
> densely than I would.

I could live with adding a little bit of padding back, but not too
much.  There's already way too much whitespace on the Web.  ;)

If you like, I'll prepare a new "patch" and post screenshots so we can
try to reach consensus.

-- 
Thanks,
Adam




Re: [Worg] Proposing a few CSS changes

2021-09-25 Thread Adam Porter
Bastien  writes:

> Hi Adam,
>
> Adam Porter  writes:
>
>> If these are agreeable, I can apply them to the Worg repo.
>
> Sure, please go ahead!  Thanks,

Hi Bastien,

Thanks.  Since Timothy has some thoughts on these changes, I'll wait
until we come to a consensus on them.  :)




Re: [ANN] org-ql 0.6 released

2021-09-22 Thread Adam Porter
Juan Manuel Macías  writes:

> Hi Adam,
>
> Thank you very much for this great package. I could no longer live without
> org-ql/helm-org-ql :-)

Hi Juan,

Thanks for the kind words.  I'm glad it's useful to you.  :)




[ANN] org-ql 0.6 released

2021-09-22 Thread Adam Porter
Hi friends,

FYI, I just released version 0.6 of org-ql.  Please see the changelog
here:

https://github.com/alphapapa/org-ql#06

-- 
Thanks,
Adam




Re: Heading toward Org 9.5

2021-09-21 Thread Adam Porter
Bastien  writes:

> I'll work on integrating small bug fixes and feature improvements
> listed on https://updates.orgmode.org during this week, aiming at
> releasing Org 9.5 over the next week-end.
>
> If your patch does not appear on updates.orgmode.org and didn't 
> receive an answer on the list, please send me an email pointing at
> the reference on orgmode.org/list.

Hi Bastien,

Back in July I mentioned a bug I found:

https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00603.html

If this could be addressed for Org 9.5, I would be grateful.  As it is,
it makes it difficult to keep my org-super-agenda tests working cleanly
on Org versions both before and after 9.4.6.

--
Thanks,
Adam




[BUG] 81c7a2dee8 misaligns time lines in agenda

2021-07-25 Thread Adam Porter
Hi,

In the course of working on a PR for org-super-agenda [0], we found that
a recent change to Org, commit 81c7a2dee8 [1], causes a misalignment in
the way time lines in the agenda are displayed.  The org-super-agenda
test suite shows this change when results from Org 9.4 and 9.4.6 are
compared.  For example, in this diff of an agenda buffer:

#+BEGIN_EXAMPLE diff
 @@ -2,8 +2,8 @@
 Wednesday   5 July 2017
 
  Today
-  test:7:02.. Sunrise (12:04 of daylight)
-   8:00.. 
+  test:   7:02..  Sunrise (12:04 of daylight)
+  8:00..  
   10:00.. 
   12:00.. now - - - - - - - - - - - - - - - - - - - - - - - - -
   12:00.. 
#+END_EXAMPLE

The old lines, with single-digit hours, were properly aligned with the
lines with multi-digit hours, but the new lines are one character too
far to the left.

Since Bastien made this change, and it's very simple, I'm guessing he'll
know what the proper fix is.  :)

Thanks,
Adam

0: https://github.com/alphapapa/org-super-agenda/pull/167
1: 
https://code.orgmode.org/bzg/org-mode/commit/81c7a2dee8e6d0c5e58d0cb4ca97cfc9477ff660




Re: [ANN] org-ql 0.5 released

2020-11-23 Thread Adam Porter
Hi Jean Louis,

Thanks for your feedback.

>As the more complexities are created then even org-ql becomes complex
>to work with just as SQL becomes more and more complex with more
>relational tables and pieces of information.

The idea of Org QL is to make such things simple.  For example, you
don't need to know Elisp to run "M-x org-ql-search RET" and type this
query:

  todo: priority:A deadline:to=3

Which would display all to-do items with priority A due within the next
3 days.

> For org-ql I hope that your system can be used as underlying layer or
> low level language for functionality that may help user to think their
> stuff without thinking on underlying functionality. You have offered
> examples and those are in my opinion too abstract for Org users. They
> are fine for programmers or more skilled users.

The org-ql-search and org-ql-view UIs are built on the underlying org-ql
library.

> High level functions would be something like a wizard with code
> generation, that creates hyperlink for the user without user having to
> think about org-ql

> It could be something like `ql-meta' or `ql-summary' that is created
> on the fly and that collects information for agenda like view, and
> creates Org file with hyperlink that invokes the agenda like view.

This is already implemented.  Search views can be built incrementally
using the Transient UI.  See the screencast GIFs in the readme.

> Entries from the past week could be something on the fly. Additional
> hyperlink in the ql-summary could have the user to customize sorting
> without thinking of the underlying code.

See "M-x org-ql-view-recent-items RET".

> Find entries matching a certain CUSTOM_ID could be automatically
> generated heading:
>
> *** Entries by CUSTOM_ID
>
> ONE TWO THREE MORE HYPERLINKED AND SORTED CUSTOM_IDS
>
> when user clicks on any of those this would invoke the org-ql and show
> those entries. By click and by thinking, not necessarily by
> constructing the org-ql.
>
> Similar could be for deadlines.

This is already implemented.  See the sections "Links" and "Dynamic
Blocks" in the readme.

> Music could be sorted by author in the summary Org file that has many
> hyperlinks which in turn use the org-ql to activate music, or annotate
> it.

Those are interesting ideas for future work, thanks.

> Your file `examples.org' has some hyperlinks under the heading
> Contents and none of hyperlinks work. Why is it so?

I went to https://github.com/alphapapa/org-ql/blob/master/examples.org
and clicked the links in "Contents" and they work for me.

> In the end I could not test examples as it asks for org-ql-search that
> in turn asks for super-agenda that I do not have.
>
> I wonder how could I install the package that requires
> org-super-agenda and that it starts working. Maybe you missed one
> (require 'org-super-agenda) as when I wish to install it, it does not.

If you install org-ql from MELPA or with Quelpa, org-super-agenda will
be installed automatically.  The `require' function does not install
packages.

Thanks,
Adam




[ANN] Org QL Custom Predicates Tutorial

2020-11-22 Thread Adam Porter
Hi again friends,

Following the release of org-ql 0.5, I've pushed a new feature to the
0.6-pre branch: custom predicates.  You can now easily define custom
predicates to make searching easier.  For example, you could define a
custom (person) predicate like so:

#+BEGIN_SRC elisp
(org-ql-defpred person (name)
  "Search for entries with the \"person\" property being NAME."
  :body (property "person" name))
#+END_SRC

Then you could do a search for entries in your agenda files having the
property "person" with the value "Bob" like this:

#+BEGIN_SRC elisp
(org-ql-search (org-agenda-files) "person:Bob")
#+END_SRC

Please see the tutorial for a walkthrough of the process of building a
custom predicate incrementally:

https://github.com/alphapapa/org-ql/blob/master/examples/defpred.org

Thanks,
Adam




[ANN] org-ql 0.5 released

2020-11-22 Thread Adam Porter
Hi friends,

FYI, I've released org-ql 0.5.  It includes many improvements since the
last release, including some unique features, such as linking to and
bookmarking agenda-like views for easy access, and designing agenda-like
views incrementally with a Magit-like UI.

Changelog: https://github.com/alphapapa/org-ql#05

Please let me know if you have any feedback.

Thanks,
Adam




[ANN] org-super-agenda 1.2 released

2020-11-21 Thread Adam Porter
Hi friends,

FYI, I've released version 1.2 of org-super-agenda, which includes
several improvements since the last stable release.

https://github.com/alphapapa/org-super-agenda#changelog

Please let me know if you have any feedback.

Thanks,
Adam




[ANN] org-ql: Bookmarks, dynamic blocks, and links

2020-11-11 Thread Adam Porter
Hi all,

FYI, I've recently added some new features to org-ql[0]:

1.  Dynamic Blocks[1] allow you to insert a block that lists headings in
a document which match a query, formatting them into certain columns.
For example (please excuse the wrapped header line for this message):

#+BEGIN: org-ql :query "todo: priority:A,B" \
:columns (todo (priority "P") deadline heading) \
:sort (deadline priority) :take 7 :ts-format "%Y-%m-%d %H:%M"
| Todo | P | Deadline | Heading   |
|--+---+--+---|
| TODO | A | 2017-07-07 00:00 | Take over the world   |
| TODO | B | 2017-07-10 00:00 | Renew membership in supervillain club |
| TODO | A | 2017-07-15 00:00 | Take over the universe|
| TODO | B | 2017-07-21 00:00 | Internet  |
| TODO | A | 2017-08-01 00:00 | Spaceship lease   |
| TODO | A |  | Skype with president of Antarctica|
| TODO | B |  | Take over Mars|
#+END:

2. Links[2] allow you to access an Org QL View by clicking on a link,
like:

[[org-ql-search:todo:NEXT priority:A]]

It integrates with the Org link storing and inserting commands (`C-c l`
and `C-c C-l`), so you can easily create a custom search view and insert
a link to it into an Org file.  Then you can click the link to run the
search.

3.  Bookmarks allow Org QL View buffers to be bookmarked with Emacs
bookmark commands, like "C-x r m".  This also integrates with my new
buffer/window/frame/workspace-restoration package, Burly.[3]

Together, these features allow agenda-like views and searches to be
easily and quickly designed, saved, and accessed.

Please let me know if you have any feedback.

Thanks,
Adam

0: https://github.com/alphapapa/org-ql
1: https://github.com/alphapapa/org-ql#dynamic-block
2: https://github.com/alphapapa/org-ql#links
3: https://github.com/alphapapa/burly.el




Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-06-01 Thread Adam Porter
Hi Bastien,

On 6/1/20, Bastien  wrote:
> Hi Adam,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html
>
> ahem, my bad.  I made this bold (and wrong) move, and I broke code out
> of org-mode.
>
> I understand your proposal, and it's always good to be reminded that
> many people depend on Org's code out there.  It is not easy to spend
> time working on Org *and* tracking all these interesting extensions.

Of course, no one could be expected to keep track of all those things.
Such is the nature of writing software that runs in a Lisp image,
where anyone can use anything, and does.

> I agree with Nicolas that we should not put more constraints on the
> shoulders of Org current developers, especially because their time is
> limited - and obviously not enough to cope with every request.

I mostly agree with you.  My request is simply that, when a change has
the potential to break third-party packages, and it's a change, such
as this one, that mostly moves code around for organizational
purposes, that it be delayed until the next major version.  My goal
for such a policy would be to reduce the frequency of such changes
that third-party package authors have to write compatibility code for.
The (if (version< org-version ...)) workarounds become confusing for
authors and users, and somewhat of a maintenance burden.

> That said, we can make it easier for third-party developers to know
> what changes will be released in the future.
>
> See the "Upcoming changes" in https://updates.orgmode.org
>
> You can subscribe to this RSS feed:
> https://updates.orgmode.org/feed/changes
>
> Or check the data directly:
> https://updates.orgmode.org/data/changes
>
> To announce the change you see, I just used this email header:
>
>   X-Woof-Change: 9092c289 9.4
>
> That is the commit number where the change happens and the version
> in which the change will be released.
>
> The list of upcoming changes is emptied when a new major released is
> done, because the changes are then advertized in this file, as usual:
> https://orgmode.org/Changes.html
>
> I think that's a tiny distributed effort for developers and a easy
> way to track changes for third-party developers.

That's a very clever way to do it!  Thanks for your work on this.  If
it's feasible, you might also consider allowing committers to put such
a header in the git commit log and parsing it out of that, which could
make it even easier.

Thanks,
Adam



Re: org-clip-link should be included in core

2020-05-24 Thread Adam Porter
On Sat, May 23, 2020 at 10:14 AM Bastien  wrote:

> So IIUC the need is to easily remove the link part of a link.
>
> I pushed a change to make this easier.  Now you can hit `C-c C-l' on
> a link, empty the link part, keep the description and RET to get only
> the description inserted as non-link text.
>
> Let me know if this seems okay for you.
>
> I'm copying Adam as he may comment on that too.

That seems like an elegant solution.  Thanks, Bastien.



Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-04-22 Thread Adam Porter
Hi Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>
> [...]
>
>> Thankfully, Kyle has proposed a patch to revert that change.  I hope
>> it is merged.
>>
>> If it is not, when a new Org version is released with those changes
>
> What makes you think a new Org would be released in this situation,
> without fixing it first?

I don't know what will happen.  I don't know whether the Org maintainers
would consider the problem serious enough to avert (as you said later,
"it happens").  That's why I pointed out what the consequences would be
if the patch isn't merged, to encourage its merging.

>> I think changes like this should not be made without very careful
>> consideration of the wider implications.  These kinds of changes
>> create a not-insubstantial burden on maintainers of Org-related
>> packages to keep up with churn and maintain compatibility with
>> multiple Org versions (which are used in the wild for years--I know
>> of users still using Org 8, as well as Org 9 versions that are
>> included with older Emacs versions (e.g. Emacs 26.3 is still stuck in
>> Debian unstable, not migrating to testing, stable, or backports)).
>
> [...]
>
>> So, I propose that changes like these should not be made except in
>> major version increments, e.g. this change should have been delayed
>> until the release of Org 10.0.  It would be helpful for users and
>> package authors if they knew that changes like these would not be
>> made until the next major version increment.
>
> FWIW, I think this is too strong a requirement.
>
> This breakage is unfortunate, and I can hear the consequences it has
> on the Org ecosystem, but, hey, it happens. Note that moving part of
> Org elsewhere usually introduces less friction. This is a relatively
> exceptional situation.

Of course, I am biased here, but I feel like it's not quite as
exceptional as it ought to be.  The more Org-related packages I make and
maintain, the more version-specific workarounds I have to add due to
changed function names, signatures, etc.  These are sometimes necessary,
of course, but I think they should be made more carefully and
deliberately.

Of course, Org doesn't make any promises to third-party packages.  But
that is the issue, isn't it?  I'm saying that I think it should start
taking this issue a little more seriously.  :)

> Master is an unstable branch, relatively open to experimentation.
> Moreover, that experimentation happens before deciding if the next
> release should be 10.0 or 9.4, so it wouldn't help users or package
> authors.

That is a matter of policy, which is what I'm proposing.  When such a
change is desired (symbol name, function signature, etc), it should be
targeted at the next major version increment.  If the project as a whole
is not ready to make that increment, that change should be delayed until
then--it can be developed in a branch and merged when preparing the
major release.  These kinds of changes could even be documented in
advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call
it, which would be more explicit and referenceable than merely a mailing
list post.

> It doesn't mean we cannot do better here. For example, I think we
> could improve the way Org loads its libraries. Ideally, external
> libraries should only (require 'org), and optionally, (require 'ox-*)
> or (require 'ol-*). Thus, changes like the one discussed here would be
> implementation details. For example, "ox-hugo.el" requires directly
> "ob-core.el", and now "org-refile.el", which is, IMO, a path to
> troubles. It should only require "org.el".
>
> The current situation is tricky though: "org.el" requires some
> libraries (e.g., "org-key.el", "org-table.el", ...), and some
> libraries require "org.el" (e.g., "org-capture.el", "org-element.el",
> ...). I expect "org.el" to be the entry point for the Org package, so
> loading should happen in one-way only.
>
> This would not solve everything, but it would certainly make things
> smoother for external libraries.
>
> WDYT?

That is a good idea, and one that needs addressing.  I'd be glad to give
some feedback on it, but in a separate thread, please, because it seems
like a different matter from the issue I'm raising and the proposal I'm
making.

Thanks,
Adam




Re: [ANN] org-ql 0.4 released

2020-04-22 Thread Adam Porter
David R  writes:

> On Saturday, January 25, 2020, Adam Porter  wrote:
>
>> I care about stability, not MELPA Stable.  It's your choice to use MELPA
>> Stable, and you're free to upgrade or downgrade individual packages to
>> work around such occasional, temporary breakage caused by it--the pieces
>> are yours to keep.  I'm sorry for any inconvenience, but your config is
>> up to you.
>
> It seems to me that this last statement ("Your config is up to you"),
> or perhaps the point of view that produces it, is not self-evident
> when applied to package versions. I think that in some way it's near
> the heart of the controversy.
>
> Maybe for me personally, my config being up to me (regarding package
> versions) is a disadvantage. I gratefully make use of a number of
> packages that I don't fully understand, and if I was required to study
> all of them until I was confident that I *did* fully understand them
> before installing, I'd just give up using Emacs at all.

That is not what I am suggesting.

I suggest that you:

1.  Keep your Emacs config backed up, preferably with version control,
including all installed packges.

2.  Upgrade packages deliberately, not "upgrade all upgradable
packages."

3.  When you discover a problem caused by an upgrade, roll-back to a
known-good configuration until you have time to debug the problem.

This is what I recommend to all Emacs users.  It does not require
understanding any packages' source code.

Elisp has no inter-package API.  It's just a Lisp machine.  Elisp
packages are just symbols that you load into your image.  There is no
actual separation between packages' symbols.  There are no versioned
APIs, no synchronized transitions.

Each user's configuation, image, set of installed packages, etc. is that
user's responsibility.  In that sense, it's no different from a computer
system as a whole: you choose what software to install on it.  If you
like or need a certain version of certain software, it's up to you to
ensure that you have a copy of it available.  If you upgrade some
software and it doesn't work anymore with some other software version,
it's up to you to deal with it.

One of Emacs's chief strengths is user empowerment.  That doesn't mean
that users need to know how everything works--not even the core Emacs
developers do.  It means that you should know enough to maintain the
operability of the system, like you generally do for the rest of your
computer system.

The Emacs package "ecosystem" is not a "vendored" system.  It's not like
Debian, with thousands of relatively curated packages maintained as a
middleman, expected to work together in a stable release.  In Emacsland,
Each package (outside of Emacs and ELPA, and somewhat within ELPA as
well) is developed independently.

Nor should Emacs be treated like other software systems that are
live-updated whenever the developers hit the "push" button, with users
expecting the latest everything to work together all the time because
one party (ostensibly) takes responsibility for ensuring that.

Emacs gives the user the power.  And with great power...well, you know.

Having said all that, the problems with MELPA Stable are, in a sense,
artificial, and they're orthogonal to these general issues.  I can only
recommend, again, to not use it.  If you're lucky, it will work fine.
When it doesn't, the solution will involve not using it.  So you might
as well just skip it.  If you want less-frequent package upgrades, just
don't upgrade your packages so frequently.  Or use something like Quelpa
or Straight or Borg, where you can easily install the package versions
you want.




Policy proposal: Do not move existing functions/macros except in major version increments

2020-04-16 Thread Adam Porter
The relatively recent moving of org-get-outline-path to org-refile.el
has caused breakage in Org itself in several places, e.g.

https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html

Thankfully, Kyle has proposed a patch to revert that change.  I hope it
is merged.

If it is not, when a new Org version is released with those changes
(actually, sooner, because some users run the master branch), it will
cause further breakage in out-of-tree packages and code in user
configurations.

I think changes like this should not be made without very careful
consideration of the wider implications.  These kinds of changes create
a not-insubstantial burden on maintainers of Org-related packages to
keep up with churn and maintain compatibility with multiple Org versions
(which are used in the wild for years--I know of users still using Org
8, as well as Org 9 versions that are included with older Emacs versions
(e.g. Emacs 26.3 is still stuck in Debian unstable, not migrating to
testing, stable, or backports)).

For my own packsges, I would expect to get multiple bug reports for
several of my packages, which means that for each one, I then have to
deal with the report, make a fix, test it, log it, push it, close the
bug report...and for all that, nothing is gained.  It adds up, and it's
frustrating and demoralizing.

Of course, I am not opposed, in principle, to refactoring and
reorganization of this sort.  Org is a huge project, and it certainly
could benefit from these kinds of changes, in general.

So, I propose that changes like these should not be made except in major
version increments, e.g. this change should have been delayed until the
release of Org 10.0.  It would be helpful for users and package authors
if they knew that changes like these would not be made until the next
major version increment.

If this is agreeable to the Org maintainers, I'd ask that it be
documented in the project and announced in the NEWS file.

Thanks,
Adam




Re: I'm slowly coming back

2020-04-13 Thread Adam Porter
Hi Bastien,

I've been keeping an eye out for you!  :)  Glad to hear you're well, and
I'm looking forward to your return.

Adam




Re: Assistant to remove unused IDs of org-id

2020-04-13 Thread Adam Porter
Marc-Oliver Ihm  writes:

> as I use the excellent package org-id in a somewhat non-standard way,
> I tend to produce IDs, that are not referenced from anywhere. Org-id
> handles this great and does not suffer in performance, but eventually
> I want to remove those unreferenced IDs.  Therefore I have written a
> small interactive assistant:
>
> https://github.com/marcIhm/org-working-set/blob/master/org-id-cleanup.el
>
> to help with removing those IDs.  The assistant (interactive function:
> org-id-cleanup) is quite detailed with its instructions and checks, so
> that the risk of doing harm ist reduced to a minimum, although not to
> zero (therefore the first step is to ask for a backup).
>
> In any case I wonder, if this functionality (removing unreferenced
> IDs) could be helpful for anyone else.
>
> So please feel free to have a look.  Finally I would be grateful for
> any comment whatsoever (e.g. regarding the name of org-id-cleanup.el).

Hi Marc,

Thanks, this looks useful.  I posted some feedback as an issue on the
repository.

Adam




Re: virtual org-mode meetup tomorrow 11am EST

2020-03-29 Thread Adam Porter
Ihor Radchenko  writes:

> FYI:
> I have recently stumbled upon a FOSS service for video conferencing:
> https://meet.jit.si/ (recommended in Tor blog
> https://blog.torproject.org/remote-work-personal-safety) 
>
> Might be another option for future meetings.

Yes, that's what was used for EmacsConf 2019.  It seemed to work well
enough.  See the archived videos.




Re: Automatic formatting of the table as you type

2020-03-29 Thread Adam Porter
ndame  writes:

> As for org-at-table-p being slow storing the start and end position of
> the table could be a solution, so if point is between them then there
> is no need to check org-at-table-p again.
>
> org-table-align seemed fast enough for me when I tried the posted
> code, but if it's slower for large tables then the code could measure
> the time it takes to perform the alignment for the current table and
> if it's above a certain threshold then it could introduce a bit of
> idle delay for the update, so it doesn't hold back the user from
> typing, and if the alignment is fast then it could perform the update
> without delay.
>
> Anyway, I think if implemented properly then this feature could be a
> worthy addition to org, even as default if it works well, because it's
> a much better user experience and a much better first impression for
> new users, instead of the current default fragile table which falls
> apart during typing and fixed only when TAB is pressed.

I suggest being very careful with this.  While it's a very nice feature,
it's bound to be slow with large tables.  And it is very frustrating for
users when typing becomes laggy.  Most users who encounter it would
probably not know if there's a way to fix the problem, e.g. by disabling
a feature, because they probably wouldn't even know what to look for.
Most would probably think it a bug, and it could harm Org's and Emacs's
reputation, making people think they're inherently slow or laggy when
typing.

Pressing TAB (or any other key that moves to the next field) to realign
a table is not a significant burden.  A feature like this should
probably remain an add-on package, or at least disabled by default.




Re: org-pop-mode

2020-03-18 Thread Adam Porter
"Mark E. Shoulson"  writes:

> Heh; fair enough.  The filename originally was "org-level-end.el", I
> think; I started using the catchier "org-pop" because... well, it was
> catchier.  It made sense in my mind, in the "push"/"pop" sense used
> with stacks in programming, that you "push" to a deeper level and this
> library would allow you to "pop" back up to a higher one.  I'll see if
> I can think of something better, thanks.

Well, org-heading-push-pop wouldn't be a /great/ name, but the push/pop
paradigm is understandable, so you might consider that.  :)

>
>> 2.  In the code, I saw you comment about cl-flet, and I see you using
>> fset and unwind-protect in the org-pop-with-continuations macro.
>> Instead, use cl-letf with symbol-function, like:
>>
>>(cl-letf* (((symbol-function 'foo)
>>#'my-foo)
>>   ((symbol-function 'bar)
>>(lambda ()
>>  ...)))
>>  BODY)
>>
>> See also Nic Ferrier's package, noflet.
>
> I'll take a look, thanks.  It's questionable whether I really should
> even be messing about with that macro anyway.  I musnt have removed the
> comments, but I had a whole thing there about how I had been trying
> with cl-letf and/or cl-flet and it didn't work. Thing is, cl-flet,
> according to the docs, (info:cl#Function Bindings) is strictly
> *lexical* binding, which is not going to cut it.  cl-letf might be
> different; the docs are different about it, but I am pretty sure I
> tried it and it didn't work, or didn't work "enough of the time."  But
> maybe I had it wrong, and maybe noflet will succeed.

The issue is what the macros expand to.  cl-letf rebinds the function
symbols, just like fset, so it affects all code that runs in Emacs until
the function symbols are set again.  cl-flet expands into lambdas bound
to variables and replaces calls to them with funcall, so it only affects
calls in the macro's body.  Use pp-macroexpand-last-sexp to see the
expansions.

BTW, in the body of your email, the text you write has these two
characters between sentences: "  ".  The second is a plain space, but
the first is a Unicode non-breaking space, or "C-x 8 RET a0".  I noticed
because it's displayed in Emacs as an underline character next to the
plain space.




Re: org-pop-mode

2020-03-18 Thread Adam Porter
"Mark E. Shoulson"  writes:

> This is something I've wanted for years in org-mode, but which in some
> ways could actually be _offensive_ to its ideals.  If you're an
> outline purist, look away.
>
> ...
>
> So, I present a pre-alpha version,
> https://gist.github.com/clsn/09ac4b098b6ad7366bb5e0bc2d5f of
> org-pop-mode.  To "pop" back up, create a headline at the level you're
> popping back to, and give it a tag of "contd", and the headline text
> should not be something important.  Instructions and explanations are
> in the comments of the file (the part about installing from MELPA is a
> lie, though).
>
> Any feedback?

Hi Mark,

Indeed, this is something that is frequently asked about.  I probably
wouldn't use it myself, but it looks like you've done a good job on it.
Here is some feedback:

1.  I'd suggest a more descriptive name, especially if you plan to
publish it to MELPA.  org-pop doesn't seem to convey anything about what
it does.  :)

2.  In the code, I saw you comment about cl-flet, and I see you using
fset and unwind-protect in the org-pop-with-continuations macro.
Instead, use cl-letf with symbol-function, like:

  (cl-letf* (((symbol-function 'foo)
  #'my-foo)
 ((symbol-function 'bar)
  (lambda ()
...)))
BODY)

See also Nic Ferrier's package, noflet.




Re: ox.html causes w3c xhtml validation

2020-03-15 Thread Adam Porter
Colin Baxter  writes:

> In my opinion, if it can't be fixed then the changes should be
> removed. Surely, we cannot have an org-mode that knowingly
> exports/publishes something that causes a validation error!

Looking at the error message, the fix might be very simple:

  The most common cause of this error is unencoded ampersands in URLs as
  described by the WDG in "Ampersands in URLs".




Re: virtual org-mode meetup tomorrow 11am EST

2020-03-15 Thread Adam Porter
Thanks to John for hosting, and to all who "attended" virtually.  It was
great fun.  Looking forward to doing it again.




Re: [PATCH] Add NO-STATS switch to org-get-heading

2020-03-13 Thread Adam Porter
Please don't add more arguments to org-get-heading.  It used to have 2,
then it had 4, and now you want to add a 5th.  Every time the function's
signature changes, it breaks code in third-party packages and user code
in random places, which requires the addition of messy compatibility
code and intermediate functions that do nothing but wrap org-get-heading
with a certain number of arguments.

It would be much preferable to make a new function that uses keyword
arguments so the addition of more arguments won't affect existing code.
Maybe it could be called org-entry-heading.




Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Adam Porter
Kaushal Modi  writes:

> Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS
>
> Compiling ox-hugo.el now gives:
>
> ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not known 
> to be defined.
>
> I see that defun has now moved to org-refile.el. I see that
> org-get-outline-path has nothing to do specific to refiling. Can that
> be moved back to org.el, or may be a separate library? Otherwise,
> ox-hugo.el will have to load org-refile.el too (yes, I don't use
> org-refile (yet), and that's how I discovered this :))

Yes, please move that function back.  This is going to cause breakage in
a variety of packages that use that function but do not load
org-refile.  I can hear the bug reports rumbling already...  ;)




Re: Regarding collapsing blank lines between headlines

2020-02-19 Thread Adam Porter
Hi Russell,

This is not exactly what you asked for, but here's some code that
ensures blank lines exist between headings and entry content.  You could
modify it to remove excess lines without too much trouble.

https://github.com/alphapapa/unpackaged.el#ensure-blank-lines-between-headings-and-before-contents




Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Adam Porter
Marco Wahl  writes:

 - org-loop-over-headlines-in-active-region => t
>>>
>>> I vote for => 'start-level.  Loop over headlines with same level as the
>>> first.
>>
>> Yes, good suggestion.
>
> Let's see what others say.

I can see how that could be useful, but I feel like it would be less
intuitive than looping over all headings in the region.  I would be
confused by that behavior if I weren't aware of this discussion and the
option's settings.  So I would vote for t over 'start-level.

My two cents.  :)




Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Adam Porter
I generally approve of all of these changes.  However, hiding emphasis
and macro markers can make editing text at the boundaries of emphasized
text non-intuitive, which I can imagine might frustrate some new users,
so that should probably be carefully considered.  The other changes seem
like obvious improvements to me.  :)  Thanks for your work on this,
Bastien!




Re: Possible to exclude/include tags for agenda custom commands?

2020-02-19 Thread Adam Porter
Hi Bastien,

Bastien  writes:

> Hi Adam,
>
> Adam Porter  writes:
>
>> https://alphapapa.github.io/org-almanac/
>
> this is a very nice list of resources!
>
> Do you think we can advertize it somewhere on Worg?
>
> If yes but are unsure *where*, just go ahead with whatever location
> seems fine, we can always rearrange Worg's contents later on.

Yes, I'd be glad for it to be listed on Worg.  Feel free to add it if
you like, or I might add it myself after I add a bit more content.

I was thinking about working on Worg rather than making yet another
resource, but:

1.  I saw you mention that you're planning to reorganize Worg's content
soon, and I wouldn't want to interfere with that.

2.  I sometimes feel hesitant to put a lot of effort into curating and
organizing content on Worg because, like all wikis, that work can easily
be invalidated if others come along later and add content in random
places.

One of my goals for this "org-almanac" is to catalog content in a
somewhat canonical way, to avoid the "wiki effect."  For this project,
I'd rather have less content that's organized more clearly, than have
lots of content scattered about.  Of course, I don't presume to say that
the way I've done it is the best way, and I'm experimenting as I go.

Anyway, do you have any more thoughts about these issues?

Thanks,
Adam




Re: Possible to exclude/include tags for agenda custom commands?

2020-02-14 Thread Adam Porter
Stig Brautaset  writes:

> Hi Bastien,
>
> Bastien  writes:
>>> I can easily do this in the list of TODOs, with a tag search. However, I
>>> haven't figured out how to do this for the agenda. Is it possible? If
>>> so, how?
>>
>> From what I understand, check `org-agenda-tag-filter' to see how to
>> use it within an agenda custom command.
>
> Thank you! That did indeed do it. 
>
> FWIW my stanza looks like this now:
>
> (setq org-agenda-custom-commands
>  '(("w" "Work Agenda"
> ((agenda "" ((org-agenda-span 'day)))
>  (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@home" "-MAYBE"
>("h" "Home Agenda"
> ((agenda "")
>  (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@work" "-MAYBE"
>("m" "Maybe"
> ((todo "PROJ")
>  (tags-todo "-PROJ/TODO"))
> ((org-agenda-tag-filter '("MAYBE"
>("P" "Projects" tags-todo "-MAYBE/PROJ"
>
> Stig

Hi Stig,

Thanks for sharing that.  I think this is a fairly common question among
Org users, yet not always easy to find the answer to, so I've added your
example here along with a couple of other solutions:

https://alphapapa.github.io/org-almanac/#Exclude%20and%20include%20tags%20in%20custom%20Agenda%20commands




Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

2020-02-13 Thread Adam Porter
Dear Nicolas and Bastien,

I feel like a child whose parents are fighting.  :)  If I may speak for
other Org users: you're invaluable to us, and we look up to you.  Please
don't let the deficiencies inherent in online, textual communication
cause deterioration in your fellowship.

With gratitude for all your contributions,
Adam




Re: Provide org-insert-subitem

2020-02-13 Thread Adam Porter
Bastien  writes:

> First of all, don't be afraid, I don't have a grand plan for "cleaning
> up" things.

Don't worry, I trust you.  :)  Org wouldn't be what it is today without
your work, and I'm grateful for how much time you've been putting into
improving Org lately.

>> I'm not sure what you mean about functions mentioned as usable by the
>> user.  org-insert-subheading is an interactive command, so it's
>> explicitly usable by the user.
>
> Yes, org-insert-subheading is interactive and usable and in Org's core
> but how can a user *discover* this command?
>
> There is no keybinding for it and no mention in the manual.  Even as a
> function, it is not even used in Org codebase.
>
> The ways I can see for a user to discover this command is by trying to
> complete M-x org-insert TAB or by reading Org's code (or other code in
> the wild using it.)

I guess what happened here is that I found that command years ago,
probably from either reading someone else's config online or, as you
say, using completion (I discover so many things using Helm
completion--I'm constantly using "C-h f org-" when working on
Org-related code).  Then I bound it to S-RET in my config, and I've been
using it ever since.  To me it feels like just as much a part of Org as
any other Org command.

> So to me it's a "utility" command: something that Org does not depend
> on, something that provides a useful feature, but not useful enough to
> have a keybinding in Org's core or to be used as a function in Org's
> core.

What if we document it in the manual?  For example, in section 2.5,
"Structure editing", we have:

`M-' (`org-insert-heading')
 Insert a new heading/item with the same level as the one at point.

`C-' (`org-insert-heading-respect-content')
 Insert a new heading at the end of the current subtree.  

`M-S-' (`org-insert-todo-heading')
 Insert new TODO entry with same level as current heading.  See
 also the variable `org-treat-insert-todo-heading-as-state-change'.  

`C-S-' (`org-insert-todo-heading-respect-content')
 Insert new TODO entry with same level as current heading.  Like
 `C-', the new headline will be inserted after the current
 subtree.  

What if we add:

`S-' (`org-insert-subheading')
 Insert a new subheading and demote it.
 Works for outline headings and for plain lists alike.

Note that I also propose binding it to S-.  It seems that, by
default, that key is currently bound in Org buffers to
org-table-copy-down:

Copy the value of the current field one row below.

That's surely a useful function, but I feel like it probably isn't
widely used enough to deserve to be bound to S- in all contexts.
Of course, frequent users of this command, feel free to correct me, lest
I be a hypocrite.  ;)

If that seems agreeable, then I'd also propose renaming the command
(preserving its old name in an alias, of course) to something which
would not imply that it only works in outlines, perhaps
org-insert-subitem or org-insert-demoted.

In the longer term , perhaps we could make a new, contextual command
that would call one command in tables and another command in non-table
contexts.  If there were a clever way we could make similar, roughly
corresponding actions in both tables and tree structures use the same
bindings contextually, that might be useful.  I think it would be
reasonable, because if point is in a table, the user probably won't want
to insert a new outline heading in the middle of it.

What do you think?  Thanks.




Re: Provide org-insert-subitem

2020-02-12 Thread Adam Porter
Hi Bastien,

Bastien  writes:

> I still find it strange to keep functions that are used nowhere in the
> Org's core--except of course for functions that explicitely mention as
> usable by the user (e.g. `org-clock-persistence-insinuate'.)
>
> I'd rather have these functions stored in a org-utils.el library for
> those who care.

I'm not sure what you mean about functions mentioned as usable by the
user.  org-insert-subheading is an interactive command, so it's
explicitly usable by the user.  And it's in org.el, so it's in Org's
"core", right?  I guess we're thinking in different terms.

Inserting a subheading or subitem is a very common operation in an
outlining and list-making tool, so it would seem like a significant
regression to remove it.

I'm not opposed to reorganizing the code, of course, as long as it
remains loaded as a command when org-mode is activated.




[ANN/RFC] org-ql-view-dispatch command

2020-02-10 Thread Adam Porter
Hi friends,

I've pushed a new feature to org-ql's master branch: a Magit-like view
dispatcher using Jonas Bernoulli's transient.el library.  It makes for
quick and easy modification of org-ql-view queries, allowing you to
build them interactively rather than requiring you to write Lisp code or
use the Customization system.  Here's a screencast of it:

https://github.com/alphapapa/org-ql/raw/master/images/org-ql-view-dispatch.gif

It seems to work well, but I'd appreciate any feedback.

Thanks,
Adam




Re: How to intersperse commands with their output in RESULTS block?

2020-02-07 Thread Adam Porter
Diego Zamboni  writes:

> I came up with the following block, which cleans up all the cruft from
> the output of the =script= command and produces a nicely formatted
> session transcript:
>
> #+NAME: cleanup
> #+BEGIN_SRC emacs-lisp :var data="" :results value :exports none
>   (replace-regexp-in-string
>"\\$ exit\\(.\\|\n\\)*$" ""
>(replace-regexp-in-string
> "^bash-.*\\$" "$"
> (replace-regexp-in-string
>  "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" ""
>  (replace-regexp-in-string "
> " "" data) nil nil 1)))
> #+END_SRC
>
> (I am not happy with the regexp nesting and repetition above, I am not
> an expert yet in emacs-lisp regex facilities. Suggestions appreciated
> for how to simplify it).

Hi Diego,

A few suggestions:

1.  You can use `rx' to define regexps in a Lispy way, and the ELPA
package `xr' converts existing regexp strings to the rx format, which
can help in learning rx syntax.  For example:

  (xr "^bash-.*\\$" 'brief) ;;=> (seq bol "bash-" (0+ nonl) "$")

So you can use that regexp like:

  (replace-regexp-in-string (rx bol "bash-" (0+ nonl) "$") ...)

This nasty one is much easier with rx:

  (xr "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" 'brief)
  ;;=>
  ;; (seq (group (*? (group anything)))
  ;;  "$" (0+ (group anything)) eos)

2.  To avoid the nested calls, you can use a loop, like:

  (cl-loop for (match replace) in
   (list (list (rx foo bar) "replacement"))
   do (setf string
(replace-regexp-in-string match replace
  string)))




Re: org-adapt-indentation default should be nil [legibility 3/6]

2020-02-05 Thread Adam Porter
Texas Cyberthal  writes:

>> the default settings do not put blank lines between headings and
>> their entry text,
>
> I don't know what this means. Plain Emacs behaves the same way
> Spacemacs does in this regard. Insertion of a blank line after a
> heading is voluntary but standrd.

I don't know what you mean, either, but you keep mentioning Spacemacs,
which isn't very relevant.

>> without any indentation, headings and entry text on varying levels
>> tends to blend together, making for very poor readability.
>
> If the goal is to read the body text of headings, then deeply
> indenting it is contrary to the goal. If the goal is to see the depth
> of headings, then the bodies should be folded. If folded mode doesn't
> convey sufficient information, the solution is to rewrite the heading
> titles to better summarize the body text.

It is not for you to decide what others should do.  Your preferences are
not mine.  It sounds like you should develop your own "Texas Cyberthal
Emacs starter kit" that has all the settings you think are best.

>> No one is "good at" Emacs and Org when they first come to it.
>
> UI difficulty is exponential, not linear.

Come on, we all know that the Emacs learning curve is a spiral.

> The more initially difficult the Emacs UI is acknowledged to be, the
> more important it is to reduce that difficulty with noob-friendly
> defaults, so that they can eventually reach the point of elitist
> unconcern for noobs.

The issue here is not whether Emacs can generally be improved, but
whether your specific proposals are good ideas.

It's unfriendly of you--and incorrect--to imply that we are elitists
without concern for new users.  Much effort is put into improving
documentation, answering questions, writing explanatory articles, giving
demonstrations, etc.  Some of us even publish code to help others
improve their configs, e.g. https://github.com/alphapapa/alpha-org.  I
suggest that you give those avenues a try, rather than insisting that
your preferences are best for others.

> The problem with aiming software at noobs is ruining the expert
> experience.

That is one problem with software that overemphasizes the experience of
new users.  Another, perhaps more serious, problem is that it inhibits
the development of such expertise.  I feel like some of ESR's writings
are relevant here.

> Changing defaults doesn't ruin expert experience because experts have
> configuration management.

A VCS does not obviate the need to compensate for changes in default
behavior.

> Noob friendly defaults increases the likelihood there is a long term
> for them.  Emacs' biggest barrier to adoption is acclimatization.

You're not quite wrong, but you're missing the point about long-term
users.  What makes software attractive in the long-term is not what
makes it appeal to new users.  Emacs is not called "the editor of a
lifetime" for nothing--nor is notepad.exe called that, even though it is
very easy for new users to use.  Emacs is attractive in the long-term
because of its power, flexibility, and potential for mastery.  There is
a balance to be struck between appealing to new users and empowering the
development of expertise; to an extent, the two goals do conflict.

> I just read a GTD thread in which they all agreed Org was too hard to
> be worth learning, including the guy advocating it:
>
> https://forum.gettingthingsdone.com/threads/emacs-org-mode-is-the-perfect-tool-for-gtd.15028/page-2
>
> To be clear, this is the biggest GTD forum, which Org is the best
> implementation of, and it seems most of them are using digital GTD
> tools.

So what?  Emacs and Org do not need to adapt themselves to users who do
not like them.  They are successful because of what they are.

You seem very concerned about new users, thinking that, unless we make
Emacs/Org very easy for new users to understand, there will be no new
users.  This is obviously not the case.  Emacs is one of the oldest
pieces of software still widely used.  It and Org are gaining new users
every day; the community is more vibrant than ever.  Probably more
people use Emacs and Org today than ever before.

Consider an analogy: Years ago, Mozilla Firefox was the fastest, most
powerful, most popular browser that wasn't imposed on its users.  It was
the obvious victor in the "browser wars," having led the way in
unseating IE and freeing the Web from Microsoft's hegemony.  Then Google
Chrome arose as a challenger, with certain inherent advantages due to
Google's position.  Mozilla then chose to stop leading and start
following.  Every new Firefox release became more like Chrome, with
Mozilla thinking that it could win back users.  But why would a user who
was happy with Chrome want to switch to a poor imitation of it?  Mozilla
thought it could succeed by abandoning what had made it successful--it
thought Firefox would be more popular if it stopped being Firefox.  The
result was continued decline in Firefox's market share and, eventually,
Mozilla's 

Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-05 Thread Adam Porter
Texas Cyberthal  writes:

>> visual-line-mode and toggle-truncate-lines are basic Emacs commands
>> that all users should learn early.
>
> Visual lines, logical lines etc is a complicated mess that Spacemacs
> avoids entirely. I recall fiddling with it and never being satisfied,
> until adopting Spacemacs solved it. Now I know even less about it than
> I did then, because there's no need to know. A brief investigation
> shows Spacemacs sets (line-move-visual t) in prosey text modes, so
> that C-n next-line operates on visual lines. However commands such as
> C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane
> default that permits fluid navigation of paragraphs, which is all a
> noob wants to do.
>
> Similarly, I almost never use truncate-lines, to the point that I had
> to websearch to recall what it was called within the last week.

If I understand correctly, you're arguing that defaults should be
changed because you don't understand how Emacs works, and since you use
Spacemacs, you don't even care how it works.

May I suggest that you propose your changes on the Spacemacs repo.




Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

2020-02-05 Thread Adam Porter
Texas Cyberthal  writes:

> Making a vet change a default if he decides he doesn't like a change
> upon upgrading won't drive him away, but Emacs' unfriendly defaults
> are always driving away noobs. Therefore Org's defaults should be
> noob-friendly, not vet-friendly.

There is certainly room to improve some Emacs defaults; there are active
threads on emacs-devel about it now.

However, the question of to what degree Emacs should target certain
types of users is a wider one, and answering it one way or the other
doesn't necessarily support your proposed changes.

> Probably vets should use legible settings as well. I became accustomed
> to less-legible Org settings, and thought they were superior. But when
> I cleaned up my Spacemacs config, I incidentally restored some default
> legibility tweaks I'd disabled. After a brief exposure, I realized the
> tweaks were superior, and that my preferences had been wrong. Changing
> the defaults can overcome vet inertia and improve their UI.

It's neither the spirit nor practice of Emacs to tell users what
settings they should use.  Emacs exists to empower users to meet their
needs according to their preferences.

It is not for you, nor us, to decide whether certain users are suffering
from "inertia" which we ought to overcome on their behalf for the sake
of improving their UI.  That is for them to decide, not us.  This is
Emacs, not Apple, Inc.

>> Terminals can display colors, underlines, italics, and bold text
>
> Proposed legibility changes don't affect those font aspects.

I was responding to this claim of yours:

>>> Concerns about terminal impact appear to be moot, since terminal
>>> ignores most font settings.

So your claim has been clarified from "terminals ignore most font
settings" to "my proposed changes don't affect the font aspects that
terminals display."

Please quote enough of the message you're replying to so that the
conversation can be easily followed (by me, if no one else).





Re: org-mode functional programming library

2020-02-03 Thread Adam Porter
Nicolas Goaziou  writes:

> Note that, at some point, Org will support "seq.el", i.e., when we
> drop support for Emacs 24.

Just a small FYI about seq.el, for those who may not be aware: while
it's a very useful library, it can be quite slow since it uses generics.
For example, here are some benchmarks comparing seq-intersection with
other functions that intersect lists:

https://gist.github.com/alphapapa/36b117c178dec677258f372c3a01d8b5

Note the last benchmark listed, which shows that cl-intersection is
about 2x as fast as seq-intersection.  As well, dash.el's -intersection
is about 17x faster than seq-intersection.

So while seq.el will undoubtedly be useful in Org, it should be used
carefully with regard to performance.  Type-specific functions will
generally be much faster.  And as long as dash.el can't be used in Org
proper, a custom implementation may be called for at times.




Re: Prose with markup needs more line spacing [legibility 5/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> Code requires less line spacing. It has more whitespace, fewer capital
> letters, and no markup such as underlining. Code is read differently
> than prose; it requires less sequential scanning.

Code certainly can have markup like underlining.  For example,
flymake/flycheck highlighting, highlight-function-calls-mode, Semantic,
etc.

> Prose has big blocks of text with taller capital letters that must be
> scanned sequentially. The tall bits bump into lines above and below.
> Org prose adds markup. Underlining and all-caps tags are common. This
> requires a bit more line spacing for optimal legibility:
>
> #+begin_src elisp
> ;; prose with markup needs more line spacing
> (defun leo-space-lines ()
>   (setq line-spacing 0.175))
> (add-hook 'org-mode-hook 'leo-space-lines)
> #+end_src

We should definitely not be messing with line spacing in default
settings.  Line spacing is a very personal preference, and it varies
widely by other configuration, such as font.

Please, feel free to make your own prose-specific Org theme or minor
mode, or use or improve one of the several that already exist.  Org
defaults need not be changed to meet your preferences.




Re: Fixed vs variable pitch font [legibility 4/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> Readable prose requires variable-pitch font. Readable code requires
> fixed-pitch font. Org should make it easy to configure the two
> separately.
>
> mixed-pitch-mode mostly solves this problem, but only advanced users
> know about it.
> https://gitlab.com/jabranham/mixed-pitch

I also prefer proportional fonts for prose in Org buffers, and I
configured my face settings accordingly a long time ago.

However, it is not necessarily so that proportional fonts are required
for prose.  Great works have been written on typewriters for many
years.  As well, Emacs/Org are not necessarily aimed at prose writing
more than other uses, and changing the default would probably be
off-putting to many existing users, so the default probably should not
be changed.

Having said that, if Org could have a simple org-mixed-pitch-mode, or
something like that, that could be very helpful, since it could make
such configuration much easier.  Maybe one could be written to use
face-remapping, which shouldn't take much code.




Re: org-adapt-indentation default should be nil [legibility 3/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> #+begin_src elisp
> (org-adapt-indentation nil)
> #+end_src
>
> Adaptive indentation makes sense when using Org as a plain-text
> database. It does not make sense when using Org for longform prose.
>
> In the former case, outline depth is important to reflect properties
> such as inheritance. The code elements are primary and the prose
> secondary.
>
> In the latter case, the primary payload is the prose. Gratuitously
> indenting it wastes screen space and requires the user to make layout
> adjustments for legibility. The extra information value of indentation
> reflecting outline depth is negligible; the heading already conveys
> it.
>
> Beginners are bad at making adjustments to keep heavily-indented prose
> legible. Thus the default should be nil.

I think you have a better case for changing this setting.  However, I
think there is another consideration: the default settings do not put
blank lines between headings and their entry text, and without any
indentation, headings and entry text on varying levels tends to blend
together, making for very poor readability.  Disabling this setting
would make this problem worse.

Generally, I don't think "beginners are bad at" is a good argument for
changing defaults.  No one is "good at" Emacs and Org when they first
come to it.  There's probably room for improving the defaults, but we
should not necessarily make changes based on guessing what brand-new
users are most likely to want.  Emacs and Org are, thankfully, generally
free from the trend of aiming software at those who have never used it
before.  Instead, it tends to call users to learn more and aspire to
mastery, which is more useful and empowering in the long run.




Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> #+begin_src elisp
> (org-startup-truncated nil)
> #+end_src
>
> Line truncation is necessary for code but anathema for prose. Prose
> lines need visual wrap as windows resize, so that texts can be
> compared easily.
>
> Advanced Org uses such as large tables require line truncation. Tables
> are a code-like fixed-pitch feature.
>
> Users will write a paragraph of prose longer than the screen well
> before they discover a need for line truncation, such as long lines of
> code or wide tables. Users who need line truncation are likely to know
> about it, whereas users who need line truncation off are unlikely to
> know what it's called.
>
> Learning about line truncation is an unnecessary hurdle for beginners.
> Therefore the default should be nil.

visual-line-mode and toggle-truncate-lines are basic Emacs commands that
all users should learn early.  As well, many users prefer to use filled
paragraphs rather than visual wrapping.  And we shouldn't prioritize
prose above other uses. So this default should probably not be changed.

What would be useful would be if Emacs/Org could be configured to wrap
prose lines but not, e.g. tables and code blocks.  I don't think such
functionality exists in Emacs now, but here's a new package that may be
relevant: https://github.com/luisgerhorst/virtual-auto-fill

As well, it might be good to discuss on emacs-devel whether a feature
could be developed to truncate/wrap lines selectively; maybe
font-locking could be used to apply text properties to disable wrapping
dynamically (assuming that a feature could be developed to wrap based on
a certain text property).  Then we could have the best of both worlds,
and solve an existing problem, viz. that tables and code gets wrapped
when visual-line-mode is enabled.




Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> Beginners spend a while learning to use Emacs as a simple text editor
> before they're able to do anything more advanced. Their ability to
> intelligently customize is minimal. Meanwhile experts have automated
> dotfile deployment, so defaults are almost irrelevant to them.
> Therefore defaults should be set for inexperienced users.

Defaults are relevant for all users, because if you change the default
of a setting that an "experienced user" uses the default for, he will
have to change that setting in his config.  New users come to Emacs/Org
a few at a time; changing the defaults would affect all existing users
at once.  Therefore changing the defaults should be very carefully
considered, and they should not reflect one user's beliefs about what
best suits other users.

> Inexperienced users will mostly use Org for longform prose, since they
> haven't learned its database functions yet. Since Org aspires to be a
> personal info manager, it should prioritize prose presentation above
> code conventions.

Org is not intended more for prose writing than for other uses.  We
should not prioritize one such use above others.

> Concerns about terminal impact appear to be moot, since terminal
> ignores most font settings.

Terminals can display colors, underlines, italics, and bold text, and
terminal appearance should not be ignored or de-prioritized.




Re: Make code elements in prose unobtrusive [legibility 6/6]

2020-02-03 Thread Adam Porter
As Tim said, this is really a matter for theming.  There are several
themes and example configs available that make Org buffers "pretty".
For example:

https://github.com/kunalb/poet
https://github.com/jonnay/org-beautify-theme
https://lepisma.xyz/2017/10/28/ricing-org-mode/

As well, faces are easy to customize using:

  M-x customize-apropos-faces RET org RET

There may be improvements to be made, but the defaults shouldn't be set
to match the preferences of any one user.  Remember that people have
been using Org for years, and theming and faces are very personal.  ;)




Re: Provide org-insert-subitem

2020-02-02 Thread Adam Porter
Bastien  writes:

> `org-insert-subheading' and `org-insert-todo-subheading' are not used
> anywhere in Org's code.  Do you them?  How?
>
> I'm more inclined to delete these commands since they have no binding
> than to add an `org-insert-subitem'.
>
> Hitting  then  seems swift and handy enough.

Please do not delete org-insert-subheading!  I use it every day and have
for years.  :) It would be much less convenient to have to use two
commands.

BTW, in my version of Org, org-insert-subheading works on both list
items and subheadings, so there's no need for a separate
org-insert-subitem command:

  Insert a new subheading and demote it.
  Works for outline headings and for plain lists alike.




Re: org-superstar-mode: A re-imagining of org-bullets with new features

2020-02-02 Thread Adam Porter
Hi D,

This looks fantastic!  Great work!  I sent you a quick suggestion on the
issue tracker.  Let's get this on MELPA ASAP!  :)




Re: can't sign in to code.orgmode.org

2020-01-28 Thread Adam Porter
"Tyler Smith"  writes:

> I am trying to set up an account with code.orgmode.org. I have already
> done this, but when I try to sign in, I get an error about incorrect
> username or password. I have clicked the link to send a password reset
> several times this morning, but no email has shown up in my account,
> or in my spam folder.

I also tried to create an account the other day (I thought I already had
one, but apparently not), and I never received the confirmation email.




Re: New page https://orgmode.org/worg/donate.html

2020-01-28 Thread Adam Porter
FYI, Jonas Bernoulli also maintains a similar page for Emacs in general:

https://github.com/tarsius/elisp-maintainers




Re: [RFC] C-c C-c in agenda

2020-01-28 Thread Adam Porter
Marco Wahl  writes:

> For some days now C-c C-c disables column view in Org files.  This helps
> me a bit and never got in my way.  And I thought it would be quite
> natural and consistent to use this binding for the agenda too.
>
> What do you think about all that?

Hi Marco,

I've always had the impression that the "C-c C-c" binding was intended
to do the most obviously useful or natural action in the current
context.  For example, in a capture or log buffer, it completes the
capture.  With point on a #+ line, it resets buffer properties
accordingly.

I don't use column view very often, so I may be biased, but anyway: in
the general context of an Agenda buffer, I don't feel like enabling or
disabling column view is the most obviously useful or natural thing to
do, so "C-c C-c" doesn't seem like an appropriate binding to me.




Re: org-word-count exemptions

2020-01-25 Thread Adam Porter
There are various solutions floating around.  Here's one way:

(defun ap/org-count-words ()
  "If region is active, count words in it; otherwise count words in current 
subtree."
  (interactive)
  (if (use-region-p)
  (funcall-interactively #'count-words-region (region-beginning) 
(region-end))
(org-with-wide-buffer
 (cl-loop for (lines words characters)
  in (org-map-entries
  (lambda ()
(unpackaged/org-forward-to-entry-content 'unsafe)
(let ((end (org-entry-end-position)))
  (list (count-lines (point) end)
(count-words (point) end)
(- end (point)
  nil 'tree)
  sum lines into total-lines
  sum words into total-words
  sum characters into total-characters
  finally do (message "Subtree \"%s\" has %s lines, %s words, and 
%s characters."
  (org-get-heading t t) total-lines total-words 
total-characters)

(defun unpackaged/org-forward-to-entry-content ( unsafe)
  "Skip headline, planning line, and all drawers in current entry.
If UNSAFE is non-nil, assume point is on headline."
  (unless unsafe
;; To improve performance in loops (e.g. with `org-map-entries')
(org-back-to-heading))
  (cl-loop for element = (org-element-at-point)
   for pos = (pcase element
   (`(headline . ,_)
(org-element-property :contents-begin element))
   (`(,(or 'planning 'property-drawer 'drawer) . ,_)
(org-element-property :end element)))
   while pos
   do (goto-char pos)))




Re: [ANN] org-ql 0.4 released

2020-01-25 Thread Adam Porter
Michael Alan Dorman  writes:

> 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.

If it were only a matter of maintainers assessing the stability of
individual packages, there would be no problem.  The problem is that
some packages depend on other packages, and their maintainers don't
coordinate the tagging of stable versions.  Everyone does their own
thing in their own time.  MELPA Stable can't solve that.

> 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.

It works pretty well, except when it doesn't.

> 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

AFAICT no good comes from using MELPA Stable.

> 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

Even the most widely used, most impressive packages, like Magit and
Helm, don't consistently tag stable versions and don't use actual
semantic versioning.  There are no rules, so even if a few developers
were disciplined in their development and tagging, it would not justify
a user using MELPA Stable, because the other packages on it would not
live up to the same standards.  It doesn't offer what you seem to think
it does.

> rather than consigning every emacs user to doing individual curation
> for every single package they ever use.

That's not necessary.  Just put ~/.emacs.d/elpa in version control, and
when your config and package versions seem to be working, commit
everything.  Next time you upgrade packages, if something breaks and you
don't have time to fix it, rollback to what works and try again later.
If everything seems to work, commit the upgraded packages.  It's very
simple, and unlike MELPA Stable, it will give you actual stability.

> 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.

I care about stability, not MELPA Stable.  It's your choice to use MELPA
Stable, and you're free to upgrade or downgrade individual packages to
work around such occasional, temporary breakage caused by it--the pieces
are yours to keep.  I'm sorry for any inconvenience, but your config is
up to you.




Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Adam Porter
Tim Cross  writes:

> I don't disagree with most of what you write. I do think a big part of
> the problem is inconsistency and poor practices by some maintainers
> which is at the hart of the issue. Sometimes it seems that package
> maintainers put too much emphasis on getting the latest package out and
> forget about the stability and dependencies that users have.
>
> All of this leaves me wondering why the ELPA system doens't adopt a
> semantic versioning scheme and configure the repositories to
> keep/maintain previous versions. Emacs was very late to the whole
> 'package' concept and it is a little disappointing that more time wasn't
> invested in understanding the challenges and solutions implemented by
> other systems like deb, rpm, CPAN, Java, ruby, python etc. There is
> little unique to the Emacs environment that other environments haven't
> had to resolve one way or the other.  

The problems you identified in the first paragraph are why the solution
identified in the second paragraph doesn't work (for this case; I like
SemVer in general).

> However, a semantic version does provide more information than
> something like version 20200123, which just tells me the release
> date. At least with complaint semantic versions I can have a better
> idea as to whether the changes are just a bug fix, an enhancement or
> major API changes that may break existing dependencies.

Yes, and that's why I like it, too.  But we can't make other developers
use it.  Even if MELPA required SemVer-like numbering, nothing would
stop package maintainers from incrementing major-only version numbers.
It's their code.

Developing with proper use of semantic versioning is a discipline that
requires extra diligence.  It's rarely more fun, and for most Emacs
packages, it's not worth the trouble.  Most packages are dependents
rather than dependencies, leaves at the ends of the branches, and they
can be freely upgraded without breaking anything else.  Most packages'
interoperability with other packages is minor.

If SemVer were required, MELPA would probably have 5-10% of the packages
it does today.  The lax, welcoming approach used by MELPA has drawbacks,
but it also has tremendous benefits, and I think it's to credit for much
of the vibrancy of the Emacs package "ecosystem" and community today.

The problem I'm writing about here is that users' perception of MELPA
Stable doesn't match the reality.  Discussions about how to change MELPA
Stable and MELPA versioning for the better have been going on for years.
Ultimately that doesn't matter, because package authors can do whatever
they want.  We should help users understand and accept the technical
reality--and MELPA Stable misleads them, so it should be removed.  As I
posted in my proposal on the MELPA tracker, we can pursue better
technical solutions then, ones that may be more in line with the
limitations of the platform.

If you're interested in the topic, please join the discussions on the
MELPA tracker.




Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Adam Porter
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 the mercy of whatever commits
happen to be in MELPA at the moment.

For myself, I commit the ~/.emacs.d/elpa directory to Git with the rest
of my config, and I upgrade packages intentionally.  If breakage
happens, I can easily revert and deal with it later.  Other users use
alternative package managers, like Borg or Straight or Quelpa, which
pull changes directly from Git repos and allow pinning to commits, tags,
etc.

So, for yourself, I can only recommend that you abandon MELPA Stable and
install packages by other means.  If you don't have the time or
inclination to redo your whole config like that, then just use something
like Quelpa to install the current version of org-super-agenda directly.
It's a couple lines of use-package in your config, and you can upgrade
it manually from then on, e.g. with
.
As always, your Emacs config is up to you.

Now, I'm off to to the discussions on MELPA's tracker to add my vote to
abolish MELPA Stable, or to at least allow packages to opt-out of it.




[ANN] org-ql 0.4 released

2020-01-23 Thread Adam Porter
Hi friends,

FYI, I've released org-ql 0.4.  It includes many improvements since 0.3.

https://github.com/alphapapa/org-ql

Thanks,
Adam




Re: Long links

2020-01-04 Thread Adam Porter
Steven Penny  writes:

> yes, and I would have never made this point had you not insisted on
> starting an off topic conversation.
>
> Next we know you will say why someone is using spaces over tabs, or
> emac over vim, or red over blue bikeshed. Stop.

This rude one-upsmanship is uncalled for.  The gentleman attempted to
offer you a solution you did not appear to be aware of.  If, in fact,
one of you misunderstood the other, or he offered you a solution you
can't use, no harm has been done--thank him for his offer and move on.
Or, if you can't be kind, let it be unanswered.




Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
Someone reminded me that Org has org-num-mode now, so please disregard
all of that.  At least it was good exercise.




Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
Adam Porter  writes:

> There is no built-in way to do that, and no way independent of
> org-export to get the numbers, AFAIK.
>
> Here's some ugly old code that shows outline numbering as overlays in an
> Org buffer.  It doesn't update automatically, so you have to run it
> again when the outline changes.  But it seems to work well.  It uses
> dash.el and let-alist, in case you don't have them loaded.

Please do disregard that monstrosity.  I rewrote it in a much simpler
way.  It seems fast on a reasonably large Org buffer.  It doesn't
account for org-indent-mode or org-bullets, but that wouldn't be too
hard to fix, I think.

No third-party packages are required.  See attached file, or
<https://github.com/alphapapa/unpackaged.el#outline-number-overlays>.



november-0ac22.el
Description: org-outline-numbers rewritten


Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
FYI, I tidied the code a tiny bit and posted it here:

https://github.com/alphapapa/unpackaged.el#outline-number-overlays




Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
There is no built-in way to do that, and no way independent of
org-export to get the numbers, AFAIK.

Here's some ugly old code that shows outline numbering as overlays in an
Org buffer.  It doesn't update automatically, so you have to run it
again when the outline changes.  But it seems to work well.  It uses
dash.el and let-alist, in case you don't have them loaded.

mike-0ac22.el
Description: ap/org-outline-numbers


Re: refile captured to all opened Org buffer files as targets

2019-12-26 Thread Adam Porter
stardiviner  writes:

> I recently created an org-capture template for elfeed, it is finished. Now I
> have an idea is to refile it to all currently opened Org buffer files. So I
> created an function for ~org-refile-targets~ variable.
>
> #+begin_src emacs-lisp
> (defun org-refile-targets-all-files ()
>   "Use all currently opened Org buffer files as org-refile targets."
>   (mapcar 'buffer-file-name
>   (seq-filter (lambda (buffer) (if-let (file (buffer-file-name 
> buffer)) (f-ext? file "org"))) ; filter Org buffers
>   (buffer-list
> #+end_src
>
>
> Then set ~org-refile-targets~ to use upper custom function
>
> #+begin_src emacs-lisp :eval no
> (setq org-refile-targets '((nil :maxlevel . 3) ; current buffer headlies
>(org-agenda-files :maxlevel . 2) ; agenda files 
> headlines
>(org-refile-targets-all-files :maxlevel . 3) ; all 
> opened Org buffer files headlines
>))
> #+end_src
>
> Can I add this as a patch to Org Mode repository?

org-buffer-list is a compiled Lisp function in ‘org.el’.

(org-buffer-list  PREDICATE EXCLUDE-TMP)

Return a list of Org buffers.
PREDICATE can be ‘export’, ‘files’ or ‘agenda’.

export   restrict the list to Export buffers.
filesrestrict the list to buffers visiting Org files.
agenda   restrict the list to buffers visiting agenda files.

If EXCLUDE-TMP is non-nil, ignore temporary buffers.





Re: How to get parsed output of org-eww-copy-for-org-mode ?

2019-12-25 Thread Adam Porter
You may find the package org-web-tools useful.




Re: Asynchronous org-agenda-redo

2019-12-23 Thread Adam Porter
Ihor Radchenko  writes:

> If you accidentally move the point in the buffer being processed by
> agenda, the results may be unpredictable (org-agenda-get-* functions
> move across the buffer with re-search-forward).

I'm afraid that's the basic problem with threading in Emacs: shared
state.  I don't know of a way to work around that.  I suppose you could
modify a lot of the agenda code to, e.g. store the position of the
current search in a variable and go to it before each search.  Of
course, that would also reduce performance to some extent.  It's a hard
problem.




Re: Properties Drawer versus tags

2019-12-20 Thread Adam Porter
I'll try to explain my view of tags.  Let's see if it makes sense.  :)

Conceptually, properties are like a generic key-value store for
headings, and tags are like a certain property.  Imagine if, instead of
tags being placed in headings, like this:

  * Blueberries  :food:fruit:

...tags were implemented as properties, like this:

  * Blueberries
  :PROPERTIES:
  :TAGS: food fruit
  :END:

The meaning would be essentially the same.

>From a technical perspective, putting tags on headings makes them much
faster to search for, because a regexp can be used to search directly to
them (local ones, anyway).  In contrast, to find the next location of a
certain property, a single regexp search is not enough, because even if
a regexp search was done to find an entry like the previous example,
like:

  (re-search-forward
(rx bol ":TAGS:" (1+ blank) (0+ nonl) bow "food" eow)
nil t)

...it would not be guaranteed that the result would actually be in a
heading's property drawer, so additional checks must be done to ensure
that.

Some properties are special, like CATEGORY.  As well, some properties
are "virtual," like SCHEDULED, which is written like:

  * Heading
  SCHEDULED: <2019-12-20 Fri 11:00>

...but is accessible with org-entry-get, like a property in a drawer.

So, use tags for applying simple, conceptual labels to headings, because
they're faster to search for than properties and always visible.  Use
properties as a key-value store for details that are less likely to be
used in a query and are less important to see.

What do you think?  :)




Re: Emacs bug 37890; killing capture buffer

2019-12-17 Thread Adam Porter
Michael Heerdegen  writes:

> Adam Porter  writes:
>
>> I guess you're asking me, since I'm the only other person in this
>> thread--but I'm not an Org maintainer, so my opinion isn't very
>> important.  IMO, the hooks are worth considering, however they should
>> be done very, very carefully, because bad things can happen when
>> functions called in kill hooks don't work as expected (e.g. they can
>> make it very difficult to kill a buffer or the Emacs process,
>> especially for an average user).
>
> Yes, all true.  I didn't even check if the code I posted breaks any
> org commands that kill the buffer.  So far it's only meant for
> demonstration (and my personal usage).
>
> Will my request be noticed here, or do you think I should report it to
> some other place?

I can't speak for what the maintainers are reading.  They are active on
this list, as you can see, but I doubt they have time to read every
message.  If you don't get the response you're looking for, you might
post the proposal in a separate thread, perhaps prefixed with [RFC] or
[PATCH] as appropriate.  They're definitely more likely to notice and
respond to actual patches, but that's not a requirement; if you ask for
specific feedback about a specific idea or code, that usually gets
noticed.

>> > BTW, what about my question whether my original bug report can be
>> > closed?
>>
>> I haven't seen your bug report.  Was there discussion about it
>> previously?
>
> No, no discussion at all.  As I said, it is Emacs bug #37890, this was
> my issue:
>
> | I want to capture an APPT with `org-capture'.  I the pop-up buffer to
> | edit the item I move the date to the second line and add text after the
> | date (personal preference).  That loses the final newline in
> | CAPTURE-todo.org.  As a result, the headline of the item following the
> | item to be inserted gets appended to the last line of the text:
> |
> | ** APPT Abc
> |<2019-10-23 Mi>
> | text... ** APPT 8:30 Important Appointment
> |
> | breaking the whole item.  The user should somehow be prevented from that
> | happening.
>
> It seems it has been resolved, just without noticing my bug report.
> If you can confirm that the cited issue has been cared about, I'll
> close it as done.

I can neither confirm nor deny.  ;)  I do seem to recall discussion of
that issue here recently (the problem, not necessarily your official bug
report of it), and maybe seeing that a fix was made.  If you search the
list archive for this month or November, you should find something--I
think that's the right timeframe.  You might also search the git log for
capture-related commits.  Shouldn't be hard to find if there was
something.

If it helps, none of my capture templates seem to end with newlines, and
I don't see anything in the docstring for org-capture-templates that
suggests one is required, so I don't think one is.  If you're still
having the problem, I'd suggest trying to reproduce it in a clean Emacs
configuration with the latest version of Org.  You may find this script
helpful for that:

https://github.com/alphapapa/alpha-org/blob/master/emacs-sandbox.sh

> BTW, what is the canonical place to report org-mode bugs?  Emacs bug
> reports are not (takes a long time until someone even notices) -- I
> thought this list would be good...or is there a better place?

I think this list is a canonical place.  Some people do report Org bugs
as official bug reports on the Emacs bug tracker.  I don't know whether
the Org maintainers read them all.  Since Org is officially part of
Emacs, sometimes the Emacs maintainers Cc this list about such reports.
Anyway, here is a fine place.

If you're not sure that something is a bug, you might consider
mentioning it on https://old.reddit.com/r/orgmode before posting it
here, since /r/orgmode has a wider audience.

> @Adam it's ok if you answer, though I'm a bit disappointed that no one
> else seems to care so far...

People do care!  But everyone here works on Org in their spare time, and
Org is a big project, and things slip through the cracks.




Re: Emacs bug 37890; killing capture buffer

2019-12-17 Thread Adam Porter
Hi Michael,

Michael Heerdegen  writes:

> Would you consider to do something like this by default?

I guess you're asking me, since I'm the only other person in this
thread--but I'm not an Org maintainer, so my opinion isn't very
important.  IMO, the hooks are worth considering, however they should be
done very, very carefully, because bad things can happen when functions
called in kill hooks don't work as expected (e.g. they can make it very
difficult to kill a buffer or the Emacs process, especially for an
average user).

> BTW, what about my question whether my original bug report can be
> closed?

I haven't seen your bug report.  Was there discussion about it
previously?

Adam




Re: Asynchronous org-agenda-redo

2019-12-16 Thread Adam Porter
Ihor Radchenko  writes:

>> So, of course, you can call custom functions in queries, even your
>> own skip functions (with `not', of course), but in most cases, they
>> can be covered with built-in predicates.
>
> Unfortunately, it does not seem to be the case for me.  My main agenda
> view needs to take into account multiple properties, which cannot be
> handled within framework of built-in org-ql predicates (AFAIK):
>
> - =:SHOWFROMTIME:= (always inheriting) :: The purpose of this is to be
>  able to assign specific projects for different days of week or,
>  say, show the home items only in the evening of weekdays and not
>  annoy me at work when I cannot do it any way. Hence, I can focus on
>  the items I really need to do now in this agenda. Additionally, the
>  time of the day after midnight is treated specially here. If
>  =org-extend-today-until= is not 0 and the current time is before
>  its value, the current time is still considered to be yesterday.
> - =:SHOWFROMDATE:= :: The purpose of this is to be able to postpone the
>  scheduled tasks for future if I cannot do it. The property is
>  formatted as an org date. This property is especially useful if
>  there is something more pressing, so that there is a temptation to
>  reschedule less pressing event to another day. If the more pressing
>  task is done earlier than expected, the postponed tasks can be
>  still find in normal agenda view (not in the
>  [[id:ff70b03f-3876-4b2b-9aab-c3209bd31cb8][focused]] one).
> - =:SHOWDATES:= (always inheriting) :: It contains dairy =sexps= to set
>  when the project should be shown. For example, I may want to work on
>  Saturday once or twice, but the working items should not be shown on
>  weekend normally. Hence, I can define it. Or some things can only be
>  done on specific dates (say, going to some shop, which is open few
>  days a week only)

There may still be some performance improvement available for these kind
of queries.  For example, assuming that a function `yantar/showfromdate'
is a predicate which accepts the value of property SHOWFROMDATE as its
argument and returns non-nil when an entry matches a query, an org-ql
query like this could work:

(and (property "SHOWFROMDATE")
 (yantar/showfromdate (property "SHOWFROMDATE")))

The first (property "SHOWFROMDATE") clause allows org-ql to optimize the
query using a regexp preamble that jumps directly to entries having that
property, while the second clause passes the value of the property to
the custom predicate using the built-in predicate (property
"SHOWFROMDATE") to retrieve the property from the org-ql node-value
cache, which reduces the number of calls to org-entry-get.  (That the
`property' predicate returns the value of the property when called with
only a property argument is a helpful feature that I should document...)

> Thanks for the info! I did not know about this optimisation in org-ql.
> org-entry-get consumes most of cpu time while building my agenda views.
> Though I don't think that there will be much difference for me since
> most of my property conditions in agenda involve inherited properties.

For properties using inheritance, the preamble regexp can't be used to
optimize the query across the buffer (I have some ideas about how to do
that, maybe someday...), but the node-value cache can improve
performance of retrieving the values of inherited properties within a
buffer, because it avoids repeated calls to org-entry-get going up an
outline tree.

For example, see the benchmark here:

https://github.com/alphapapa/org-ql/blob/master/notes.org#caching-of-inherited-tags

The node-value cache, which is used for properties, uses essentially the
same code as the tag cache benchmarked here (I haven't yet converted the
tag cache to use the generic node-value cache), and it provides about a
6x speedup, so property-inheritance-based queries should benefit
similarly.

So it sounds like your custom agendas would benefit from being written
as org-ql queries.  Please let me know if you try it, as your examples
would give the code a good workout and might reveal some improvements to
be made.




Re: [Idea] Org Collections

2019-12-15 Thread Adam Porter
How does this idea compare with Akira Komamura's org-starter package?

https://github.com/akirak/org-starter

Its readme begins:

> Org-starter is a framework for basic configuration of Emacs Org
> Mode. It allows you to configure Org Mode easily even with many files
> and directories.

> The standard way to configure Org Mode is set a bunch of variables
> such as org-agenda-files and org-refile-targets. This makes it hard to
> add/delete files to/from the configuration. Org-starter lets you
> configure Org Mode in a file-centric and incremental manner, which
> scales well especially if you have many Org files and sometimes have
> to tweak the file list.

> In other words, org-starter allows you to configure Org Mode in a
> manner similar to use-package. The following is an example file
> configuration with org-starter:

>(org-starter-define-file "subjects.org"
>  :agenda t
>  :refile '(:maxlevel . 9))




Re: Emacs bug 37890; killing capture buffer

2019-12-13 Thread Adam Porter
Michael Heerdegen  writes:

> Or (really better IMHO) consider a different implementation where the
> original buffer is not modified until the user explicitly confirms the
> stuff to capture with C-c C-c.

That would be helpful in some ways, but harmful in others.  For example,
consider a capture that is started while in a meeting, on a phone call,
away from one's desk, etc., with some notes in it, clock start time,
etc.  (You can find examples of this workflow in, e.g. Bernt Hansen's
Org config.)  If Emacs were interrupted (crash, power failure, reboot,
etc), the un-finalized capture would still be present in the auto-save
file and could be recovered when restarting Emacs and finding the file
again.

But if the original buffer were not modified until the capture is
finalized, where would the unfinalized data be, and how would it be
recovered into the desired capture location?

The way Org uses indirect, narrowed buffers for capturing is an elegant
use of Emacs features that helps protect user data from accidental loss.




Re: Asynchronous org-agenda-redo

2019-12-13 Thread Adam Porter
Ihor Radchenko  writes:

>>> Asynchronous code is not faster; it's generally slower because of
>>> yielding and synchronization.
>
>> Anyway, I will try to throw yields into agenda code just to check how
>> bad the performance can degrade.
>
> With the following code, org-agenda-redo runs for 21 second on my
> system, while without threads it is 16 seconds. However, emacs remains
> responsive during rebuilding agenda!
>
> (define-advice org-agenda-redo (:around (oldfun  all) make-async)
>   (make-thread (lambda () (funcall oldfun all)) "org-agenda-redo"))
> (define-advice org-agenda-skip-eval (:around (oldfun form) make-async)
>   (thread-join (make-thread (lambda () (funcall oldfun form)) 
> "org-agenda-skip-eval")))

That's a very elegant way to add the threading!  The performance penalty
is noticeable, but the tradeoff could be worth it in some cases, like a
background agenda refresh on a timer, or after a "remote" edit.  I can
imagine an org-agenda-refresh-async command that would add that advice
and remove them in an unwind-protect.

> The problem, of course, is that touching agenda buffer and org buffers
> may be risky while org-agenda-redo is running.
> Wondering if it is possible to block user commands during that time.

The first thing that comes to mind is to set buffer-read-only on each
buffer before it is scanned, and unset it when done with a buffer.  That
might not be doable with advice.




Re: Asynchronous org-agenda-redo

2019-12-13 Thread Adam Porter
Ihor Radchenko  writes:

>> org-ql doesn't use skip functions, just queries.
>
> Skip functions are essentially used-defined queries as soon as the
> queries are tested against every headline.

Skip functions aren't necessary with org-ql, because the query itself
can have arbitrary Lisp code.  So, of course, you can call custom
functions in queries, even your own skip functions (with `not', of
course), but in most cases, they can be covered with built-in
predicates.

> I can rewrite my skip functions into queries, but I don't expect much
> improvement since org-ql seems to use org-entry-get, which is the main
> performance bottleneck for my agenda generation.

org-entry-get is only called for the (property) predicate.  It's the
correct way to get Org properties, because it handles special
properties, inheritance, etc.  However, when possible, queries are
optimized to a whole-buffer regexp search that finds possible matches.
So, for example, a query like '(property "owner" "yantar") would be
optimized to a whole-buffer regexp search that would be very fast.  See
function org-ql--query-preamble.





Re: Asynchronous org-agenda-redo

2019-12-12 Thread Adam Porter
Ihor Radchenko  writes:

>> Be sure to read the Emacs Lisp manual regarding threads.  They are
>> cooperative, so functions called as threads must yield back to the main
>> thread for Emacs to do anything else before the function returns.
>
> I tried to read the manual, but I clearly misunderstand something.
> The manual says:
>
>>   Currently, thread switching will occur upon explicit request via
>> ‘thread-yield’, when waiting for keyboard input... 
>
> So, except directly calling thread-yield, it should be possible to
> trigger switching the current thread when keyboard input is expected.
> I tried the following demo code:
>
> (defun test ()
>   (let ((a 0))
> (dotimes (_ 5)
>   (setq a (1+ a))
>   (sleep-for 2)
>   (message "%s" a
>
> (progn ;This should return to command loop quickly
>   (make-thread #'test)
>   (message "Executed...")); `eval-last-sexp' here
>
> I can move around the buffer while the progn is running.
> However, it is not the case with `org-agenda-redo' for a reason I do not
> fully understand.

Org Agenda code does not wait for keyboard input; it's busy building the
agenda.  This is the case with most code in Emacs: it's not written to
be asynchronous, and it doesn't return to the main thread until done.
So you can sprinkle yields here and there and maybe be able to move
point around while some code is running, but that will decrease
performance, as well as introducing another level of complexity and
another class of bugs (e.g. what if the user modifies a buffer while the
agenda code is scanning it?).

>> 1.  The process would have to load the same Org buffers, which takes
>> time, especially in large buffers.  Depending on configuration, it
>> can take some time, indeed.
>
>> 3.  Ensuring that configuration and state between the main Emacs process
>> and the separate, agenda-generating process is not necessarily
>> simple.  Consider as well that if a buffer had unsaved changes,
>> those would not be readable by the other process, which would lead
>> to invalid results.  One could force the buffers to be saved first,
>> but that may not always be desirable, as saving buffers can have
>> side effects.
>
> Why cannot org-buffer simply be copied into the subordinate process? If
> all be buffer-locals, text properties, and overlays are copied directly
> from the main emacs process, there may be no need to even initialise
> org-mode (the idea is to do something similar to clone-buffer).

AFAIK there exists no way to do such a thing.  Buffers are not designed
to be serialized/deserialized like that.  You could try writing some
Elisp code to do it, but the end result would probably be much slower
than existing agenda code, as well as more difficult to debug.

> The question though is whether buffer-locals + overlays + propertized
> .org files text + org-agenda-buffer copy can be sufficient to make the
> org-agenda-redo run properly. Are there any other buffers, variables,
> or other environment settings used by org-agenda-redo?

As you can see in org-agenda.el, it's complicated.  Remember that an
Emacs process is like a Lisp image, full of state.  The more symbols and
other structures you copy to the async Emacs process (by printing and
reading them as text, remember), the slower it's going to be--and it
will always be slower than not using async.

>> If your agenda buffers are taking too long to refresh, you might
>> consider org-ql's views/saved-searches as an alternative. ...
>
> I know org-ql and I am pretty sure that it will improve performance.
> Actually, if one can make built-in org-agenda asynchronous, org-ql can
> probably use similar approach and become even faster :)

Asynchronous code is not faster; it's generally slower because of
yielding and synchronization.

> I am trying on default org-agenda now mostly because my current config
> is heavily geared towards default agenda and I am not sure if
> refactoring everything to use org-ql will worth it at the end in terms
> of performance. I use too many slow custom skip-functions.

org-ql doesn't use skip functions, just queries.




Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

2019-12-12 Thread Adam Porter
May I recommend using the rx macro for regexps?  They are much easier
for humans to parse, which helps reduce errors like the ones mentioned
here.  And they are about to gain some very useful new features
in Emacs 27.




Re: Asynchronous org-agenda-redo

2019-12-12 Thread Adam Porter
Be sure to read the Emacs Lisp manual regarding threads.  They are
cooperative, so functions called as threads must yield back to the main
thread for Emacs to do anything else before the function returns.

If you're feeling adventurous, you could experiment with adding yields
in relevant agenda functions.  But that wouldn't be suitable for merging
into Org, because that yielding also decreases performance generally.

As long as Elisp threads are cooperative, they are of very limited use.

Generating agendas with async.el in a separate Emacs process is an
interesting idea, but probably generally impractical for a few reasons:

1.  The process would have to load the same Org buffers, which takes
time, especially in large buffers.  Depending on configuration, it
can take some time, indeed.
2.  The process would also have to load the same packages (or, at least,
all the necessary ones, which depends on configuration), which takes
time.
3.  Ensuring that configuration and state between the main Emacs process
and the separate, agenda-generating process is not necessarily
simple.  Consider as well that if a buffer had unsaved changes,
those would not be readable by the other process, which would lead
to invalid results.  One could force the buffers to be saved first,
but that may not always be desirable, as saving buffers can have
side effects.

If your agenda buffers are taking too long to refresh, you might
consider org-ql's views/saved-searches as an alternative.  The built-in
caching in org-ql significantly improves performance, especially when
refreshing views.




Re: org-custom-id-goto?

2019-12-05 Thread Adam Porter
Functions like helm-org-in-buffer-headings,
helm-org-agenda-files-headings, etc. are built-in to the helm-org
package (they used to be part of the helm package, but now they're in
this separate helm-org package which is not installed automatically with
the helm package).

The packages org-rifle and org-ql are also helpful here.  For example,
with the command helm-org-ql, you could use a search query like:

property:CUSTOM_ID=emacs-notes

You could also define a custom predicate that searches CUSTOM_ID
properties, so you could type a query like:

cid=emacs-notes

You could even go a step further and define a custom command that used
that predicate by default, so you could simply type the custom ID as the
query.  See discussion at .




Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

2019-12-05 Thread Adam Porter
Karl Fogel  writes:

> Unless you meant make a new interactive function to display a vertical
> hierarchy and base it on the existing Org Mode functions you informed
> me of the existence of?  But I don't think there's a way to do that
> without adding some new parameters to those existing functions, and,
> as you point out, that's probably not worth the extra complexity.

Forgive me, I think I misunderstood you.  Yes, I meant to make a new
interactive function for displaying the vertical hierarchy.

BTW, you might also find the org-sticky-header package helpful.




Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

2019-12-05 Thread Adam Porter
Karl Fogel  writes:

> Unless you meant make a new interactive function to display a vertical
> hierarchy and base it on the existing Org Mode functions you informed
> me of the existence of?  But I don't think there's a way to do that
> without adding some new parameters to those existing functions, and,
> as you point out, that's probably not worth the extra complexity.

I'm not sure what you mean about having to add new parameters to
existing functions.  For example, if I understand correctly what you're
wanting, this code does approximately that:

(defun ap/org-display-olp-lines ()
  (interactive)
  (thread-first
  (cl-loop for heading in (org-get-outline-path t)
   for i from 0
   for indent = (make-string (* i 2) ? )
   collect (concat indent "* " heading))
(string-join "\n")
message))

Which displays, e.g.

* Computers
  * Software
* Emacs
  * Org-mode
* Articles
  * Orgmode for GTD




Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

2019-12-03 Thread Adam Porter
Karl Fogel  writes:

> Thank you, Adam -- I didn't know about those.  I had searched for
> something like that before implementing my own, but I think I searched
> using the term "heading" or something instead of "outline",
> unfortunately, so I never found them.

Org is like Emacs in that it has many nooks and crannies that even
experienced users are unfamiliar with.  There's always something more to
discover.

> Now that I know about `org-display-outline-path', the one improvement
> I'd like to make is to enable it to display the headings with
> per-level indentation, and treat the first level specially (with an
> anchoring dot instead of a directional arrow), as my code did.  It's a
> lot more readable that way displayed in the minibuffer.

You might consider adjusting your fontification settings.  The
single-line outline path can be quite readable with the right faces (see
attached example).
> I suppose I would implement this by adding two new optional arguments to 
> `org-display-outline-path':
>
>   * `per-level-indentation': add a newline followed by  times> in front of each SEPARATOR
>
>   * `level-1-prefix': a special prefix for the first level's heading

I'd recommend against adding more optional arguments to that function,
because it already has four.  Emacs/Org already have enough problems
with code like (org-whatever nil t nil t nil nil t).

> ...and make corresponding changes to the helper functions of course.

Please consider such changes very carefully, because those functions are
used by a number of other packages.  It's already difficult, and often
frustrating, for package authors to maintain code that works across Org
versions, which persist in the wild for years.  Today Org 9.3 was
released with more breaking changes, and I'm just waiting for the bug
reports to roll in on my packages so I can add more conditional
definitions and aliases to meet the needs of the variety of users out
there.

> There should also be some way to access the new functionality
> interactively; the solution might be a new interactive wrapper
> function with its own name, or maybe some new variables?  I don't
> know; I haven't thought it all the way through yet.

> Is there any interest in or opposition to such a patch?  I'd like to
> get a sense of whether it would be able to land in Org Mode before I
> start working on it.

I'd recommend simply making a new interactive function, putting it in
your personal config, and sharing it publicly (e.g. here and on
/r/orgmode).  Use it "in anger" for a while, and solicit feedback from
other users for a while.  Then, if it still seems widely useful enough
to deserve being added to Org proper, apply what you've learned in the
meantime to improve and simplify its implementation before proposing a
patch.

You might also consider sending it to my "unpackaged.el" repo, which
might make a good home for it: http://github.com/alphapapa/unpackaged.el


Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

2019-12-03 Thread Adam Porter
Karl Fogel  writes:

> By the way, when I run `M-x eldoc-mode' in a Org Mode buffer, I get this 
> message:
>
>   "There is no ElDoc support in this buffer"
>
> Am I doing it wrong?

You need org-eldoc.el from /contrib.




Re: [PROPOSAL] New function `org-headings-to-point' and displayer.

2019-12-03 Thread Adam Porter
This seems to duplicate functionality from org-get-outline-path.  As
well, org-eldoc displays in the minibuffer the outline path for the
heading at point.




Re: [PATCH] org-timer.el: Allow org-timer-set-timer from non-Org buffers

2019-11-16 Thread Adam Porter
Hi Ian,

There's a small typo in the docstring.  :)




Re: Agenda: Display scheduled items only once

2019-11-16 Thread Adam Porter
Have you checked these settings?

  M-x customize-group RET org-agenda RET

Be sure to check the subgroups as well--there are many options.




Re: Exporting agendas as org-mode files?

2019-11-14 Thread Adam Porter
Mikhail Skorzhinskii  writes:

> Here is the snippet I am currently using to export all subtress directly
> tagged with :info: to the separate file. (Sorry for the lack of proper
> parametrisation).
>
> #+begin_src emacs-lisp
> (defun org-user/store-info ()
>   (let ((file "~/org/cals/info.org")
> (heading (org-format-outline-path (org-get-outline-path t
> (save-excursion
>   (org-copy-subtree)
>   (find-file file)
>   (end-of-buffer)
>   (org-paste-subtree)
>   (org-edit-headline heading
>
> (defun org-user/export-info ()
>   "Export all information entries into one file."
>   (find-file "~/org/cals/info.org")
>   (erase-buffer)
>   (insert "#+TITLE: Information")
>   (org-ql-select
> (org-agenda-files)
> '(tags-local "info")
> :action #'org-user/store-info)
>   (save-buffer))
> #+end_src

Thanks, Mikhail, it's like you read my mind.  :)




Re: Exporting agendas as org-mode files?

2019-11-12 Thread Adam Porter
org-ql would make this pretty easy, I think.  Use an org-ql query to
select entries, and for the :action function, use a simple function that
copies the entry or subtree and yanks it into a buffer.  Then save that
buffer to a file.




Re: orgformat.py: util library for generating Org mode from Python

2019-11-06 Thread Adam Porter
Thanks for working on and sharing this, Karl.  It's great to see the Org
format getting more support in other languages and contexts.




Re: Anyone use 3rd party search tools w/org-mode?

2019-11-06 Thread Adam Porter
Eric Abrahamsen  writes:

> I think this last point is key. Most full-text search engines provide
> config options for defining fields, or "facets", which in theory we
> could set up to parse tags/properties/timestamps.

Of course it's an Emacs-based tool, but please note that org-ql has
extensive, optimized support for searching Org-specific data like that.
For example, you could search for those three data types in a single
query, like:

  tags:Emacs,Org property:key1=val1,key2=val2 ts-active:on=2019-11-06




Re: org-scrum

2019-10-29 Thread Adam Porter
ian martins  writes:

> Hello, I wrote some helper functions for generating a scrum board and
> reports that is built on top of org-mode. The project is currently
> emacs-scrum. I submitted it to melpa recently and got the suggestion
> to name the package org-scrum since it's based on org-mode. Is that
> fine?

Yes.




Re: Discrepancy between documentation and implementation regarding comments

2019-10-27 Thread Adam Porter
I agree with Robert that "whitespace" includes newlines in "Emacsland."
For example, with this document (the second "#" has a newline
immediately after, no spaces or tabs):

#+BEGIN_SRC org
foo

# comment

bar

#

buzz
#+END_SRC

This code matches both lines that begin with "#":

  (re-search-forward (rx bol "#" (1+ space)))

But this code only matches the first one, because "blank" only matches
"horizontal whitespace":

  (re-search-forward (rx bol "#" (1+ blank)))

So I think Pandoc is technically at fault here.  However, outside of
Emacs's own context, I can see how the the documentation could be
misinterpreted in this case, so it's hard to fault them too much.  :)




Re: [O] [RFC] Document level property drawer

2019-10-23 Thread Adam Porter
Gustav,

There are a lot of deprecation recommendations in your attached
document:

> I propose to depricate property-keywords
> I propose to depricate the Options-keyword
> I propose to relabel these keywords as document keywords
> I propose to depricate the #+CATEGORY syntax
> I propose to depricate the #+FILETAGS syntax
> I propose to depricate the #+COLUMNS syntax
> I propose to depricate the #+ARCHIVE syntax
> I propose to depricate the TODO-keywords
> I propose to depricate the priorities-keyword
> I propose to depricate the tags-keyword
> I propose to depricate the link-keyword
> I propose to depricate the constants-keyword
> I propose to depricate the setupfile-keyword
> I propose to depricate the Macro-keyword

The thoroughness of your investigation is admirable.

However, I propose that we don't deprecate any of those.  Org has been
around for over a decade now.  Such drastic changes would not serve
users well.

Note that I'm taking your use of the word "deprecate" to mean what
it's expected to mean in this context: that the software developers
recommend against using it, with the intention to eventually remove
support for the feature.  We shouldn't be removing any such features
from Org.

Not only would it not serve users well, but it would make the software
much more complicated.  As it stands, finding, e.g. a #+CATEGORY:
keyword and getting its value is as simple as:

(save-excursion
  (goto-char (point-min))
  (when (re-search-forward (rx bol "#+CATEGORY:" (1+ blank)
   (group (1+ nonl)))
   nil t)
(match-string 1)))

Hiding those keywords in drawers means that either:

a) Eligible drawers must be located, and then the desired
property must be searched for inside of them.

b) Possibly valid properties must be located, and each one must be
confirmed to be inside an eligible drawer.

What benefit would this added complexity serve?  To put the keywords
in one place in the document?  There are already multiple ways to
achieve that.

I can't emphasize enough how important stability and consistency is
for Org and its file formats right now.  As I've said, there are new
implementations in development, which have the potential to bring a
lot of publicity and new users to Org.  For example, this one was
mentioned on a Hacker News post a few days ago:

https://github.com/mickael-kerjean/filestash

In the same HN post were examples of implementations for Vim and
VSCode.  Already, especially in the VSCode ones, there were apparent
incompatibilities in their implementations of the Org file format.

As well, there are now parsers in JavaScript, Python, and Rust.

Markdown is by far the most popular plain-text format, and has been
for years, but it has long suffered from competing, slightly
incompatible flavors and implementations.  Reddit has theirs, GitHub
has theirs, etc.

Org's file format may finally be gaining some momentum.  Let's not
jeopardize Org's chances by making implementors' job more difficult
than it already is.




Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation

2019-10-23 Thread Adam Porter
Clearly my Gnus-fu is weak, as somehow I posted that in entirely the
wrong thread.  :)




Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation

2019-10-22 Thread Adam Porter
Gustav,

There are a lot of deprecation recommendations in your attached
document:

> I propose to depricate property-keywords
> I propose to depricate the Options-keyword
> I propose to relabel these keywords as document keywords
> I propose to depricate the #+CATEGORY syntax
> I propose to depricate the #+FILETAGS syntax
> I propose to depricate the #+COLUMNS syntax
> I propose to depricate the #+ARCHIVE syntax
> I propose to depricate the TODO-keywords
> I propose to depricate the priorities-keyword
> I propose to depricate the tags-keyword
> I propose to depricate the link-keyword
> I propose to depricate the constants-keyword
> I propose to depricate the setupfile-keyword
> I propose to depricate the Macro-keyword

The thoroughness of your investigation is admirable.

However, I propose that we don't deprecate any of those.  Org has been
around for over a decade now.  Such drastic changes would not serve
users well.

Note that I'm taking your use of the word "deprecate" to mean what
it's expected to mean in this context: that the software developers
recommend against using it, with the intention to eventually remove
support for the feature.  We shouldn't be removing any such features
from Org.

Not only would it not serve users well, but it would make the software
much more complicated.  As it stands, finding, e.g. a #+CATEGORY:
keyword and getting its value is as simple as:

(save-excursion
  (goto-char (point-min))
  (when (re-search-forward (rx bol "#+CATEGORY:" (1+ blank)
   (group (1+ nonl)))
   nil t)
(match-string 1)))

Hiding those keywords in drawers means that either:

a) Eligible drawers must be located, and then the desired
property must be searched for inside of them.

b) Possibly valid properties must be located, and each one must be
confirmed to be inside an eligible drawer.

What benefit would this added complexity serve?  To put the keywords
in one place in the document?  There are already multiple ways to
achieve that.

I can't emphasize enough how important stability and consistency is
for Org and its file formats right now.  As I've said, there are new
implementations in development, which have the potential to bring a
lot of publicity and new users to Org.  For example, this one was
mentioned on a Hacker News post a few days ago:

https://github.com/mickael-kerjean/filestash

In the same HN post were examples of implementations for Vim and
VSCode.  Already, especially in the VSCode ones, there were apparent
incompatibilities in their implementations of the Org file format.

As well, there are now parsers in JavaScript, Python, and Rust.

Markdown is by far the most popular plain-text format, and has been
for years, but it has long suffered from competing, slightly
incompatible flavors and implementations.  Reddit has theirs, GitHub
has theirs, etc.

Org's file format may finally be gaining some momentum.  Let's not
jeopardize Org's chances by making implementors' job more difficult
than it already is.




Re: [O] [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

2019-10-15 Thread Adam Porter
Hi Sebastian,

Sebastian Miele  writes:

> * lisp/org-src.el (org-src--contents-for-write-back): Use the
> potentially buffer-local value of `org-edit-src-content-indentation'
> from the source buffer instead of that from the editing buffer.
> ---
>  lisp/org-src.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/org-src.el b/lisp/org-src.el
> index 9134d5b5d..b7fe4c0fa 100644
> --- a/lisp/org-src.el
> +++ b/lisp/org-src.el
> @@ -422,7 +422,8 @@ Assume point is in the corresponding edit buffer."
>(if org-src--preserve-indentation 0
>  (+ (or org-src--block-indentation 0)
> (if (memq org-src--source-type '(example-block src-block))
> -   org-edit-src-content-indentation
> +   (with-current-buffer (marker-buffer org-src--beg-marker)
> + org-edit-src-content-indentation)
>   0
>   (use-tabs? (and (> org-src--tab-width 0) t))
>   (source-tab-width org-src--tab-width)

You might consider using the function buffer-local-value instead of the
macro with-current-buffer.  Not that it matters so much here, but
benchmarking shows that it is much faster when simply accessing the
buffer-local value of a variable.




Re: [O] (re-)introducing: orgtbl-query (nee org-query)

2019-10-15 Thread Adam Porter
Hi Greg,

That's very cool!  Thanks for sharing it.




Re: [O] [RFC] Document level property drawer

2019-10-15 Thread Adam Porter
Gustav Wikström  writes:

> Hi again,
>
> I'd like to take the next step with this patch. I'm hesitant to do it
> without wider support though, since only a few people have commented.
>
> @Marco Wahl; As I understand you've applied the patch and tried it
> out. Have you found any issues yet? What do you think of the patch
> after having used it for a while?
>
> Any other thoughts/comments/objections/praises?

Please do not merge your patch without the approval of the Org
maintainers.




Re: [O] Help with "macro"

2019-10-12 Thread Adam Porter
Nathan Neff  writes:

> I'm trying to implement a function to display the TODO items of the
> currently highlighted item in the agenda and have a few questions:
>
> Goal:
>
> 1) From the agenda, place the cursor on a heading.
>
> 2) Press a key and instantly narrow the agenda to the heading which
> the cursor is on.
>
> 3) Display org-todo-list for the "narrowed" item in a new buffer, with
> the name "agenda for " or perhaps "agenda for  "PROP" of the narrowed item"
>
> 4) Keep the existing original agenda view (using sticky or some other
> tactic).

Agenda restrictions are awkward to work with.  I recommend using org-ql
for this sort of thing, since it's designed to do things like this.
This seems to work:

(defun nn/agenda-item-todos ()
  (interactive)
  (org-with-point-at (org-get-at-bol 'org-marker)
(save-restriction
  (org-narrow-to-subtree)
  (org-ql-search (current-buffer)
'(todo)
:narrow t




Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation

2019-10-10 Thread Adam Porter
stardiviner  writes:

> This is really a helpful sidebar package. Thanks :) I like it very much.
>
> Hope can add an command to toggle it. I found I have to manually close it.

FYI, I just added some toggle commands.  Thanks for the suggestion.




Re: [O] [PATCH] org: org-get-priority: reduce `not`, deduplicate magic `(* 1000 ..)` operation

2019-10-09 Thread Adam Porter
Hi Anton, Nicolas, et al,

I'm in favor of tidying up the priority-related code, as I also have
found it hard to follow.

But please do not change the API of these functions, i.e. the signatures
and return values.  Their output is used in other packages, including
some of mine like org-rifle, org-super-agenda, and org-ql.  If the API
were to change, it would create significant headaches in writing
compatibility code for different Org versions.

I can't easily tell if that's something that's been proposed, but I'm
making the request just in case.

Thanks,
Adam




  1   2   3   4   5   >