Fossil Forum

Forum
Login

Timeline formatting

(1) By donallen on 2019-01-13 23:25:03

Is there some way to get Fossil to display timelines preserving the newlines that are in the editor buffer at commit time? By default, when displaying timelines, it removes the newlines that separate the individual transactions in a commit, making the record of each commit very hard to read.

/Don Allen

(2) By vor0nwe on 2019-01-14 11:07:07 [link] in reply to 1

You could add the following style rule to your skin’s CSS:

.timelineModernComment {
    white-space: pre-wrap;
}

Unfortunately, this will also add an empty line above and below every comment, because the generated HTML has a line break between the <span> tag and the comment text, and also between the comment text and the closing </span> tag.

(3) By wyoung on 2019-01-14 14:58:24 [link] in reply to 1

A longstanding wish list item is an option to treat comment text as Markdown, which would give the effect you want. Someone just has to want it badly enough to implement it. It shouldn't actually be all that difficult, since all the pieces are already in place. It's just a matter of stringing them together in the right order.

If you find yourself writing essays in the comment box, you might make use of the new timeline feature to create a wiki article attached to a particular checkin. It's only a few weeks old, so you'll have to build from trunk to get it, for now.

Finally, if you're the sort to run their web browser full-screen, try making it no wider than a book page. Books haven't changed much in size since Gutenberg, for a good reason, yet some people run browsers full-screen on monitors bigger than 12", the widest page you're likely to find. It baffles me. The longer the lines of text, the harder it is to read at a given text size and line spacing.

Unfortunately, these two camps fight, so that many web sites won't render properly with reasonably narrow browser window widths, so you'll have to compromise some.

(4) By donallen on 2019-01-15 13:01:35 [link] in reply to 3

Thanks for the responses, but I would note that this is not only an issue with viewing the timeline with a web browser, but also with the 'fossil timeline' command. I simply do not understand why the newlines that were present in the editor when doing a commit are not preserved, which seems completely obvious to me. The current approach makes the timeline extremely hard to read (you have to parse the damned thing mentally to find the comments and the fossil transactions they go with) and no, narrowing the web browser doesn't help, because it doesn't restore the missing newlines, and, of course, has nothing whatsoever to do with the output of 'fossil timeline'.

This is such a serious issue for me, because it interferes with my ability to easily view the history of my commits, which is an important part of why you use a version-management system in the first place, that I'm considering returning to git, which does this correctly.

(5) By drh on 2019-01-15 13:56:21 [link] in reply to 4

I simply do not understand why the newlines that were present in the editor when doing a commit are not preserved, which seems completely obvious to me.

Well, Fossil has been used by many thousands of people for over a decade, and none of those other people seemed to think this was such an obvious requirement, or if they do, they haven't felt the need to complain about it. Perhaps you have a different perspective.

One approach would be for you to try to understand the viewpoint of the existing developers and users of Fossil and why Fossil works as it does, and then patiently explain why you think preserving newlines in comment display would be a compelling new feature, and how this would help make comments easier to read. Fossil is open-source, so you might even suggest some patches. Perhaps you could do a mock-up of the display as you think it ought to appear, so that we could better understand why your approach is an improvement.

Or, you could continue to tell us all how stupid we are for missing something that is so blindingly obvious, hoping that in our embarrassment, we will rush in and fix it for you.

The first approach is probably what will best move us forward. I invite you to follow it.

I'm a little busy working on SQLite today and do not have time to jump in and a new preserve-newlines feature to the timeline display, at least not right this moment. But if you can make an argument in support of this alternative display style, and flesh-out the requirements a little more, I can perhaps get something going later this week. Or if not me, then perhaps one of the other very capable contributors to the project.

What do you say, Don? Are you willing to work with us on this?

(8) By donallen on 2019-01-15 16:53:50 [link] in reply to 5

I'm sorry, but your response really seems like a bit of an over-reaction to what I wrote.

I am not accusing you or anyone else of being stupid. I just think the requirement to display the transaction history in an easily-read per-transaction format is clear (paragraphs and sentences serve the same purpose in written language, for example). I don't pretend to know why you chose not to do this in fossil -- you may have had a very good reason that I don't presume to know. But in any case, I don't attribute it to stupidity. I've known a lot of super-smart people in a long career and not one of them was immune to mistakes.

As for making more of a case for this, I really have nothing to add. The readability argument is the key point and I've already made it.

I'm trying to do a quick little hack (maybe a few lines of sed?) to process the output of the timeline command into something resembling what I need. I can't spend a lot of time on this, but if successful, I'll share it and a sample of its output.

As for contributing a patch, just as sqlite imposes demands on your time, I, too, have demands that I can't ignore. So I'm afraid I can't offer any immediate help.

(19) By anonymous on 2019-01-15 21:57:56 [link] in reply to 5

Here are my requirements for commit messages:

  • 1st field - memorable commit identifier (like versions instead of hashes)
  • 2nd field - commit title
  • 3rd field - commit category (like addition/removal/change/fix)
  • 4th field - commit comment with basic formatting (Markdown is readable in plain-text mode, so new-lines are enough) and line/post/character accurate linking to the wiki/forum/diff

Example commit comment:

Description of commit, reason behind the changes.
Explanation why it was merged from this branch instead of that branch.

List of changes:
- better
- faster
- more secure
- [changed to LibreSSL][@@ foo.bar 48,49-67#10-11,71,117-150 | @@ wiki:libressl#18]
- [made it compatible with LibreSSL][@@ goo.bar 8#7,10-49 | @@ wiki:dependencies]

Accurate linking would be for 3-way (2-way +1 comment) diffing.

I hope you will find this post useful for future development. :)

(7) By anonymous on 2019-01-15 15:17:06 [link] in reply to 4

I too think Fossil should preserve whatever the user enters as-is and then attempts to display it appropriately if requested, however, I also understand the challenges of making a command-line tool do this well with all the rest of the data it has to worry about.  I think Fossil does a pretty good job (and likely others do which is why it hasn't really been changed).  What would you propose?  Here is some formatted text and what it currently looks like after I make the commit comment:

=== 2019-01-15 ===
14:51:03 [7111fc1e0f] *CURRENT* This is a formatted line of text that should
         not be interfered with by Fossil because I like to have my spaces
         and newlines preserved so that when I return to read the comment it
         is in a form that I understand. Got it? (user: joe tags: trunk)
14:49:53 [d52efb8dc8] initial empty check-in (user: joe tags: trunk)
+++ no more data (2) +++

But that is not how I entered it; the newlines are not where I placed them and some spaces have been removed.  Should it be better viewed as the following?

=== 2019-01-15 ===
14:51:03 [7111fc1e0f] *CURRENT*
         This is a formatted  line of text that should not  be interfered with by
         Fossil because I  like to have my spaces and  newlines preserved so that
         when I return to read the comment it is in a form that I understand. Got
         it?
         (user: joe tags: trunk)
14:49:53 [d52efb8dc8] initial empty check-in (user: joe tags: trunk)
+++ no more data (2) +++

The latter no longer fits on a standard sized terminal.  Should it?  Fossil automatically detects the width of the terminal and adjusts white space appropriately so as to avoid lines longer than the terminal.  Maybe it shouldn't do this?

Perhaps a setting would be useful to track the user preference of preserving whitespace?

(9) By donallen on 2019-01-15 16:58:07 [link] in reply to 7

Your example doesn't illustrate the problem. If there are multiple transactions, e.g., EDIT, ADD, etc. in a checkin, the newlines that separate them in the editor buffer during commit are lost. For example<

=== 2019-01-13 ===
23:08:32 [8e00c375be] *CURRENT* Path to levenshtein library now passed as argument. EDITED credit_card_statement_importer/transaction_loader/src/main.rs DELETED haskell.m4 Turn on debug. EDITED makefile Clean up some uses of borrow_mut that were unnecessarily
         complicated, due to my imperfect understanding of its use. EDITED newcash/src/book.rs Clean up comment about use of refcells, which was previously unnecessarily complicated. EDITED newcash/src/main.rs Fix bug in price_edited. Handle a price of zero and a choice
         of changing the quantity correctly. Previously, the division by zero would result in a null quantity, violating a table constraint. EDITED newcash/src/transaction.rs (user: dca tags: trunk)
=

(11) By joeld on 2019-01-15 17:31:02 and edited on 2019-01-15 17:34:51 [link] in reply to 9

With the BIG caveats that

  • what I'm about to say is based on my limited personal experience
  • there's a good chance this was a contrived example purely to illustrate the problem, so maybe the substance of your commit messages doesn't actually represent the way you do your work
  • in general I agree that preserving newlines in the commit messages makes sense (although I don't believe it is ultimately at all important for the reasons below)

That said. Almost every single one of those sentences in your example would have been expected to be a separate commit at most places I have worked. Consider that the reason this issue hasn't come up before now, and is not obvious for most people, is because it's extremely idiosyncratic to make several unrelated edits in a single commit and want to write detailed descriptions of each of them.

The generally accepted best practice is that, even if several files have changed in a single commit, the changes should be related enough that they can be summarized together in a single sentence of not more than 50–72 characters.

In Fossil, if the change requires more detail then you typically open a ticket in the web UI, keep detailed notes there, and refer to that ticket in the commit message. This is the value of having a full SCM system with integrated ticketing versus Git where you are limited to version control and must rely on extra tools/services for full SCM.

Unrelated edits should always be committed separately. Following this principle will result in a much clearer timeline. This is as obvious to me as the newline-preservation issue is to you.

(12) By wyoung on 2019-01-15 17:46:10 [link] in reply to 11

is because it's extremely idiosyncratic to make several unrelated edits in a single commit and want to write detailed descriptions of each of them.

Ding, ding, ding! Correct answer!

Long commit messages are a sign the checkin is trying to do too much. That makes bisects, code reviews, cherrypicks, backports, and ChangeLog construction more difficult than when each checkin has a single well-focused purpose.

On a good productive day, I can expect to make around a dozen checkins. Occasionally, that'll spike into the multiple dozens.

With short checkin messages, format preservation is less important.

Nevertheless, I do occasionally feel the need to write multi-paragraph comments. This usually happens when I've got a single well-focused checkin where the reason for it is nonintuitive.

I think the most recent time this happened to me, I'd spent a couple of hours working out a one-line fix. I was unwilling to just write "Fixes bug [abcd1234]" in the comment field. I had to explain why it fixes it, which required that I write up what those few hours of debugging turned up.

(13) By drh on 2019-01-15 17:49:12 [link] in reply to 12

Perhaps the SVN tradition is different. I dunno. Didn't the OP say he was coming from SVN?

(15) By wyoung on 2019-01-15 17:52:50 [link] in reply to 13

No. I ran my Subversion projects the same way, for many years. It's where I learned the practice.

In a public Subversion-based project I ran, I'd frequently get patches posted to the mailing list doing two or more unrelated things, then I'd either have to be a troll and demand the patch be resubmitted, or break it up myself. Since being a troll usually resulted in silence or abuse, I eventually just started breaking patches up and committing the pieces separately without public complaint.

But oh how I grumbled behind my screen. :)

(16) By donallen on 2019-01-15 18:23:19 [link] in reply to 11

Not that I need to justify the way I work, but I will try to help you understand it. I am retired and working on a personal finance project. I am the sole developer and I therefore I do not need to use the kinds of methods, such as those you suggest, that would be sensible in a workplace (and that I myself required when running software projects) where multiple people are collaborating on a project. So sometimes I include unrelated changes in single commits, because it isn't a problem for me, and you are correct that what I posted is an example of that.

But I do not agree that working the way you suggest reduces the need for preserving formatting. I frequently make related changes to multiple files and commit them immediately, and I think it is essential that the comments and each of the multiple fossil transactions are separated from each other by newlines, just as they appear in the editor during the commit. Again, it's the same readability issue that prompts writer to separate prose into paragraphs.

Even if you went to the extreme of committing changes to files individually, which I don't think makes sense (e.g., makes it difficult to back out a change to multiple files that you discover after the fact has a flaw), I still would want the comments separated visually from the transaction/file description as they appear in the editor buffer during the commit.

So I don't agree with either of you that the need to preserve formatting is as sensitive to the style of interaction with fossil as you think it is.

I would add that preserving the formatting does no harm to those who need or prefer to work as you and wyoung do -- frequent, small commits. So even if you don't think you need it, it does you no harm if you have it. But for those, like me, who can get away with fewer, larger commits, the loss of formatting is a real issue.

(17) By skywalk on 2019-01-15 19:22:46 [link] in reply to 16

vor0nwe posted a workaround, https://fossil-scm.org/forum/forumpost/ed1a173fa9
"You could add the following style rule to your skin’s CSS:
.timelineModernComment {
    white-space: pre-wrap;}"

I use this approach and even modify the timeline display to drop time and dates. It is rare that I or my users need to know such detail. Reduce the noise and transmit the intent of the commits in clear text is my goal. Newlines help clarity.

(18) By wyetr on 2019-01-15 19:53:40 [link] in reply to 16

Not that I need to justify the way I work

If you want someone else to feel your pain acutely enough to make it their pain and thus choose to solve your problem on their time, then yeah, you do have to justify your work habits, since our work habits clearly haven't caused us enough pain to solve your problem for you already.

if you're unwilling to try to generate sympathy — in its literal meaning — you're reduced to demanding that others work for you for free.

You say presenting the comments the way you expect is "essential," but this push-back you're getting should tell you that we are very far from the essence of the correct approach. We're deep into personal preference territory, which is a good sign that the solution either doesn't belong in Fossil core or it needs to be optional.

I frequently make related changes to multiple files and commit them immediately, and I think it is essential that the comments and each of the multiple fossil transactions are separated from each other by newlines

A cohesive change shouldn't take multiple paragraphs to describe, most of the time, regardless of whether it touches multiple files or not.

Checkin comments should be at a higher level than the code they describe, so as a rule, the description should be shorter than the code. Otherwise, you're probably just paraphrasing the code.

The exceptions are those rare cases where the checkin is highly non-obvious. And there, I usually prefer to put the explanation in a code comment rather than a commit message, which you can format as you like.

the loss of formatting is a real issue.

So add the CSS customization that's been mentioned twice now.

If that doesn't work for you, you'll at least have something to point at to say why it doesn't work.

(20) By donallen on 2019-01-15 22:36:11 [link] in reply to 18

You use the word "demand". I defy you to find that word in any of my posts. fossil is an open source project, made available through the goodness of the developers' hearts. I'm trying to convince them that this is a design mistake they should fix. If they do, they do, If they don't, they don't. I can go back to git, which does this right, in my opinion, or I can fix it after-the-fact with sed. But, I repeat, for your benefit, I am demanding nothing from anybody.

"A cohesive change shouldn't take multiple paragraphs to describe, ...". Did you read my posts? Not clear that you did. I am arguing that per-transaction comments should be separated from the description of the transaction and that the transactions should be separated from each other, exactly as they are in editor buffers during commit. This has nothing to do with lengthy tomes. Useful information is being thrown on the floor between commit time and timeline time. I think that should not be the case.

As for the CSS fix -- does it fix the format of 'fossil timeline'?

(21) By mgagnon on 2019-01-15 22:56:18 [link] in reply to 20

... or I can fix it after-the-fact with sed

Just out of curiosity, how can you fix it using sed, when the output of "fossil timeline" strip the original newline from the commit message.

Are you planning to parse the output of "fossil sql ..." to get the original commit message ?

(22) By anonymous on 2019-01-15 23:13:26 [link] in reply to 20

Well, I think Don gave enough good arguments that at least the optional option for keeping the formatting as it is might be an improvement.

Changing the default that is established since years now (as DRH pointed out) might bring other problems, but Don convinced me that there are good reasons for potential display of "raw commit comments".

This might be useful for the commandline usage (aka 'fossil timeline') and for the web display as well.

At least for the web display formatting of markdown as wyoung suggested might be another perfect improvement. Markdown is everywhere nowadays, also in fossil - so formatting commit comments nicely with markdown will be a real plus.

What about
'fossil commit -M <file> -type xxx' where xxx specifies the content.

OH WAIT!

My fossil here has that?!

See fossil commit --help:

   [...]
   -M|--message-file FILE     read the commit comment from given file
   --mimetype MIMETYPE        mimetype of check-in comment
   [...]

What is that --mimetype for? Maybe text/plain, text/markdown or similar will do the job?

Maybe this '--mimetype' is what Don is looking for? I see it for the first time today ... does this affect the display lateron? It should, or?

(30) By anonymous on 2019-01-16 15:09:50 [link] in reply to 18

> We're deep into personal preference territory,

I disagree.  Preserving data is what a DVCS is supposed to do.  This includes preserving the commit log.  If the user enters it in a certain way, Fossil ought to be able to display it back the way the user entered it.  If it doesn't do so by default, that's alright.  Even the venerable RCS had this ability; notice how cleanly it preserves my commit log:

$ rlog test.txt 

RCS file: test.txt,v
Working file: test.txt
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;     selected revisions: 3
description:
File to test RCS logs.
----------------------------
revision 1.3
date: 2019/01/16 15:08:17;  author: joe;  state: Exp;  lines: +1 -0;
COMMENT: This is a really long  comment that has special formatting that
I don't want  Fossil to alter when it displays.  It should have multiple
newlines that separate paragraphs, and multiple distinct actions.

EDIT: It  should continue to  display things in  the way that  I entered
them, though, I'm not sure how that will look.

----------------------------

(34) By stephan on 2019-01-16 16:18:29 [link] in reply to 30

We're deep into personal preference territory,

I disagree. Preserving data is what a DVCS is supposed to do. This includes preserving the commit log.

Fossil preserves the input faithfully, it just doesn't render it how the OP would prefer it to be rendered. As proof that it faithfully stores the data as-is, try:

fossil artifact COMMIT-ID | grep '^C '

The result will be a "fossilized" copy of that checkin's commit message, with spaces represented by \s and newlines by \n (those escape constructs are part of the "fossilized" encoding format). That's exactly what the user enters for the commit message except that leading and trailing spaces might (i don't recall for certain) be stripped.

So, indeed, we're in "personal preference territory" - how to render what the user entered and fossil faithfully recorded. As Richard mentioned, in 11 years of fossil, nobody's been annoyed enough by the existing behaviour to change it (other than console-side wrapping and space-collapsing).

(35) By ddevienne on 2019-01-16 16:50:40 [link] in reply to 34

I do not think this is "personal preference" at all, FWIW.

The UI, be it command-line or web, should allow to see the commit message "verbatim" in one way or another. And all this talk about whether messages should be paragraph(s) or 1-liner are completely off-topic IMHO.

The fact such a request comes only after 11 years does amaze me as well.

But I'm not sure at all it paints the OP's request in a bad light, or suggests it is somehow an "esoteric" or "unusual" feature, but rather suggests to me Fossil remains a very niche tool, not in widespread use. Otherwise this would have been requested long ago IMHO.

(36) By mgagnon on 2019-01-16 17:30:57 [link] in reply to 35

The fact such a request comes only after 11 years does amaze me as well.

Actually, there was some request before on the old mailing list.

Example:

I guess it never been a very high priority.

(37) By anonymous on 2019-01-16 18:19:15 [link] in reply to 36

It is wonderful that the -comfmtflags flag has been found. I understand that it affects the output of the commit message.

Somewhere above 'anonymous' found that on the input side there is the "--mimetype MIMETYPE mimetype of check-in comment" flag for 'fossil commit'.

What is this mimetype for? How does this affect the potential display?

(39) By anonymous on 2019-01-16 19:51:03 [link] in reply to 35

> The fact such a request comes only after 11 years does amaze me as well.

If you look through the mailing list archives you'll find people who have requested this, or been surprised by it.  It just happens that this particular thread has more adamant opinions in it than previously---perhaps a sign of a growing community?

(40) By anonymous on 2019-01-16 20:04:07 [link] in reply to 34

> Said Stephan
> Fossil preserves the input faithfully,

Sometimes it preserves, sometimes it does not.  For example, using interactive commits, Fossil discards some data, specifically any trailing newlines:

$ export EDITOR="ed -s"            
$ echo $RANDOM > file              
$ fossil ci                        
ed -s "./ci-comment-8B57A2D23DCB.txt"
a
TRAILING NEWLINES?

.
w
q
New_Version: a4fd50ebe84d9a6e8f07c19c79fab370d319f782e67177129d7a3bbc41582173
$ f art a4fd50ebe84d | grep '^C '
C TRAILING\sNEWLINES?

But if I use the -M option it does not:

$ cat /tmp/message.txt 
TRAILING NEWLINES?

$ hexdump -C /tmp/message.txt 
00000000  54 52 41 49 4c 49 4e 47  20 4e 45 57 4c 49 4e 45  |TRAILING NEWLINE|
00000010  53 3f 0a 0a                                       |S?..|
00000014
$ echo $RANDOM > file            
$ fossil ci -M /tmp/message.txt 
New_Version: 4ac595c28b7bed3b45d085239d4c24cb72c43b44a555f1a9ab645ecf48c4367b
$ fossil art 4ac595c28b | grep '^C '
C TRAILING\sNEWLINES?\n\n

So, I guess there does exist a bug which trims off trailing newlines (and maybe even whitespace) when using the interactive comment editor.

(31) By anonymous on 2019-01-16 15:22:50 [link] in reply to 16

> From donallen:
>
> So even if you don't think you need it, it does you no harm if you have it.

An undocumented feature was recently rediscovered that preserves your commit log.  Have you tried it yet?

fossil timeline -comfmtflags 16

Is it sufficient?

(27) By anonymous on 2019-01-16 14:20:50 [link] in reply to 9

> Your example doesn't illustrate the problem.

Actually, I think it illustrates it quite accurately, though perhaps more subtly than your example.  For example, in my example there are intentionally placed multiple white spaces and intentionally placed newlines.  The only thing I didn't have is multiple newlines separating paragraphs, however, if Fossil did not mangle my example, it would also not mangle multiple newlines between paragraphs.

(25) By mgagnon on 2019-01-16 03:35:22 and edited on 2019-01-16 03:50:44 [link] in reply to 4

... but also with the 'fossil timeline' command.

While looking at the CLI timeline code, I found an undocumented option that might do the job: The "-comfmtflags" option give some control on how the comment are displayed.

To keep the newline, the COMMENT_PRINT_ORIG_BREAK (0x10) flag should do what you want.

Just try it like this:

    fossil timeline -comfmtflags 0x10

Description in the source code:

  • https://fossil-scm.org/fossil/artifact?udc=1&ln=464-467&name=e97f8902b57cbce6

If this flag does what you want, it would be easy to add a simple command line option to the timeline command.

EDIT: Actually, thanks to the anonymous simulaneous post on this thread, using COMMENT_PRINT_NONE (0x0) or COMMENT_PRINT_LEGACY (0x1) gave same result for the few test I made.

(26) By ddumitriu on 2019-01-16 10:43:40 [link] in reply to 25

Actually, when given on the command line, the flags should be in decimal rather that hexadecimal. It also seems like COMMENT_PRINT_WORD_BREAK works better, so the command would be:

    fossil timeline -comfmtflags 8

You can also try with 16 or 24 and see what suits you better.

As a remark, passing any "0x.." to the underlying atoi() would pass on 0 as flags, which results in COMMENT_PRINT_NONE and is seemingly similar to COMMENT_PRINT_ORIG_BREAK.

While we are at it, it would be nice to have a setting for this, e.g. comment-format.

(33) By mgagnon on 2019-01-16 15:55:32 [link] in reply to 26

Actually, when given on the command line, the flags should be in decimal rather that hexadecimal

Yeah, my bad. That's explains why I didn't see any difference between 0x0, 0x1 and 0x10.

I normally use strtoul(...) with base param set to 0 to detect the radix automatically. I didn't realize atoi(...) was used here.

(28) By anonymous on 2019-01-16 14:55:56 [link] in reply to 25

> To keep the newline, the COMMENT_PRINT_ORIG_BREAK (0x10) flag should do what you want.

This actually does work as I would expect, however, it didn't work using a hex value, presumably because it scanned the 0 from the 0x10:

$ fossil time -comfmtflags 16  
=== 2019-01-16 ===
14:49:50 [c13da2c90e] 
         Edit [56625eb79e32bf89|56625eb79e]: Edit check-in comment. (user: joe)
14:49:07 [56625eb79e] *CURRENT* 
         COMMENT: This is a really long  comment that has special formatting that
         I don't want  Fossil to alter when it displays.  It should have multiple
         newlines that separate paragraphs, and multiple distinct actions.
         
         EDIT: It  should continue to  display things in  the way that  I entered
         them, though, I'm not sure how that will look. (user: joe tags: trunk)
14:47:48 [b9841704f5] 
         initial empty check-in (user: joe tags: trunk)
+++ no more data (3) +++

So it sounds like the OP has a way to display after all.

(6) By anonymous on 2019-01-15 15:00:35 [link] in reply to 3

> Finally, if you're the sort to run their web browser full-screen, try
> making it  no wider than a book page. ... The longer the lines of text,
> the harder it is to read at a given text size and  line spacing.

Funny that you should say that.  I intentionally choose to run my browser at about half-screen for just the very reasons that you mention.  I constantly run into problems with websites that are designed to be viewed full-screen and when I report problems they tell me to make my browser bigger, or reduce the font-size so the page becomes unreadable.

(14) By wyoung on 2019-01-15 17:49:40 [link] in reply to 6

Point them at web sites like the one I linked in my prior post. There's hard-and-fast human factors research behind all of this. Books haven't changed size all that much in 500 years because humans haven't changed all that much in the same time.

Large computer screens are for having at least two vertical windows up side-by-side, each about the width of a piece of office paper, at widest.

(23) By anonymous on 2019-01-16 03:09:24 [link] in reply to 1

Irrelevant of any particular developers opinions, I believe the sought after effect can be found by appending the (undocumented?) 'comfmtflags' parameter to the timeline command (using any other value then '1' to use the "new" comment format function). Applicable values [for the parameter] can be found examining the file 'src/comformat.c' respectfully.

e.g.

# fossil timeline -comfmtflags 0

(29) By anonymous on 2019-01-16 15:02:04 [link] in reply to 23

> fossil timeline -comfmtflags 0

Actually, I think -comfmtflags 16 is more readable and more accurate because it stuffs the commit log after the timeline date and hash.  The only thing I wish it would do better is put the (user: blah tags: blah) information on a line by itself instead of mangling the original output.

(32) By veedeehjay on 2019-01-16 15:23:06 [link] in reply to 23

as far as I can see, '-comfmtflags' is really not documented. I think this should be fixed, it might be useful for some people to know about it (personally, I was not aware of it at all, but probably have no real use for it either).

another thought: accepting that the flag makes sense and might get more usage (and yes: a setting controling the default would also be good to have), maybe one should change the name to something more compact (maybe even provide a one letter short option, too).

(38) By anonymous on 2019-01-16 19:50:00 [link] in reply to 32

It would also be great if one could save the desired '-comfmtflags' as per-repository setting.

(42) By ddumitriu on 2019-01-17 16:47:46 [link] in reply to 38

Trying to patch (against [8cb1b231], see below) the code to provide a comment-format configuration option and makes use of it for the timeline command, I've discovered a small problem with the flags: g.comFmtFlags is filled upon parsing commmand line arguments, that is, before opening any repository (according to a comment, probably to ensure that all global flag fields are initialized) and having the chance to read configuration options. That leaves us two options (I chose the second one):

  • open the repository directly in main(), read the option, then possibly close it, which seems momentarily overkill but has the advantage of allowing to read the option in one place and use it then in several
  • read the comment-format option in every function that makes use of the comment formatting flags

Can someone with a deeper knowledge of fossil's code (drh?) tell us which approach is better?


Index: src/db.c
==================================================================
--- src/db.c
+++ src/db.c
@@ -0,0 +3111,4 @@
+/*
+** SETTING: comment-format       width=16 default=1
+** Sets comfmtflags, the comment formatting flags
+*/

Index: src/timeline.c
==================================================================
--- src/timeline.c
+++ src/timeline.c
@@ -0,0 +2582,1 @@
+  g.comFmtFlags = db_get_int("comment-format", COMMENT_PRINT_DEFAULT);

(43) By stephan on 2019-01-17 17:06:42 [link] in reply to 42

Here's my 2 cents:

1) Don't open the repo in main(). Instead, initialize g.comFmtFlags in main() to -1.

2) All routines which use g.comFmtFlags could be adapted to instead do:

    int const fmtFlags = fossil_get_fmt_flags();

Where fossil_get_fmt_flags() does something like:

    if(g.comFmtFlags<0) { g.comFmtFlags = 0; get the flags from wherever ... }
    return g.comFmtFlags;

In the end, the only references to g.comFmtFlags would be in main(), where it's initialized, and in fossil_get_fmt_flags(), where it's populated.

(44) By florian.balmer on 2019-01-18 08:36:42 [link] in reply to 43

And, my 2 cents:

In Fossil, command-line options usually allow overriding per-repository settings.

So fossil_get_fmt_flags() should only query the repository database config table if the setting was not yet initialized through the command-line option.

(46) By ddumitriu on 2019-01-28 11:42:08 [link] in reply to 44

Thanks for the change, Richard. I was just going to submit my patch but still wondering whether it is better to read the option once, so you beat me to it. :-)

(41) By florian.balmer on 2019-01-17 09:02:11 [link] in reply to 32

as far as I can see, '-comfmtflags' is really not documented.

It's documented here:

Environment Variables and Global Options

By the way, this is a very handy document, with a lot of other useful information.

(45) By florian.balmer on 2019-01-18 16:32:27 [link] in reply to 41

There's also:

fossil help --options

Summarize command-line options common to all commands.