next-error for agenda searches

next-error for agenda searches

[Samuel Wales]

if you search for a regexp in a single org buffer, you can do
next-error to go to the next search.

if you search in agenda, there is a mode where the match will show up
in the ohter window.  i find this inconvenient.

there is no next-error to go to the next match for agenda searches.
or am i missing this feature someplace?  seems strange not to?

such a thing would be consistent with c-c / / in an org buffer,
grep-mode, occur-mode, compilation-shell-minor-mode.  thanks!

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Samuel Wales]

just curious whehter fr/bug/inconsistency emails drop off the end of
the org mailing list or whether they go on a todo list someplace.

i have others not responded to but can't keep track of them, but
that's ok.  i am grateful for the work done on org.  i realize this is
not a hight priority item, and possibly of no interest to others, and
everybody is a volunteer, etc.  not asking about that stuff.


On 12/14/21, Samuel Wales <samologist@gmail.com> wrote:
> if you search for a regexp in a single org buffer, you can do
> next-error to go to the next search.
>
> if you search in agenda, there is a mode where the match will show up
> in the ohter window.  i find this inconvenient.
>
> there is no next-error to go to the next match for agenda searches.
> or am i missing this feature someplace?  seems strange not to?
>
> such a thing would be consistent with c-c / / in an org buffer,
> grep-mode, occur-mode, compilation-shell-minor-mode.  thanks!
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> just curious whehter fr/bug/inconsistency emails drop off the end of
> the org mailing list or whether they go on a todo list someplace.

Yes and no. Most of your emails are feature requests (at least that's my
impression) and some of them are very short and do not explain why the
feature is needed for other people than you.

Feature requests are generally of lower priority unless they get
traction via many responses from other interested users. Similar case
for general questions.

Your recent bug reports are also difficult to process because of lack of
reproducer. They are in a todo list though.

Best,
Ihor

Re: next-error for agenda searches

[Samuel Wales]

btw, if anybody has difficulty understanding why i mention a bug or
suggest a feature [such as why anbydoy would want it], please feel
free to say so, otherwise i don't know that that is the case.  [please
go easy on me though.]

in this case, it is an emacs consistency fr.  across emacs, next-error
goes from match to match, and it seems to me [perhaps i am mistaken]
that agenda searches should be emacsy too.

as for why it would be useful to me, so that i can get full context,
with point at the match, thus 1] getting all the matches in my hands
in the outline and 2] being able to edit immediately.

furthermore, the next-closest thing, follow mode, puts point in wrong
window.  also, 'canonical visibility is not present so i cannot see
everything [this might or might not be fixable by user].

also there is an accessibility issue with it.  i use large fonts so 2
windows do not show much.  i use 2 windows only for very rare
completion or selecting purposes.  not usable here.

but i think it is an emacs consistency issue.  i agree with the
frequently expressed idea that new features should be justified
carefully, and next-error working as in e.g. grep seems right here.

this isn't a huge deal for me at all, but e.g. when i do agenda
searches i get really overwhelmed by the size and irrelevance
[including duplication] of my own org forest developed over years.

next-error would help me traverse and trim it rapidly.  i could
perhaps create a kb macro to emulate it, but i haven't tried yet.
then again, one could do so for grep mode etc. also.  :]

On 12/14/21, Samuel Wales <samologist@gmail.com> wrote:
> if you search for a regexp in a single org buffer, you can do
> next-error to go to the next search.
>
> if you search in agenda, there is a mode where the match will show up
> in the ohter window.  i find this inconvenient.
>
> there is no next-error to go to the next match for agenda searches.
> or am i missing this feature someplace?  seems strange not to?
>
> such a thing would be consistent with c-c / / in an org buffer,
> grep-mode, occur-mode, compilation-shell-minor-mode.  thanks!
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Samuel Wales]

another thing: it is an org consistency fr also, as in the outline c-c
/ does use next-match, and it would be good to have the same
capability among agenda results files, not merely in a single buffer.

