Re: [fossil-users] Suggestion: WIKI command EXPORT clean of tags

[Warren Young]

On Jun 28, 2017, at 7:57 AM, Tony Papadimitriou  wrote:
> 
> However, these formatting tags are displayed cluttering the display (for some 
> heavily formatted pages to the point of being unreadable).

Why not use Markdown formatting then?  The same source file that produces 
pretty HTML is generally usable as plain text as well.

> With the filter, a cleaner view:

It feels like a violation of a separation of concerns boundary to me.

Fossil does already blur this line, doing transforms from the native data 
format (e.g. Markdown, Fossil Wiki, etc.) to HTML, but I don’t see that as a 
good reason why it should support an arbitrary number of other transforms.  
Where’s the limit?

HTML is special because the web is special.  No other output format has that 
same level of privilege.

Plain text has a different order of privilege from HTML.  Information should be 
stored in Fossil in the most universal form, then transformed at the end user’s 
computer as needed.

I view your problem as similar to storing C source code in Fossil in a Word 
document.  If you sometimes want plain C code and sometimes want a Word doc, 
store the file in plain C form and transform it into Word as needed, not the 
other way around.

> I currently use a Lua script to do this cleaning

You’ve reinvented a perfectly good wheel here.  Allow me to demonstrate it 
using Fossil’s own repo:

 $ f wiki exp 'To Do List' | pandoc -f mediawiki -t plain

This is what I mean by “separation of concerns:” use a tool like Pandoc when 
you want to transform markup formats.  Fossil should provide the untouched 
original or an HTML rendering, and that’s it.  Leave everything else up to 
format translators.

Pandoc also supports Markdown input and output, so you could strip even most of 
the Markdown formatting, if you wanted.

> However, if there are tags inside a  ...  they should 
> remain visible.

Yet another reason to leave this to specialist tools like Pandoc, in my view.
___
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] Obey ci=ckout in /file URLs

[Stephan Beal]

On Thu, Jun 29, 2017 at 7:07 PM, Warren Young  wrote:

> A URL of the form /file/NAME?ci=ckout should work the same under Fossil UI
> as /doc/ckout/NAME.
>
> I ask because I was working with a /file URL, then wanted to see the
> checkout version of the file instead of the repo version.  I spent quite a
> while fighting with it before I gave up and rewrote it as an embedded doc
> URL.
>
> This request is thus about orthogonality rather than about which URL type
> is better.  The ckout concept should work everywhere it makes sense.


i like it, but it sounds like there's a _potential_ data leak case there
which would need to be accounted for:

/file//etc/hosts?ci=ckout
or:
/file/.fslckout?ci=ckout

A blanket rejection of serving files outside the checkout (or
fossil-internal files like .fslckout) is ostensibly fine... until someone
wants to symlink to stuff outside of their checkout, which they're
presumably expect to work.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] advice on managing language specific branches

[Warren Young]

On Jun 28, 2017, at 1:39 AM, Luca Ferrari  wrote:
> 
> Now I have to maintain the same application on two different language
> versions, php 5 and 7. I created a LANG_5 and LANG_7 branch and work
> as usual.
> But what about common branches? Let's say I develop a  common feature
> that could run on both, at the time I merge into both the above, but
> I'm pretty sure there's a smarter way.

The “common branch” is called “trunk”.

I don’t mean to be glib: I am suggesting that you drop your LANG_7 branch and 
develop everything on trunk for the latest version of PHP you are supporting, 
then conditionally backport changes to the LANG_5 branch where that’s 
appropriate.

I would actually name the LANG_5 branch after your application’s version 
numbering scheme, not after the associated PHP version.

For example, if your system was developed to its version 3.x under PHP 5, then 
you started developing v4.0 of your system for PHP 7 and up, I’d create a “v3” 
major branch just prior to the point where the trunk started to contain v4+ 
features.  v4 is then developed on the trunk, with backports to the v3 major 
branch at need.

When you start work on v5, you create a v4 branch and continue as before, even 
if you don’t change PHP versions.

The point is that branches and version numbers in Fossil should refer to your 
system, not to the versions of the software stack it is based on.  You should 
be able to rewrite your whole app in another language and still keep the same 
version numbering scheme.
___
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] Suggestion: WIKI command EXPORT clean of tags

[Ron W]

On Thu, Jun 29, 2017 at 8:00 AM, 
wrote:
>
> Date: Wed, 28 Jun 2017 16:57:29 +0300
> From: "Tony Papadimitriou" 
> Subject: [fossil-users] Suggestion: WIKI command EXPORT clean of tags
>
> I use Wiki a lot for keeping short notes/memos about pretty much anything
> related to the host repo.
> For cosmetic purposes when viewing from a Web browser these notes often
> contain  ...  or other such formatting tags.
>
> However, doing most programming from the command-line, when I want to
> quickly look up some notes, I often do (f=fossil):
>
> f wik exp PAGENAME
>
> to get the related note displayed on the console screen.
>
> However, these formatting tags are displayed cluttering the display (for
> some heavily formatted pages to the point of being unreadable).
>
> My suggestion is when ‘wiki export’ command is used without the optional
> file (which would save wiki page to a file, as is), and the console is the
> target to filter out all those formatting tags.
>

"fossil wiki export" outputs the "raw" content of the wiki page, which
seems reasonable, And, when the page contains only wiki mark-up, is very
readable.

Maybe an option to strip HTML, but I would not change the current default
behavior.

Also, from the command line, I sometimes use the lynx web browser, which is
text only. I have a bash macro, so I can type:

fw page+name

The macro is defined as:

fw() { lynx -dump "http://localhost:8080/wiki?name=$1; | less }

The only downside to this macro is needing to type + instead of spaces when
a page name has spaces. (Though, I'm old enough that my first use of a wiki
was with one that used the old "WikiWord" convention for naming pages, so I
tend to name wiki pages in that style.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Linker warnings with VS2015

[Daniel Dumitriu]

Hi,

This does not look to be a problem with serious consequences, but if one
wants to have a completely clean build, it might be interesting to
investigate this further. When compiling version 048738b28 with VS2015 I
get two "locally defined" linking warnings coming from zlib:

zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _free
imported in function _zcfree
zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _malloc
imported in function _zcalloc

After googling it [1], it looks like this is due to mismatch between
zlib and fossil compiler options for runtime selection (static
multi-threaded vs. dynamic). Indeed zlib.lib is compiled with -MD (line
29 in compat\zlib\win32\Makefile.msc) and fossil static with -MT (line
235 in win\Makefile.msc). Compiling zlib with -MT eliminates the
warnings, neverless when doing this from the fossil Makefile (by adding
`LOC=-MT' in line 677) one gets another VS warning about overriding
options (which cannot be disabled).

I am not an expert, what could be a clean solution here (without
touching zlib's Makefile)?

Best regards,
Daniel

[1] https://stackoverflow.com/a/6979586
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users