Emacs LISP Question

Emacs LISP Question

[Yakov Nekritch]

Hello,

I have the following emacs lisp question. 
How can I implement a  mouse pop-up menu, for a menu defined with 
easy-menu-define?

I was thinking about something like this:


(require 'xcscope )

(defun mouse-popup-cscopemenu ( )
 "Popup a cscope menu."
 (popup-menu  cscope:menu ) )


(define-key c-mode-base-map [S-down-mouse-3]  'mouse-popup-cscopemenu)


And  cscope:menu is defined in  xcscope.el .


However this does not work. When I press Shift-RightMouse I get:

Wrong type argument: commandp, mouse-popup-cscopemenu



Can anybody tell me what is wrong with my approach and how this function should 
be realised?
Any help will be appreciated.


Regards,
Yakov


==========================================================================
Dr. Yakov Nekrich		Phone:  +49-(0)228-734209
Computer Science Department	Fax:    +49-(0)228-734440
University of Bonn		e-mail: yasha@cs.uni-bonn.de
Römerstrasse 164,		http://theory.cs.uni-bonn.de/~yasha
53117 Bonn
Germany
==========================================================================

Re: Emacs LISP Question

[Klaus Zeitler]

>>>>> "Yakov" == Yakov Nekritch <yasha@theory.cs.uni-bonn.de> writes:
    Yakov> 
    Yakov> How can I implement a  mouse pop-up menu, for a menu defined with 
    Yakov> easy-menu-define?
    Yakov> 
    Yakov> (defun mouse-popup-cscopemenu ( )
    Yakov>  "Popup a cscope menu."
    Yakov>  (popup-menu  cscope:menu ) )
    Yakov> 
    Yakov> (define-key c-mode-base-map [S-down-mouse-3] 'mouse-popup-cscopemenu)

close, but I think the parameter is missing. Here's what I use:

(defun cscope-popup-menu-prompt (event)
  "Handle `mouse' events for cscope. EVENT is the mouse event."
  (interactive "e")
  (popup-menu cscope:menu event))

(defun cscope-popup-menu-no-prompt (event)
  "Handle `mouse' events for cscope. EVENT is the mouse event."
  (interactive "e")
  (let ((cscope-no-mouse-prompts t))
    (popup-menu cscope:menu event)))

(define-key c-mode-map   [H-mouse-1]   'cscope-popup-menu-prompt)
(define-key c-mode-map   [S-H-mouse-1] 'cscope-popup-menu-no-prompt)
(define-key c++-mode-map [H-mouse-1]   'cscope-popup-menu-prompt)
(define-key c++-mode-map [S-H-mouse-1] 'cscope-popup-menu-no-prompt)))


Cheers

Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
 ------------------------------------------
---
The trouble with doing something right the first time
is that nobody appreciates how difficult it was.

Emacs Lisp question

[Gian Uberto Lauri]

Could someone give me an explaination  of the meaning of the third and
fourth parameter of (put-text-property) ?

What  does it  means  using the  current  syntax table  for the  third
argument and a single number list for the fourth ?

Thanks in advance!

 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

Re: Emacs Lisp question

[Paolo Gianrossi]

GianUberto.Lauri@eng.it (Gian Uberto Lauri) writes:

> Could someone give me an explaination  of the meaning of the third and
> fourth parameter of (put-text-property) ?
> 
> What  does it  means  using the  current  syntax table  for the  third
> argument and a single number list for the fourth ?

don't see what you say in doc... Here's what I get:

        put-text-property is a built-in function.
        (put-text-property START END PROPERTY VALUE &optional OBJECT)

        Set one property of the text from START to END.
        The third and fourth arguments PROPERTY and VALUE
        specify the property to add.
        The optional fifth argument, OBJECT,
        is the string or buffer containing the text.
          
PROPERTY is the text property you want to put (e.g. intangible, ecc.. see the
emacs lisp manual for more), value is to what you want to set it... So, like

(put-text-property 0 20 'invisible t) 

will hide the first 20 chars in buffer..

hope this helps 
cheers
paolino

> 
> Thanks in advance!
> 
>  /\            ___
> /___/\__|_|\_|__|___Gian Uberto Lauri_____________________
>   //--\ | | \|  |   Integralista GNUslamico e fancazzista 
> \/

Emacs & Lisp question

[Ben Badgley]

Been using Google all day to no avail. I think it is pretty straight 
forward question.

Can you use compressed Lisp code? Will it evaluate, compile and evaluate?

The reason I ask is due to looking at the Emacs directory. The Lisp code 
directory sure does eat up a lot of space. So, it came to mind, "why not 
compress each of those buggers and let the interpreter use them from the 
archives?"

Will Emacs allow this? Further is it even doable beyond Emacs?

This may not be exactly the best place for me to ask, understood. I am 
trying to keep it related to Emacs on a general usage level. If we can 
use compressed libraries, wouldn't it be worth knowing? ;-)


---
Ben

Re: Emacs & Lisp question

[Tim X]

Ben Badgley <mortecanine@peoplepc.com> writes:

> Been using Google all day to no avail. I think it is pretty straight
> forward question.
>
> Can you use compressed Lisp code? Will it evaluate, compile and evaluate?
>
> The reason I ask is due to looking at the Emacs directory. The Lisp code
> directory sure does eat up a lot of space. So, it came to mind, "why not
> compress each of those buggers and let the interpreter use them from the
> archives?"
>
> Will Emacs allow this? Further is it even doable beyond Emacs?
>
> This may not be exactly the best place for me to ask, understood. I am
> trying to keep it related to Emacs on a general usage level. If we can use
> compressed libraries, wouldn't it be worth knowing? ;-)
>
>
> ---

When you do a make install of emacs 22 or 23, the *.el files are all
gzipped. As far as I know, emacs can handle gzipped *.el files, but the
*.elc files cannot be compressed. 

Compression can be a two edged sword. On one hand, you reduce storage
space. However, on the other, the files genraly must be uncompressed
before the application can interpret the code. This can cause overhead
that may slow down an applications execution. Of course, a lot of
variables come into play - to some extent, its similar to using
compression on an ssh connection. If the data your transferring around
is really large, compression is usually beneficial. However, if the data
you are transferring around is small, the overhead of compression and
uncompression may be higher than the benefits obtained by transferring
the file. Likewise, with emacs (or any other application that loads
libraries), if the library files are small, the overheads of compression
may slow down loading. If the libraries are large, the overheads of
compression may be offset by smaller storage/memory requirements etc. 

The other issue to consider and for which I have no data is to what
extent the data is able to be compressed. some data compresses really
well, while other data gives pretty poor results. A lot also depends on
the type of compression being used. 

And finally, you also have to consider the profiel of the system your
running on. If you have a system with very fast CPU and restricted
storage, compression may be beneficial. However, if you have slower CPUs
or large amounts of available storage with good disk IO etc, compression
may not actually be of any real benefit - maybe even a negative benefit.

Tim




-- 
tcross (at) rapttech dot com dot au

Re: Emacs & Lisp question

[Richard Riley]

Ben Badgley <mortecanine@peoplepc.com> writes:

> Been using Google all day to no avail. I think it is pretty straight 
> forward question.
>
> Can you use compressed Lisp code? Will it evaluate, compile and evaluate?
>
> The reason I ask is due to looking at the Emacs directory. The Lisp code 
> directory sure does eat up a lot of space. So, it came to mind, "why not 
> compress each of those buggers and let the interpreter use them from the 
> archives?"
>
> Will Emacs allow this? Further is it even doable beyond Emacs?
>
> This may not be exactly the best place for me to ask, understood. I am 
> trying to keep it related to Emacs on a general usage level. If we can 
> use compressed libraries, wouldn't it be worth knowing? ;-)
>

Emacs can use gzipped el files. e.g text-mode.el.gz.

However, at about 80 euro for a terabyte of hard drive, I wonder if its
a good investment of anyone times and effort at this stage when one
considers the overhead in start up time! A trade off only you can call.

Re: Emacs & Lisp question

[Ben Badgley]

Richard Riley:

"at about 80 euro for a terabyte of hard drive, I wonder if its
a good investment of anyone times and effort at this stage"


Fair enough, though some of us are indeed poor working class sods
that can not dole out about $160 USD just for giggles. :-) I have
a 160 Gig hard drive for the *nix system. I would love to slap a
new terabyte drive on board.

That is a modest drive for me. Had not expected to fill it up so 
quickly, Emacs and Lisp  in general have corrupted me. I'm gathering 
docs, libraries, hack tips, bit and bobbles like the hatter. That 
requires this odd thing called space.

And I actually had only ordered an 80 Gig. Not complaining, merely
saying. Guess the hardware vendor was thinking ahead for me. It worked
out to the same price.

At present, still awaiting this Change thing. Finding good steady
employ limits the wont. So, got to wait on getting the terabyte drive.



Tim X:

  "As far as I know, emacs can handle gzipped *.el files, but the
*.elc files cannot be compressed. "


Okay, gotcha. That means emacs is capable of x, not y. Which is good
to know before going out on a limb with crofting.

"On one hand, you reduce storage
space. However, on the other, the files genraly must be uncompressed
before the application can interpret the code. This can cause overhead
that may slow down an applications execution."

Alright, this is in general, as far as any application or program, or 
just emacs?

Apologies if it appears I'm being ignorant on this point. I am really 
genuinely curious and feel compelled to know specifics. If emacs needs 
to uncompress, okay no problem. If however it applies all the across the 
board, then I may not be able to implement as desired, or else find a 
way. So, this is really a learning quest, being new to emacs and Lisp in
general.

"The other issue to consider and for which I have no data is to what
extent the data is able to be compressed."

Well, from my limited point of view and reading of docs, text seems to 
compress quite well. And Lisp libraries are in fact text. That was 
something which prompted my thought of compressing them for use with 
emacs, and then led to the next thought, "hey why not do that for all 
Lisp code?"

Then again, I'm just a silly country boy coming unto all of this with 
fresh eyes. My views may be skewed and or incorrect. Please do tell me.
You don't learn by spewing sewage.

"profiel of the system your
running on. If you have a system with very fast CPU and restricted
storage, compression may be beneficial. However, if you have slower CPUs
or large amounts of available storage with good disk IO etc, compression
may not actually be of any real benefit - maybe even a negative benefit.
"

Yep. There are lots of variables to consider in this. I did not say 
there wasn't. I could suggest programmers do as programmers oft do, 
classify the variables. Create a common object such as computer type. 
Hm, but then that really installs Insanity version 0.01, doesn't it? :-)

Excuse me, off now to mow the lawn. Run it slow.

---
Ben

Re: Emacs & Lisp question

[Johan Bockgård]

Ben Badgley <mortecanine@peoplepc.com> writes:

> Can you use compressed Lisp code? Will it evaluate, compile and evaluate?
>
> The reason I ask is due to looking at the Emacs directory. The Lisp
> code directory sure does eat up a lot of space. So, it came to mind,
> "why not compress each of those buggers and let the interpreter use
> them from the archives?"

Emacs will handle compressed files automatically provided that
auto-compression-mode is used (it's on by default in Emacs >= 22). Also,
compressed .elc files should work just fine.

Emacs lisp question

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

I have a small ELlisp package that configures Emacs to use a vertical bar
caret.  It takes into account the differences between GNU Emacs and XEmacs.

In this package I have the following line.

(setq-default cursor-type '(bar . bk-preferred-caret-width))

bk-preferred-caret-width is a defcustom variable with a default value of 2.

Unfortunately this does not have the desired effect.  However, the following
does work.

(setq-default cursor-type '(bar . 2))

Can anyone suggest how I might get this to work?

Thanks.

[-- Attachment #2: Type: text/html, Size: 653 bytes --]

Emacs lisp question

[Ben]

I have a small ELlisp package that configures Emacs to use a vertical
bar caret.  It takes into account the differences between GNU Emacs
and XEmacs.

In this package I have the following line.

(setq-default cursor-type '(bar . bk-preferred-caret-width))

bk-preferred-caret-width is a defcustom variable with a default value
of 2.

Unfortunately this does not have the desired effect.  However, the
following does work.

(setq-default cursor-type '(bar . 2))

Can anyone suggest how I might get this to work?

Thanks.

Re: Emacs lisp question

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]


On Feb 6, 2011, at 5:04 PM, Ben Key wrote:

> I have a small ELlisp package that configures Emacs to use a vertical bar caret.  It takes into account the differences between GNU Emacs and XEmacs.
> 
> In this package I have the following line.
> 
> (setq-default cursor-type '(bar . bk-preferred-caret-width))
> 
> bk-preferred-caret-width is a defcustom variable with a default value of 2.
> 
> Unfortunately this does not have the desired effect.  However, the following does work.
> 
> (setq-default cursor-type '(bar . 2))
> 
> Can anyone suggest how I might get this to work?

Is it possible that bk-preferred-caret-width is being set *after* the line (setq-default ...) executes?

This could be, for example, if the package that defines bk-preferred-carent-wdith is
loaded after the (setq-default ...) line.

If so, then require the package that bk-preferred-caret -width before the seq-default line.

(I use the term "package"... in Emacs terms, this is usually an elisp file)

HTH,
Perry


[-- Attachment #2: Type: text/html, Size: 1468 bytes --]

RE: Emacs lisp question

[Drew Adams]

> (setq-default cursor-type '(bar . bk-preferred-caret-width))
> bk-preferred-caret-width is a defcustom variable with a
> default value of 2.
>
> Unfortunately this does not have the desired effect.
> However, the following does work.
> (setq-default cursor-type '(bar . 2))
>
> Can anyone suggest how I might get this to work?

Change
'(bar . bk-preferred-caret-width) to
`(bar . ,bk-preferred-caret-width)

The latter is the same as
(cons 'bar bk-preferred-caret-width), which you can also use if you prefer.

Simply quoting the cons cell
(bar . bk-preferred-caret-width)

evaluates to that cons cell itself.  And that cons cell has a car of `bar' and a
cdr that is the symbol `bk-preferred-caret-width'.

Re: Emacs lisp question

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Thanks.  That solved my problem.

On Sun, Feb 6, 2011 at 7:05 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > (setq-default cursor-type '(bar . bk-preferred-caret-width))
> > bk-preferred-caret-width is a defcustom variable with a
> > default value of 2.
> >
> > Unfortunately this does not have the desired effect.
> > However, the following does work.
> > (setq-default cursor-type '(bar . 2))
> >
> > Can anyone suggest how I might get this to work?
>
> Change
> '(bar . bk-preferred-caret-width) to
> `(bar . ,bk-preferred-caret-width)
>
> The latter is the same as
> (cons 'bar bk-preferred-caret-width), which you can also use if you prefer.
>
> Simply quoting the cons cell
> (bar . bk-preferred-caret-width)
>
> evaluates to that cons cell itself.  And that cons cell has a car of `bar'
> and a
> cdr that is the symbol `bk-preferred-caret-width'.
>
>

[-- Attachment #2: Type: text/html, Size: 1313 bytes --]

Re: Emacs lisp question

[Barry Margolin]

In article 
<28c7d37e-682e-41e2-b6cd-6fe18322949d@x11g2000yqc.googlegroups.com>,
 Ben <bkey76@gmail.com> wrote:

> I have a small ELlisp package that configures Emacs to use a vertical
> bar caret.  It takes into account the differences between GNU Emacs
> and XEmacs.
> 
> In this package I have the following line.
> 
> (setq-default cursor-type '(bar . bk-preferred-caret-width))
> 
> bk-preferred-caret-width is a defcustom variable with a default value
> of 2.
> 
> Unfortunately this does not have the desired effect.  However, the
> following does work.
> 
> (setq-default cursor-type '(bar . 2))
> 
> Can anyone suggest how I might get this to work?
> 
> Thanks.

(setq-default cursor-type `(bar . ,bk-preferred-caret-width))

However, this grabs the value of bk-preferred-caret-width when Emacs 
starts up.  Changing it later won't have any effect.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Emacs Lisp Question

[drain]

(defun copy-region-as-kill (beg end)
  "Save the region as if killed, but don't kill it.
     In Transient Mark mode, deactivate the mark.
     If `interprogram-cut-function' is non-nil, also save the text for a
window
     system cut and paste."
  (interactive "r")
  (if (eq last-command 'kill-region)
      (kill-append (filter-buffer-substring beg end) (< end beg))
    (kill-new (filter-buffer-substring beg end)))
  (if transient-mark-mode
      (setq deactivate-mark t))
  nil)

What is the "nil" doing at the end here? The syntax seems to be:

(defun copy-region-as-kill (beg end) [...] nil)



--
View this message in context: http://emacs.1067599.n5.nabble.com/Emacs-Lisp-Question-tp290340.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Emacs Lisp Question

[Thorsten Jolitz]

drain <aeuster@gmail.com> writes:

> (defun copy-region-as-kill (beg end)
>   "Save the region as if killed, but don't kill it.
>      In Transient Mark mode, deactivate the mark.
>      If `interprogram-cut-function' is non-nil, also save the text for a
> window
>      system cut and paste."
>   (interactive "r")
>   (if (eq last-command 'kill-region)
>       (kill-append (filter-buffer-substring beg end) (< end beg))
>     (kill-new (filter-buffer-substring beg end)))
>   (if transient-mark-mode
>       (setq deactivate-mark t))
>   nil)
>
> What is the "nil" doing at the end here? The syntax seems to be:
>
> (defun copy-region-as-kill (beg end) [...] nil)

I think the nil makes sure the function returns nil and not anything
killed in the function body or so. Its seems to be a function called
only for its side-effects, not for its return value.

-- 
cheers,
Thorsten

Re: Emacs Lisp Question

[Barry Margolin]

In article <mailman.2559.1372339138.22516.help-gnu-emacs@gnu.org>,
 drain <aeuster@gmail.com> wrote:

> (defun copy-region-as-kill (beg end)
>   "Save the region as if killed, but don't kill it.
>      In Transient Mark mode, deactivate the mark.
>      If `interprogram-cut-function' is non-nil, also save the text for a
> window
>      system cut and paste."
>   (interactive "r")
>   (if (eq last-command 'kill-region)
>       (kill-append (filter-buffer-substring beg end) (< end beg))
>     (kill-new (filter-buffer-substring beg end)))
>   (if transient-mark-mode
>       (setq deactivate-mark t))
>   nil)
> 
> What is the "nil" doing at the end here? The syntax seems to be:
> 
> (defun copy-region-as-kill (beg end) [...] nil)

I suspect it's left over from an old version of the function whose last 
expression returned the contents of the kill ring (probably before 
transient mark mode was added to Emacs). If you ran it interactively 
(e.g. in the *scratch* buffer), this would produce enormous amounts of 
output. So they put nil there to avoid this.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Emacs lisp question

[Matthias Pfeifer]

Hi there,

My emacs version is 25.0.91.1 and it's running on Windows 7. I have this
piece of Emacs lisp that does insert a template file in a fresh java-mode
buffer and start my "pre-processor"


(add-to-list 'auto-insert-alist '(".*\\.java$" . [ "template.java"
mp:java-preprocessor] ))

pre-processor looks like this:

(defun mp:java-preprocessor()
  (let ((classname (file-name-sans-extension (buffer-name)))
    (packagename (mp:predict-package-name-for-current-buffer)))
    (while (search-forward "CLASSNAME" nil t)
      (replace-match classname))
    (goto-char (point-min))
    (while (search-forward "PACKAGE" nil t)
      (replace-match packagename) ) ) )

(defun mp:predict-package-name-for-current-buffer ()
  "Simply take two parent directories and concat with . inbetween."
  (let* ((components (remq ""
               (reverse
                (split-string
                 (file-name-directory (buffer-file-name))
                 "\\/")))))
    (concat (nth 0 components) "." (nth 1 components) "." (nth 2
components))))


The problem is that the class-name and package-name are actually inserted
in capital letters while all file-names involved are writtn with lower-case
letters. So for a file with this path "c:/a/b/c/d/. The predict method
actually inserts: C.D.

Calling it outside the auto-insert environment eg by pressing C-x C-e
behind the closing paren belonging to the form in the
mp:predict-package-name-for-current-buffer function results into a lower
case letters package name.

Sorry for the bit lengthy question. I hope the question is clear: Why is
the result in capital letters in one case and in the case of the filename
letters in the other case?

Matthias

Re: Emacs lisp question

[Barry Margolin]

In article <mailman.616.1460989677.7477.help-gnu-emacs@gnu.org>,
 Matthias Pfeifer <mpfeifer77@gmail.com> wrote:

> Hi there,
> 
> My emacs version is 25.0.91.1 and it's running on Windows 7. I have this
> piece of Emacs lisp that does insert a template file in a fresh java-mode
> buffer and start my "pre-processor"
> 
> 
> (add-to-list 'auto-insert-alist '(".*\\.java$" . [ "template.java"
> mp:java-preprocessor] ))
> 
> pre-processor looks like this:
> 
> (defun mp:java-preprocessor()
>   (let ((classname (file-name-sans-extension (buffer-name)))
>     (packagename (mp:predict-package-name-for-current-buffer)))
>     (while (search-forward "CLASSNAME" nil t)
>       (replace-match classname))
>     (goto-char (point-min))
>     (while (search-forward "PACKAGE" nil t)
>       (replace-match packagename) ) ) )
> 
> (defun mp:predict-package-name-for-current-buffer ()
>   "Simply take two parent directories and concat with . inbetween."
>   (let* ((components (remq ""
>                (reverse
>                 (split-string
>                  (file-name-directory (buffer-file-name))
>                  "\\/")))))
>     (concat (nth 0 components) "." (nth 1 components) "." (nth 2
> components))))
> 
> 
> The problem is that the class-name and package-name are actually inserted
> in capital letters while all file-names involved are writtn with lower-case
> letters. So for a file with this path "c:/a/b/c/d/. The predict method
> actually inserts: C.D.

From the documentation of replace-match:

If second arg fixedcase is non-nil, do not alter case of replacement 
text.
Otherwise maybe capitalize the whole text, or maybe just word initials,
based on the replaced text.
If the replaced text has only capital letters
and has at least one multiletter word, convert newtext to all caps.
Otherwise if all words are capitalized in the replaced text,
capitalize each word in newtext.

So use (replace-match packagename t)

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Emacs lisp question

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 18, 2016 at 04:27:50PM +0200, Matthias Pfeifer wrote:
> Hi there,
> 
> My emacs version is 25.0.91.1 and it's running on Windows 7. I have this
> piece of Emacs lisp that does insert a template file in a fresh java-mode
> buffer and start my "pre-processor"
> 
> 
> (add-to-list 'auto-insert-alist '(".*\\.java$" . [ "template.java"
> mp:java-preprocessor] ))
> 
> pre-processor looks like this:
> 
> (defun mp:java-preprocessor()
>   (let ((classname (file-name-sans-extension (buffer-name)))
>     (packagename (mp:predict-package-name-for-current-buffer)))
>     (while (search-forward "CLASSNAME" nil t)
>       (replace-match classname))
>     (goto-char (point-min))
>     (while (search-forward "PACKAGE" nil t)
>       (replace-match packagename) ) ) )
> 
> (defun mp:predict-package-name-for-current-buffer ()
>   "Simply take two parent directories and concat with . inbetween."
>   (let* ((components (remq ""
>                (reverse
>                 (split-string
>                  (file-name-directory (buffer-file-name))
>                  "\\/")))))
>     (concat (nth 0 components) "." (nth 1 components) "." (nth 2
> components))))

[...]

Replace-match, by default, keeps the case of the match. So you need to
set the second argument of replace-match to false, like so:

  (replace-match package-name nil)

HTH
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlcVOqEACgkQBcgs9XrR2kbrRwCeIm2/D77KAEKqQfsLFKMOExhM
3mIAmgNoXAAtkInK3XhDhm2dYT9NsGEM
=9oMa
-----END PGP SIGNATURE-----

Re: Emacs lisp question

[Matthias Pfeifer]

Expect the unexpected! (Or i could have just spent more attention to the
replace-match docstring....)

Thanks for pointing out!

-- 
Matthias

Re: Emacs lisp question

[Alexis]

Matthias Pfeifer <mpfeifer77@gmail.com> writes:
 
>     (while (search-forward "CLASSNAME" nil t) 
>       (replace-match classname)) 
>     (goto-char (point-min)) (while (search-forward "PACKAGE" nil 
>     t) 
>       (replace-match packagename) ) ) )

Does changing these two calls to `replace-match` to:

    (replace-match classname t)

and

    (replace-match packagename t)

respectively, fix the issue?


Alexis.

Re: Emacs lisp question

[Matthias Pfeifer]

Hi Alexis,

that did the trick!

Thanks.

Matthias