Theodore Kilgore was describing:
view/F3 anf edit/F4 both have have search file
facilities, which have mutually diferent behavious. And seem inconsisitent ?
Since users are likely to have search requoirements which are
common to may files/mcS/sessions, it would be
usefull to have 'search hotlist/s'.
I was recently forced to use DOS and was reminded how
frustrating it is to be forced to RE-enter strings.
Users and programms merge,in that much common activety
is repetative. So, eg. linux's 'pick an action/string
from recent history to repeat' is usefull.
A definition of 'computing' is:
"do sub-tasks once only, and then just 'recall' them "
== Chris Glur.
On 6/12/09, [email protected] <[email protected]> wrote:
> Send Mc mailing list submissions to
> [email protected]
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> [email protected]
> You can reach the person managing the list at
> [email protected]
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mc digest..."
> Today's Topics:
> 1. two questions about Slackware's "mc-20090514_git"
> (Theodore Kilgore)
> Message: 1
> Date: Thu, 11 Jun 2009 21:25:21 -0500 (CDT)
> From: Theodore Kilgore <[email protected]>
> Subject: two questions about Slackware's "mc-20090514_git"
> To: [email protected]
> <[email protected]>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
> First one:
> There is some behavior about searching, to which I am not accustomed.
> Namely, when one uses F3 to view then "/" or F7 allows one to search. That
> is, of course, as usual. If one is editing a file with F4, then again F7
> is used for doing a search. That is, of course, also as usual.
> But what seems to me to be new is that if I do a search, then close the
> file, and want to open either it or another file in the same directory and
> do another search for the same thing, now the contents to be searched for
> are gone and need to be re-entered in the search window. I could just
> swear that the content of the search used to be persistent, and now it is
> volatile. Now, even if one is opening the same file again, that which was
> being searched for has disappeared. I think it was much more convenient
> the other way.
> Second one:
> Again we have the feature in the editor that tabs are marked thus:
> <------>err_code = reg_w(gspca_dev, 11);
> <------>if (err_code < 0)
> <------><------>return err_code;
> This is not a bad thing if one is doing some kernel coding and has to obey
> the rules. It certainly does distinguish tabs from spaces. But look what
> it did when I used the mouse to copy it over here! Since some kind of
> meta-characters are used, why exactly do they have to be seen and copied
> thus by the mouse?
> Even worse, when I create a new file called codesample.txt and use the
> mouse to copy over the same three lines, now I literally have the arrow
> characters in the file, not tabs. But of course they are supposed to
> be tabs, not arrow characters. So it was OK to move the snippet of code
> over, but now every line has to be edited by hand. Ouch.
> Well, one might think that I was stupid and what I really ought to do is
> to use F3 instead of having opened it with F4. But if I do that then at
> the beginning of each line I have spaces instead of tabs. So, as far as
> having to edit each line after copying, the result is equally unpleasant.
> Interestingly, if I use "less" to open the file to be copied from, and
> copy into a file which was opened by mcedit, then, upon checking, it
> appears the tabs do get preserved. But no arrow symbols appear even
> though the tabbing has survived the mouse-copy operation. Weird. Also
> Therefore, the question boils down to the following:
> Is it somehow possible to mark tabs (that is nice for coding, obviously)
> but when one copies using the mouse from one file to another, the tabs are
> preserved, and appropriate marking for them is used or introduced, but
> the marking for them (if it was already present) is not transformed into
> actual characters, which then need to be manually removed from the copied
> Theodore Kilgore
> Mc mailing list
> End of Mc Digest, Vol 62, Issue 3
Mc mailing list