putting double quotes efficiently

putting double quotes efficiently

[C K Kashyap]

Hi,
I am looking for a way to transform

print line1
print line two
print line3

into

print "line1";
print "line two";
print "line3";

most efficiently. For the first quote of each line I place the cursor
before line1 and I set the mark and then move all the way down to just
before line3 and then do a C-x-r-t " <RET>
Then I do a regexp replace to change $ to ";

I'd like to do better. While at it, can I please also know how I can use
the line range in the mark set mode in user defined function?

Regards,
Kashyap

Re: putting double quotes efficiently

[Andreas Röhler]

Am 03.06.2013 07:43, schrieb C K Kashyap:
> Hi,
> I am looking for a way to transform
>
> print line1
> print line two
> print line3
>
> into
>
> print "line1";
> print "line two";
> print "line3";
>
> most efficiently. For the first quote of each line I place the cursor
> before line1 and I set the mark and then move all the way down to just
> before line3 and then do a C-x-r-t " <RET>
> Then I do a regexp replace to change $ to ";
>
> I'd like to do better. While at it, can I please also know how I can use
> the line range in the mark set mode in user defined function?
>
> Regards,
> Kashyap
>

M-x query-replace-regexp

^\([^ ]+\) \(.+\)
RET
\1 "\2;
RET

Re: putting double quotes efficiently

[Andreas Röhler]

Am 03.06.2013 09:26, schrieb Andreas Röhler:
> Am 03.06.2013 07:43, schrieb C K Kashyap:
>> Hi,
>> I am looking for a way to transform
>>
>> print line1
>> print line two
>> print line3
>>
>> into
>>
>> print "line1";
>> print "line two";
>> print "line3";
>>
>> most efficiently. For the first quote of each line I place the cursor
>> before line1 and I set the mark and then move all the way down to just
>> before line3 and then do a C-x-r-t " <RET>
>> Then I do a regexp replace to change $ to ";
>>
>> I'd like to do better. While at it, can I please also know how I can use
>> the line range in the mark set mode in user defined function?
>>
>> Regards,
>> Kashyap
>>
>
> M-x query-replace-regexp
>
> ^\([^ ]+\) \(.+\)
> RET
> \1 "\2;
> RET
>
>

resp. with missing " in replace expression

  \1 "\2";

Re: putting double quotes efficiently

[C K Kashyap]

Thanks Andreas,
This works.
Although I'd still like to know how to write custom function that work over
a marked region.
Regards,
Kashyap


On Mon, Jun 3, 2013 at 1:25 PM, Andreas Röhler <
andreas.roehler@easy-emacs.de> wrote:

> Am 03.06.2013 09:26, schrieb Andreas Röhler:
>
>  Am 03.06.2013 07:43, schrieb C K Kashyap:
>>
>>> Hi,
>>> I am looking for a way to transform
>>>
>>> print line1
>>> print line two
>>> print line3
>>>
>>> into
>>>
>>> print "line1";
>>> print "line two";
>>> print "line3";
>>>
>>> most efficiently. For the first quote of each line I place the cursor
>>> before line1 and I set the mark and then move all the way down to just
>>> before line3 and then do a C-x-r-t " <RET>
>>> Then I do a regexp replace to change $ to ";
>>>
>>> I'd like to do better. While at it, can I please also know how I can use
>>> the line range in the mark set mode in user defined function?
>>>
>>> Regards,
>>> Kashyap
>>>
>>>
>> M-x query-replace-regexp
>>
>> ^\([^ ]+\) \(.+\)
>> RET
>> \1 "\2;
>> RET
>>
>>
>>
> resp. with missing " in replace expression
>
>  \1 "\2";
>
>

Re: putting double quotes efficiently

[Andreas Röhler]

Am 03.06.2013 10:03, schrieb C K Kashyap:
> Thanks Andreas,
> This works.
> Although I'd still like to know how to write custom function that work over
> a marked region.

For example that way:

