Re: [fossil-users] Timeline questions

[Warren Young]

On Nov 25, 2015, at 5:16 PM, Abilio Marques  wrote:
> 
> When using git, you're suggested to write comments in the form of:
> 
> Subject Line (recommended as short, 50 to 75 characters long single line)
> 
> Description (whatever you want to put here)

That feature annoys me, FWIW.  Checkin comments give you a way to summarize the 
content of the checkin, but Git wants you to do that, and then summarize the 
summary.  Grrr.

> Fossil lets you add a multi-line comment, by making fossil ci, without 
> passing the -m parameter. It then proceeds to store the newlines in the 
> database, but then the newlines are not displayed.

There is a setting that is supposed to control this, but it doesn’t seem to 
work correctly, or at least, not as I expect it to.

   Admin > Timeline > Allow block-markup in timeline

My understanding is that enabling that setting is supposed to make it continue 
to treat single newlines as soft line breaks, but to treat a double newline as 
a paragraph break.  (Markdown rules, basically.)

Toggling that setting doesn’t change the generated HTML for a two-paragraph 
checkin comment I’m looking at right now with a near tip-of-trunk Fossil 
instance.  ([aa92270fe9])

> Am I missing something from the settings or something that can produce those 
> results?

Would the “Markdown rules” behavior do what you want, or do you really want to 
do summaries of summaries?
___
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] Timeline questions

[Stephan Beal]

On Thu, Nov 26, 2015 at 1:16 AM, Abilio Marques  wrote:

> Fossil lets you add a multi-line comment, by making fossil ci, without
> passing the -m parameter. It then proceeds to store the newlines in the
> database, but then the newlines are not displayed.
>
> I've been trying to do this at least on the fossil web server timeline
> results, but my knowledge of CSS is limited, and even so, I believe it
> would be an ugly CSS patch.
>

IIRC, the solution is to add this to your CSS:

.timelineComment {
  white-space: pre
}

See:
http://www.w3schools.com/cssref/pr_text_white-space.asp


> I believe having the flexibility of making more verbose descriptions while
> keeping the subject line clean is a "best practice" that could be useful.
> Am I wrong about that?
>

Philosophical questions don't have right or wrong answers, and how to
format commit messages is such a question :/. (FWIW, i believe fossil
should always display (in CLI mode) exactly what was input, without any
sort of reformatting.)


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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] Timeline questions

[Abilio Marques]

>
> ​​
> ...​
> ​
>  i believe fossil should always display (in CLI mode) exactly what was
> input, without any sort of reformatting.)


But actually that's not the case. Fossil doesn't show at least newlines
(making a long comment a huge blob).
​


Yeah, I tried the css trick
​ early yesterday​
, but then I learned the hard way that span items can't take many
properties as a
​block element can
, so I wasn't able to get any hide and show when hover trick to work
​. That's why I ended up doing it in javascript, so it shows only the
title, and when you hover with the mouse, it shows the rest (see the
example at
http://abiliojr.homenet.org:20003/cleantimeline/timeline)



>
___
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] Timeline questions

[Stephan Beal]

On Thu, Nov 26, 2015 at 1:47 PM, Abilio Marques  wrote:

> ​​
>> ...​
>> ​
>>  i believe fossil should always display (in CLI mode) exactly what was
>> input, without any sort of reformatting.)
>
>
> But actually that's not the case. Fossil doesn't show at least newlines
> (making a long comment a huge blob).
> ​
>

My phrasing was unfortunately ambiguous. You're correct: fossil does
reformat. My intended meaning was, "if i had my way, fossil would not do
that." (But i believe i'm in the minority on that opinion. ;)


> Yeah, I tried the css trick
> ​ early yesterday​
> , but then I learned the hard way that span items can't take many
> properties as a
> ​block element can
> , so I wasn't able to get any hide and show when hover trick to work
> ​. That's why I ended up doing it in javascript, so it shows only the
> title, and when you hover with the mouse, it shows the rest (see the
> example at
> http://abiliojr.homenet.org:20003/cleantimeline/timeline)
>

A SPAN is not a block element, but perhaps we should consider making the
comment lines DIVs instead (since DIVs are block elements)?

Another option: you can convert a timelineComment span to a block element
with CSS:

span.timelineComment {
  display: block
}

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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] Timeline questions

