headers
Emmanuel Blot | 1 Aug 02:01
Picon
Gravatar

Re: Re: [Trac] InterTrac and RST links

> Sorry, I didn't add InterTrac support to our reStructuredText renderer.
[moved from trac <at> lists.edgewall.com]

> Patches are welcomed ;)

I'm looking at it, but I'm wondering whether the 'InterTrac' syntax
should be kept for rST:

InterTrac syntax would be `project:wiki:WikiPage`:trac:
Alternative syntax could be `WikiPage`:trac:project:
I don't know whether the rST engine support ':', but you get the idea,
something easier to type and read.

What's your feedback ?

Anyway, I guess I should submit a new ticket to track this enhancement.

Cheers,
Manu
Permalink | Reply | 0 comments |
headers
Jeroen Ruigrok/asmodai | 1 Aug 07:17
Gravatar

Re: Re: Hook scripts and plugins

-On [20060801 00:33], Emmanuel Blot (manu.blot <at> gmail.com) wrote:
>>Yes, I suppose that could happen.  But PYTHON_EGG_CACHE is just an
>>environment variable.  It can easily be set in the hook script.
>
>That's what I did, but I would have hope to define the settings only
>once to avoid duplication and out of sync if the installation is
>changed. It does not seem possible.

Not sure if Linux supports login.conf, but then you could assign with setenv
PYTHON_EGG_CACHE to what you want by default.

--

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
O, what a tangle web we weave, when first we practice to deceive...
Permalink | Reply | 0 comments |
headers
Christopher Taylor | 1 Aug 15:49
Picon

Re: Revision between 2 non-consecutive changesets

>The diff between A and B would necessarily include all changes in between.

Not necessarily: Suppose you had made some changes to something then
refacotred it to generalize.  You might want to take a look at that
whoel change sequence.

>Unless you are concerned about needing to read each
> changeset incrementally to build the final diff, which is not necessary.

Yes, that was what I was refering to.   I could think about times when
such a feature would be useful, unfortunately, it would be very
cluttered to read.  Impossible in plain text I would think.  The only
way I could think to do that is to compare A to A+1; A+1 to A+2; ...
B-2 to B-1; B-1 to B and then put each incremental diff in a
collapsable column.  You could then expand or collapse each column as
you see fit.  The hard part would be to determine how many lines you
need to add in for 'spacers'.  Figuring that out might be an
interestiung challenge.

Respectfully,
Christopher
Permalink | Reply | 0 comments |
headers
Christopher Lenz | 2 Aug 15:08
Picon
Picon
Gravatar

Re: Sandbox proposal: Markup for templating

Am 18.07.2006 um 20:58 schrieb Christopher Lenz:
> Am 17.07.2006 um 12:56 schrieb Christopher Lenz:
>> I'd like to start a new branch in the sandbox for playing the use  
>> of Markup templates in Trac.
>
> One thing I forgot: since the package of the Markup project is  
> "markup", and we use the module name "trac.util.markup" for stuff  
> like the Markup and Element/Fragment classes, this makes it  
> impossible or at least hard to provide good backwards compatibility.
>
> Ideally, on the Trac-on-Markup branch, we'd replace most of the  
> contents of the "trac.util.markup" module with imports from the  
> Markup packages. This doesn't work because Python by default  
> attempts a relative import, thus ending up with "trac.util.markup"  
> when importing "markup".
>
> I guess the only way to deal with that would be to rename  
> "trac.util.markup" before it is in an official release.
>
> I'd suggest renaming trac.util.markup to trac.util.html, and  
> replace the "html" element factory function with "tag".

Actually, I'd just rename the "trac.util.markup" module to  
"trac.util.html", and then make a couple of minor adjustments to  
avoid breaking extensions when we eventually switch over to Markup  
(such as moving the "Markup.plaintext" method out of the "Markup"  
class, etc).

So, does anyone have any objections about this plan?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Emmanuel Blot | 2 Aug 16:24
Picon
Gravatar

Re: Sandbox proposal: Markup for templating

> So, does anyone have any objections about this plan?

Nope.
I have a couple of questions though:

 1. Do you have any idea/estimation about when the trunk will switch
from Clearsilver to Markup (it takes quite a time to update the french
translation, so if I can avoid updating it and restart from scratch
after the switch ... ;-))

 2. I did not try Markup yet, but I read the documentation, and I
found one point that sounded weird at first:
http://markup.edgewall.org/wiki/MarkupTemplates#py:strip

"As a shorthand, if the value of the py:strip attribute is empty, that
has the same effect as using a truth value (i.e. the element is
stripped)."

As an empty string in Python means a False value, I found this
shorthand a bit confusing and error-prone. I guess this choice is on
purpose, so I think it would be helpful if you could give some details
about this specific point.

Additional note: I just went to see whether a markup ML already exists
(before posting an off-topic email), and it appears that there are two
similar wiki pages on Markup site: "MailingList" and "MailingLists".

Cheers,
Manu
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthew Good | 2 Aug 18:17

Re: Sandbox proposal: Markup for templating

On Wed, 2006-08-02 at 16:24 +0200, Emmanuel Blot wrote:
> > So, does anyone have any objections about this plan?
> 
> Nope.
> I have a couple of questions though:
> 
>  1. Do you have any idea/estimation about when the trunk will switch
> from Clearsilver to Markup (it takes quite a time to update the french
> translation, so if I can avoid updating it and restart from scratch
> after the switch ... ;-))
> 
>  2. I did not try Markup yet, but I read the documentation, and I
> found one point that sounded weird at first:
> http://markup.edgewall.org/wiki/MarkupTemplates#py:strip
> 
> "As a shorthand, if the value of the py:strip attribute is empty, that
> has the same effect as using a truth value (i.e. the element is
> stripped)."
> 
> As an empty string in Python means a False value, I found this
> shorthand a bit confusing and error-prone. I guess this choice is on
> purpose, so I think it would be helpful if you could give some details
> about this specific point.

