Re: Mc Digest, Vol 62, Issue 3

[chris glur]

Search 'hot-list'
 ..yes...
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, mc-requ...@gnome.org mc-requ...@gnome.org wrote:
 Send Mc mailing list submissions to
   mc@gnome.org

 To subscribe or unsubscribe via the World Wide Web, visit
   http://mail.gnome.org/mailman/listinfo/mc
 or, via email, send a message with subject or body 'help' to
   mc-requ...@gnome.org

 You can reach the person managing the list at
   mc-ow...@gnome.org

 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 kilg...@banach.math.auburn.edu
 Subject: two questions about Slackware's mc-20090514_git
 To: mc@gnome.org
 Message-ID:
   alpine.lnx.2.00.0906112056130.5...@banach.math.auburn.edu
 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
 inconsistent.

 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
 text?

 Theodore Kilgore




 --

 ___
 Mc mailing list
 http://mail.gnome.org/mailman/listinfo/mc


 End of Mc Digest, Vol 62, Issue 3
 *

___
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc

Re: Mc Digest, Vol 62, Issue 3

[Theodore Kilgore]

On Sun, 14 Jun 2009, chris glur wrote:


Search 'hot-list'
..yes...
Theodore Kilgore was describing:

view/F3 anf edit/F4 both have have search file
facilities, which have mutually diferent behavious. And seem inconsisitent ?



Actually, Chris, I was not complaining about the fact that different keys 
can be used for doing searches, depending on whether one is Viewing or 
Editing. In any event, the use of those keys is at this point ancient, 
time-honored, and hallowed by tradition. No problem there. Now, since that 
was not the problem, here again is a description of the problem:


I used to be able to search a file for something, then search another file 
for the *same string* and I did not need to re-enter the string when I 
opened the second file and wanted to search it. Now if I open the second 
file and hit the same search key, then the contents of the search request
did not get saved for potential re-use. This is not old behavior. It used 
not to be thus. It is new behavior, which un-does something which used to 
be done right.


I did make one mistake in describing the MC version, which may have 
caused confusion:


I forgot that I was running the git source, and what was the reason for 
that. There is no such Slackware package, as far as I know, named 
mc-20090514_git except for the one which was locally created, right 
here. And now I am not using it any more, either, but the problems I 
described are still present. Yesterday I did git pull and re-compiled 
and re-installed to see if the problem I described just above has been 
fixed. I am running the most up-to-date Midnight Commander code that it 
is possible for me to run. The problem described above has not been fixed.


What was the reason why I have the git tree over here? Well, I wanted to 
look into the VirtualFileSystem stuff and see if I could understand it.


(No luck with that, unfortunately)

Why? Well, because it seems that LZM and LZMA compression are replacing 
Gzip and Bzip in a lot of applications. Slackware, my favorite distro, has 
for example quit using tgz (tar and gzip) packages and has switched over 
to a new package format txz (tar and lzm compress). Boy, it sure would 
be nice to be able to open one of those just like it is possible to open a 
gzipped or bz2'ed tarball and look inside at it just like it was an 
ordinary directory. Boy, with this new package format, I feel all of a 
sudden blind because I can not open this package format with MC.


Also there are several live distros which are using LZMA compression for 
big pieces of the filesystem, and are decompressing the stuff on the fly 
upon boot and mounting the pieces in a union file system. Boy, it sure 
would be nice to be able to open one of those compressed files, just like 
one can open a tarball, by hitting Enter. Boy, it sure would be nice at 
least to be able to see the directory structure of one of these things (or 
of a compressed Slackware package, for that matter) by just hitting F3.


Well, I posted about this topic, it seems to me a couple of months ago. 
I pointed out that I am somewhat inexperienced with the way that the 
Midnight Commander code is put together, and therefore I might not be 
considered much of a helper, but I was also willing to put in time and 
energy to help, if I could. There were no responses to that post.


So that is one of the reasons why I got a copy of the git tree. The other 
reason is that I was trying to figure out how that the --- stuff for 
tabbing is working in the editor. As I said in the last post to which you 
are replying, Chris, there are some problems with that. It is a really 
clever idea, and useful, too, if one is writing code. But something bad is 
happening with those -- thingies if one is using the mouse to copy 
code from one window to another. Namely, they are supposed to be a 
reflection of invisible characters, but when the mouse is thus used they 
literally become visible characters which are part of what is copied. 
Examples are given below.



Theodore Kilgore


do sub-tasks once only, and then just 'recall' them 

== Chris Glur.



On 6/12/09, mc-requ...@gnome.org mc-requ...@gnome.org wrote:

Send Mc mailing list submissions to
mc@gnome.org

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.gnome.org/mailman/listinfo/mc
or, via email, send a message with subject or body 'help' to
mc-requ...@gnome.org

You can reach the person managing the list at
mc-ow...@gnome.org

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 kilg...@banach.math.auburn.edu
Subject: two questions about Slackware's mc-20090514_git
To: mc@gnome.org
Message-ID: