Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Andy Bradford]

Thus said Warren Young on Mon, 27 Mar 2017 10:21:42 -0600:

> Explain to me how someone deciding between Fossil and Git gets down to
> automatic pagination  as the  key differentiator,  the one  that seals
> their decision.

While it may not be used as a determining factor in deciding between Git
and Fossil, it most certainly is  a confusing factor for people who have
never used a pager before. I cannot  recall how many times I have had to
tell people that to exit the pager they can press q. Or how many times I
have had to tell  them that they cannot use the  mouse to scroll through
the output  because the pager  doesn't work that  way. Or how  to search
through the output because ctrl-f doesn't work, etc.

Andy
-- 
TAI64 timestamp: 400058d9c0c2


___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Martin S. Weber]

On 03/27/17 01:55, Roy Marples wrote:
Pager output disappearing with the pager (I assume when asking the 
pager to exit) is an issue with the pager.


I disagree. Disappearing output uses the "alternate screen" of a 
terminal so that the pager's output does not interfere with your 
non-reading session. It most certainly is a feature, and one with a long 
history to lean on as well.


Regards,
-Martin
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Warren Young]

On Mar 27, 2017, at 10:19 AM, Martin S. Weber  wrote:
> 
> On 03/27/17 01:55, Roy Marples wrote:
>> Pager output disappearing with the pager (I assume when asking the pager to 
>> exit) is an issue with the pager.
> 
> I disagree. Disappearing output uses the "alternate screen" of a terminal so 
> that the pager's output does not interfere with your non-reading session. It 
> most certainly is a feature, and one with a long history to lean on as well.

Not all terminal/pager/OS combos do this correctly.  Thus this Super User post:

https://superuser.com/questions/106637

As far as Fossil goes, though, this issue is not relevant.  If you want to use 
a pager, point Fossil at a decent one, configure the pager correctly, and run 
it under a reasonable terminal program.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Warren Young]

On Mar 26, 2017, at 11:49 AM, Tomasz Konojacki  wrote:
> 
> On Sun, 26 Mar 2017 19:25:25 +0200
> Christophe Gouiran  wrote:
> 
>> I see that most of you complain about this proposed feature.
> 
> TBH, many members of this list live in the UNIX greybeard bubble, and
> that's why there is so much opposition to this feature. They're used to
> the original UNIX way and they have different expectations than most of
> users.

Unix greybeard here: I like automatic pagination, and I expect to use this 
feature if it manages to land in a Fossil release.

Be careful how you swing that broad brush around, you might hit someone.

Automatic pagination comes out of the Unix greybeard world.  As suggested 
up-thread, it was done during the transition from paper teletypes to glass ttys 
without scrollback buffers in the mid to late 1970s, since in that new world 
you couldn’t:

a) read the output in real time as it printed at 110 bps on your Teletype Model 
33 ASR, since glass terminals generally ran at least 10x faster, too fast for a 
human to read in real time; or

b) lift the continuous-feed paper up and read what the computer printed 
previously

Although the original Unix man pages were ruthlessly edited and features culled 
and consolidated to keep man pages to a single printed page, that’s still about 
twice as many lines as allowed on a glass tty of the day.  It was also about 
this time that man pages started to creep beyond single printed pages.

Unix greybeards invented automatic pagination, by necessity.

> there is *nothing* nice about
> fossil dumping thousands of lines to the terminal.

As you’ve seen, that’s debatable.  I happen to fall on your side, but I can see 
the point of those who prefer to just use the terminal scrollback feature or 
manual pipe-thru-pager.

> In fact, I think it scares off newbies who only used git before.

Explain to me how someone deciding between Fossil and Git gets down to 
automatic pagination as the key differentiator, the one that seals their 
decision.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[John P. Rouillard]

Hi all:

In message <787dd2f8-edf8-4caf-5d8c-b63cac39a...@marples.name>,
Roy Marples writes:
>On 26/03/2017 22:19, Joerg Sonnenberger wrote:
>> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
>>> For someone with a different background, there is *nothing* nice about
>>> fossil dumping thousands of lines to the terminal. In fact, I think it
>>> scares off newbies who only used git before.
>>
>> I quite disagree. Terminal output is C friendly. Pager output tends to
>> disappear with the pager. That's a real world UX issue I have with the
>> git default settings.
>
>Pager output disappearing with the pager (I assume when asking the pager 
>to exit) is an issue with the pager.
>
>As Fossil is a single binary to do everything approach, I'm sure that a 
>Fossil pager would not suffer this defect.

