Weeks in diary

[GoogleCodeExporter]

It would be great if there was a way to see weeks in the diary. I suggest 
putting empty lines between the weeks and adding (localized) week days:

== 2012 ==

=== January ===
        * Sun, 2012-01-01: New Year

        * Mon, 2012-01-02: Another title
        * Tue, 2012-01-03: Going out
        * Wed, 2012-01-04 
        * Thu, 2012-01-05 
        * Fri, 2012-01-06 
        * Sat, 2012-01-07 
        * Sun, 2012-01-08 

        * Mon, 2012-01-09: New line before new week
        * Tue, 2012-01-10 
        [...]

For German it could be:

        * Mo, 2012-01-02: Another title
        * Di, 2012-01-03: Going out
        [...]

Original issue reported on code.google.com by dominik.mayer on 1 Jan 2012 at 6:44

[GoogleCodeExporter]

What about diaries that get filled only occasionally, once or twice a week? It 
would look fairly poor to see all those empty lines in a file of that sort.

I think that this sort of formatting issue is really a personal preference, and 
each person is responsible for making it look the way he or she likes. Besides, 
different regions or people have weeks "starting" on different days: this would 
be a configuration nightmare.

Adding weekdays is useful. But again, automatic localization would add too much 
burden to a small program like vimwiki. Another user option, this time an array 
of seven strings? I think the calendar plugin that some people use in 
conjunction with vimwiki is a better choice.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 3:17

[GoogleCodeExporter]

I agree that there should be settings (on/off, startday, day names) but I 
disagree that the calendar is a solution. It doesn't show the titles so it's 
impossible to see what happened over the course of one week.

I would add the empty lines myself but that's impossible because the file would 
be overwritten by vimwiki.

Original comment by dominik.mayer on 13 Jan 2012 at 3:21

[GoogleCodeExporter]

I see. That is really the problem then, if the file is automatically generated 
all the time, the possibilities for customization are very limited.

The generation of the whole file from scratch all the time is not elegant (and 
must be getting really slow for large diaries), perhaps this should be improved 
instead... 

To "see what happened over the course of one week": why should this be written 
in a file? Should not it just be displayed on demand?

If it was a mostly static information, it would make sense to write it in the 
file (and keep it there).

But if it is dynamic, and I can change now what happened on 1955-03-18, as well 
as any other days, why to have a file that attempts to keep all the file all 
the time in sync with all the hundreds of day-headers?

I would suggest: have a function that creates/displays a 
yearly/monthly/whatever list on demand (similar to "agenda" kinds of requests). 
If the user wants (for instance, considers that list complete/static/worth 
saving), just save the generated list as you please, under any name you like, 
with any modifications/niceties you like. Why should vimwiki try to do all of 
this automatically all the time?

Vimwiki works with no database, and actually no saved configuration at all 
aside from the one in vim rc files (which is completely under the control of 
the user, not vimwiki). This has to be taken into account. No common/automatic 
operations should require opening/scanning/processing a large number of files. 
Where large number is more than two, give or take.

But getting back to the days of week: yes, this is useful. There is also the 
possibility of putting the day-of-week name as the first word of the title 
(inside the newly clreated YYYY-MM-DD wiki file; localization problem might be 
perhaps outsourced to the OS, and there may be no need to deal with on/off). 
This has to be done just once when the file is created, after that it is up to 
the user whether to keep it there or not or put is upside down or whatever. And 
it is going to be visible in the summary just as well for those who decide to 
keep it. Much more efficient and flexible, if you asked me.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 5:30

[GoogleCodeExporter]