On 12/18/21, Samuel Wales <samologist@gmail.com> wrote:
> btw, if anybody has difficulty understanding why i mention a bug or
> suggest a feature [such as why anbydoy would want it], please feel
> free to say so, otherwise i don't know that that is the case.  [please
> go easy on me though.]
>
> in this case, it is an emacs consistency fr.  across emacs, next-error
> goes from match to match, and it seems to me [perhaps i am mistaken]
> that agenda searches should be emacsy too.
>
> as for why it would be useful to me, so that i can get full context,
> with point at the match, thus 1] getting all the matches in my hands
> in the outline and 2] being able to edit immediately.
>
> furthermore, the next-closest thing, follow mode, puts point in wrong
> window.  also, 'canonical visibility is not present so i cannot see
> everything [this might or might not be fixable by user].
>
> also there is an accessibility issue with it.  i use large fonts so 2
> windows do not show much.  i use 2 windows only for very rare
> completion or selecting purposes.  not usable here.
>
> but i think it is an emacs consistency issue.  i agree with the
> frequently expressed idea that new features should be justified
> carefully, and next-error working as in e.g. grep seems right here.
>
> this isn't a huge deal for me at all, but e.g. when i do agenda
> searches i get really overwhelmed by the size and irrelevance
> [including duplication] of my own org forest developed over years.
>
> next-error would help me traverse and trim it rapidly.  i could
> perhaps create a kb macro to emulate it, but i haven't tried yet.
> then again, one could do so for grep mode etc. also.  :]
>
> On 12/14/21, Samuel Wales <samologist@gmail.com> wrote:
>> if you search for a regexp in a single org buffer, you can do
>> next-error to go to the next search.
>>
>> if you search in agenda, there is a mode where the match will show up
>> in the ohter window.  i find this inconvenient.
>>
>> there is no next-error to go to the next match for agenda searches.
>> or am i missing this feature someplace?  seems strange not to?
>>
>> such a thing would be consistent with c-c / / in an org buffer,
>> grep-mode, occur-mode, compilation-shell-minor-mode.  thanks!
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> btw, if anybody has difficulty understanding why i mention a bug or
> suggest a feature [such as why anbydoy would want it], please feel
> free to say so, otherwise i don't know that that is the case.  [please
> go easy on me though.]

This is a difficult query. There are many emails coming through mailing
lists daily and people tend to skip everything
confusing/unclear/uninteresting. So, difficulty in understanding most
likely leads to no replies.

> in this case, it is an emacs consistency fr.  across emacs, next-error
> goes from match to match, and it seems to me [perhaps i am mistaken]
> that agenda searches should be emacsy too.

FYI, I never used next-error. Reading through the docstring, it looks
like it is not very suitable for agendas.

AFAIU, normal use case of next-error is when you have a big project with
multiple files and you want to look at the context for every compiler
error. You have a single compiler error log that can be assigned to
places in the project.

This kind of assumption is not correct for Org agendas. I assume that
your workflow only includes a single agenda view all the time. However,
multiple agenda views is not an uncommon workflow. You may have daily
agenda, some tag-matching agendas, agendas with various restrictions,
etc. It would be unclear which agenda view to use when you call
next-error. Last generated? Last visited? What about agenda filters?
Dimmed tasks?

> furthermore, the next-closest thing, follow mode, puts point in wrong
> window.  also, 'canonical visibility is not present so i cannot see
> everything [this might or might not be fixable by user].

Can you elaborate?

> also there is an accessibility issue with it.  i use large fonts so 2
> windows do not show much.  i use 2 windows only for very rare
> completion or selecting purposes.  not usable here.

I also use relatively large fonts, though I do have space for two
windows (but not more). Note that there is org-agenda-entry-text-mode.
Might be useful. Also, I personally prefer org-quickpeek in agenda.

> this isn't a huge deal for me at all, but e.g. when i do agenda
> searches i get really overwhelmed by the size and irrelevance
> [including duplication] of my own org forest developed over years.

This sounds like you could use more tight search criteria or custom
agenda searches. An example of irrelevant vs. relevant information could
help us to suggest something for you.

> next-error would help me traverse and trim it rapidly.  i could
> perhaps create a kb macro to emulate it, but i haven't tried yet.
> then again, one could do so for grep mode etc. also.  :]