IIRC the patch is using an external pager right? There is not a pager
being build into fossil.

>Yes, terminals have scroll bars and can page up, but that's the wrong 
>approach as well.
>
>When viewing a diff I want to start at the top and scroll down, not 
>start at the bottom and scroll up, hence a pager makes perfect sense.

As long as it can be turned off so wrappers around fossil (fsl, emacs
vc mode, other programs using the cli as a fossil interface) are not
broken if terminal detection fails, I'm meh about it.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.


On 26/03/2017 22:19, Joerg Sonnenberger wrote:
> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
>> For someone with a different background, there is *nothing* nice about
>> fossil dumping thousands of lines to the terminal. In fact, I think it
>> scares off newbies who only used git before.
>
> I quite disagree. Terminal output is C friendly. Pager output tends to
> disappear with the pager. That's a real world UX issue I have with the
> git default settings.

Pager output disappearing with the pager (I assume when asking the pager 
to exit) is an issue with the pager.

As Fossil is a single binary to do everything approach, I'm sure that a 
Fossil pager would not suffer this defect.

Yes, terminals have scroll bars and can page up, but that's the wrong 
approach as well.

When viewing a diff I want to start at the top and scroll down, not 
start at the bottom and scroll up, hence a pager makes perfect sense.

Roy
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Roy Marples]

On 26/03/2017 22:19, Joerg Sonnenberger wrote:

On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:

For someone with a different background, there is *nothing* nice about
fossil dumping thousands of lines to the terminal. In fact, I think it
scares off newbies who only used git before.


I quite disagree. Terminal output is C friendly. Pager output tends to
disappear with the pager. That's a real world UX issue I have with the
git default settings.


Pager output disappearing with the pager (I assume when asking the pager 
to exit) is an issue with the pager.


As Fossil is a single binary to do everything approach, I'm sure that a 
Fossil pager would not suffer this defect.


Yes, terminals have scroll bars and can page up, but that's the wrong 
approach as well.


When viewing a diff I want to start at the top and scroll down, not 
start at the bottom and scroll up, hence a pager makes perfect sense.


Roy
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Tomasz Konojacki]

On Sun, 26 Mar 2017 19:25:25 +0200
Christophe Gouiran  wrote:

> I see that most of you complain about this proposed feature.

TBH, many members of this list live in the UNIX greybeard bubble, and
that's why there is so much opposition to this feature. They're used to
the original UNIX way and they have different expectations than most of
users.

For someone with a different background, there is *nothing* nice about
fossil dumping thousands of lines to the terminal. In fact, I think it
scares off newbies who only used git before.

Anyway, there's no point in arguing about it. This feature will be
optional, no one is forcing anyone to change their habits.


___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Scott Robison]

On Mar 26, 2017 11:25 AM, "Christophe Gouiran" 
wrote:

Please find as attached file another patch which:

   1. First test for a real terminal before spawning the pager command.
   2. No more paginate json command.

I see that most of you complain about this proposed feature.

It was only a proposition, if it is not accepted I won't care.

However, it would be possible to make both world happy:

   1. Those who don't like this feature simply don't set a pager-command
   setting.
   2. Those who want to use it set a pager-command setting.

And, IMHO adding or removing a '|' at the end of command names is not a
maintenance nightmare.

I'm sorry if I've offended. My point was that one code path that works with
all future commands or changes to commands is not bad, even if it is not
something I will personally use. Needing to tweak code paths unrelated to
DVCS functionality to maintain this feature going forward seems less than
ideal.

I do commend you for stepping forward to implement it. I just disagree with
the idea of making it command specific.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Christophe Gouiran]

Please find as attached file another patch which:

   1. First test for a real terminal before spawning the pager command.
   2. No more paginate json command.

I see that most of you complain about this proposed feature.

