Fossil Forum

Feature request: source link and trhead link in reply form
Login

Feature request: source link and trhead link in reply form

Feature request: source link and trhead link in reply form

(1) By anonymous on 2021-06-10 19:56:21 [source]

My request is to display the source link and thread link in the reply form.

Including the source link in the reply form is useful to make proper quoting, so that you can copy the source text.

(2) By Warren Young (wyetr) on 2021-06-10 20:31:59 in reply to 1 [link] [source]

The text of the post you're replying to is displayed above the textedit box you use for composing your reply. It wasn't always so, but that feature landed months ago.

Also, realize that the need for quoting the source message is considerably lower with a reliable threaded message system, where replies can't become disconnected from their parents. Primitive messaging systems like RFC 822 email and Usenet need quoting more than Fossil forums do, because they lack its durable Merkle tree design. Since child posts are always attached to their parents with Fossil, you can just scroll up a bit to see what was said.

On Fossil forums, I usually only quote when replying when the parent message covers many points, so it's not clear which piece I'm replying to if I don't quote a line or two to break my reply up.

(3) By anonymous on 2021-06-10 23:16:47 in reply to 2 [link] [source]

While it is true that quoting may be needed less, but that doesn't necessarily mean that you will not use quoting at all.

When you do use quoting, having the source link available would be helpful to copy the formatting properly, and you may also want a link to the thread in order to review it.

(These kind of thing being variously different on web forums is one reason why I would prefer to use the NNTP rather than having specialized web forum software. I use NNTP for my own projects, although I know that not everyone likes that, so I will hope that I can integrate it with the web forum software too.)

(4) By sean (jungleboogie) on 2021-06-11 01:14:42 in reply to 3 [link] [source]

having the source link available would be helpful to copy the formatting properly

What’s this mean? I guess Warren understood what you were asking but I’m confused.

(5.1) By Stephan Beal (stephan) on 2021-06-11 02:50:33 edited from 5.0 in reply to 4 [link] [source]

What’s this mean?

When viewing the raw source, you get a full markup for the formatting. For example, if you want to quote this <strong>blah</strong> then you'd currently have to manually add the backticks (after copy/pasting the text) to keep the tag from being seen as HTML. If you have the source of this post readily available, you can copy the backticks when copying the text you'd like to quote, instead of having to manually escape it. (Keep in mind that a conventional "quote this post" feature is essentially impossible for this forum because fossil supports multiple forum post formats, none of which can be mixed into a single post.)

It might not be a bad idea to add an option to toggle the original text between its current view and a read-only textarea containing the source. The only downside to that, aside from having to deal with posts which themselves inject a closing TEXTAREA tag, would be that it would effectively double the size of the page content (which is negligible until you want to respond to a huge message - people sometimes post 1000+ lines of output or large schemas in the sqlite forum).

(6) By anonymous on 2021-06-11 04:29:53 in reply to 5.1 [link] [source]

It might not be a bad idea to add an option to toggle the original text between its current view and a read-only textarea containing the source. The only downside to that [...] would be that it would effectively double the size of the page content (which is negligible until you want to respond to a huge message [...]).

It is why I think that a link should be added for the source and for the thread; the user can use the "open in new window" function in their browser (by middle click or whatever the function is in that specific web browser) if wanted to view it in a separate window to not disturb the existing reply. (The reply itself doesn't load in a separate window since it is a button instead of a hyperlink; in many web browsers the function to open it in a separate window doesn't work for a button.)

If you do have a toggle, you will have to do something that can work even if JavaScripts are disabled too (not necessarily the same that will be done if it is enabled)

Another possibility might be to add a "reply with quote" option; if selected, then the markup style and text input are prefilled with the quoted text with the proper notation for quoting (> in front for markdown and plain); you can then split up the quotation and delete the unused parts by yourself. (This is the common way to do it with email and NNTP, as well as some web forum software.)

(7) By Stephan Beal (stephan) on 2021-06-11 04:41:06 in reply to 6 [link] [source]

Another possibility might be to add a "reply with quote" option; if selected, then the markup style and text input are prefilled with the quoted text with the proper notation for quoting