What happened over the course of one week: This could of course be manually 
written in a file. But this file would not be part of the diary. I was thinking 
about something like this (naive example):

        * Mon, 2012-01-02: Got fired :-(
        * Tue, 2012-01-03: I hate looking for jobs!
        * Wed, 2012-01-04: Two applications done
        * Thu, 2012-01-05: Waiting and two more applications
        * Fri, 2012-01-06: First Interview
        * Sat, 2012-01-07: Buying presents for tomorrow
        * Sun, 2012-01-08: Peter's party

The titles -- which are automatically extracted from the files -- tell you 
what's going on.

Regeneration: My file is already over 900 lines. I filed issues asking for a 
greater index depth (http://code.google.com/p/vimwiki/issues/detail?id=270) and 
a way to manually regenerate 
(http://code.google.com/p/vimwiki/issues/detail?id=269).

Putting the day in the file: I do this manually right now. My files look like 
this (German formatting):

        Do, 12. Januar 2012.

        = Title =

        Text.....

What I actually want to achieve:

        = Do, 12. Januar 2012. Title =

        Text.....

But this would look bad in the index:

        * 2012-01-12: Do, 12. Januar 2012. Title

Hence this issue :-).

Original comment by dominik.mayer on 13 Jan 2012 at 5:46

[GoogleCodeExporter]

OK, I have read the issue 270 now. You have 900 diary days already ... nice, 
then you are really motivated to get same improvements in.

My suggestion (disclaimer: I do not really know how things work now, I am just 
guessing from the comments you provided):

* diary.wiki (the staging area): the only auto/dynamic part that Vimwiki 
updates automatically (on opening?). But _only_ by appending (the dates/headers 
of YYYY-MM-DD.wiki files whose timestamps are newer than the timestamp of 
diary.wiki), never overwriting anything, no attempt to sort those 
[[1955-03-18]] you just modified into "proper" place: it is the user's job to 
decide what to keep in diary.wiki and in which order and what form.
* functions to create yearly/monthly/weekly overview, as suggested above. You 
modify and save it where you like it, vimwiki could not care less (no 
auto-updates whatsoever, you should see from your "staging" file whether 
[[1955]] needs a refresh or a just a quick modification). Suggested usage: when 
February comes, generate the January file, save it where you want, and clean up 
you staging file (by removing all the 2011-01-DD) to keep it smaller if you 
like, and put in the link to [[2011-01]] if you like. But it is all up to you, 
vimwiki does not track/care what you keep there.
* days in a week are handled as described at the end of Comment 3: the only 
automatic operation happens at the time of creation of the new diary entry, but 
vimwiki does not track/care what you keep there.

Obviously, you may want to write some scripts to adjust your huge diary en 
masse (to add the days of week to the title, for instance), but for anyone who 
will just start creating diary files now, this is a very flexible and 
practical/fast system, that can be implemented without too much work, and 
little/no chance of destroying someones files.

Any problem this does not solve? 270, 269, 267: check, 268: perhaps?, 253: not 
too far off.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 6:35

[GoogleCodeExporter]

I think vimwiki should be able to manage files for months and years (issue 270) 
because only then it can provide a way to navigate the diary (<C-Up>/<C-Down> 
for last/next month, year).

In the case of index depth 3/2/1 vimwiki would automatically regenerate the 
file for the current month/year or everything. If the user changes the index 
depth or some older headings he would have to run :VimwikiRecreateDiaryIndex.

There should be a toggle for the date in the index. Maybe someone doesn't want 
a hard coded formatting in every file and prefers the current implementation:

        * 2012-01-02: Got fired :-(
        * 2012-01-03: I hate looking for jobs!
        * 2012-01-04: Two applications done

Whereas the default would be (using German formatting):

        * Mo, 02. Januar 2012: Got fired :-(
        * Di, 03. Januar 2012: I hate looking for jobs!
        * Mi, 04. Januar 2012: Two applications done

Where the whole string ("Mo, 02. Januar 2012: Got fired :-(") is the first 
title inside 2012-01-02.wiki. On creating a new file, vimwiki adds (according 
to my predefined formatting): "= Fr, 13. Januar 2012. =")

Original comment by dominik.mayer on 13 Jan 2012 at 6:50

[GoogleCodeExporter]

Navigation has to be sensibly defined for vimwiki in general, this is not an 
issue specific to the diary. But it will certainly require user creating a file 
that specifies the desired sequence/hierarchy, it would be crazy to try to do 
that somehow "automatically".

What does it mean to "manage files for months and years"? To overwrite any 
changes user might have made? This should be avoided at all cost!

Actually, the cost is just a handful of keystrokes per month in my proposed 
solution... with the benefit of vastly larger flexibility. Want to organize you 
diary-summaries by seasons? Go ahead. Use the provided summary-functions to get 
yearly or monthly summary, and save whichever part you want. Do you "weeks" 
have 5 days, and "start" on Yousday, and you want them separated by three empty 
lines? No problem, do as you please with a few keystrokes per week (whatever 
that is), vimwiki won't care, and nobody will be spending hours studying 
configuration options just for the diary. It is a wiki, you create the content, 
and not leave it to a fairly simplistic program that is only slightly less 
primitive if you add dozens of configuration options.

Yes, the initial "title" ought to be configurable.

Regarding your preference to see the date explicitly in the day file: you could 
use

%title Mo, 02. Januar 2012
= Mo: Got fired :-( =

but I do not think that it is needed to support exactly this by vimwiki, you 
can write your own function to do that... vimwiki could be configured to 
provide you with
= Mo, 02. Januar 2012 =
upon opening the new file (provided the OS will do the localization), and you 
would write your own mapping to transform it the way you prefer.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 7:35

[GoogleCodeExporter]

"manage files for months and years": Vimwiki automatically creates diary.vim. I 
want it to create 2012.vim and 2012-01.vim (depending on the index depth) as 
well. There is no overwriting of user changes because user generated diary 
files have the format 2011-01-01.vim.

Date in the file: Yeah, I can write that myself. The only thing I need is a way 
to disable the "2011-01-01: " in front of the title in the index.

Original comment by dominik.mayer on 13 Jan 2012 at 3:38

[GoogleCodeExporter]

What is the point of having automatically generated .wiki files, if you cannot 
modify them (I mean: modify without having all your changes and formatting 
wiped out at anytime later)?

No point whatsoever, exactly.

I have a feeling that I somewhat understand your concerns, but it seems you 
either did not read or understood what I wrote, because I have already repeated 
everything two times.

Basic Principle:
All .wiki files are created/modified by the user. Vimwiki may have some 
functions to help you to put some data in a buffer, but it is all up to the 
user how such data is used and saved and whether the user want to overwrite 
some of the other files.

In particular: No automatic writing (= overwriting = potentially deleting 
someone's work) of .wiki files.

Any exceptions to this principle have to be carefully justified and implemented 
to reduce the risk of damaging/destroying someone's work (read how I proposed 
an exception concerning the diary.wiki file (and nothing else!)).

Your "2012.vim and 2012-01.vim" (I assume you mean .wiki?): when does it get 
created? How often it updates? What specific format does it contain?

Take twenty people like you (that is, those who want a yearly and a monthly 
summary, unlikely a random sample of diary-using people), and there will be 18 
different incompatible answers to the questions above. Even disregarding the 
lurking issues of huge inefficiency, what you seem to want is inherently 
inflexible, and will give two people out of twenty what they want (or 6, if you 
add five configuration options for formatting). And we are talking only "people 
like you" here, not those week/season/decade preferring once etc.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 4:33

[GoogleCodeExporter]

I do understand what you wrote, I just don't agree. And I don't know if you 
understand what I want.

> Basic Principle:
> All .wiki files are created/modified by the user. Vimwiki may have some 
functions to help you to put some data in a buffer, but it is all up to the 
user how such data is used and saved and whether the user want to overwrite 
some of the other files.

This is not how it's working right now and this is not how I want it. All the 
index files are generated (and saved!) based on the diary files. So vimwiki 
extracts the information from the files and saves them in diary.wiki. Why would 
I want to create diary.wiki myself if the software can do it for me?

2012.wiki, 2012-01.wiki: Those two files have nothing to do with this issue, 
they're part of issue 270, so we should discuss them over there. I want them to 
be generated the same way as diary.wiki is generated. So they replace the 
900-line-long file. I don't understand why there would be incompatible answers. 
I posted a clarification in issue 270.

Original comment by dominik.mayer on 13 Jan 2012 at 5:00

[GoogleCodeExporter]

My fairly incomplete understanding of what you want:
0. (configure tons of vimwiki options)
1. ??? ->  :w! diary.wiki index.wiki 2012.wiki ...

This is an example/elaboration of the second item of my Comment 5:
1.  :VWDiarySummary 2012    -> splits window with a new buffer, containing 
summaries of all day-diary pages from 2012
2. format to your liking (e.g. adding empty lines, or changing the title, 
etc.), :w 2012.wiki (or any name you want)
OR
2'  :diffsplit 2012.wiki   :diffput ...   :w ...  (if I already have a nicely 
formatted 2012.wiki)

OR
1'. :VWDiarySummary 2012-01  -> splits window with a new buffer, containing 
summaries of all day-diary pages from 2012-01
2.  cut away what you need, save as 2012w11.wiki

etc. etc. (this is an elaboration of the second item of Comment 5).

Yes, I know this is very unlikely the way it works now, but I assume you are 
filing issues regarding diary because not everything that is done now is 
perfect already.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 5:50

[GoogleCodeExporter]

Quick Question: Have you tried the current implementation? Because if not it 
doesn't make sense to discuss because I think we're talking different things 
here. And we're especially talking about things completely unrelated to this 
issue which is called "Weeks in diary".

All I want are a few extra options and a slightly improved index generation 
function. I do not want to have a manually generated index at all.

Original comment by dominik.mayer on 13 Jan 2012 at 5:56

[GoogleCodeExporter]

Oh, OK, maybe you like the way the present diary.wiki file works, and I made it 
a bit confused by suggesting to use it slightly differently to avoid the 
regeneration problems (there have been some Issues about that too, I seem to 
remember). But that was not the core of my suggestion. But you should really 
think of whether it is worth giving up any ability to modify your higher-level 
diary files just so that you can save a few keystrokes per month.

And I would really like to keep .wiki files as input/modifiable files. If some 
advanced functionality requires wiki to cache some files, they should not be 
.wiki files.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 6:20

[GoogleCodeExporter]

Sorry, I do not have the current implementation, I am still on 1.1.1, and do 
not know what are the differences in diary to the version you are using.

But I am still a little puzzled why someone with nearly a thousand entries (or 
is it 4 times 900?) in diary.wiki does not seem to appreciate the prospect of 
being able to  change it (with about a minute of work) into something like

= Diary =
[[2008]]
[[2009]]
[[2010]]
[[2011]]

== January 2012 ==
[[2011-01-09]]
[[2011-01-10]]
[[2011-01-11]]

(I am not putting the headlines there as I am not sure which place you really 
want them) 
and sleep easy knowing that vimwiki is not going to mess anything up, only 
adding things at the bottom.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 6:43

[GoogleCodeExporter]

I created issue 273 for a distinction between automatically generated and other 
files.

I don't appreciate being able to change it because I don't want to *have to* 
manually change everything. I want to have all the data in the files for each 
day. The software should then extract this data and present it in an 
appropriate way without me having to make sure that everything is in sync.

Original comment by dominik.mayer on 13 Jan 2012 at 6:49

[GoogleCodeExporter]

I forgot to put the list markers there, but I am sure you get my intention.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 6:52

[GoogleCodeExporter]

My 2 cents:

- Dominik has a vision of how to create a stylized and multilevel 
date-structured diary.  It sounds like it would be incredibly useful for people 
who are comfortable structuring their wiki notes accordingly.

- Tpospich is concerned about wiki content that automatically overwritten, 
complexity issues dealing with individual preferences for date localization, 
ordering, and nesting, and efficiency.

I tend to agree with Tpospich.  I think vimwiki would be best served by 
focussing on its core functionality of editing and converting lightweight 
markup, leaving external programs responsible for further summarizations or 
transformations of the content.  I have written some simple tools for my own 
workflow, and there are already examples of such external programs integrating 
with vimwiki listed on the wiki.

The diary is a great feature, but improving it by spacing weeks or supporting 
multiple levels would probably involve a lot of assumptions about how 
individuals use their wikis or risk expanding the list of configurable options 
and complicating the code.  

On the other hand, if someone has time and can implement a clean solution, then 
it would likely become part of vimwiki.  I liked Tpospich's idea of functions 
that create yearly/monthly/weekly overviews writing the results to temporary 
buffers.  Using such functions, it would be trivial to generate a flat diary, 
or a multi-level diary, if those are your use-cases, but otherwise leaves a lot 
of flexibility including the option to discard the results once read.

Original comment by stu.andrews on 13 Jan 2012 at 8:05

[GoogleCodeExporter]

Isn't there a simple way to let the function that's creating diary.wiki also 
create 2010.wiki 2010-01.wiki (or maybe 2010.anotherextension, ...)? I'm not 
familiar with vim programming but shouldn't it be a mere construction of a few 
if-statements and loops?

Original comment by dominik.mayer on 13 Jan 2012 at 8:09

[GoogleCodeExporter]

And if the depth is set to one, the implementation would be the same as it is 
now. This could be the default an no one would even notice that there is a more 
powerful version?

Original comment by dominik.mayer on 13 Jan 2012 at 8:10

[GoogleCodeExporter]

You still make no mention of "little" things such as updating and 
synchronization, the `???` part in my Comment 11 (aside the fact you would not 
want to do that "manually"), which makes is very hard to guess what "manually" 
and "change" (the words you use very often) mean.

Just to use your terminology from 
http://code.google.com/p/vimwiki/issues/detail?id=270#c1, the example in 
Comment 14 above is precisely your "DEPTH 2" or "DEPTH 3" diary.wiki, where 
Comment 11 1.&2. describes how you make "DEPTH 2" 2008.wiki, and 2009.wiki, etc.

As to you wanting "to have all the data in the files for each day", I have no 
idea who you are arguing with here, I have not noticed anyone suggesting 
something else in the entire discussion. You seem to be so preoccupied with the 
idea someone will write a program that will reorganize your impressive diary 
with no "manual" work by you (yet satisfying all your peculiar formatting 
demands), that you cannot see it is just a one-time job, and jobs like that are 
very poor candidates for a "full" automation. Try to keep in mind that this 
should be designed for people who use diary continually, and who will be once 
in a while reorganizing how many levels or what time periods they use as their 
collection grows. Changing a number in vimwiki options is not going to do that 
"automatically" to their full satisfaction.

This is likely my last comment here, so I should mention one last thing: this 
useful function skimming the top headers that I called `VWDiarySummary` has 
nothing specific in it regarding the diary, it would be useful in other 
situations, for instance improving and generalizing `:VimwikiGenerateLinks`. 
The way I wrote it, it just used a simplified diary-specific argument like 
`2011` instead of what would be a general regular expression like `2011-??-??` 
(just as an example, to get "DEPTH 3" 2011.wiki, you would run `:VWDiarySummary 
2011-??` and `:w 2011.wiki`, which would skim the headers of of month-level 
summaries into 2011.wiki; you'd have to get those monthly-summaries first, of 
course, but that is what regular frequent users would do naturally just about 
once a month, I suspect). If you were happy with the default headers, someone 
could even write a two-line function doing an "automatic" two-level split for a 
year, of course (but in that case, forget your demands on precise localization 
and linebreaks etc.) I am not going to make this longer by mentioning (again) 
that people are basically asking for similar (slightly more general) skimming 
function for agenda-generating purposes.

It is more or less clear that you should perhaps take a day off and think about 
it,  If you have done your homework, you will see how much more powerful and 
reusable is the slightly-less-automatic system I am suggesting here.

Original comment by tpospi...@gmail.com on 13 Jan 2012 at 9:18

[GoogleCodeExporter]

Please don't attack me. I prefer a rational discussion. I transfered about 900 
entries manually into vimwiki so I don't think I refuse to do manual work.

Your suggestion in comment 11 leads to the odd situation that one would have to 
do all the work (:VWDiarySummary 2012, entering lines ...) again and again 
whenever a title is canged. So all the work would have been in vain.

About :VWDiarySummary 2012-01. I have no idea what you mean with "summaries of 
all day-diary pages". All my day diary-pages of one month are combined about 
400 Kilobyte... And the "function skimming the top headers" is already part of 
revision 323 and used to generate the index of the diary.

Are you sure you don't want to try the current implementation?

Original comment by dominik.mayer on 13 Jan 2012 at 9:35

[GoogleCodeExporter]

@dominik,

I encourage you to learn some vimscript and give it a try.  There's plenty of 
example code within vimwiki's files, the language and its stdlib functions are 
accessible from the help, and there's plenty of resources and discussion groups 
on the web.  I recommend you clone the repository and then create a separate 
branch for your work.

http://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/VimL_Script_language

@tpospich

A general-purpose skimming tool ... that sounds cool!   Something like that is 
accomplished with the VikiTasks plugin 
http://www.vim.org/scripts/script.php?script_id=2894.  

Original comment by stu.andrews on 14 Jan 2012 at 4:39

[GoogleCodeExporter]

Is there a way to test without messing with my files? Or do I have to uninstall 
vimwiki and change the location of my wiki in .vimrc?

Original comment by dominik.mayer on 14 Jan 2012 at 11:08

[GoogleCodeExporter]

I use this script to install my development versions 
https://gist.github.com/580276.  There are other similar tools (for example 
gmarik's vundle).  Also, check out the sandbox directory under vimwiki 
including the grun command.

In my workflow, I maintain separate directories for my development, and the 
main vimwiki repo, which I'll call vimwiki-custom and vimwiki-master.  That 
way, I can install either version into VIMRUNTIME (~/.vim/).

I keep my experimental work in vimwiki-custom.  When I have a feature that I 
want to share with vimwiki-master, I implement it as a branch in the main 
vimwiki repo, and commit the branch to the site.  This allows other developers 
flexibility in testing the feature; importantly, it avoids accidentally 
breaking of the trunk.

HTH, 
-S.

Original comment by stu.andrews on 14 Jan 2012 at 7:36

[GoogleCodeExporter]

Thanks for the detailed instruction. I'll give it a try.

Original comment by dominik.mayer on 14 Jan 2012 at 8:02