Re: [fossil-users] Markdown wiki relative links
On 07/04/18 16:37, Stephan Beal wrote: i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) Fossil already does apply different semantics. It's simple, but not what you're thinking: As far as I can tell, Fossil rejects URLs containing %xx in the path. Sounds like a good way to avoid people sneaking metacharacters past security filters. Wouldn't want %2e%2e%2f to come up as ../ allowing you to see files outside of the document root! -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown wiki relative links
i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 23:26 Andy Goth wrote: > On 07/04/18 16:01, Stephan Beal wrote: > > Fwiw, a few years back i created a patch which caused generated wiki > > links to always emit wiki/x rather than name=x, but it was pointed out > > to me that wiki/x doesn't work when x contains a slash, which is a valid > > wiki page name character. Thus the portable approach is to use name=x. :/ > > Well, I totally forgot slashes could be in page names. What about %2f? > > -- > Andy Goth | > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown wiki relative links
On 07/04/18 16:01, Stephan Beal wrote: Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ Well, I totally forgot slashes could be in page names. What about %2f? -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown wiki relative links
Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 22:54 Andy Goth wrote: > To create a link in the Markdown wiki, the syntax is [like this](url). > That's all well and good, but what precisely does url need to be for one > page to link to another? In writing embedded documentation, I've gotten > used to relative paths, so in order to link /doc/trunk/doc/foo.md to > /doc/trunk/doc/bar.md, I write (bar.md). > > However, with the wiki, there's an issue. Most (if not all) of the > links into the wiki use the ...?name=page syntax rather than the > theoretically equivalent .../page syntax. This throws off relative > paths entirely. Relative links between wiki pages will be different > depending on which "equivalent" syntax was used to access the wiki. > > Suppose wiki page foo wants to link to wiki page bar. If foo was > accessed as wiki?name=foo, then it must link to (wiki?name=bar) or > (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), > which it what I hoped would work all along. > > To make intra-wiki links work regardless of which syntax is used to > access the wiki, it appears it's necessary to use "absolute" (actually > relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). > This is not something I've had to deal with (yet?) when doing embedded > documentation. > > My preference would be for Fossil to never send the name query parameter > to the user. If a name query parameter is received from the user, I > think maybe Fossil should not call the webpage function (other than > confirming that one exists) and instead immediately send a 301 Moved > Permanently back to the user to rewrite the URL to use /. > > Or maybe I'm missing something fundamental here. > > There's one other style of relative link I'll mention: (?name=bar). > This replaces the name query parameter. I don't think this would work > very well if linked from /wiki/foo. Also it gets even weirder when > clicking a link in the preview shown by wikiedit, since it takes the > user to the editor for the target page. But this last would still occur > should we replace all ?name= with /. To avoid that, the link would have > to be either (/wiki/bar) or (../wiki/bar), though of course that last > one combines the worst of all worlds. > > For now, I'll make sure all my wiki links are to /wiki/whatever. > > Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's > what Chiselapp uses. > > -- > Andy Goth | > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Markdown wiki relative links
To create a link in the Markdown wiki, the syntax is [like this](url). That's all well and good, but what precisely does url need to be for one page to link to another? In writing embedded documentation, I've gotten used to relative paths, so in order to link /doc/trunk/doc/foo.md to /doc/trunk/doc/bar.md, I write (bar.md). However, with the wiki, there's an issue. Most (if not all) of the links into the wiki use the ...?name=page syntax rather than the theoretically equivalent .../page syntax. This throws off relative paths entirely. Relative links between wiki pages will be different depending on which "equivalent" syntax was used to access the wiki. Suppose wiki page foo wants to link to wiki page bar. If foo was accessed as wiki?name=foo, then it must link to (wiki?name=bar) or (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), which it what I hoped would work all along. To make intra-wiki links work regardless of which syntax is used to access the wiki, it appears it's necessary to use "absolute" (actually relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). This is not something I've had to deal with (yet?) when doing embedded documentation. My preference would be for Fossil to never send the name query parameter to the user. If a name query parameter is received from the user, I think maybe Fossil should not call the webpage function (other than confirming that one exists) and instead immediately send a 301 Moved Permanently back to the user to rewrite the URL to use /. Or maybe I'm missing something fundamental here. There's one other style of relative link I'll mention: (?name=bar). This replaces the name query parameter. I don't think this would work very well if linked from /wiki/foo. Also it gets even weirder when clicking a link in the preview shown by wikiedit, since it takes the user to the editor for the target page. But this last would still occur should we replace all ?name= with /. To avoid that, the link would have to be either (/wiki/bar) or (../wiki/bar), though of course that last one combines the worst of all worlds. For now, I'll make sure all my wiki links are to /wiki/whatever. Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's what Chiselapp uses. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Syntax Highlighting
In message <20531f51e58eeb700e801d854d82d...@amlegion.org>,
"Lester L. Martin II" writes:
>On 2018-07-04 10:03, John P. Rouillard wrote:
>> There is something odd happening with the history buffer. Start at:
>>
>> https://code.amlegion.org/hljs_line_numbers/
>>
>> click on "Single line selection". You end up at:
>>
>>
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2
>>
>> bur rather than 2 items in the history, there are 4 items in my
>> history:
>>
>> 4
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2
>>
>> 3
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#
>>
>> 2
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2
>>
>> 1 https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md
>>
>> I have to hit the back button 3 times to move back to the original
>> page.
>> It looks like URL's 2 and 4 are the same.
>>
>> Any idea what's happening here?
>>
>> Have a great day.
>
>Hey Mr. Rouillard,
>
>I bet I know what that is. The code uses window.location.hash to
>establish where the URIs will link to by doing something that is
>partially destructive. Something like:
>
>var uri = window.location;
>var old_hash = window.location.hash;
>window.location.hash = "";
>uri = window.location.href;
>window.location.hash = old_hash;
>
>So now I need to figure out how to reset history to where it should
>be after those operations. I'm welcome to ideas (that I'll review
>later on and push up a fix to the repo and then pull into the
>static files for my repos so that it can be tested.)
Maybe:
https://stackoverflow.com/questions/8969878/in-javascript-how-do-i-clear-the-back-history-1
which offers:
window.location.replace("path/to/target/page");
as way to fix?
Have a great day.
--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Syntax Highlighting
Hello Mr. Martin: In message , "Lester L. Martin II" writes: >For the JS source that enables line numbering see: >https://code.amlegion.org/hljs_line_numbers/ (Fossil repo with it) > >For a showcase of it doing its job and doing it well since I've recently >got it up to par with the C source's selection code: >https://code.amlegion.org/hljs_line_numbers/ > >The home page gives some links to test selection with line numbering, >multi-selection, and scroll to top. As time permits I'll also create >(and link to from the home page) wiki documents describing the setup >of this for one's own Fossil Repo. There is something odd happening with the history buffer. Start at: https://code.amlegion.org/hljs_line_numbers/ click on "Single line selection". You end up at: https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2 bur rather than 2 items in the history, there are 4 items in my history: 4 https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2 3 https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0# 2 https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2 1 https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md I have to hit the back button 3 times to move back to the original page. It looks like URL's 2 and 4 are the same. Any idea what's happening here? Have a great day. -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] branch assistance needed
On 12:42AM, Wed, Jul 4, 2018 Nicola wrote: > > On 04/07/2018 00:18, Warren Young wrote:> On Jul 3, 2018, at 3:09 PM, > Dewey Hylton wrote: > > >> I then attempted to change that latest commit by adding a 'trunk' > tag and cancelling the new branch tag. > > > > Ow! > As a newbie Fossil user, after reading > > https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki > > and, specifically, this sentence: > > > […] check-ins can be freely moved between branches simply by altering > > their tags > I was (mis)lead to believe that what the OP did might somehow work > (well, actually I was skeptic, so I tried on a test repository). > > Maybe, the sentence above could be complemented with an example of how > to do that and how *not* to do it (e.g., explaining what the effect of > adding a 'trunk' tag to a random check-in is and why it should not be > done). So provide a patch with the enhancement and let's see what happens. > > Nicola > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Syntax Highlighting
On 2018-07-03 19:12, Offray Vladimir Luna Cárdenas wrote: Lester, Thanks a lot for your efforts in that front. I'm planing into extending Fossil with Lua using javascript, so the steps you describe here are pretty useful (maybe they could be collected in some of your public repositories that serve as a showcase of your Fossil customizations). It will be my first attempt on that front and I need to finish some other stuff before, but I will try do document it as well. Offray, Not only did I do that, I went ahead and created 2 patches for Fossil. The first one enabled syntax highlighting in general however syntax highlighting engines would have been broken when line numbering came into play. The second patch got syntax highlighting with line numbers working and provided a way for the theme to handle when JS for line numbering and/or highlighting is enabled/called. See the other Syntax Highlighting related emails by me for more info. For the JS source that enables line numbering see: https://code.amlegion.org/hljs_line_numbers/ (Fossil repo with it) For a showcase of it doing its job and doing it well since I've recently got it up to par with the C source's selection code: https://code.amlegion.org/hljs_line_numbers/ The home page gives some links to test selection with line numbering, multi-selection, and scroll to top. As time permits I'll also create (and link to from the home page) wiki documents describing the setup of this for one's own Fossil Repo. Feel free to help me improve the documentation as to doing this. -- Lester L. Martin II ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Syntax Highlighting
Lester, Thanks a lot for your efforts in that front. I'm planing into extending Fossil with Lua using javascript, so the steps you describe here are pretty useful (maybe they could be collected in some of your public repositories that serve as a showcase of your Fossil customizations). It will be my first attempt on that front and I need to finish some other stuff before, but I will try do document it as well. Cheers, Offray On 26/06/18 13:02, Lester L. Martin II wrote: > Recently I had the pleasure of succeeding in enabling syntax > highlighting. Even > with that success I still found some things that could make the > process easier > and more robust. > > One major issue would be that fossil by default inserts the following > in the > head: > > > > This is fairly prohibitive towards trying to get outside resources > included so > as to allow syntax highlighting. The solution? Download jquery, > highlightjs, and > a CSS file to the directory that fossil server is serving up and tell > it with > the "--files" glob pattern to serve those sorts of files. Even so, I > understand > it's perhaps useful when running as it's own http server during local > development but truthfully when ran with say the "--scgi" parameter > I'm unsure > that it does any good setting things that can be set in headers by the > http > server that is proxying it. In my case I use nginx and had my own set > of CSP > headers defined that I use across quite a few different resources. > This confused > me for a good minute when trying to use a CDN for highlightjs. > > The next major issue is that the "Artifact Content" pages use > "" instead of "". This means that there > are quite a > few syntax highlighting tools that will absolutely not work. These > tools insist > on the latter (think prism.js). Luckilly highlightjs doesn't insist. > Regardless, > even if its "", utilizing "" would > be far > better. I've looked at the function in "src/info.c" and I also notice > one other > area where this could be improved if it were to move to "". > The > function already knows the file name and thereby could ascertain the > file's > extension quite easily. That said, say the file name is "bla.lua", it > could > detect the extension "lua", and set the class of the code block to it > like > "". > > Having the ability to utilize syntax highlighting would greatly > enhance fossil > and I'd love to see the previous paragraph's proposal implemented > because most > syntax highlighting detection engines will be more than horribly > incorrect (I've > played with highlightjs and have had nothing but incorrect detection). > > Finaly, I'd love to contribute, and had thought to go ahead and write > a probably > horrible patch considering I haven't read the entirety of the code > base and am > ultimately not up to speed with the project from a programming > perspective. I > saw on the site that a contributors agreement is needed but I also > didn't see a > way to submit the agreement even if I did fill it out. I at the moment > believe > someone other than myself could implement this feature correctly and less > horribly than I could before I could manage to appropriately submit > such an > agreement. Even so, I'd like to get a contributors agreement on file > so if > anyone can help with that. > > -- > Lester L. Martin II > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] branch assistance needed
On 04/07/2018 00:18, Warren Young wrote:> On Jul 3, 2018, at 3:09 PM, Dewey Hylton wrote: >> I then attempted to change that latest commit by adding a 'trunk' tag and cancelling the new branch tag. > > Ow! As a newbie Fossil user, after reading https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki and, specifically, this sentence: > […] check-ins can be freely moved between branches simply by altering > their tags I was (mis)lead to believe that what the OP did might somehow work (well, actually I was skeptic, so I tried on a test repository). Maybe, the sentence above could be complemented with an example of how to do that and how *not* to do it (e.g., explaining what the effect of adding a 'trunk' tag to a random check-in is and why it should not be done). Nicola ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
