Opened 15 years ago
Closed 15 years ago
#9144 closed enhancement (fixed)
Add documentation to auto_preview_timeout mentioning minus value for immediate update
Reported by: | Owned by: | Remy Blank | |
---|---|---|---|
Priority: | normal | Milestone: | 0.12 |
Component: | wiki system | Version: | 0.12dev |
Severity: | normal | Keywords: | preview |
Cc: | mark.m.mcmahon@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The TracIni section mentions to use 0 to disable the automatic preview.
I also thought that the following might be useful when setting this value:
- It cannot be a floating point number (has to be a whole number)
- Setting a minus value will update the preview immediately.
The attached patch will update the doc string for auto_preview_timeout
.
Attachments (1)
Change History (9)
by , 15 years ago
Attachment: | TracIni_auto_preview_timeout_doc.patch added |
---|
comment:1 by , 15 years ago
Milestone: | → 0.12 |
---|---|
Owner: | set to |
Does it really update immediately for negative values? I couldn't remember :) So the improved documentation is certainly welcome.
follow-up: 3 comment:2 by , 15 years ago
Yes - tested on Trac 0.12dev-r9359.
Are there any concerns that should be noted by setting it to a minus value? I love the fact it is updated immediately - but I have worries that it may cause problems with server load (though my servers are very lightly loaded)
comment:3 by , 15 years ago
Replying to mark.m.mcmahon@…:
Are there any concerns that should be noted by setting it to a minus value? I love the fact it is updated immediately - but I have worries that it may cause problems with server load (though my servers are very lightly loaded)
Yes, we should probably warn about that. And also check that this effect is indeed desired, and not just an unwanted side-effect.
follow-up: 5 comment:4 by , 15 years ago
Perhaps we should allow fractional delays (there was already a patch for FloatOption from eblot) if we want "real time" updates, but having an instantaneous update (is that one for every keypress?) is really too much I think. So better be able to specify e.g. 0.2 than -1 …
comment:5 by , 15 years ago
Replying to cboos:
Perhaps we should allow fractional delays (there was already a patch for FloatOption from eblot) if we want "real time" updates,
Yes, I agree with that. I almost did that when I implemented the feature, but then didn't want to make the patch more complicated for review, and finally forgot about it.
but having an instantaneous update (is that one for every keypress?)
Every keypress would trigger an update, but they are serialized, so no new update request is sent until the reply to the previous one has been received.
Ok, let's do the FloatOption
thing.
comment:7 by , 15 years ago
This sounds good to me too - in fact I tried a Float first.
New doc string would be ?
Inactivity timeout in seconds after which the automatic wiki preview triggers an update. Set this to 0 to disable automatic preview. This option can contain floating point values for example 0.2, 1.5. ''The lower the setting the more requests will be made to the server.'' The default value is 2 seconds. (''since 0.12'')
comment:8 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Changed [trac] auto_preview_timeout
to a FloatOption
, and fixed the docstring accordingly in [9364]. Negative values now also disable the automatic preview.
Patch to doc string for auto_preview_timeout