headers
Stefan Santesson | 1 Sep 2009 03:02
Favicon

Re: why my nroffedit is so slow

Actually, I just posted a new version that improves the experience quite a
bit when working with large files (or slow computers).

This is incorporated in version 1.33, available from:
http://aaa-sec.com/nroffedit/index.html

In 1.33 there is a timer that prevents any update action until 1.5 seconds
after last key press. That way there will be no updating going on while
typing. You can override this timer by checking "Instant Text Update" in the
edit menu (off by default).

/Stefan

On 09-08-31 7:36 PM, "Stefan Santesson" <stefan <at> aaa-sec.com> wrote:

> Hi Hui
> 
> The delays in version 1.2 and beyond is mainly caused by the spell checker
> and automatic instant updates of the text version of your draft.
> 
> There is a new version (1.32) available that has implemented several
> optimizations.
> 
> When editing large files it is advisable to turn off the Automatic Update
> feature. This way you can edit without delay and only update the text when
> you want to see the result.
> 
> You can also turn off the spell checker in order to speed up the process
> when you don't need it.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hui Deng | 1 Sep 2009 16:06
Picon

Re: why my nroffedit is so slow

It's really good now, cool...
thanks a lot for your kind help.

Best regards,

-Hui

2009/9/1 Stefan Santesson <stefan <at> aaa-sec.com>:
> Actually, I just posted a new version that improves the experience quite a
> bit when working with large files (or slow computers).
>
> This is incorporated in version 1.33, available from:
> http://aaa-sec.com/nroffedit/index.html
>
> In 1.33 there is a timer that prevents any update action until 1.5 seconds
> after last key press. That way there will be no updating going on while
> typing. You can override this timer by checking "Instant Text Update" in the
> edit menu (off by default).
>
>
> /Stefan
>
>
>
>
> On 09-08-31 7:36 PM, "Stefan Santesson" <stefan <at> aaa-sec.com> wrote:
>
>> Hi Hui
>>
>> The delays in version 1.2 and beyond is mainly caused by the spell checker
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrik Levkowetz | 1 Sep 2009 17:08

Re: Rfcmarkup-1.83 feedback

Hi George,

On 2009-08-29 08:21 George Barwood said the following:
> I'm getting inconsistent results when using the URL
> 
> http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport
> 
> Sometimes it redirects to
> 
> http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport-01
> 
> and sometime it doesn't redirect and shows only version 00.
> 
> What I want is a link that will always show the latest version of the draft.
> 
> Is this possible?

The URL without any explicit number should always redirect to the latest version
of the draft.  I just checked all the tools servers, and they all currently
redirect to -02.  The only time you should see the behaviour above would be
when a new version has just appeared in the repository, and the servers have
not all yet downloaded the new version.

Best,

	Henrik
Permalink | Reply | 0 comments |
headers
Henrik Levkowetz | 10 Sep 2009 16:07

Tools release feed

Hi,

In order to make it easier to follow tool releases for people who may wish
to do so, I've put together a feed which pulls information from the changelog
file and a meta-information file for each tool hosted on tools.ietf.org.

General Info:
  The feed is available at

    http://tools.ietf.org/tools/atomfeed.xml

  and there is an autodiscovery link in the tools overview page at

    http://tools.ietf.org/tools/

  The intention is to provide feed entries not only for tools hosted on
  tools.ietf.org, but also for other tools which are listed on the tools
  overview page.

For Tool Authors:

  In order to make it easy to automatically add release information to the
  feed, the tool which puts together the feed reads meta-information from
  an augmented debian-style control[1] file, and release information from a
  debian-style changelog[2] file.  If you can arrange for your tool releases
  to contain a control file and changelog in the appropriate format, and
  be available online, the online repository will be regularly polled, and
  the tool overview page and the feed automatically updated.

  The additional control file entries required are:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 11 Sep 2009 18:45
Favicon

bug report: autogenerated section links


It seems that the I-D HTML output autogenerates internal links to things
like "Section *.*" even if the text is referring to an external
document. See for example:

http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-01#section-12.1

Best,

Peter

--
Peter Saint-Andre
https://stpeter.im/
Permalink | Reply | 1 comment |
headers
Henrik Levkowetz | 12 Sep 2009 23:05

Re: bug report: autogenerated section links

Hi Peter,

On 2009-09-11 18:45 Peter Saint-Andre said the following:
> It seems that the I-D HTML output autogenerates internal links to things
> like "Section *.*" even if the text is referring to an external
> document. See for example:
> 
> http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-01#section-12.1

Yes.  This is because these HTML versions are generated straight from
the text documents, not from for instance XML source, and the generation
is basically regex-based; i.e., the text document is *not* parsed into
a datastructure where for instance references could be resolved to
documents and appropriate external html links could be generated.  I'm
not saying that it wouldn't be great to have a parser, rather than
just a regex-based conversion, but that requires more work than I've had
time for.

I can suppress link generation for the special case of 'Section X.Y of [ref]'
(and similar), but generating sensible links for this case and the 
'Section 2.6 therein' case seems out of reach at the moment.

Regards,

	Henrik
Permalink | Reply | 0 comments |
headers
Sandra Murphy | 17 Sep 2009 16:25

tools issue tracker?

There's a request in my wg that "we move to using the ietf tools issue 
tracker".

That is a tool that has gottem some praise on the wg chairs list.

But I can't find it.  Lame, I know.  Even the tools site's tool page 
didn't help me.

Coudl you (gently) apply clue there?

--Sandy
Permalink | Reply | 1 comment |
headers
Pasi.Eronen | 17 Sep 2009 17:37
Picon

Re: tools issue tracker?

Go to the WG's page (e.g. http://tools.ietf.org/wg/ipsecme/) and 
click "Issues" in the top of the page.

If your WG doesn't have it yet, you can ask Henrik to create
it for your WG.

Best regards,
Pasi

> -----Original Message-----
> From: tools-discuss-bounces <at> ietf.org [mailto:tools-discuss-
> bounces <at> ietf.org] On Behalf Of ext Sandra Murphy
> Sent: 17 September, 2009 17:25
> To: tools-discuss <at> ietf.org
> Subject: [Tools-discuss] tools issue tracker?
> 
> There's a request in my wg that "we move to using the ietf tools issue
> tracker".
> 
> That is a tool that has gottem some praise on the wg chairs list.
> 
> But I can't find it.  Lame, I know.  Even the tools site's tool page
> didn't help me.
> 
> Coudl you (gently) apply clue there?
> 
> --Sandy
> 
> _______________________________________________
> Tools-discuss mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Bormann | 21 Sep 2009 14:00
Favicon
Gravatar

rfcdiff lies

I just had an interesting encounter with rfcdiff, more precisely with

http://tools.ietf.org/rfcdiff?url2=draft-ietf-6lowpan-nd-05.txt

draft-ietf-6lowpan-nd-05.txt changes a packet format from its -04  
version:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              TID              |     Status    |P|   Reserved  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Lifetime                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                  Owner Interface Identifier                   +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Owner Nonce                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Registration option(s)...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Node Registration/Confirmation message format

to its -05 version:

     0                   1                   2                   3
(Continue reading)

Permalink | Reply | 15 comments |
headers
Henrik Levkowetz | 21 Sep 2009 15:32

Re: rfcdiff lies

Hi Carsten,

On 2009-09-21 14:00 Carsten Bormann said the following:
> I just had an interesting encounter with rfcdiff, more precisely with
> 
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-6lowpan-nd-05.txt

<snip details showing erroneous display of whitespace change>

Ugh.  Not good.

> I was just about to file the defect report on -05...
> 
> Whitespace *is* significant in RFC box notation!
> 
> Even if the change is not color-coded (which would probably be hard to  
> do in general for whitespace-only changes), the right column should  
> get its content from the actual file, not from the "unchanged"  
> contents of the left column.

Agreed.

> Until then, I'll triple-check my box notation from the original files.

I've made an experimental update of rfcdiff which doesn't consider white-
space significant when looking for changes in general.  Doing this only
for artwork requires a major re-write of the tool, so I'm looking for
workable solutions which require somewhat less work.

The URL above should now show the whitespace change faithfully, with
(Continue reading)

Permalink | Reply | 14 comments |

Gmane