The quoting style depends not only on the original post (or posts, in the case of quoting a post which itself contains other quotes) but also on the response format, which we don't know in advance, so automatic quoting is genuinely not a possibility for us. Consider a thread where you want to quote two levels deep and the OP, the first responder, and yourself all use a different post format. There is no decent solution to that problem for a multi-dialect forum.

(> in front for markdown and plain); you can then split up the quotation and delete the unused parts by yourself.

Except that many people don't trim their quotes, leading to responses which are 100 lines of quote followed by a single line of response (one of my pet peeves in certain forums). One of the genuine advantages to not supporting automatic quoting is that people only quote as much as they need to (if they bother to quote at all).

(This is the common way to do it with email and NNTP, as well as some web forum software.)

It's ubiquitous, or close to it, for any forum-style platform which supports only a single input format (namely plain text or a single forum-specific markup style). Fossil supports 3 formats, none of which can be freely mixed with the others. Supporting multiple formats has its advantages, but it makes automatic/assisted quoting effectively impossible.

(8) By sean (jungleboogie) on 2021-06-11 05:08:16 in reply to 7 [link] [source]

Thanks for the explanation above.

Except that many people don't trim their quotes, leading to responses which are 100 lines of quote followed by a single line of response

Yeah, that’s extremely annoying. It happens on email as well.

(9) By graham on 2021-06-11 08:45:22 in reply to 6 [link] [source]

It is why I think that a link should be added for the source and for the thread;

FWIW, I would second at least a thread-link on the "Reply" page.

If I'm replying to a specific point that I want to quote, I've "trained myself" to select-and-copy the relevant part from the thread before clicking "Reply" so that I can paste it in on the reply screen (as I did with the above). However, as I'm writing the reply I'll often find I want to refer back to other posts in the thread (not necessarily to quote, but just for context), and not being able to easily get back to the thread can be "irksome".

If you anticipate wanting to do this before clicking "Reply", you can (in Chrome at least) hold Ctrl-Shift as you click, which will open (and switch to) the reply-page in a new window, leaving the original thread in the original window. However, if you forget to do this (or didn't anticipate the need), it's a bit of a pain.

The most obvious place to do this would be to "linkify" the "Thread: <subject>" line (perhaps just the subject part of it) at the top of the page. Ideally such a link would focus on the post you are replying to (and from where you could view that post's source).

For myself, I would be tempted to make such a link automatically open in a new tab (target="_blank"), but recognise some people don't like too many auto-opening tabs.

(10) By Stephan Beal (stephan) on 2021-06-11 09:05:15 in reply to 9 [link] [source]

For myself, I would be tempted to make such a link automatically open in a new tab (target="_blank"), but recognise some people don't like too many auto-opening tabs.

i will be adding this and the OP's request for a source link in the next couple of hours. From the response page we "need" to use target=_blank because it's otherwise too easy to lose form data. Whether or not a browser will keep form data when clicking away from, then back-buttoning to, a page is not specified by any standard and may differ from one version of a browser to the next. Thus opening in a new tab is the only certain way to avoid loss of current edits. (That is, until the forum eventually gets JS'd more and we use localStorage to stash edits like we do for /wikiedit and /fileedit.)

(11) By Stephan Beal (stephan) on 2021-06-11 09:35:50 in reply to 1 [link] [source]

My request is to display the source link and thread link in the reply form.

This is now in the trunk.

It links, as Graham suggested, to the responded-to post, rather than the top of the thread, as that seems generically more useful but still leaves the user in a place where they can search around for more context if needed.

Rather than link the subject line, these links were added to the "replying to" line below that because:

  1. The subject line is permitted to be blank (at least, the code which emits it checks for that case and leaves out that header if the subject is blank).
  2. It just felt really noisy as part of the H1 header. It's still a bit noisy as part of an H2, but it's more tolerable. It was not added as its own new line in order to avoid taking up yet more vertical screen space.

The new links use target=_blank to help avoid any data loss if a user clicks away from the page while editing and the browser chooses to discard their edits if they tap the Back button (that's browser/version dependent). That's up for debate and change, but it seems to me that a user will otherwise always have to remember to use ctrl-click/middle-click on those to open them in new tabs.