This is a carry-over from Kid which has worked well.  It doesn't mean
that the attribute contains an empty string, but that it actually
contains no expression.  So, py:strip="''" is actually an "empty
string", which is False so the tag would not be stripped.  However
py:strip="" contains no expression, so it's a special case where it is
stripped since there is no expression to check.  Of course there's not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher Lenz | 2 Aug 18:31
Picon
Picon
Gravatar

Re: Sandbox proposal: Markup for templating

Am 02.08.2006 um 16:24 schrieb Emmanuel Blot:
>> So, does anyone have any objections about this plan?
>
> Nope.
> I have a couple of questions though:
>
> 1. Do you have any idea/estimation about when the trunk will switch
>> from Clearsilver to Markup (it takes quite a time to update the  
>> french
> translation, so if I can avoid updating it and restart from scratch
> after the switch ... ;-))

I can't really say... so far the migration has been going rather  
nicely on the sandbox branch, but there's still a lot left to do, and  
it's a lot of work. And then there's the question of what order the  
various 0.11-scheduled branches get merged in, which we haven't  
really discussed yet. Personally, I'd like to see refactoring  
branches such markup, datetime, and possibly controller/setuptools to  
be merged before the feature branches (such as workflow), because  
e.g. markup will have more of an effect on workflow than the other  
way around. But either order requires work for those branches that  
get merged later.

About i18n, I'm still hoping we can get a proper gettext-based  
solution integrated in 0.11, making separate sets of templates for  
different languages shouldn't unnecessary. My current thinking is to  
simply use the _() gettext function inside templates to externalize  
strings, e.g.:

   <title>${_('Timeline')}</title>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emmanuel Blot | 2 Aug 21:00
Picon
Gravatar

Re: Sandbox proposal: Markup for templating

Ok Matt,
thanks for your detailled answer.

Cheers,
Manu

On 8/2/06, Matthew Good <trac <at> matt-good.net> wrote:
> On Wed, 2006-08-02 at 16:24 +0200, Emmanuel Blot wrote:
> > > So, does anyone have any objections about this plan?
> >
> > Nope.
> > I have a couple of questions though:
> >
> >  1. Do you have any idea/estimation about when the trunk will switch
> > from Clearsilver to Markup (it takes quite a time to update the french
> > translation, so if I can avoid updating it and restart from scratch
> > after the switch ... ;-))
> >
> >  2. I did not try Markup yet, but I read the documentation, and I
> > found one point that sounded weird at first:
> > http://markup.edgewall.org/wiki/MarkupTemplates#py:strip
> >
> > "As a shorthand, if the value of the py:strip attribute is empty, that
> > has the same effect as using a truth value (i.e. the element is
> > stripped)."
> >
> > As an empty string in Python means a False value, I found this
> > shorthand a bit confusing and error-prone. I guess this choice is on
> > purpose, so I think it would be helpful if you could give some details
> > about this specific point.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emmanuel Blot | 7 Aug 15:42
Picon
Gravatar

About 0.10 ETA

Hi,

I was wondering whether 0.10 should be declared as "feature freeze".
There are several enhancements /  bug fixing that have recently been
(re)targeted for 0.10. The consequence is that the list of bug-to-fix
has been increased.

I think that a lof of Trac users are waiting for 0.10, so I would
propose to create a 0.10.1 milestone and stop adding new tickets for
0.10, or we'd keep postponing the release of this major Trac delivery.
0.9 is already 9 months old...

I think that some tickets such as:
 * #3506 (tracd / projects from root)
 * #3486 (localhost for notifications)
 * #3526 (ReStructuredText / InterTrac)
are not blocking issues and could potentially be postponed to 0.10.1

My 2cts opinion ;-)

Cheers,
Manu
Permalink | Reply | 5 comments |
headers
Christopher Lenz | 7 Aug 15:58
Picon
Picon
Gravatar

Re: About 0.10 ETA

Am 07.08.2006 um 15:42 schrieb Emmanuel Blot:
> I was wondering whether 0.10 should be declared as "feature freeze".
> There are several enhancements /  bug fixing that have recently been
> (re)targeted for 0.10. The consequence is that the list of bug-to-fix
> has been increased.
>
> I think that a lof of Trac users are waiting for 0.10, so I would
> propose to create a 0.10.1 milestone and stop adding new tickets for
> 0.10, or we'd keep postponing the release of this major Trac delivery.
> 0.9 is already 9 months old...
>
> I think that some tickets such as:
> * #3506 (tracd / projects from root)
> * #3486 (localhost for notifications)
> * #3526 (ReStructuredText / InterTrac)
> are not blocking issues and could potentially be postponed to 0.10.1

Agreed. There are a couple others on the list that could be postponed.

Also, I think we should push out a beta release before the final,  
meaning there'd still be approx. two weeks (between beta and final)  
for more bug fixes.

 From my POV, there are three things that hold up the release:
  * The ContentConverter refactoring: I would say postpone the  
refactoring and keep the current API as is. Maybe add a comment  
saying that the API is highly likely to change.
  * Moving trac.util.markup to trac.util.html... as I proposed on the  
markup sandbox thread. I can do that, was just waiting to see whether  
anyone would raise late objections. I guess there are none.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane