Re: [mmh] Previous-Sequence
[2020-03-24 23:38] Philipp Takacs Hi, > [2020-03-24 08:56] markus schnalke > > [2020-03-23 21:46] Philipp Takacs > > > A updated version of my patches is attached, including the updated > > > man pages. > > > > Please add a HISTORY section to the mh-sequence(7) manpage with > > some explanation about the removal of the Previous-Sequence, so > > that people, who search for it, are informed that it was removed > > and why. > > > > Then it's ready to commit, I'd say. > > OK I have added following: I tried editing the wording a bit to make it read better. > --- a/man/mh-sequence.man7 > +++ b/man/mh-sequence.man7 > @@ -263,5 +263,24 @@ in your profile with an empty value. > .SH "SEE ALSO" > flist(1), mark(1), pick(1), mh-profile(5) > > +.SH "HISTORY" > +.SS Previous\-Sequence > +Earlier versions of > +.B mmh > +supported the `Previous\-Sequence'. This sequence stored the selected messages for the previous mmh command. It was disabled by default because it introduced a lot of extra writes to the .mh_sequences file. Additionally, it introduced possible race conditions when running multiple mmh commands in parallel. The feature was removed for these reasons. [..] -- Simon Thelen
Re: [mmh] Previous-Sequence
[2020-03-24 08:56] markus schnalke > [2020-03-23 21:46] Philipp Takacs > > A updated version of my patches is attached, including the updated > > man pages. > > Please add a HISTORY section to the mh-sequence(7) manpage with > some explanation about the removal of the Previous-Sequence, so > that people, who search for it, are informed that it was removed > and why. > > Then it's ready to commit, I'd say. OK I have added following: --- a/man/mh-sequence.man7 +++ b/man/mh-sequence.man7 @@ -263,5 +263,24 @@ in your profile with an empty value. .SH "SEE ALSO" flist(1), mark(1), pick(1), mh-profile(5) +.SH "HISTORY" +.SS Previous\-Sequence +Earlier versions of +.B mmh +supported the `Previous\-Sequence'. +In this sequence every +.B mmh +command save the selected messages. +This feature was disabled by default, +because it introduces a lot write access to the +.IR \&.mh_sequence +file. +If you used multiple +.B mmh +commands parallel or other tools writing the +.IR \&.mh_sequence +file, this could lead to race conditions. +Because of this this feature was removed. + .SH DEFAULTS None > > > meillo >
Re: [mmh] Previous-Sequence
Hoi. [2020-03-23 21:46] Philipp Takacs > [2020-03-22 07:53] markus schnalke > > [2020-03-22 00:21] Philipp Takacs > > > [2020-03-21 09:54] markus schnalke > > > > Before we remove it, I just would like to know why it was > > > > introduced in MH the first time and what possible other usecases > > > > there could be. This means asking on the nmh-workers mailing list. > > > > Both, out of curiosity and as a double-check in case we've not > > > > thought on something. Do you wanna write this message or should > > > > I? > > > > > > This is a good idea. I want to write this mail. > > > > > > So conclusion ask the nmh guys for use cases we missed and if there > > > aren't any, remove it. > > > > Yes! :-) > > > > Please as well ask them when and why the previous sequence was > > introduced. I'd like to have confirmed that it was because of lack > > of a shell history, or told why else. > > I have asked[0] them. > > [0] https://lists.nongnu.org/archive/html/nmh-workers/2020-03/msg0.html Thanks for asking. i've read through the mails there. > Some conclusion: > > We have missed that a command may have side effects. Here the example > from Ralph: > > show next:3 > scan !$ > > I see, this isn't possible to solve without a sequence. This is a > problem, when you notice you want to use these messages after you > started show. I would say this corner case isn't sufficient to keep the > Previous-Sequence. If you did show n:3 you can use scan c:-3 to address the same messages. For further commands on the same messages, you keep repeating `c:-3', as the commands place `c' again on the last message of the range. (You have to be careful, however, if the first command was mark(1), for instance, because mark(1) does not change the current message, thus the second command would still take `n:3'.) Yes, that requires some brain action, compared to the pseq, but it's feasible if you know the commands. Btw: I agree with what Valdis wrote about muscle memory that was set in times before command line editing was available. A lot of the nmh guys are that old. I have such hard-wired typing strokes too ... only that they were burned in some decades later. ;-) But still not enough reason to keep it. > I would say remove it. Yes. > A updated version of my patches is attached, including the updated > man pages. Please add a HISTORY section to the mh-sequence(7) manpage with some explanation about the removal of the Previous-Sequence, so that people, who search for it, are informed that it was removed and why. Then it's ready to commit, I'd say. meillo
Re: [mmh] Previous-Sequence
Hoi. [2020-03-22 00:21] Philipp Takacs > [2020-03-21 09:54] markus schnalke > > [2019-12-15 17:55] Philipp Takacs > > > > > > During that I found the Previous-Sequence again. I don't see a reason > > > why we need this feature. The usecases, I see, for the feature are better > > > handled with mark or the backlog of your shell. But I don't use this > > > feature. > > During reading some old mails on the nmh mailing list I found a use case. > Put mails in a sequence after a refile[0]. > [0] https://lists.nongnu.org/archive/html/nmh-workers/2005-12/msg00086.html That's a valid usecase. But I don't think that we need to have the previous sequence to cover that. The refiled messages will always be at the end of the destination folder. Thus, you can solve it this way as well: b=`mhpath b +dest` refile -src +src ...msg... +dest mark -seq pseq +dest "$b"-l (If you've forgotten to remember the beyond message beforehand, a human can still look at the destination folder and know which the first refiled message was.) As it is a rare usecase and there is a workaround, I'd rather document the ``workaround'' (actually not really a workaround but rather a different approach to solve the problem) in the man page. (I think it's good to have hints and examples in the man pages to help newer users to figure out how to effectively work with mmh. See the manpage of pick(1) for example.) > Not sure if this works, but > for this I would suggest to add a -preserve switch to refile instead of > using previous-sequence for this, like nmh has done. The `-preserve' switch changes how the refiling works in nmh ... using it makes the refiled message spread over the destination folder (trying to preserve the previous message numbers from the source folder), thus the above solution won't work. In this case you need to set something like a previous sequence to find the refiled messages again. But in mmh I've dropped the `-preserve' switch a long time ago. Here from my master's thesis (PDF page 33): [no]preserve of refile was removed [ 8edc5aa] because what use was it anyway? Quoting nmh's man page refile(1): Normally when a message is refiled, for each destination folder it is assigned the number which is one above the current highest message number in that folder. Use of the preserv [sic!] switch will override this message renaming, and try to preserve the number of the message. If a conflict for a particular folder occurs when using the preserve switch, then refile will use the next available message number which is above the message number you wish to preserve. That means: We have a valid usecase but still no real need for the previous sequence. The `refile -preserve' case does not exist in mmh. > > Besides: It does introduce a lot of write accesses to the sequence > > files. > > Would it only be the write access itself, it wouldn't be that bad. You > still need to enable it. Do you mean that it is disabled by default? This kinda contradicts the idea of mmh, where all (new/good) features should be enabled by default. I kept it disabled by default because of the many write accesses, i.e. a lot of stuff it does though it is almost never used. Actually it's only still there because I wasn't sure enough that we can safely drop it. > > Before we remove it, I just would like to know why it was > > introduced in MH the first time and what possible other usecases > > there could be. This means asking on the nmh-workers mailing list. > > Both, out of curiosity and as a double-check in case we've not > > thought on something. Do you wanna write this message or should > > I? > > This is a good idea. I want to write this mail. > > So conclusion ask the nmh guys for use cases we missed and if there > aren't any, remove it. Yes! :-) Please as well ask them when and why the previous sequence was introduced. I'd like to have confirmed that it was because of lack of a shell history, or told why else. meillo
Re: [mmh] Previous-Sequence
Hi [2020-03-21 09:54] markus schnalke > [2019-12-15 17:55] Philipp Takacs > > > > During that I found the Previous-Sequence again. I don't see a reason > > why we need this feature. The usecases, I see, for the feature are better > > handled with mark or the backlog of your shell. But I don't use this > > feature. During reading some old mails on the nmh mailing list I found a use case. Put mails in a sequence after a refile[0]. Not sure if this works, but for this I would suggest to add a -preserve switch to refile instead of using previous-sequence for this, like nmh has done. > Just for reference, the section from mh-sequence(7): > >The Previous Sequence >Mmh provides the ability to remember the `msgs' or `msg' >argument last given to an mmh command. The entry `Previ‐ >ous-Sequence' should be defined in the mmh profile; its >value should be a sequence name or multiple sequence >names separated by spaces. If this entry is defined, >when an mmh command finishes, it will define the >sequence(s) named in the value of this entry to be those >messages that were specified to the command. Hence, a >profile entry of > > Previous-Sequence: pseq > >directs any mmh command that accepts a `msg' or `msgs' >argument to define the sequence `pseq' as those messages >when it finishes. > >Note: there can be a performance penalty in using the >`Previous-Sequence' facility. If it is used, all mmh >programs have to write the sequence information to the >.mh_sequences file for the folder each time they run. If >the `Previous-Sequence' profile entry is not included, >only pick and mark will write to the .mh_sequences file. Actually the last sentence is wrong. A lot more mmh programs write the .mh_sequences file, like show, inc, ... > Besides: It does introduce a lot of write accesses to the sequence > files. Would it only be the write access itself, it wouldn't be that bad. You still need to enable it. > Before we remove it, I just would like to know why it was > introduced in MH the first time and what possible other usecases > there could be. This means asking on the nmh-workers mailing list. > Both, out of curiosity and as a double-check in case we've not > thought on something. Do you wanna write this message or should > I? This is a good idea. I want to write this mail. So conclusion ask the nmh guys for use cases we missed and if there aren't any, remove it. Philipp [0] https://lists.nongnu.org/archive/html/nmh-workers/2005-12/msg00086.html
Re: [mmh] Previous-Sequence
Hoi. [2019-12-15 17:55] Philipp Takacs > > During that I found the Previous-Sequence again. I don't see a reason > why we need this feature. The usecases, I see, for the feature are better > handled with mark or the backlog of your shell. But I don't use this > feature. Just for reference, the section from mh-sequence(7): The Previous Sequence Mmh provides the ability to remember the `msgs' or `msg' argument last given to an mmh command. The entry `Previ‐ ous-Sequence' should be defined in the mmh profile; its value should be a sequence name or multiple sequence names separated by spaces. If this entry is defined, when an mmh command finishes, it will define the sequence(s) named in the value of this entry to be those messages that were specified to the command. Hence, a profile entry of Previous-Sequence: pseq directs any mmh command that accepts a `msg' or `msgs' argument to define the sequence `pseq' as those messages when it finishes. Note: there can be a performance penalty in using the `Previous-Sequence' facility. If it is used, all mmh programs have to write the sequence information to the .mh_sequences file for the folder each time they run. If the `Previous-Sequence' profile entry is not included, only pick and mark will write to the .mh_sequences file. I myself don't use the previous sequence neither, yet I was reluctant to throw it away as I wondered if I just haven't understood it fully enough to find use for it. Also, I have the feeling that I haven't really understood its reason for existance well enough. To me, it seems that it might have been introduced in times before the shell history feature and today, the shell history covers the usecase up fully. The usecase I have in mind is something like: show 16 25-29 33 34 41-l refile pseq +foo However, with shell history and line editing facilities, I simply do: Escape k cw refile to get the second command with out the previous sequence. The argument set doesn't get lost if you have a shell history. The shell history covers up the case of a wrong command you like to undo, too. E.g. I have ``mark unread'' and ``mark read'' commands (which wrap around mark(1)). And regarding the situation apart from interactive shells with history, in scripts you'll have the msg arguments in variables anyways, thus you have them remembered. This brings me to the conclusion that I don't see a relevant need for the previous sequence in mmh. I find all the usecaes I can think of covered otherwise (and more convenient) and I haven't used the previous sequence myself at all. Besides: It does introduce a lot of write accesses to the sequence files. Before we remove it, I just would like to know why it was introduced in MH the first time and what possible other usecases there could be. This means asking on the nmh-workers mailing list. Both, out of curiosity and as a double-check in case we've not thought on something. Do you wanna write this message or should I? meillo