If you decide to go with macro, it should not be too hard. Just <RET> on
agenda item, do your edits, macro-beg, switch to agenda buffer,
next-line, <RET>, macro-end

Best,
Ihor

Re: next-error for agenda searches

[Samuel Wales]

On 12/19/21, Ihor Radchenko <yantar92@gmail.com> wrote:
> multiple agenda views is not an uncommon workflow. You may have daily

i think this is a strong objection.  multiple simultaneous agenda
views seems to sink my suggestion.

can one have multiple simultaneous c-c / buffers?  and multiple
grep/occur/compilation shell minor mode?

or a grep buffer and an occur buffer and a compilation shell minor
mode buffer simultaneously?  what disambiguates those?

idk what is done in such cases.  perhaps there is an assumption of a
single set of errors at a time, or some buffer local thing.

> etc. It would be unclear which agenda view to use when you call
> next-error. Last generated? Last visited? What about agenda filters?
> Dimmed tasks?

yes, good points, if you mean separate agendas.  [else filters
honored; dimmed presumably not skipped by default.]

>
>> furthermore, the next-closest thing, follow mode, puts point in wrong
>> window.  also, 'canonical visibility is not present so i cannot see
>> everything [this might or might not be fixable by user].
>
> Can you elaborate?

well it is moot because of the accessibility issue, but it is
unsuitable for the next-error task.  point in wrong window so you have
to switch.  some things hidden so you have to make visible is all i
meant.  again, moot so no suggestions needed here.

>> also there is an accessibility issue with it.  i use large fonts so 2
>> windows do not show much.  i use 2 windows only for very rare
>> completion or selecting purposes.  not usable here.
>
> I also use relatively large fonts, though I do have space for two
> windows (but not more). Note that there is org-agenda-entry-text-mode.

indeed that shows text.  not editable directly in the real buffer, so
not like next-error.  not useful for me in practice but nice.

the next-error idea is for consistency with other parts of emacs.
your multiple simultaneous agenda problem might nix it, dunno.

> Might be useful. Also, I personally prefer org-quickpeek in agenda.

can't seem to find that package but next-error allows editing not just peeking.

> This sounds like you could use more tight search criteria or custom
> agenda searches. An example of irrelevant vs. relevant information could
> help us to suggest something for you.

appreciate the offfer but pretty ure nobody can help here.  i am also
limited in computer use and the back and forth is an issue.  i would
not be able to describe the poroblems in sufficient detail, there
would be further questions, i'd have to respond, etc.

but basically i have had org for a long time and i am not able to
maintain my forest as well as i need to.

but it was just one point of many.  help here would in most cases
likely be smething i have already thought of.  appreciates the offer.

next-error is a sort of general tool.  it is not just for this purpose
and compilation errors.  imo at least.  that is why c-c / uses it.

>
>> next-error would help me traverse and trim it rapidly.  i could
>> perhaps create a kb macro to emulate it, but i haven't tried yet.
>> then again, one could do so for grep mode etc. also.  :]
>
> If you decide to go with macro, it should not be too hard. Just <RET> on
> agenda item, do your edits, macro-beg, switch to agenda buffer,
> next-line, <RET>, macro-end

yes :) [and doing soething to create canonical visibility at point so
that everything relevant is visible, and setting line in window].

[and finding that kb macro to lisp package and binding the command and
possibly overloading the next-error bindings.]

>
> Best,
> Ihor
>
>

my suggestion was for org's sake and i didn't think this much detail
would be needed at the time.  i used my computer use time to do the
best i could, but it seems that more detail was needed, and that
detail needed discussion.  my bad.

n.b.  i've been on the list for years, and many core features of org,
and parts thereof, were actually... my suggestions :).

but sometimes i miss the mark apparently, especially lately.  as in this case.

still, not sure why multiple grep buffers or grep with occur or c-c /,
etc. are compatible but multiple simultaneous agenda not so.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Samuel Wales]