(defun my-New-Command (beg end)
   (interactive "r*")
   (save-excursion
     (save-restriction
       (narrow-to-region beg end)
       (goto-char beg)
       (DO-What-I-Want...

Recommend a walk through Info section Elisp, you will find plenty of useful stuff.

Cheers,

Andreas

Re: putting double quotes efficiently

[C K Kashyap]

Thanks Andreas,

This is exactly what I was looking for -

(defun kash-util-quotes (beg end st en)
  (interactive "r*\nsStart Pattern: \nsEnd Pattern: \n")
  (save-excursion
    (save-restriction
      (string-rectangle beg end st)
;      (narrow-to-region beg end)
      (goto-char beg)
      (replace-regexp "$" en)
      )))


Thanks,
Kashyap


On Mon, Jun 3, 2013 at 2:40 PM, Andreas Röhler <
andreas.roehler@easy-emacs.de> wrote:

> Am 03.06.2013 10:03, schrieb C K Kashyap:
>
>  Thanks Andreas,
>> This works.
>> Although I'd still like to know how to write custom function that work
>> over
>> a marked region.
>>
>
> For example that way:
>
> (defun my-New-Command (beg end)
>   (interactive "r*")
>   (save-excursion
>     (save-restriction
>       (narrow-to-region beg end)
>       (goto-char beg)
>       (DO-What-I-Want...
>
> Recommend a walk through Info section Elisp, you will find plenty of
> useful stuff.
>
> Cheers,
>
> Andreas
>

narrowing considered harmful (was: putting double quotes efficiently)

[Stefan Monnier]

BTW,

I tend to consider narrow-to-region in Elisp as a problem,so I encourage
you to write your code without it.

In your example, you don't need to narrow: the only thing you need is
to keep the "end" updated when the buffer is modified, which is easy to
do by changing the "end" form an integer to a marker.

Or alternatively, you can simply work your way backward, in which case
you don't need to worry about using a marker since the "start" position
to which you're going won't be affected by the buffer modifications.


        Stefan

Re: narrowing considered harmful

[Leo Liu]

On 2013-06-13 22:40 +0800, Stefan Monnier wrote:
> I tend to consider narrow-to-region in Elisp as a problem,so I encourage
> you to write your code without it.
>
> In your example, you don't need to narrow: the only thing you need is
> to keep the "end" updated when the buffer is modified, which is easy to
> do by changing the "end" form an integer to a marker.
>
> Or alternatively, you can simply work your way backward, in which case
> you don't need to worry about using a marker since the "start" position
> to which you're going won't be affected by the buffer modifications.

Do you think it is a good idea to add a macro along these lines:

(defmacro with-markers (markerlist &rest body)
  "Execute BODY with markers in MARKERLIST bound.
Each element of MARKERLIST is a symbol (which is bound to a
marker pointing to nowhere) or a list (SYMBOL EXPR) (which binds
SYMBOL to a marker pointing to the value of EXPR)."
  (declare (indent 1) (debug (sexp body)))
  `(let ,(mapcar (lambda (m)
                   (let ((m (if (listp m)
                                m
                              (list m))))
                     `(,(car m) (copy-marker ,(cadr m)))))
                 markerlist)
     (unwind-protect
         (progn ,@body)
       ,@(mapcar (lambda (m)
                   (let ((m (or (car-safe m) m)))
                     `(and (markerp ,m) (set-marker ,m nil))))
                 markerlist))))

Leo

Re: narrowing considered harmful

[Stefan Monnier]

> Do you think it is a good idea to add a macro along these lines:
> (defmacro with-markers (markerlist &rest body)

I don't see the point.  It only saves you the calls to `copy-marker'.


        Stefan

Re: narrowing considered harmful

[Leo Liu]

On 2013-06-14 21:00 +0800, Stefan Monnier wrote:
> I don't see the point.  It only saves you the calls to `copy-marker'.

What about set-marker to nil?

Leo

Re: narrowing considered harmful

[Stefan Monnier]

>> I don't see the point.  It only saves you the calls to `copy-marker'.
> What about set-marker to nil?

I wouldn't worry about it.  It can even be a bad idea (set-marker to
nil requires scanning the whole list of markers, so it can take a while.
It can be more efficient to let the GC collect them later on).


        Stefan

Re: narrowing considered harmful

[Leo Liu]

On 2013-06-15 10:43 +0800, Stefan Monnier wrote:
> I wouldn't worry about it.  It can even be a bad idea (set-marker to
> nil requires scanning the whole list of markers, so it can take a while.
> It can be more efficient to let the GC collect them later on).
>
>
>         Stefan

Good to know this. The manual contains this:

,----[ (info "(elisp)Overview of Markers") ]
|      ;; When you are finished using a marker, make it point nowhere.
|      (set-marker m1 nil)
|           => #<marker in no buffer>
`----

Should that be changed?

Leo

Re: narrowing considered harmful

[Stefan Monnier]

>> I wouldn't worry about it.  It can even be a bad idea (set-marker to
>> nil requires scanning the whole list of markers, so it can take a while.
>> It can be more efficient to let the GC collect them later on).
>> 
>> 
>> Stefan

> Good to know this. The manual contains this:

> ,----[ (info "(elisp)Overview of Markers") ]
> |      ;; When you are finished using a marker, make it point nowhere.
> |      (set-marker m1 nil)
> |           => #<marker in no buffer>
> `----

> Should that be changed?

Not necessarily: whether it's better to nil them explicitly or to leave
them as they are depends on the specific case.


        Stefan

RE: narrowing considered harmful

[Drew Adams]

> >> It can even be a bad idea (set-marker to nil requires scanning
> >> the whole list of markers, so it can take a while.  It can be
> >> more efficient to let the GC collect them later on).
> 
> > Good to know this. The manual contains this:
> 
> > ,----[ (info "(elisp)Overview of Markers") ]
> > |      ;; When you are finished using a marker, make it point nowhere.
> > |      (set-marker m1 nil)
> > |           => #<marker in no buffer>
> > `----
> 
> > Should that be changed?
> 
> Not necessarily: whether it's better to nil them explicitly or to leave
> them as they are depends on the specific case.

For which some guidance can be given (in the manual)?

Perhaps say something like what you said here, regarding performance
as one reason you might not want to "make it point nowhere"?

The text is currently imperative: "make it point nowhere".
What you are suggesting is something different.
Please consider providing some nuance (better guidance).

Re: narrowing considered harmful

[Stefan Monnier]

> For which some guidance can be given (in the manual)?

Not important enough, no.


        Stefan