[bch]

On Nov 26, 2015 5:11 AM, "Stephan Beal"  wrote:
>
> On Thu, Nov 26, 2015 at 1:47 PM, Abilio Marques 
wrote:
>>>
>>> ​​
>>> ...​
>>> ​
>>>  i believe fossil should always display (in CLI mode) exactly what was
input, without any sort of reformatting.)
>>
>>
>> But actually that's not the case. Fossil doesn't show at least newlines
(making a long comment a huge blob).
>> ​
>
>
> My phrasing was unfortunately ambiguous. You're correct: fossil does
reformat. My intended meaning was, "if i had my way, fossil would not do
that." (But i believe i'm in the minority on that opinion. ;)

I *think* git reads first content to newline for display of short synopsis
by default, and will print the long form by demanding it. *I* think that
would be ideal. Example:

"Fixes [cafebabe] formatting error for timeline. Shows by default (keep
this short).

This is the long form, and not displayed by default in listing (CLI or
web). Here we describe the challenges and steps, maybe appropriate hints
for this, etc. Examples or code samples would be appropriate here."

So, for the default short display, it *could* conceivably be fine to format
for width (by wrapping), since it's not multi-line anyway - you're not
breaking user-provided multi-line formatting here because we're only
dealing w one line.

-bch

>>
>> Yeah, I tried the css trick
>> ​ early yesterday​
>> , but then I learned the hard way that span items can't take many
properties as a
>> ​block element can
>> , so I wasn't able to get any hide and show when hover trick to work
>> ​. That's why I ended up doing it in javascript, so it shows only the
title, and when you hover with the mouse, it shows the rest (see the
example at
>> http://abiliojr.homenet.org:20003/cleantimeline/timeline)
>
>
> A SPAN is not a block element, but perhaps we should consider making the
comment lines DIVs instead (since DIVs are block elements)?
>
> Another option: you can convert a timelineComment span to a block element
with CSS:
>
> span.timelineComment {
>   display: block
> }
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "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
>
___
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] Timeline questions

[Abilio Marques]

Here is a trivial working example of what I mean:
http://abiliojr.homenet.org:20003/cleantimeline/timeline

If you see carefully there are some commits with ellipsis at the end,
hovering with the mouse over the comment of that commit, you'll see the
full comment as a tooltip.

This was ugly done by introducing the following javascript quick and dirty
hack on the footer:

​
> 

var comments = document.getElementsByClassName("timelineComment");

var i;

for (i = 0; i < comments.length; i++) {

  var fullText = comments[i].textContent.trim();

  var description = "";

  var descriptionStart = fullText.search('\n');

  if (descriptionStart !== -1) {

comments[i].setAttribute('title', fullText);

comments[i].textContent = fullText.split('\n', 1)[0] + '...';

  }

}




​Needs to be done in a cleaner way. Also, the tooltip can be drawn in a
more beautiful way (e.g., http://www.menucool.com/tooltip/css-tooltip)​


Can anyone else see the usefulness of this idea (if also available in the
command line)?

On Wed, Nov 25, 2015 at 7:46 PM, Abilio Marques  wrote:

> I know, I know, here we go again looking to git, but this is a question
> concerning clean comments on commits.
>
> When using git, you're suggested to write comments in the form of:
>
> Subject Line (recommended as short, 50 to 75 characters long single line)
>
> Description (whatever you want to put here)
>
>
>
> Then you can do git log (and get the timeline with all the descriptions
> included, keeping the newlines visible), or git log --oneline, to print
> just the subject.
>
>
> Fossil lets you add a multi-line comment, by making fossil ci, without
> passing the -m parameter. It then proceeds to store the newlines in the
> database, but then the newlines are not displayed.
>
> I've been trying to do this at least on the fossil web server timeline
> results, but my knowledge of CSS is limited, and even so, I believe it
> would be an ugly CSS patch.
>
> I believe having the flexibility of making more verbose descriptions while
> keeping the subject line clean is a "best practice" that could be useful.
> Am I wrong about that?
>
> Am I missing something from the settings or something that can produce
> those results?
>
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users