[as an example, i should not have brought up the follow mode example
at all.  it seems to have only confused readers.  i was trying to
forestall any suggestions that follow-mode exists and can do the job
that next-error can is all.  it can't do the same job.]

On 12/19/21, Samuel Wales <samologist@gmail.com> wrote:
> On 12/19/21, Ihor Radchenko <yantar92@gmail.com> wrote:
>> multiple agenda views is not an uncommon workflow. You may have daily
>
> i think this is a strong objection.  multiple simultaneous agenda
> views seems to sink my suggestion.
>
> can one have multiple simultaneous c-c / buffers?  and multiple
> grep/occur/compilation shell minor mode?
>
> or a grep buffer and an occur buffer and a compilation shell minor
> mode buffer simultaneously?  what disambiguates those?
>
> idk what is done in such cases.  perhaps there is an assumption of a
> single set of errors at a time, or some buffer local thing.
>
>> etc. It would be unclear which agenda view to use when you call
>> next-error. Last generated? Last visited? What about agenda filters?
>> Dimmed tasks?
>
> yes, good points, if you mean separate agendas.  [else filters
> honored; dimmed presumably not skipped by default.]
>
>>
>>> furthermore, the next-closest thing, follow mode, puts point in wrong
>>> window.  also, 'canonical visibility is not present so i cannot see
>>> everything [this might or might not be fixable by user].
>>
>> Can you elaborate?
>
> well it is moot because of the accessibility issue, but it is
> unsuitable for the next-error task.  point in wrong window so you have
> to switch.  some things hidden so you have to make visible is all i
> meant.  again, moot so no suggestions needed here.
>
>>> also there is an accessibility issue with it.  i use large fonts so 2
>>> windows do not show much.  i use 2 windows only for very rare
>>> completion or selecting purposes.  not usable here.
>>
>> I also use relatively large fonts, though I do have space for two
>> windows (but not more). Note that there is org-agenda-entry-text-mode.
>
> indeed that shows text.  not editable directly in the real buffer, so
> not like next-error.  not useful for me in practice but nice.
>
> the next-error idea is for consistency with other parts of emacs.
> your multiple simultaneous agenda problem might nix it, dunno.
>
>> Might be useful. Also, I personally prefer org-quickpeek in agenda.
>
> can't seem to find that package but next-error allows editing not just
> peeking.
>
>> This sounds like you could use more tight search criteria or custom
>> agenda searches. An example of irrelevant vs. relevant information could
>> help us to suggest something for you.
>
> appreciate the offfer but pretty ure nobody can help here.  i am also
> limited in computer use and the back and forth is an issue.  i would
> not be able to describe the poroblems in sufficient detail, there
> would be further questions, i'd have to respond, etc.
>
> but basically i have had org for a long time and i am not able to
> maintain my forest as well as i need to.
>
> but it was just one point of many.  help here would in most cases
> likely be smething i have already thought of.  appreciates the offer.
>
> next-error is a sort of general tool.  it is not just for this purpose
> and compilation errors.  imo at least.  that is why c-c / uses it.
>
>>
>>> next-error would help me traverse and trim it rapidly.  i could
>>> perhaps create a kb macro to emulate it, but i haven't tried yet.
>>> then again, one could do so for grep mode etc. also.  :]
>>
>> If you decide to go with macro, it should not be too hard. Just <RET> on
>> agenda item, do your edits, macro-beg, switch to agenda buffer,
>> next-line, <RET>, macro-end
>
> yes :) [and doing soething to create canonical visibility at point so
> that everything relevant is visible, and setting line in window].
>
> [and finding that kb macro to lisp package and binding the command and
> possibly overloading the next-error bindings.]
>
>>
>> Best,
>> Ihor
>>
>>
>
> my suggestion was for org's sake and i didn't think this much detail
> would be needed at the time.  i used my computer use time to do the
> best i could, but it seems that more detail was needed, and that
> detail needed discussion.  my bad.
>
> n.b.  i've been on the list for years, and many core features of org,
> and parts thereof, were actually... my suggestions :).
>
> but sometimes i miss the mark apparently, especially lately.  as in this
> case.
>
> still, not sure why multiple grep buffers or grep with occur or c-c /,
> etc. are compatible but multiple simultaneous agenda not so.
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Samuel Wales]

