Re: [fossil-users] how to link to other pages in the wiki, wiki-link syntax

2016-01-27 Thread John Gabriele
On Tue, Jan 26, 2016, at 04:48 PM, Warren Young wrote:
> On Jan 26, 2016, at 2:06 PM, John Gabriele  wrote:
> > 
> > I see. You want to be able to have both of these link to the same wiki
> > page:
> > 
> >[fettuccine alfredo]
> >[you might like this](fettuccine alfredo)
> 
> Yes.
> 
> > That last line above doesn't look good to me; since this is markdown,
> > that thing in parens should be a url or path to an html file.
> 
> It would be straightforward for Fossil to test whether the link text is a
> Fossil wiki article text before writing it literally into the HTML.  If
> it isn’t, it can simply fall back to its current HTML generation logic.

Ok. I now think I was mistaken. Your suggestion makes sense to me in
terms of
"[descriptive text](where you should go for that)":

[descriptive text](http://example.com)
[descriptive text](foo.jpg)
[descriptive text](path/to/foo.html)
[descriptive text](some wiki page)

> The only risk is that there’s a wiki article with that title, but you
> *don’t* want Fossil to make the link.
> 
> Do you see that as a significant risk?

I think there's two separate issues:

1. you want to write "[sic]" and not have the wiki try and link to a
"sic" page. You can avoid this by backslash escaping the open bracket (
\[sic] ).

2. you write "[go here]", then later there's a line "[go here]:
http://example.com;, but there's also a "go here" wiki page. Where does
the link point to? [Oh, you addressed this below in your numbered list.]
I'd say that if you took the trouble to create that link target line,
then the wiki should honor that before trying to link to a wiki page.

> While I’m thinking about it, Fossil should also auto-link artifact IDs
> and tag names when used as link targets, for the same reason:
> 
> See the [original bug report](f86d58fe11).
> 
> Here, f86d58fe11 is explicitly the link text.  If it matches a Fossil
> artifact ID, Fossil should auto-link it.
> 
> This design error was fixed in [the v5 branch](v5.0.0).
> 
> Same thing, only with a tag name instead of an artifact ID.
> 
> This design extends a partial fix already committed. ([f86d58fe11])
> 
> There is a tiny risk of ambiguity here, since the descriptive text and
> the link target are the same thing.  But, all that’s needed to resolve it
> is a clear precedence hierarchy.  I propose:
> 
> 1. Try to treat it as a link reference.  (e.g. [foo] in a document that
> also contains [foo]: target)
> 
> 2. Try to find a tag or branch with the same name.
> 
> 3. Try to find a wiki article with the same name.
> 
> 4. If it’s hexadecimal, try to treat it as an artifact ID.
> 
> 5. Failing all that, do what it does now.

(Well, using markdown syntax *now*, it doesn't create a link at all --
you just get the plain text with brackets around it. If the feature were
implemented though, I'd say the default last-case behaviour should be to
create the link to an empty wiki page, so the author can click it,
create the new page, and keep writing.)

> Your challenge: find a sane use case where the precedence rules above
> give surprising results.
>
> You will notice that I have ordered the rules to give a controlled expansion 
> of the search scope.  Rules 2 and 3 could swap [snip]

Looks good to me. Though I'm not yet familiar with fossil, my hunch is
that you'll run into cases where there's branches and wiki pages with
the same name. Don't know which would make more sense to come first.

-- John
___
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] Semi-annual drumming-up-of-support for libfossil

2016-01-27 Thread Saša Janiška
On Pon, 2016-01-18 at 12:19 +0100, Stephan Beal wrote:

> And i spoke too soon. That weekend of blissful hacking caused my
> elbow to regress and i'll likely be back on medical leave as soon as i
> can get to a doctor :/. 

Have you considered to use Spacemacs (http://spacemacs.org/) which,
among other things, says: "Lower the risk of RSI by heavily using the
space bar instead of modifiers. If you have issues with your thumbs you
can still use Spacemacs using modifiers."
(https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.org
#core-pillars)?


Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though
faultily, than another's duties perfectly. Destruction in the course
of performing one's own duty is better than engaging in another's
duties,for to follow another's path is dangerous.




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users