variables set in prj.el bleeding thru to custom.el
> "Paul" == Paul Erion <[EMAIL PROTECTED]> writes: Paul> I have some variables being set in a prj.el file (e.g., Paul> 'jde-run-application-class') and only there. But when I Paul> exit XEmacs and look in '~/.xemacs/custom.el', well, there Paul> they are. Is this standard behaviour, or am I messing up Paul> somewhere? Most likely the latter. Please describe the exact steps that you used to set the variables in the project file so we can try to reproduce the problem. Paul Paul> I'm using JDE 2.3.3 and XEmacs 21.4.13 on WinXP Paul> Pro. This isn't a big deal, but it's not what I expected. Paul> Thanks, Paul> Paul Paul> __ Do you Yahoo!? New Paul> Yahoo! Photos - easier uploading and sharing. Paul> http://photos.yahoo.com/
Problem with abbrev
Hello,
I think I have another problem with abbrevs (beside the problem-report I've
filed some hours ago):
If I try to use a control-flow-expansion (for example "if" or "while", not
"for")), it works as expected, with one problem: It doubles if to ifif and
while to whilewhile.
Has anyone except me seen this strange behaviour?
I use JDE 2.3.3, XEmacs 21.4.14 on a Debian-System.
I have attached my .custom.el-file (I think I forgot this in the
problem-report, there I have additionally set abbrev-mode to 1 in the file).
If I use for in a comment, it remains unexpanded, but point moves several
lines forward.
If I use if or while in a comment, it gets doubled, but nothing else happens.
Have I found some bugs or is my system broken in some way?
Wolfgang(custom-set-variables
'(jde-javadoc-describe-constructor-template "\"* Constructs \"")
'(abbrev-file-name "~/.xemacs/abbrev_defs" t)
'(jde-run-working-directory "~/Programmieren/CivQuest/civquest/classes/")
'(jde-javadoc-return-tag-template "\"* @return \"")
'(jde-compile-option-debug (quote ("all" (t t t
'(jde-gen-cflow-enable t)
'(jde-javadoc-author-tag-template "")
'(jde-db-option-java-profile (quote (nil . "./java.prof")))
'(jde-gen-interface-buffer-template (quote ("(funcall jde-gen-boilerplate-function)"
"(jde-gen-get-package-statement)" "(progn (require 'jde-javadoc)
(jde-javadoc-insert-start-block))" "\" * \"" "(file-name-nondirectory
buffer-file-name) '>'n" "\" \" (jde-javadoc-insert-empty-line)" "\" \"
(jde-javadoc-insert-empty-line)" "\" \" (jde-javadoc-insert-empty-line)" "\" \"
(jde-javadoc-insert 'tempo-template-jde-javadoc-author-tag)" "\" \"
(jde-javadoc-insert 'tempo-template-jde-javadoc-version-tag)" "\" \"
(jde-javadoc-insert 'tempo-template-jde-javadoc-end-block \"*/\")" "'>'n" "\"public
interface \"" "(file-name-sans-extension (file-name-nondirectory buffer-file-name))"
"\" \" (jde-gen-get-extend-class)" "(if jde-gen-k&r " " ()" " '>'n)" "\"{\"'>'n"
"'>'p'n" "\"}\">" "\"// \"" "(file-name-sans-extension (file-name-nondirectory
buffer-file-name))" "'>'n")))
'(jde-run-option-java-profile (quote (nil . "./java.prof")))
'(jde-run-application-class "civquest.swing.CivQuest")
'(jde-javadoc-describe-class-template "")
'(jde-run-option-enable-assertions "Everywhere")
'(jde-complete-display-qualified-types nil)
'(jde-bug-vm-includes-jpda-p t)
'(jde-global-classpath (quote ("~/Programmieren/CivQuest"
"~/Programmieren/CivQuest/civquest/"
"~/Programmieren/CivQuest/civquest/classes/civquest/"
"~/Programmieren/CivQuest/civquest/classes/civquest/swing/"
"~/Programmieren/CivQuest/civquest/classes/civquest/swing/quadmap/"
"~/Programmieren/CivQuest/civquest/classes/civquest/parser/"
"~/Programmieren/CivQuest/civquest/classes/civquest/parser/ruleset/"
"~/Programmieren/CivQuest/civquest/classes/civquest/gameChange/")))
'(jde-build-function (quote (jde-ant-build)))
'(jde-javadoc-describe-field-template "")
'(jde-complete-function (quote jde-complete-in-line))
'(column-number-mode t)
'(jde-key-bindings (quote (("[? ? ?]" . jde-run-menu-run-applet) ("[? ? ?]" .
jde-build) ("[? ? ?]" . jde-compile) ("[? ? ?]" . jde-debug) ("[? ? ?]" .
jde-find) ("[? ? ?]" . jde-open-class-at-point) ("[? ? ? ]" . jde-bsh-run) ("[?
? ? ]" . jde-gen-println) ("[? ? ?]" . jde-help-browse-jdk-doc) ("[? ? ?]" .
jde-save-project) ("[? ? ?]" . jde-wiz-update-class-list) ("[? ? ?]" . jde-run)
("[? ? ?]" . speedbar-frame-mode) ("[? ? ?]" . jde-jdb-menu-debug-applet) ("[?
? ?]" . jde-help-symbol) ("[? ? ?]" . jde-show-superclass-source) ("[? ? ?]" .
jde-open-class-at-point) ("[? ? ?]" . jde-import-find-and-import) ("[? ? ?e]" .
jde-wiz-extend-abstract-class) ("[? ? ?f]" . jde-gen-try-finally-wrapper) ("[? ?
?i]" . jde-wiz-implement-interface) ("[? ? ?j]" . jde-javadoc-autodoc-at-line) ("[?
? ?o]" . jde-wiz-override-method) ("[? ? ?t]" . jde-gen-try-catch-wrapper) ("[? ?
?]" . jde-run-etrace-prev) ("[? ? ? ]" . jde-run-etrace-next) ("[(control c)
(control v) (control ?.)]" . jde-complete) ("[(control c) (control v) ?.]" .
jde-complete-in-line) ("[(control c) (control t) (control a)]" .
jde-gen-junit-add-test-to-suite) ("[(control c) (control t) (control j)]" .
jde-gen-junit-test-class-buffer) ("[(control c) (control t) (control c)]" .
jde-gen-class-buffer) ("[(control c) (control t) (control f)]" . jde-gen-method)
("[(control c) (control t) (control s)]" . jde-gen-to-string-method) ("[(control c)
(control t) (control i)]" . jde-gen-inner-class) ("[(control c) (control t) (control
r)]" . jde-gen-interface-buffer
'(jde-javadoc-param-tag-template "\"* @param \" name \" \"")
'(jde-ant-use-global-classpath t)
'(jde-gen-comments nil)
'(gnuserv-program (concat exec-directory "/gnuserv"))
'(jde-import-sorted-groups (quote asc))
'(jde-import-auto-sort t)
'(jde-run-option-vm-args (quote ("-ea")))
'(jde-gen-cflow-if (quote ("(if (jde-parse-comment-or-q
Re: variables set in prj.el bleeding thru to custom.el
Oops, I don't really remember how I initially created "prj.el" -- it was a while ago.
I
just happened to be looking over my "~/.xemacs/custom.el" file and noticed that
variables
that were being set in "prj.el" were also being (unexpectedly) set in "custom.el". And
deleting them (via editing) from "custom.el" did not make them go away (that is, the
code
to set those variables kept reappearing). If it's any help, I've included the contents
of "prj.el" (which resides in the directory "~/../Projects/WordDance/").
(jde-project-file-version "1.0")
(jde-set-variables
'(jde-ant-interactive-buildfile "~/../Projects/WordDance/Development/build.xml")
'(jde-global-classpath (quote ("~/../Projects/WordDance/class")))
'(jde-db-source-directories (quote ("~/../Projects/WordDance/source/main/"
"~/../Projects/WordDance/source/generated/"
"$JAVA_HOME/src")))
'(jde-run-application-class "com.mv.worddance.gc.WordDanceApp")
'(jde-run-working-directory "~/../Projects/WordDance/Deployment/")
)
--- Paul Kinnucan <[EMAIL PROTECTED]> wrote:
> > "Paul" == Paul Erion <[EMAIL PROTECTED]> writes:
>
> Paul> I have some variables being set in a prj.el file (e.g.,
> Paul> 'jde-run-application-class') and only there. But when I
> Paul> exit XEmacs and look in '~/.xemacs/custom.el', well, there
> Paul> they are. Is this standard behaviour, or am I messing up
> Paul> somewhere?
>
> Most likely the latter. Please describe the exact steps that you used
> to set the variables in the project file so we can try to reproduce
> the problem.
>
> Paul
>
> Paul> I'm using JDE 2.3.3 and XEmacs 21.4.13 on WinXP
> Paul> Pro. This isn't a big deal, but it's not what I expected.
>
> Paul> Thanks,
>
> Paul> Paul
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: variables set in prj.el bleeding thru to custom.el
> "Paul" == Paul Erion <[EMAIL PROTECTED]> writes: Paul> Oops, I don't really remember how I initially created Paul> "prj.el" -- it was a while ago. I just happened to be Paul> looking over my "~/.xemacs/custom.el" file and noticed that Paul> variables that were being set in "prj.el" were also being Paul> (unexpectedly) set in "custom.el". And deleting them (via Paul> editing) from "custom.el" did not make them go away (that Which is of course exactly not the way to delete them. The code in custom.el is automatically generated, depending on the settings of customization variables. Any edits that you make to the file will be overwritten by XEmacs next time you customize a variable, using the XEmacs customization interface. Paul> is, the code to set those variables kept reappearing). If Paul> it's any help, I've included the contents of "prj.el" (which Paul> resides in the directory "~/../Projects/WordDance/"). You must follow the procedure outlined in the JDEE User's Guide to set JDEE variables. If you have any questions about the procedure, feel free to ask. Paul
Re: variables set in prj.el bleeding thru to custom.el
On Mon, 22 Dec 2003 11:51:27 -0800 (PST), Paul Erion wrote: > Oops, I don't really remember how I initially created "prj.el" -- it was a while > ago. I > just happened to be looking over my "~/.xemacs/custom.el" file and noticed that > variables > that were being set in "prj.el" were also being (unexpectedly) set in "custom.el". > And > deleting them (via editing) from "custom.el" did not make them go away (that is, the > code > to set those variables kept reappearing). *if* you want to edit custom.el, do it outside emacs (and when no emacs is open). Usually its is a better idea to do M-x customize-variable your-variable and then select "erase customization" (you should not have opened any JDE-mode files while you do that so that you do not mess up any prj.el files) to remove entries from your custom.el. HTH, Michael
Problem-report concerning abbrev-file
> "Wolfgang" == Wolfgang Pausch <[EMAIL PROTECTED]> writes: Wolfgang> Hello, I have attached a problem-report concerning Wolfgang> writing and reading abbrev-files. I have also attached Wolfgang> my abbrev_defs-file. Wolfgang> Wolfgang PauschTo: [EMAIL PROTECTED] Subject: --text Wolfgang> follows this line-- Wolfgang> Please enter the details of your bug report here Wolfgang> Problem occured also under an earlier path of XEmacs Wolfgang> 21.4 Wolfgang> I defined some extra abbrevs (for texinfo-mode, Wolfgang> BTW). Then I wrote an abbrev-defining-file using Wolfgang> write-abbrev-file. When I read this file again using Wolfgang> read-abbrev-file, I get the error "Invalid read syntax: Wolfgang> Cannot read unreadable object". When I remove the Wolfgang> jde-mode-abbrev-table manually from the file and try Wolfgang> again, everything works fine. So I think the problem is Wolfgang> located somewhere in the way JDE defines its abbrevs. The JDEE uses functions to generate expansions for Java control flow abbreviations. It looks to me like XEmacs write-abbrev-file function is trying to write out the expansions as objects, regardless of whether they are strings or functions, depending on low-level I/O functions to use the correct Lisp "read" syntax for the objects being written out. I don't know whether this approach would work in principal for abbreviations that use functions to generate the expansions but it does not appear to be working in practise. Paul