manual> These
commands can also be used in ‘*grep*’ buffers, where the hyperlinks are
search matches rather than error messages (*note Grep Searching::).
--- (info "(emacs) Compilation Mode")

it is likely common to have grep and compilation mode open at the same
time.  i think this is like your multiple agenda objection.  no?

On 12/19/21, Samuel Wales <samologist@gmail.com> wrote:
> [as an example, i should not have brought up the follow mode example
> at all.  it seems to have only confused readers.  i was trying to
> forestall any suggestions that follow-mode exists and can do the job
> that next-error can is all.  it can't do the same job.]
>
> On 12/19/21, Samuel Wales <samologist@gmail.com> wrote:
>> On 12/19/21, Ihor Radchenko <yantar92@gmail.com> wrote:
>>> multiple agenda views is not an uncommon workflow. You may have daily
>>
>> i think this is a strong objection.  multiple simultaneous agenda
>> views seems to sink my suggestion.
>>
>> can one have multiple simultaneous c-c / buffers?  and multiple
>> grep/occur/compilation shell minor mode?
>>
>> or a grep buffer and an occur buffer and a compilation shell minor
>> mode buffer simultaneously?  what disambiguates those?
>>
>> idk what is done in such cases.  perhaps there is an assumption of a
>> single set of errors at a time, or some buffer local thing.
>>
>>> etc. It would be unclear which agenda view to use when you call
>>> next-error. Last generated? Last visited? What about agenda filters?
>>> Dimmed tasks?
>>
>> yes, good points, if you mean separate agendas.  [else filters
>> honored; dimmed presumably not skipped by default.]
>>
>>>
>>>> furthermore, the next-closest thing, follow mode, puts point in wrong
>>>> window.  also, 'canonical visibility is not present so i cannot see
>>>> everything [this might or might not be fixable by user].
>>>
>>> Can you elaborate?
>>
>> well it is moot because of the accessibility issue, but it is
>> unsuitable for the next-error task.  point in wrong window so you have
>> to switch.  some things hidden so you have to make visible is all i
>> meant.  again, moot so no suggestions needed here.
>>
>>>> also there is an accessibility issue with it.  i use large fonts so 2
>>>> windows do not show much.  i use 2 windows only for very rare
>>>> completion or selecting purposes.  not usable here.
>>>
>>> I also use relatively large fonts, though I do have space for two
>>> windows (but not more). Note that there is org-agenda-entry-text-mode.
>>
>> indeed that shows text.  not editable directly in the real buffer, so
>> not like next-error.  not useful for me in practice but nice.
>>
>> the next-error idea is for consistency with other parts of emacs.
>> your multiple simultaneous agenda problem might nix it, dunno.
>>
>>> Might be useful. Also, I personally prefer org-quickpeek in agenda.
>>
>> can't seem to find that package but next-error allows editing not just
>> peeking.
>>
>>> This sounds like you could use more tight search criteria or custom
>>> agenda searches. An example of irrelevant vs. relevant information could
>>> help us to suggest something for you.
>>
>> appreciate the offfer but pretty ure nobody can help here.  i am also
>> limited in computer use and the back and forth is an issue.  i would
>> not be able to describe the poroblems in sufficient detail, there
>> would be further questions, i'd have to respond, etc.
>>
>> but basically i have had org for a long time and i am not able to
>> maintain my forest as well as i need to.
>>
>> but it was just one point of many.  help here would in most cases
>> likely be smething i have already thought of.  appreciates the offer.
>>
>> next-error is a sort of general tool.  it is not just for this purpose
>> and compilation errors.  imo at least.  that is why c-c / uses it.
>>
>>>
>>>> next-error would help me traverse and trim it rapidly.  i could
>>>> perhaps create a kb macro to emulate it, but i haven't tried yet.
>>>> then again, one could do so for grep mode etc. also.  :]
>>>
>>> If you decide to go with macro, it should not be too hard. Just <RET> on
>>> agenda item, do your edits, macro-beg, switch to agenda buffer,
>>> next-line, <RET>, macro-end
>>
>> yes :) [and doing soething to create canonical visibility at point so
>> that everything relevant is visible, and setting line in window].
>>
>> [and finding that kb macro to lisp package and binding the command and
>> possibly overloading the next-error bindings.]
>>
>>>
>>> Best,
>>> Ihor
>>>
>>>
>>
>> my suggestion was for org's sake and i didn't think this much detail
>> would be needed at the time.  i used my computer use time to do the
>> best i could, but it seems that more detail was needed, and that
>> detail needed discussion.  my bad.
>>
>> n.b.  i've been on the list for years, and many core features of org,
>> and parts thereof, were actually... my suggestions :).
>>
>> but sometimes i miss the mark apparently, especially lately.  as in this
>> case.
>>
>> still, not sure why multiple grep buffers or grep with occur or c-c /,
>> etc. are compatible but multiple simultaneous agenda not so.
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> On 12/19/21, Ihor Radchenko <yantar92@gmail.com> wrote:
>> multiple agenda views is not an uncommon workflow. You may have daily
>
> i think this is a strong objection.  multiple simultaneous agenda
> views seems to sink my suggestion.
>
> can one have multiple simultaneous c-c / buffers?  and multiple
> grep/occur/compilation shell minor mode?

