planner-diary entries manipulation

Hi,

There are some entries in my ~/.diary that look like this:

&%%(let ((dayname (calendar-day-of-week date)))
     (memq dayname '(1 2 3 4 5)))  08:00 | 09:00 | Some activity
 09:00 | 12:30 | Some activity
 14:00 | 14:40 | Some activity

So that when they're included in day pages, they retain the leading space.
This ruins their translation of the section defined by
'planner-diary-string' into a table; i.e. without the leading space they
would normally be published as a table with the schedule defined by the
entries in the diary.

I've checked whether there's some planner-diary hook to remove that
leading space, but haven't found any.  Is there some convenient way to do
this, before taking a pedestrian solution?  Thanks in advance.

Muse version: 3.02.90
Planner version: 3.41
GNU Emacs 22.0.50.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2006-08-06 on nautilus, modified by Debian

Cheers,

--

-- 
Seb

Re: planner-diary entries manipulation

"Sebastian P. Luque" <spluque <at> gmail.com> writes:

> There are some entries in my ~/.diary that look like this:
>
> &%%(let ((dayname (calendar-day-of-week date)))
>      (memq dayname '(1 2 3 4 5)))  08:00 | 09:00 | Some activity
>  09:00 | 12:30 | Some activity
>  14:00 | 14:40 | Some activity
>
> So that when they're included in day pages, they retain the leading space.
> This ruins their translation of the section defined by
> 'planner-diary-string' into a table; i.e. without the leading space they
> would normally be published as a table with the schedule defined by the
> entries in the diary.

I'm not sure that the leading space is causing the problem.  Just in
case, I've committed a change to the Muse development source that
strips initial and trailing whitespace from table fields.

My best guess is that the problem is being caused by Planner's default
behavior of publishing Diary sections as if they were <verse> regions
(in order to preserve line breaks).  Since you're using table markup,
you probably don't want that to happen.  Just customize
planner-section-tagnames and remove the ("Diary" . "diary-section")
line to make Planner do nothing special for that section.

--

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG

Muse 3.02.91 (3.03 Release Candidate 1) is available

I have made the first release candidate for Muse 3.03 available.  It
should be very stable, but there remain some features to add before it
can completely replace emacs-wiki.

If you are still using emacs-wiki, this would be a good time to
test-drive Muse and see if it meets your needs.  If you notice
something missing in Muse that exists in emacs-wiki, please send email
to muse-el-discuss <at> gna.org so that it can be fixed by the time of the
release.

Revision :: mwolson <at> gnu.org--2006/muse--main--0--patch-192

Tarball  :: http://download.gna.org/muse-el/muse-3.02.91.tar.gz

Zip file :: http://download.gna.org/muse-el/muse-3.02.91.zip

The NEWS items for this release candidate are attached.

Emacs Muse NEWS --- History of user-visible changes    -*- outline -*-

* Changes in Muse 3.03 (not yet released)

** Blosxom publishing (lisp/muse-blosxom.el)

*** New option: muse-blosxom-use-tags.
This specifies whether or not we are using tags.  Tags allow a page to
belong to multiple categories, but they do not rely on the directory
structure for categorization.

Muse 3.02.92 (3.03 Release Candidate 2) is available

The first release candidate had a bug with publishing bare URLs, so I
have made a second release candidate available -- Muse 3.02.92.

In addition, I have updated the Debian package for muse-el in my
private repository, so if you use Debian or Ubuntu, the release
candidate is available using that method.

Revision :: mwolson <at> gnu.org--2006/muse--main--0--patch-193

Tarball  :: http://download.gna.org/muse-el/muse-3.02.92.tar.gz

Zip file :: http://download.gna.org/muse-el/muse-3.02.92.zip

The NEWS items are unchanged from the first release candidate.

--

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG
 |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC

_______________________________________________
emacs-wiki-discuss mailing list
emacs-wiki-discuss <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/emacs-wiki-discuss

planner-timeclock-summary-proj bug & fix

Dear All,

I noticed a tiny bug in planner-timeclock-summary-proj.el where
a string-match failed if timeclock entries had no 'ProjectName:'.

I suggest the following fix:

*** /usr/pkg/share/emacs/site-lisp/planner/planner-timeclock-summary-proj.el    Thu Apr 27
17:28:24 2006
--- /home/marko/tmp/planner-timeclock-summary-proj.el   Thu Aug 17 11:53:10 2006
***************
*** 192,198 ****
        (while entry-list
          (let* ((proj (car entry-list))
                 (proj-entry-name (car proj)))
!           (if (and proj-name
                     (string-match (concat "^\\[\\[" proj-name "\\]\\]")
                                   proj-entry-name))
                (if projects
--- 192,198 ----
        (while entry-list
          (let* ((proj (car entry-list))
                 (proj-entry-name (car proj)))
!           (if (and proj-name proj-entry-name
                     (string-match (concat "^\\[\\[" proj-name "\\]\\]")
                                   proj-entry-name))
                (if projects

Best regards,

Re: planner-timeclock-summary-proj bug & fix

Marko Schütz <schutz_m <at> usp.ac.fj> writes:

> I noticed a tiny bug in planner-timeclock-summary-proj.el where
> a string-match failed if timeclock entries had no 'ProjectName:'.

Thanks!  I've installed the patch.

--

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG
 |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC

_______________________________________________
emacs-wiki-discuss mailing list
emacs-wiki-discuss <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/emacs-wiki-discuss

Re: Apologies and questions

Arnaud Bailly <abailly <at> achilleus.net> writes:

> Hi,
> First the apologies: I have at some time in the past comitted myself
> to provide documentation for planner-zoom feature and it seems that
> I have waited too long and someone did it.  My most sincere apologies
> for the delay.
>
> Next the question: I am trying to create a muse plugin for the maven
> build tool (kind of evolved mokefile in java, integrates documentation
> and project site generation). The maven API for site generation uses
> stream oriented parsing which is not AFAICT the strategy used in
> maven. I have deduced from the lisp code that each regex is analyzed
> in turn on the whole document and generates output. So what I wousd
> like to do is writing a grammar using antlr or cup and use this
> grammar to parse the file.

Not really sure if this is what you are asking for, but some time ago
I wrote a muse->xml converter using Chaperon, which is used as a
component of Cocoon. I use it to generate http://www.verona.se/joakim

> As I am not really sure that this would be a simple task (not sure the
> grammar is really context free), I would like to know before
> undertaking this task whether or not someone as already worked on
> it. Alternatively, I could use an XML format if muse files were stored
> in XML. Y.Hodique told me about this feature some times ago, not sure
> there is something implemented yet.
>
> Regards,
>

Re: Re: Apologies and questions

joakim <at> verona.se writes:

> Not really sure if this is what you are asking for, but some time ago
> I wrote a muse->xml converter using Chaperon, which is used as a
> component of Cocoon. I use it to generate
> http://www.verona.se/joakim

The mail was a bit old and actually I have implemented this
parser. Thanks anyway for the answer.

--

-- 
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com

Re: Apologies and questions

joakim <at> verona.se writes:

> Arnaud Bailly <abailly <at> achilleus.net> writes:
>
>> Hi,
>> First the apologies: I have at some time in the past comitted myself
>> to provide documentation for planner-zoom feature and it seems that
>> I have waited too long and someone did it.  My most sincere apologies
>> for the delay.
>>
>> Next the question: I am trying to create a muse plugin for the maven
>> build tool (kind of evolved mokefile in java, integrates documentation
>> and project site generation). The maven API for site generation uses
>> stream oriented parsing which is not AFAICT the strategy used in
>> maven. I have deduced from the lisp code that each regex is analyzed
>> in turn on the whole document and generates output. So what I wousd
>> like to do is writing a grammar using antlr or cup and use this
>> grammar to parse the file.
>
> Not really sure if this is what you are asking for, but some time ago
> I wrote a muse->xml converter using Chaperon, which is used as a
> component of Cocoon. I use it to generate http://www.verona.se/joakim

Neat!  If either of you are willing to write some documentation for
these plugins (and assign the copyright for the documentation changes
to the FSF), I'd be happy to mention them in the Muse manual.

Or just let me know the web location of the code, and I'll put a link
to it on http://www.mwolson.org/projects/EmacsMuse.html.