It was only a proposition, if it is not accepted I won't care.

However, it would be possible to make both world happy:

   1. Those who don't like this feature simply don't set a pager-command
   setting.
   2. Those who want to use it set a pager-command setting.

And, IMHO adding or removing a '|' at the end of command names is not a
maintenance nightmare.


Note : provided patch can be applied against latest version of the trunk
([a0ce33c90b] at the time of this writing).
Index: src/allrepo.c
==
--- src/allrepo.c
+++ src/allrepo.c
@@ -418,15 +418,15 @@
 if( showLabel ){
   int len = (int)strlen(zFilename);
   int nStar = 80 - (len + 15);
   if( nStar<2 ) nStar = 1;
   fossil_print("%.13c %s %.*c\n", '*', zFilename, nStar, '*');
-  fflush(stdout);
+  fflush(our_stdout);
 }
 if( !quiet || dryRunFlag ){
   fossil_print("%s\n", zSyscmd);
-  fflush(stdout);
+  fflush(our_stdout);
 }
 rc = dryRunFlag ? 0 : fossil_system(zSyscmd);
 free(zSyscmd);
 free(zQFilename);
 if( stopOnError && rc ){

Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -859,17 +859,17 @@
   if( zFilename[0]==0 || (zFilename[0]=='-' && zFilename[1]==0) ){
 blob_is_init(pBlob);
 #if defined(_WIN32)
 nWrote = fossil_utf8_to_console(blob_buffer(pBlob), blob_size(pBlob), 0);
 if( nWrote>=0 ) return nWrote;
-fflush(stdout);
-_setmode(_fileno(stdout), _O_BINARY);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_BINARY);
 #endif
-nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), stdout);
+nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), our_stdout);
 #if defined(_WIN32)
-fflush(stdout);
-_setmode(_fileno(stdout), _O_TEXT);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_TEXT);
 #endif
   }else{
 file_mkfolder(zFilename, 1, 0);
 out = fossil_fopen(zFilename, "wb");
 if( out==0 ){

Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -261,11 +261,11 @@
   );
 }
 
 
 /*
-** COMMAND: branch
+** COMMAND: branch|
 **
 ** Usage: %fossil branch SUBCOMMAND ... ?OPTIONS?
 **
 ** Run various subcommands to manage branches of the open repository or
 ** of the repository identified by the -R or --repository option.

Index: src/bundle.c
==
--- src/bundle.c
+++ src/bundle.c
@@ -716,11 +716,11 @@
   }
   db_end_transaction(0);
 }
 
 /*
-** COMMAND: bundle
+** COMMAND: bundle|
 **
 ** Usage: %fossil bundle SUBCOMMAND ARGS...
 **
 **   fossil bundle append BUNDLE FILE...
 **

Index: src/checkin.c
==
--- src/checkin.c
+++ src/checkin.c
@@ -350,12 +350,12 @@
   if( relPathOption ){ relativePaths = 1; }
   return relativePaths;
 }
 
 /*
-** COMMAND: changes
-** COMMAND: status
+** COMMAND: changes|
+** COMMAND: status|
 **
 ** Usage: %fossil changes|status ?OPTIONS? ?PATHS ...?
 **
 ** Report the change status of files in the current checkout.  If one or
 ** more PATHS are specified, only changes among the named files and
@@ -644,11 +644,11 @@
   }
   db_finalize();
 }
 
 /*
-** COMMAND: ls
+** COMMAND: ls|
 **
 ** Usage: %fossil ls ?OPTIONS? ?PATHS ...?
 **
 ** List all files in the current checkout.  If PATHS is included, only the
 ** named files (or their children if directories) are shown.
@@ -802,11 +802,11 @@
   }
   db_finalize();
 }
 
 /*
-** COMMAND: extras
+** COMMAND: extras|
 **
 ** Usage: %fossil extras ?OPTIONS? ?PATH1 ...?
 **
 ** Print a list of all files in the source tree that are not part of the
 ** current checkout. See also the "clean" command. If paths are specified,
@@ -872,11 +872,11 @@
   }
   blob_reset();
 }
 
 /*
-** COMMAND: clean
+** COMMAND: clean|
 **
 ** Usage: %fossil clean ?OPTIONS? ?PATH ...?
 **
 ** Delete all "extra" files in the source tree.  "Extra" files are files
 ** that are not officially part of the checkout.  If one or more PATH

Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -209,14 +209,14 @@
 db_open_repository(g.argv[3]);
   }
   db_begin_transaction();
   fossil_print("Rebuilding repository meta-data...\n");
   rebuild_db(0, 1, 0);
-  fossil_print("Extra delta compression... "); fflush(stdout);
+  fossil_print("Extra delta compression... "); fflush(our_stdout);
   extra_deltification();
   db_end_transaction(0);
-  fossil_print("\nVacuuming the database... "); fflush(stdout);
+  fossil_print("\nVacuuming the database... "); 

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Richie Adler]

Sergei Gavrikov decía, en el mensaje "Re: [fossil-users] [PROPOSED FEATURE]
Fossil commands output sent through a pager" del 25/3/2017 14:09:57:
> My 2 cents.  Many of us use f-alias to deal with fossil in a terminal,
> right? Then why not f-function?

Maybe because not everybody uses Unix-like operating systems?


___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[j. van den hoff]

On Sun, 26 Mar 2017 16:00:11 +0200, Scott Robison  
 wrote:



On Mar 26, 2017 7:13 AM, "Christophe Gouiran" 
wrote:

Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs  
to

a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:


{snipped list of commands}

I appreciate what you're trying to do here, but what you've done (based  
on

your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.

I'm coming around to the position that, given the ease of typing "|  
pager"

when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done  
this

for me, though I could be in the minority.


+1

--
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Stephan Beal]

On Sun, Mar 26, 2017 at 4:00 PM, Scott Robison 
wrote:

> their amount of output, perhaps based on some extra parameter. DRH
> suggested that it should be based on any output, which would avoid the
> worry about how fossil changes over time.
>

corner case: json output should arguably never be paged.

FWIW, i consider built-in paging (and symlinks support and fossil-side
terminal line-wrapping, for that matter) to be a bad idea (read as: "can of
worms"). i can count on one hand the number of times i've pager'd fossil
output since 2007.

-- 
- 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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Scott Robison]

On Mar 26, 2017 7:13 AM, "Christophe Gouiran" 
wrote:

Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:


{snipped list of commands}

I appreciate what you're trying to do here, but what you've done (based on
your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.

I'm coming around to the position that, given the ease of typing "| pager"
when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done this
for me, though I could be in the minority.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Martin S. Weber]

On 2017-03-26 15:13:53, Christophe Gouiran wrote:
> I come back to you with an implemented solution.
> 

Your solution doesn't check whether stdout is actually pointing to a terminal.
You should never invoke a pager if it's not.

I also think this is a horrible idea in general.

Regards,
-Martin
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Christophe Gouiran]

Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:

   1. branch
   2. bundle
   3. changes
   4. status
   5. ls
   6. extras
   7. clean
   8. artifact
   9. descendants
   10. leaves
   11. annotate
   12. blame
   13. praise
   14. diff
   15. finfo
   16. cat
   17. json
   18. search
   19. tag
   20. timeline
   21. ticket
   22. undo
   23. redo
   24. unversioned
   25. wiki

To achieve that, I modified mkindex.c and, in all relevant source files, I
appended a pipe '|' to the commands which are candidates for a pager.


Now, when fossil is launched, it decides whether to use a pager according
to following conditions in this order of priority:

   1. Fossil command is candidate for a pager.
   2. PAGER environment variable is set to a non empty value.
   3. pager-command setting is set to a non empty value.


Then, technically, when there is pager to use it is launched as a child
process and Fossil standard output stream is piped to pager standard input.

And Fossil waits for pager to quit before quitting itself.


Just give it a try : it works pretty well under Linux with pager-command
"less -FRX".

It does not work yet under Windows as I'm a complete newbie with its
programming API.

If someone wants to contribute for the Windows, it would be welcome.


As usual, waiting for your feedback ...

Note : provided patch can be applied against latest version of the trunk
([a0ce33c90b] at the time of this writing).
Index: src/allrepo.c
==
--- src/allrepo.c
+++ src/allrepo.c
@@ -418,15 +418,15 @@
 if( showLabel ){
   int len = (int)strlen(zFilename);
   int nStar = 80 - (len + 15);
   if( nStar<2 ) nStar = 1;
   fossil_print("%.13c %s %.*c\n", '*', zFilename, nStar, '*');
-  fflush(stdout);
+  fflush(our_stdout);
 }
 if( !quiet || dryRunFlag ){
   fossil_print("%s\n", zSyscmd);
-  fflush(stdout);
+  fflush(our_stdout);
 }
 rc = dryRunFlag ? 0 : fossil_system(zSyscmd);
 free(zSyscmd);
 free(zQFilename);
 if( stopOnError && rc ){

Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -859,17 +859,17 @@
   if( zFilename[0]==0 || (zFilename[0]=='-' && zFilename[1]==0) ){
 blob_is_init(pBlob);
 #if defined(_WIN32)
 nWrote = fossil_utf8_to_console(blob_buffer(pBlob), blob_size(pBlob), 0);
 if( nWrote>=0 ) return nWrote;
-fflush(stdout);
-_setmode(_fileno(stdout), _O_BINARY);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_BINARY);
 #endif
-nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), stdout);
+nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), our_stdout);
 #if defined(_WIN32)
-fflush(stdout);
-_setmode(_fileno(stdout), _O_TEXT);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_TEXT);
 #endif
   }else{
 file_mkfolder(zFilename, 1, 0);
 out = fossil_fopen(zFilename, "wb");
 if( out==0 ){

Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -261,11 +261,11 @@
   );
 }
 
 
 /*
-** COMMAND: branch
+** COMMAND: branch|
 **
 ** Usage: %fossil branch SUBCOMMAND ... ?OPTIONS?
 **
 ** Run various subcommands to manage branches of the open repository or
 ** of the repository identified by the -R or --repository option.

Index: src/bundle.c
==
--- src/bundle.c
+++ src/bundle.c
@@ -716,11 +716,11 @@
   }
   db_end_transaction(0);
 }
 
 /*
-** COMMAND: bundle
+** COMMAND: bundle|
 **
 ** Usage: %fossil bundle SUBCOMMAND ARGS...
 **
 **   fossil bundle append BUNDLE FILE...
 **

Index: src/checkin.c
==
--- src/checkin.c
+++ src/checkin.c
@@ -350,12 +350,12 @@
   if( relPathOption ){ relativePaths = 1; }
   return relativePaths;
 }
 
 /*
-** COMMAND: changes
-** COMMAND: status
+** COMMAND: changes|
+** COMMAND: status|
 **
 ** Usage: %fossil changes|status ?OPTIONS? ?PATHS ...?
 **
 ** Report the change status of files in the current checkout.  If one or
 ** more PATHS are specified, only changes among the named files and
@@ -644,11 +644,11 @@
   }
   db_finalize();
 }
 
 /*
-** COMMAND: ls
+** COMMAND: ls|
 **
 ** Usage: %fossil ls ?OPTIONS? ?PATHS ...?
 **
 ** List all files in the current checkout.  If PATHS is included, only the
 ** named files (or their children if directories) are shown.
@@ -802,11 +802,11 @@
   }
   db_finalize();
 }
 
 /*
-** COMMAND: extras
+** COMMAND: extras|
 **
 ** Usage: %fossil extras ?OPTIONS? ?PATH1 ...?
 **
 ** Print a list of all files in 

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Stefan Bellon]

On Sat, 25 Mar, Andy Bradford wrote:

> Thus said Roy Keene on Thu, 23 Mar 2017 17:36:37 -0500:
> 
> > I vote that the pagination be  off by default to preserve the
> > existing behaviour -- terminals  have been able to scroll for
> > decades now so I don't know why systemd/git like to do this by
> > default but it is REALLY annoying having to pipe EVERYTHING through
> > "cat" to defeat it.  
> 
> I'll add my voice to this as well and it's not just to preserve
> existing behavior. I think  git's default (is it even configurable
> with git?) to automatically page everything is one of its most
> annoying features. If I want a  pager, I'll pipe it  to a pager.
> Otherwise, just dump it  to my terminal, thank you.

+1 for everything said by Roy and Andy.

-- 
Stefan Bellon
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Andy Bradford]

Thus said Roy Keene on Thu, 23 Mar 2017 17:36:37 -0500:

> I vote that the pagination be  off by default to preserve the existing
> behaviour -- terminals  have been able to scroll for  decades now so I
> don't know why systemd/git like to do this by default but it is REALLY
> annoying having to pipe EVERYTHING through "cat" to defeat it.

I'll add my voice to this as well and it's not just to preserve existing
behavior. I think  git's default (is it even configurable  with git?) to
automatically page everything is one of its most annoying features. If I
want a  pager, I'll pipe it  to a pager.  Otherwise, just dump it  to my
terminal, thank you.

Andy
-- 
TAI64 timestamp: 400058d74d80


___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Reimer Behrends]

Sergei Gavrikov wrote:

My 2 cents. Many of us use f-alias to deal with fossil in a terminal,
right? Then why not f-function?


That won't work with commands that need to take input from the terminal, 
especially if an editor is invoked (e.g. "fossil commit").


There's the "fsl" script that allows you to handle interactive commands 
specially, but that's not KISS anymore.


Reimer Behrends
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Sergei Gavrikov]

My 2 cents.  Many of us use f-alias to deal with fossil in a terminal,
right? Then why not f-function?

SYNOPSIS

unalias f

f(){ fossil "$@" | more ; }

or
f(){ fossil "$@" | less -FRSXQ ; }

if you like more 'less' then 'more' :) Then try

f help commit
f timeline -n 100

IMHO, KISS is just to put such an 1-liner in your ~/.profile if you need
the pager.

Thanks for Fossil!

Sergei
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Tomasz Konojacki]

On Thu, 23 Mar 2017 23:08:04 +0100
Christophe Gouiran  wrote:

> Good morning,
> 
> I would like to implement the feature given in the title.
> I'm inspired by what Git (by default ?) and Mercurial (with Pager
>  extension activated) do.
> 
> I'd like to avoid typing "fossil  | less" everytime I notice it
> produces an output which doesn't fit in a single screen.

+1, I'd love too see this feature in fossil.

> (...)
> If pager-command is empty then following pager command will be used:
> 
>1. "more" under Windows.
>2. "less -FRSX" under any other OS.

Before using that fallback it should check PAGER environmental variable.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Roy Keene]

I vote that the pagination be off by default to preserve the existing 
behaviour -- terminals have been able to scroll for decades now so I don't 
know why systemd/git like to do this by default but it is REALLY annoying 
having to pipe EVERYTHING through "cat" to defeat it.


(Also, even better than scrolling -- my terminal can search 
forwards/backwards/copy/paste, etc, it's real handy.)


On Thu, 23 Mar 2017, Christophe Gouiran wrote:


Good morning,

I would like to implement the feature given in the title.
I'm inspired by what Git (by default ?) and Mercurial (with Pager extension 
activated) do.

I'd like to avoid typing "fossil  | less" everytime I notice it 
produces an output which doesn't fit in a single screen.

Find below my ideas (in no particular order).
Settings :
 1. Add a new boolean setting "Paginates commands" (it is true by default)
 2. Add a new string setting "pager-command" (it is empty by default)
 3. Add a new string setting "Commands to paginate" (default value to be 
defined)

If pager-command is empty then following pager command will be used:

 1. "more" under Windows.
 2. "less -FRSX" under any other OS.

When Fossil writes something to its standard output, then it is sent through 
the pager if (and only if) all following conditions are met:

 1. Fossil standard output is a real terminal.
 2. "Paginates commands" setting is true.
 3. Executed command is indicated in "Commands to paginate" setting.

Fossil standard error must not be paginated.


Now I'm waiting for your advices/improvements/feedbacks.

For example:

 1. Should the settings be versionnable ?
 2. Which commands to be put by default in "Commands to paginate" ?


Many thanks in advance for taking the time to participate.





___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Richard Hipp]

I think there should be a single setting, pager-command, which the
pager uses for *all* command-line output if it defined.  The setting
defaults to an empty string, which means no pagination.  I don't think
you want to select some subset of commands to be paginated.  Do them
all, or do none of them.

This should not be a versionable setting since it has nothing to do
with the project and is merely a user display preference.

Implement it by hooking into the fossil_print() function (in printf.c)
which should be used for all output already.  (There may be exceptions
to this, but those will be bugs that need fixing.)  Probably you will
want to accumulate text in a buffer until you know you are going to
have more than 24 lines, and only invoke the pager if the number of
lines exceeds 24.

You will also need to hook the various prompt_*() routines to convince
them to flush the pager buffer.  I do not think any prompt_*() will
ever occur after more than 2 or 3 llines of output, so there should
never be a case where the pager has already started when the prompt_()
is run.

Let me just say that I really loath software, like the "man" command
on Ubuntu, that thinks it is doing me a favor by running a pager for
me automatically.  I haven't voluntarily used a pager since back in
the 80s when my terminal was a (real) VT100.  If output is long, I'll
scroll back or I will pipe into "open -f" which just works on Mac and
for which I have a reasonable work-a-like on Linux.  If I'm working
remote, I'll redirect to a file, then scp the file back to my desktop
and bring it up in an editor there.  I'm not alone in these habits.  I
say all this just to emphasize that the default value for the
pager-command should definitely be OFF.


On 3/23/17, Christophe Gouiran  wrote:
> Good morning,
>
> I would like to implement the feature given in the title.
> I'm inspired by what Git (by default ?) and Mercurial (with Pager
>  extension activated)
> do.
>
> I'd like to avoid typing "fossil  | less" everytime I notice it
> produces an output which doesn't fit in a single screen.
>
> Find below my ideas (in no particular order).
>
> Settings :
>
>1. Add a new boolean setting "Paginates commands" (it is true by
> default)
>2. Add a new string setting "pager-command" (it is empty by default)
>3. Add a new string setting "Commands to paginate" (default value to be
>defined)
>
> If pager-command is empty then following pager command will be used:
>
>1. "more" under Windows.
>2. "less -FRSX" under any other OS.
>
> When Fossil writes something to its standard output, then it is sent
> through the pager if (and only if) all following conditions are met:
>
>1. Fossil standard output is a real terminal.
>2. "Paginates commands" setting is true.
>3. Executed command is indicated in "Commands to paginate" setting.
>
> *Fossil standard error must not be paginated.*
>
>
> Now I'm waiting for your advices/improvements/feedbacks.
>
> For example:
>
>1. Should the settings be versionnable ?
>2. Which commands to be put by default in "Commands to paginate" ?
>
>
> Many thanks in advance for taking the time to participate.
>


-- 
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Scott Robison]

I don't know about what commands to paginate by default, but no to
versionable settings for this. Don't want to force this on others.

On Mar 23, 2017 4:08 PM, "Christophe Gouiran" 
wrote:

> Good morning,
>
> I would like to implement the feature given in the title.
> I'm inspired by what Git (by default ?) and Mercurial (with Pager
>  extension activated)
> do.
>
> I'd like to avoid typing "fossil  | less" everytime I notice it
> produces an output which doesn't fit in a single screen.
>
> Find below my ideas (in no particular order).
>
> Settings :
>
>1. Add a new boolean setting "Paginates commands" (it is true by
>default)
>2. Add a new string setting "pager-command" (it is empty by default)
>3. Add a new string setting "Commands to paginate" (default value to
>be defined)
>
> If pager-command is empty then following pager command will be used:
>
>1. "more" under Windows.
>2. "less -FRSX" under any other OS.
>
> When Fossil writes something to its standard output, then it is sent
> through the pager if (and only if) all following conditions are met:
>
>1. Fossil standard output is a real terminal.
>2. "Paginates commands" setting is true.
>3. Executed command is indicated in "Commands to paginate" setting.
>
> *Fossil standard error must not be paginated.*
>
>
> Now I'm waiting for your advices/improvements/feedbacks.
>
> For example:
>
>1. Should the settings be versionnable ?
>2. Which commands to be put by default in "Commands to paginate" ?
>
>
> Many thanks in advance for taking the time to participate.
>
>
>
> ___
> 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