I am not sure what you mean by multiple C-c / buffers. org-sparse-tree
does not create new buffers, just changes visibility of the current
buffer.

> or a grep buffer and an occur buffer and a compilation shell minor
> mode buffer simultaneously?  what disambiguates those?
>
> idk what is done in such cases.  perhaps there is an assumption of a
> single set of errors at a time, or some buffer local thing.

According to next-error docstring, only the last grep/occur/compilation
result is used. In theory, we can also do the same for agendas and AFAIU
it is even not that hard to implement.

If more people are interested, I do not see why next-error integration
cannot be included into Org.

>>> furthermore, the next-closest thing, follow mode, puts point in wrong
>>> window.  also, 'canonical visibility is not present so i cannot see
>>> everything [this might or might not be fixable by user].
>>
>> Can you elaborate?
>
> well it is moot because of the accessibility issue, but it is
> unsuitable for the next-error task.  point in wrong window so you have
> to switch.  some things hidden so you have to make visible is all i
> meant.  again, moot so no suggestions needed here.

FYI, there is org-fold-show-context-detail. You can customise how much
is revealed when jumping to an entry from agenda view.

>> Might be useful. Also, I personally prefer org-quickpeek in agenda.
>
> can't seem to find that package but next-error allows editing not just peeking.

I referred to http://github.com/alphapapa/org-quick-peek
It cannot help with editing though.

> but basically i have had org for a long time and i am not able to
> maintain my forest as well as i need to.

Hmm... I myself went through several refactors of my Org file
structures. Exactly because things become unmaintainable over time. It
is hard to design a good structure without enough experience with the
old one.

I usually take things slowly and keep old and new structures together.
New things are going to the new structure and old things are moved from
old to new bit by bit (there is simply a daily 5 min task for this).

Hope it helps.

> my suggestion was for org's sake and i didn't think this much detail
> would be needed at the time.  i used my computer use time to do the
> best i could, but it seems that more detail was needed, and that
> detail needed discussion.  my bad.

Now it is quite clear for me what you meant. The idea is reasonable.

> n.b.  i've been on the list for years, and many core features of org,
> and parts thereof, were actually... my suggestions :).

Now, when I looked, mailbox search revealed the truth :)
I only casually followed the list until the beginning of this year.

> but sometimes i miss the mark apparently, especially lately.  as in this case.
>
> still, not sure why multiple grep buffers or grep with occur or c-c /,
> etc. are compatible but multiple simultaneous agenda not so.

Simultaneous agendas can be compatible, as I mentioned above. Just need
to take the last generated agenda/occur/grep/etc. It will follow the
existing next-error logic.

Best,
Ihor

Re: next-error for agenda searches

[Samuel Wales]

more below.

On 12/20/21, Ihor Radchenko <yantar92@gmail.com> wrote:
> If more people are interested, I do not see why next-error integration
> cannot be included into Org.

nitpick: it already is integrated for sparse tree matches in the
outline.  i suggested that if next-error worked for more things, like
agenda text and tag matches, then it would be consistent with the
existing org next-error functionality.  user would know to try it.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Samuel Wales]

well, i implied it at least.

On 12/20/21, Samuel Wales <samologist@gmail.com> wrote:
> more below.
>
> On 12/20/21, Ihor Radchenko <yantar92@gmail.com> wrote:
>> If more people are interested, I do not see why next-error integration
>> cannot be included into Org.
>
> nitpick: it already is integrated for sparse tree matches in the
> outline.  i suggested that if next-error worked for more things, like
> agenda text and tag matches, then it would be consistent with the
> existing org next-error functionality.  user would know to try it.
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: next-error for agenda searches

[Samuel Wales]

===
Hmm... I myself went through several refactors of my Org file
structures. Exactly because things become unmaintainable over time. It
is hard to design a good structure without enough experience with the
old one.
===

[my forest structure is actually pretty good.  it is partly that i
ahve more stuff than i need from years of adding stuff.  regular tasks
to organize and delete stuff is not within my capabilities at this
time.  so i am trying to delete stuff as i go.  if i get annoyed
enough by a search that i can't find anything, then i can in principle
go through results sometimes and doneify while trying to find what i
want.]

one issue with this great thing called capture is that there is
nothing quite so convenient that does the exact opposite.

[you can regularly purge, if your life/forest is simple enough or you
have the physical ability to do things.  but you can't just
org-doneify-lower-value-stuff-i-captured-when-wasn't-sure-of-their-value-at-the-time
without adding energy, concentration, time, etc.]


On 12/20/21, Samuel Wales <samologist@gmail.com> wrote:
> well, i implied it at least.
>
> On 12/20/21, Samuel Wales <samologist@gmail.com> wrote:
>> more below.
>>
>> On 12/20/21, Ihor Radchenko <yantar92@gmail.com> wrote:
>>> If more people are interested, I do not see why next-error integration
>>> cannot be included into Org.
>>
>> nitpick: it already is integrated for sparse tree matches in the
>> outline.  i suggested that if next-error worked for more things, like
>> agenda text and tag matches, then it would be consistent with the
>> existing org next-error functionality.  user would know to try it.
>>
>> --
>> The Kafka Pandemic
>>
>> A blog about science, health, human rights, and misopathy:
>> https://thekafkapandemic.blogspot.com
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Dealing with growing backlog (was: next-error for agenda searches)

[Ihor Radchenko]

Samuel Wales <samologist@gmail.com> writes:

> one issue with this great thing called capture is that there is
> nothing quite so convenient that does the exact opposite.
>
> [you can regularly purge, if your life/forest is simple enough or you
> have the physical ability to do things.  but you can't just
> org-doneify-lower-value-stuff-i-captured-when-wasn't-sure-of-their-value-at-the-time
> without adding energy, concentration, time, etc.]

If I understand you correctly you are talking about ever-growing someday
list.

My latest solution to this problem (which I am quite happy with) is the
following:

1. Every day/week I go through recently added someday staff and look if
   it still looks useful.  For ideas, I just check if they still make
   sense and for links, I open each link and skim through the abstract
   and sometimes link text in more details.

   When I first did the above, I was surprised that 50-80% of captured
   staff is just gone because it is not as interesting as it looked
   initially.

2. The ideas/links I mark for some day in future are scheduled using
   org-learn. They will appear again in my agenda a few days later and I
   can re-assess them. If still looks interesting, but someday not now -
   reschedule using org-learn utilising spaced repetition. Otherwise -
   archive.

   With the above approach, I only see "not sure" ideas
   days->weeks->years later. Only several times a year. More useful
   ideas remind about themselves more frequently and I often end up
   actually using them.

   Credit of this idea:
   https://www.getdnote.com/blog/how-i-built-personal-knowledge-base-for-myself/

The total time needed to do the described is surprisingly small,
especially with the ability to do bulk agenda operations to postpone all
the maybe staff when you have no time/energy/mental power.

Best,
Ihor

Re: Dealing with growing backlog (was: next-error for agenda searches)

[Tim Cross]

Ihor Radchenko <yantar92@gmail.com> writes:

