Re: [fossil-users] Patch: Enables integration of syntax highlighting systems

[Chad Perrin]

On Wed, Jun 27, 2018 at 11:31:57PM -0500, Lester L. Martin II wrote:
> This patch changes the way `void artifact_page(void)` renders a files 
> content.  Formerly a `` was issued for content,
> whereas now a `` is issued where
> $ext is the file's extension (example, "blah.lua" extension would be
> "lua").
> 
> This allows for proper integration with syntax highlighting systems
> such as "highlight.js" and "prism.js" where only the former was
> tested. This allows syntax highlighting without having to have
> language detection.

It's pretty cool you did this.  I'm going to look over this and the
syntax highlighting tools that might work with it to see if I want to
start using it, though I guess I'd have to compile my own Fossil if I
wanted to do it sooner rather than later.  Thanks for the work.


> 
> Remaining work likely includes changing the CSS of all themes to take
> this into account. Other things that might be considered is to
> conditionally remove the `` part from all but the content
> rendering. Another part would be rendering syntax highlights with line
> numbers (currently unimplemented).

Have you checked it against any themese to see if it affects them at
all?  If so, which themes did you find weren't problematic?  I'm
guessing that if you found some that were you'd mention it.


> 
> Below is the output of 'fossil diff' ran against checkout
> '6a7d2ad8f1dd5c542eba0b885418328803d8d802' with my changes:
> 
> Index: src/info.c
> ==
> --- /home/masky/misc/fossil/src/info.c~0  2018-06-27 23:21:48.520779000 
> -0500
> +++ /home/masky/misc/fossil/src/info.c2018-06-27 16:48:28.683256000 
> -0500
> @@ -670 +670 @@
> -
> +
> @@ -2157 +2157,2 @@
> -const char *z;
> +const char *z, *ext, *name;
> +char *tmp;
> @@ -2158,0 +2160,3 @@
> +name = blob_str();
> +
> +ext = (tmp = strrchr(name, '.')) == NULL ? "" : tmp+1;
> @@ -2162 +2166 @@
> -  @ 
> +  @ 
> @@ -2164 +2168 @@
> -  @ 
> +  @ 
> @@ -2232 +2236 @@
> -  ? db_text("(No title)",
> +  ? db_text("(No title)",
> 
> !!END!!
> 
> I'm unsure why "@@ -2232 +2236 @@" section got included as no changes 
> were
> made to that.

I haven't looked at the code in context; I've only seen the patch you
inlined in the email so far.  It looks sane to me, though.  I might come
back and look at it again in the morning, and check it against the
Fossil source code for context.


> 
> I would like to submit a contributor agreement to make it official. This
> change is so small that my previous post to the list serv considered,
> one could have implemented it in less time than it would take for a
> contributor agreement to finally be filed but as there was no reply
> I didn't wait upon such.

Even if they want the contributor agreement on file before incorporating
it, I'm glad you sent it to the list for people who might want to start
using it sooner than the next Fossil release.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
___
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] Help with making a subroutine x-platform to windows

[Scott Doctor]

Well thunderbird sure mucked up that formatting.

Launch windows command prompt

type nslookup

at the ">" prompt, type help

typing exit will exit out of nslookup

-
Scott Doctor
sc...@scottdoctor.com
-

On 6/27/2018 14:22, Scott Doctor wrote:
A way may be using the system() command to run nslookup. From 
the windows command line help for the command:


Commands:   (identifiers are shown in uppercase, [] means 
optional)NAME    - print info about the host/domain 
NAME using default serverNAME1 NAME2 - as above, but use 
NAME2 as serverhelp or ?   - print info on common 
commandsset OPTION  - set an option    all 
- print options, current server and host    
[no]debug   - print debugging information    
[no]d2  - print exhaustive debugging 
information    [no]defname - append domain name to 
each query    [no]recurse - ask for recursive answer 
to query    [no]search  - use domain search list 
[no]vc  - always use a virtual circuit 
domain=NAME - set default domain name to NAME 
srchlist=N1[/N2/.../N6] - set domain to N1 and search list to 
N1,N2, etc.    root=NAME   - set root server to NAME 
retry=X - set number of retries to X 
timeout=X   - set initial time-out interval to X 
seconds    type=X  - set query type (ex. 
A,,A+,ANY,CNAME,MX,NS,PTR,SOA,SRV)    querytype=X - 
same as type    class=X - set query class (ex. IN 
(Internet), ANY)    [no]msxfr   - use MS fast zone 
transfer    ixfrver=X   - current version to use in 
IXFR transfer requestserver NAME - set default server to 
NAME, using current default serverlserver NAME    - set 
default server to NAME, using initial serverroot    - 
set current default server to the rootls [opt] DOMAIN [> FILE] 
- list addresses in DOMAIN (optional: output to FILE)    
-a  -  list canonical names and aliases    -d  
-  list all records    -t TYPE -  list records of the 
given RFC record type (ex. A,CNAME,MX,NS,PTR etc.)view 
FILE   - sort an 'ls' output file and view it with 
pgexit    - exit the program


-
Scott Doctor
sc...@scottdoctor.com
-

On 6/27/2018 12:24, Richard Hipp wrote:


If anybody can suggest patches that will get this routine
(https://fossil-scm.org/fossil/info/5e083abf6?ln=47) to 
compile and

work on windows, that would really be helpful.  Thanks.



___
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] Help with making a subroutine x-platform to windows

[Scott Doctor]

A way may be using the system() command to run nslookup. From 
the windows command line help for the command:


Commands:   (identifiers are shown in uppercase, [] means 
optional)NAME    - print info about the host/domain NAME 
using default serverNAME1 NAME2 - as above, but use NAME2 as 
serverhelp or ?   - print info on common commandsset 
OPTION  - set an option    all - print 
options, current server and host    [no]debug   - print 
debugging information    [no]d2  - print exhaustive 
debugging information    [no]defname - append domain 
name to each query    [no]recurse - ask for recursive 
answer to query    [no]search  - use domain search 
list    [no]vc  - always use a virtual circuit    
domain=NAME - set default domain name to NAME    
srchlist=N1[/N2/.../N6] - set domain to N1 and search list to 
N1,N2, etc.    root=NAME   - set root server to NAME    
retry=X - set number of retries to X    
timeout=X   - set initial time-out interval to X 
seconds    type=X  - set query type (ex. 
A,,A+,ANY,CNAME,MX,NS,PTR,SOA,SRV)    
querytype=X - same as type    class=X - set 
query class (ex. IN (Internet), ANY)    [no]msxfr   - 
use MS fast zone transfer    ixfrver=X   - current 
version to use in IXFR transfer requestserver NAME - set 
default server to NAME, using current default serverlserver 
NAME    - set default server to NAME, using initial 
serverroot    - set current default server to the rootls 
[opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: 
output to FILE)    -a  -  list canonical names and 
aliases    -d  -  list all records    -t TYPE -  
list records of the given RFC record type (ex. A,CNAME,MX,NS,PTR 
etc.)view FILE   - sort an 'ls' output file and view it 
with pgexit    - exit the program


-
Scott Doctor
sc...@scottdoctor.com
-

On 6/27/2018 12:24, Richard Hipp wrote:


If anybody can suggest patches that will get this routine
(https://fossil-scm.org/fossil/info/5e083abf6?ln=47) to compile and
work on windows, that would really be helpful.  Thanks.



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

[fossil-users] Help with making a subroutine x-platform to windows

[Richard Hipp]

If anybody can suggest patches that will get this routine
(https://fossil-scm.org/fossil/info/5e083abf6?ln=47) to compile and
work on windows, that would really be helpful.  Thanks.

-- 
D. Richard Hipp
d...@sqlite.org
___
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] Meta-enhancement

[Andy Goth]

On 06/27/18 11:43, Richard Hipp wrote:

On 6/27/18, Andy Goth  wrote:

Would you be okay with me creating feature requests to track my own
Fossil development ideas, or would you prefer I keep them in wiki pages
or somewhere else?


I prefer them on this mailing list for now.  What advantage do you
hope to gain from moving feature requests to tickets and/or wiki?


I don't fully know.  I'm trying to explore alternatives right now, in 
this thread.  That's why I started it.


My concern about putting everything in email is I have too much 
accumulated to dump all at once, and I wanted a way to not lose track. 
Instead my thought was to archive it all somewhere permanent then open 
individual items for discussion in the order I want to talk about and 
possibly implement them.  Then I can later see what I've covered and 
what I haven't and choose new topics, time permitting, or reconsider in 
light of other developments, all the while keeping track of the thought 
process.  The discussion would be predominantly on this mailing list, 
but it would be indexed and summarized by the ticket tracker.


Others can do the same thing and independently pick from the list of 
open feature requests (also bugs, I have those to report as well) to 
write/code about even if I haven't written emails about them yet.


Plus, check-ins can reference tickets quite a bit more easily than they 
can reference emails, and check-ins show backreferences from tickets but 
of course not from emails.


I also thought about (and wrote about) additionally having a wiki page 
to group all my ideas and bug reports together, but honestly the ticket 
tracker's report capability can already do that.


Returning to the wording of your original question: "moving feature 
requests".  I do not propose to "move" at all.  Discussion would still 
continue on this mailing list, same as always, and in the vast majority 
of cases it's fine for the first mention of an idea to be in an email. 
The ticket tracker (or wiki) wouldn't become the new, preferred place to 
talk about ideas, only a means to keep track of the overall collection. 
But since I have a big pile of ideas, I can't dump them all at once on 
the list, so instead I'd create tickets, marked as enhancement 
(sometimes bug), with general descriptions.  And there they would sit 
idle until someone (me) writes an email about them to the list, 
whereupon discussion commences.  I'd then add ticket comments linking to 
the list archives.  Then, should implementation occur, we include ticket 
numbers in the initial branch check-ins and the merges to trunk so that 
everything be cross referenced.


Thus, the ticket tracker and wiki don't get pressed into forum duty, 
since email is already handling that for us.  The ticket tracker would 
track tickets, with discussion limited to highly technical comments 
directly targeted to the implementation.  The wiki would hold documents 
of the sort that can be versioned independently of the project.


--
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] email.c typo

[jungle Boogie]

Hi All,

I spotted one small type in the email.c file:

Index: src/email.c
==
--- src/email.c
+++ src/email.c
@@ -2028,11 +2028,11 @@

 /*
 ** WEBPAGE: announce
 **
 ** A web-form, available to users with the "Send-Announcement" or "A"
-** capability, that allows one to to send an announcements to whomever
+** capability, that allows one to send an announcements to whomever
 ** has subscribed to them.  The administrator can also send an announcement
 ** to the entire mailing list (including people who have elected to
 ** receive no announcements or notifications of any kind, or to
 ** individual email to anyone.
 */

I think the rest looks good, but others should feel free to review as well!
___
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] Meta-enhancement

