From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Newsgroups: gmane.emacs.help Subject: Re: simple first emacs script Date: Wed, 15 Dec 2010 17:28:38 +0000 Organization: Newsgroupdirect Message-ID: References: <2V2Oo.37337$hW6.28446@newsfe08.ams2> <87hbefytr8.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1292434875 20252 80.91.229.12 (15 Dec 2010 17:41:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Dec 2010 17:41:15 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 15 18:41:10 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PSvLd-0002lN-FN for geh-help-gnu-emacs@m.gmane.org; Wed, 15 Dec 2010 18:41:05 +0100 Original-Received: from localhost ([127.0.0.1]:50354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSvLc-0005Ee-TI for geh-help-gnu-emacs@m.gmane.org; Wed, 15 Dec 2010 12:41:04 -0500 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!news2.euro.net!feeder.news-service.com!cyclone02.ams2.highwinds-media.com!news.highwinds-media.com!npeersf01.ams.highwinds-media.com!newsfe06.ams2.POSTED!2f28f7ac!not-for-mail User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 Original-Newsgroups: gnu.emacs.help In-Reply-To: <87hbefytr8.fsf@kuiper.lan.informatimago.com> Original-Lines: 100 Original-X-Complaints-To: abuse@newsgroupdirect.com Original-NNTP-Posting-Date: Wed, 15 Dec 2010 17:28:41 UTC Original-Xref: usenet.stanford.edu gnu.emacs.help:183319 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:77561 Archived-At: Wow Pascal that is quite an amazing response thanks. You introduced several new things I don't know about so I can't comment on them until I go away and learn them but in response to what I do understand. Yes the indentation was destroyed by newsreader, but thanks for pointing me to paredit as I was finding managing parenthesis a pain. > The (require 'csv-mode) form would be better placed on the toplevel > (ie. above the defun form). I don't get this. If I understand you correctly you are suggesting something like this: (require 'csv-mode) (defun ... ) If I do this then wont the require mode cease to be part of the functions definition. Normally it would not be required to set the mode the csv as the file extension would be .csv and csv-mode is called automatically, but the raw files I receive have random extensions - I suppose I could rename them all to overcome this but it seemed simpler to tell the function to go into csv mode otherwise it tries to process the file in fundamental mode. > Instead of push-mark (I don't see the matching pop-mark), you might use > the save-excursion macro. I did actually start with save-excursion but I have no interest in saving the point the mark, the whole point of pushing the mark and moving the point to the start of the buffer was to specify the region arguments in csv-kill-fields, i.e. (csv-kill-fields '(4 ...) (point) (mark)) I guess this might be more logically done with (csv-kill-fields '(4 ...) (point-min) (point-max)) would that be considered better form? Thanks for the advice on eql cond, case, and distribution of my column specifiers that will clean things up a bit. I don't know enough to follow your iota operator but that gives me something to work towards > when (and unless and other macros) has an implicit progn, so there's no > need to embed one in it. That is handy to know. > Ah, if you read the documentation of csv-kill-fields, you will see that > it depends on the right setting of the variable csv-separators to know > what separator to use. By default I have it set to a comma. So you > want to bind this variable in your function: > > (let ((csv-separators '(" "))) > (csv-kill-fields ...)) > Note however that it is a single character string, and that your fields > are separated by several. When I try it, it fails with csv-kill-fields > complaining about the number of columns. It is probably better to use > commas to separate the fields, ... I have read the documentation (that doesn't mean I understood it though). I have the csv separators specified in my .emacs file (it seem it will accept both " " and "," so csv-modes seems to read my files correctly. But I guess it is logical to specify these in the function in case I run it on a computer without these specified. I don't seem to get problems with csv-kill-fields complaining about number of columns but maybe I have just worked through it with trial and error and no real understanding. > Indeed, this is a good intension. You can separate interactive user > interface commands from the functions doing the actual work, so that you > can reuse the later. The interactive form allow you to merge both > usages. > > You only have to add the wanted parameter, and specify it in the > interactive form. You can also specify some parameters optional: > > > (defun nirs-data-clean (number-of-channels&optional replace-StO2-0-p) > ...) > > The simple interactive form would use a multiline string: > > (interactive "*nEnter number of channels (1-4): > sReplace 0 StO$_2$ values with na (y/n): ") > > Unfortunately, interactive doesn't provide for a 'boolean' input, so > we'll keep using the sophisticated form: When I said I can't do this I was looking to specify boolean input, good to know I shouldn't waste my time looking for it. I could have probably worked it out the way you showed but it would have probably taken me a few hours of testing so thanks for demonstrating that. Your final script seems more solid than mine, as in it behaves in the same way on either iteration even after undoing. It doesn't seem to work perfectly with across all channel options in some of the files I ran it one, but there are lots of ideas in there (such as temporarily using commas) for me to incorporate into my script so thanks again.