> Samuel Wales <samologist@gmail.com> writes:
>
>> one issue with this great thing called capture is that there is
>> nothing quite so convenient that does the exact opposite.
>>
>> [you can regularly purge, if your life/forest is simple enough or you
>> have the physical ability to do things.  but you can't just
>> org-doneify-lower-value-stuff-i-captured-when-wasn't-sure-of-their-value-at-the-time
>> without adding energy, concentration, time, etc.]
>
> If I understand you correctly you are talking about ever-growing someday
> list.
>
> My latest solution to this problem (which I am quite happy with) is the
> following:
>
> 1. Every day/week I go through recently added someday staff and look if
>    it still looks useful.  For ideas, I just check if they still make
>    sense and for links, I open each link and skim through the abstract
>    and sometimes link text in more details.
>
>    When I first did the above, I was surprised that 50-80% of captured
>    staff is just gone because it is not as interesting as it looked
>    initially.
>
> 2. The ideas/links I mark for some day in future are scheduled using
>    org-learn. They will appear again in my agenda a few days later and I
>    can re-assess them. If still looks interesting, but someday not now -
>    reschedule using org-learn utilising spaced repetition. Otherwise -
>    archive.
>
>    With the above approach, I only see "not sure" ideas
>    days->weeks->years later. Only several times a year. More useful
>    ideas remind about themselves more frequently and I often end up
>    actually using them.
>
>    Credit of this idea:
>    https://www.getdnote.com/blog/how-i-built-personal-knowledge-base-for-myself/
>
> The total time needed to do the described is surprisingly small,
> especially with the ability to do bulk agenda operations to postpone all
> the maybe staff when you have no time/energy/mental power.
>

I use a very similar technique. Provided you do this type of
'house keeping" on a regular basis, it doesn't take long and the quality
of material in your knowledge base increases.

I've also learnt to be quite ruthless in making decisions about what to
archive and what to simply delete. This is possibly the hardest
behaviour to learn. In a digital age, it is way too easy to keep
everything. However, this has a hidden cost - the quality of material
degrades and results from searching etc become less productive because
there is too much 'noise' in your data. Data, like many other things,
degrades over time. It is important to learn how to recognise when
things have passed their 'use by date' and just get rid of them.

I'm often stunned by people who boast about the fact they still have all
their emails boing back to 1990 and are somewhat proud about having an
email archive with over 50Gb of messages. Reality is, the vast majority
of those email messages will never be read again and are of little or no
actual value.

Knowing when to just delete old data is almost as important as gathering
it, but a much harder skill to master.

Re: Dealing with growing backlog (was: next-error for agenda searches)

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> I've also learnt to be quite ruthless in making decisions about what to
> archive and what to simply delete. This is possibly the hardest
> behaviour to learn. In a digital age, it is way too easy to keep
> everything. However, this has a hidden cost - the quality of material
> degrades and results from searching etc become less productive because
> there is too much 'noise' in your data. Data, like many other things,
> degrades over time. It is important to learn how to recognise when
> things have passed their 'use by date' and just get rid of them.
>
> I'm often stunned by people who boast about the fact they still have all
> their emails boing back to 1990 and are somewhat proud about having an
> email archive with over 50Gb of messages. Reality is, the vast majority
> of those email messages will never be read again and are of little or no
> actual value.
>
> Knowing when to just delete old data is almost as important as gathering
> it, but a much harder skill to master.

I disagree about this. Sometimes, you may find yourself in a situation
when you remember some link/idea because it suddenly become relevant to
what you are doing now, though it looked interesting but irrelevant in
the past. Then, you may try to find that link and there will be nothing
to find if you deleted it. So, I prefer to keep things that caught my
attention in the past saved somewhere in searchable location.

On the other hand, it is not very useful to keep every single saved link
in "active" search location. In daily workflows, the things you search
for usually belong to the currently active areas and search results
must not be polluted by links you discarded years back.

So, I maintain the main notes file with the important links I search
relatively regularly; and an archive where the notes/links are not
searchable by default, but can be searched any time I wish so (e.g. see
org-agenda-archive-mode). The archive is just like having a backup. It
is usually useless until you suddenly need it.

Best,
Ihor