[Richard Hipp]

On 6/27/18, Andy Goth  wrote:
> Would you be okay with me creating feature requests to track my own
> Fossil development ideas, or would you prefer I keep them in wiki pages
> or somewhere else?

I prefer them on this mailing list for now.  What advantage do you
hope to gain from moving feature requests to tickets and/or wiki?
-- 
D. Richard Hipp
d...@sqlite.org
___
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] Meta-enhancement

[Andy Goth]

On 06/27/18 11:37, Richard Hipp wrote:

My impression is that I would be troubled by the thousands of open
feature requests that the ticket system would be carrying around.  But
perhaps that is just a personal bias that I need to overcome.


Would you be okay with me creating feature requests to track my own 
Fossil development ideas, or would you prefer I keep them in wiki pages 
or somewhere else?


--
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] Meta-enhancement

[Richard Hipp]

On 6/27/18, David Mason  wrote:
>
> Wouldn't it be better if feature requests didn't count as bugs. And if
> tickets were marked as bugs, can't they be redefined as feature requests
> (and then left open)?
>

Yes, you could do that.  I encourage you to experiment with that
technique on your own projects and let us know how it goes.  If you
report a positive experience, then I will consider trying it on Fossil
and SQLite.

My impression is that I would be troubled by the thousands of open
feature requests that the ticket system would be carrying around.  But
perhaps that is just a personal bias that I need to overcome.

-- 
D. Richard Hipp
d...@sqlite.org
___
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] `unversioned' questions

[j. van den hoff]

On Wed, 27 Jun 2018 17:48:43 +0200, Andy Goth   
wrote:



On 06/27/18 03:50, j. van den hoff wrote:
but doing it via shell commands remains a hack/workaround. fossil  
providing functionality to treat uv-files and tracked files mostly on  
equal footing during ci/co/up/push/pull/sync (considering, of course,  
that there is no history/no deltas for uv-files) would be much better.


You can set the ignore-glob to make Fossil's versioned commands ignore  
the unversioned files.


yes, that's right (in fact, I did that right from the start), but that's  
not the issue. rather, the problem (or missing feature...) is the absence  
of a setting/capability to handle uv-files and tracked files "identical"  
as far as possible regarding sync/update between repository and checkout.  
I've tried to explain in previous mails why I would find that useful.







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] Meta-enhancement

[David Mason]

On 27 June 2018 at 11:16, Richard Hipp  wrote:

> If a feature request comes in via ticket, I can either leave the
> ticket open for some future date when I might implement the idea, or I
> can close it immediately as "not a bug".  If I leave it open, then
> people become alarmed at all the open bugs against Fossil.  If I close
> it right away, people misunderstand that as rejecting the idea.
> Either way, users end up feeling unhappy.
>

Wouldn't it be better if feature requests didn't count as bugs. And if
tickets were marked as bugs, can't they be redefined as feature requests
(and then left open)? (I apologize for not knowing the details)

../Dave
___
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] `unversioned' questions

[Andy Goth]

On 06/27/18 03:50, j. van den hoff wrote:
but doing it via shell commands remains a hack/workaround. fossil 
providing functionality to treat uv-files and tracked files mostly on 
equal footing during ci/co/up/push/pull/sync (considering, of course, 
that there is no history/no deltas for uv-files) would be much better.


You can set the ignore-glob to make Fossil's versioned commands ignore 
the unversioned files.


--
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] Meta-enhancement

[Richard Hipp]

On 6/27/18, Warren Young  wrote:
>
> The problem there is spam.
>

Captchas and requiring moderator approval of wiki edits and new
tickets goes a long way toward fixing the spam problem.

Another more important reason why I turned off anonymous tickets is
that the signal-to-noise ratio was just too low.  An overwhelming
majority of tickets were really support requests and/or new feature
requests.  There were very few actual bugs reported by tickets.

If a feature request comes in via ticket, I can either leave the
ticket open for some future date when I might implement the idea, or I
can close it immediately as "not a bug".  If I leave it open, then
people become alarmed at all the open bugs against Fossil.  If I close
it right away, people misunderstand that as rejecting the idea.
Either way, users end up feeling unhappy.

In my experience, the mailing list is a much better mechanism for
dealing with community input.  Ideas get expressed and debated, but I
am under less pressure to pick sides or to take immediate action on
marginal ideas.  Hopefully the new Forum feature with email
notification might work out even better than the mailing list.
-- 
D. Richard Hipp
d...@sqlite.org
___
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] Meta-enhancement

[Warren Young]

On Tue, Jun 26, 2018 at 10:57 PM, David Mason  wrote:

> we all sell the value of fossil partly because it has a wiki
>

The current wiki is great for evergreen content: information whose lifetime
is independent of that of the software being discussed. Whenever the
documentation must evolve in lockstep with the software it describes, you
should use the embedded documentation feature
 instead.

We could heal this dichotomy if, after saying something like "fossil up
2017-06-05", the wiki as presented by "fossil ui" would show the wiki
documents contemporaneous with that checkout. Then it wouldn't much matter
whether you chose wiki or embedded docs.

and ticket system
>

The problem there is spam.

With the upcoming email and forum features, that problem may be solved by
requiring an email-verified login before someone can create a ticket, so
that it is no longer necessary to have a human gatekeeper on the ticket
tracker.

I'm no better on my personal projects...
>

I am. ;)  I use the wiki and ticket tracker on both public and private
Fossil repos.

No one's spammed my public Fossil ticket tracker yet, but as I recall, it's
set up to require a valid user login to create tickets.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] typos in `fossil help uv'

[j. van den hoff]

patch for `fossil help uv' output:

11,12c11,12

Re: [fossil-users] Markdown in tickets

[Martijn Coppoolse]

On 26-6-2018 22:05, Richard Hipp wrote:
> On 6/26/18, Chad Perrin  wrote:
>> I see no Markdown formatting option for tickets when visiting the web UI
>> via `fossil serve`:
>
> Go to /Admin/Tickets and edit the scripts you find there to provide
> support for markdown.  As the scripts already provide support for
> text/plain, text/html, and text/x-fossil-wiki, it should be apparent
> how to enhance them with an extra case for text/markdown.

Rendering the markdown is not quite that easy: all the existing options
use the "wiki" command, supplied with various incantations of the
 tag. This doesn't appear to work for markdown.

Browsing the source code suggests there is a separate "markdown"
command, but that returns a list instead of actually rendering HTML,
like the wiki command does.

> Once you get this working, submit your changes for inclusion in the
> SQLite source tree.

After some spelunking in th_language.c, here’s what I got working to
render the markdown. Setting the proper mimetype and including it as an
option is left as an exercise for the reader.

(...)
 if {$mutype eq "Markdown"} {
   set md [string trimright $icomment]
   set md [markdown $md]
   set title [lindex $md 0]
   set body [lindex $md 1]
   html ""
   html $title
   html ""
   html $body
} elseif {$mutype eq "Wiki"} {
(...)

I’d never written TH1 (or Tcl) before, so it can probably be improved
upon — most notably skipping the  if the title is empty, which will
usually be the case in a ticket — but it seems to work OK.

-- 
Martijn Coppoolse
___
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] `unversioned' questions

[j. van den hoff]

On Tue, 26 Jun 2018 18:58:42 +0200, Andy Goth   
wrote:


I think the next project that needs this feature should write a utility  
script for themselves that uses the uv commands to extract files however  
makes sense for them.


well, AFAIAC, I would be happy if fossil would support the equivalent of  
this shell one-liner:


for i in $(fossil uv ls); do fossil uv export $i $i; done

(plus, possibly checking whether there is any need to extract the file(s)  
again (local copy more recent or older than time stamp in the  
`unversioned' table?).


as explained previously, the use case in mind primarily would be a project  
where all uv-files reside somewhere within the checkout.


as an aside: it is really very nice that `fossil uv export' silently  
creates missing target directories (recursively, too) i.e. does something  
like `mkdir -p' implicitly. so the shell command above works even in a  
pristine clone.


but doing it via shell commands remains a hack/workaround. fossil  
providing functionality to treat uv-files and tracked files mostly on  
equal footing during ci/co/up/push/pull/sync (considering, of course, that  
there is no history/no deltas for uv-files) would be much better.


if that collides with the original intent of `uv' (and support of uv-files  
_outside_ of the checkout dir is crucial -- so that it might not be always  
a good idea to "flood" the file system at random places with copies of the  
uv-files), one or two settings controlling the behavior of `uv' related  
stuff still would be possible. in principle at least...



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users