Bug#540321: packaging status of cedet in Debian
Feel free :) . On Thu, Nov 26, 2009 at 12:02 PM, RISKÓ Gergely gerg...@risko.hu wrote: I don't have time to maintain the Debian package for CEDET anymore, so it will most likely need to be orphaned. Thanks for the reply and your work on the package until now. Is it okay then if I upload a new upstream version designating me as the new maintainer? Gergely -- Michael Olson || http://mwolson.org/ Projects: Emacs, Muse, EMMS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540321: packaging status of cedet in Debian
I don't have time to maintain the Debian package for CEDET anymore, so it will most likely need to be orphaned. On Thu, Nov 26, 2009 at 12:58 AM, RISKÓ Gergely gerg...@risko.hu wrote: Hi Michael, Thank you for your packaging work on cedet, I made some patches as I already stated: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540321 May I ask you when you will have time to have a look on them? I am happy to help you with this package, if it is needed. If you are reading this, please at least send a tiny reply, so I will know that my message got there and you have read it. Thanks, Gergely -- Michael Olson || http://mwolson.org/ Projects: Emacs, Muse, EMMS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490722: semantic: invalid read syntax
Joerg Jaspert [EMAIL PROTECTED] writes: semantic-c.el:42:13:Warning: /usr/share/emacs-snapshot/site-lisp/semantic/bovine/semantic-c.el: `semantic-tag-static-p' obsoletes overload `tag-static' semantic-c.el:42:21:Error: Invalid read syntax: ) This is a bug of emacs-snapshot, not semantic. The above compilation error is triggered by the following kind of statement: (eval-when-compile (require 'something) (require 'something-else)) The problem goes away when the lines are changed to: (eval-when-compile (require 'something)) (eval-when-compile (require 'something-else)) This is a regression and needs to be fixed in upstream Emacs. -- | Michael Olson | FSF Associate Member #652 | | http://mwolson.org/ | Hobbies: Lisp, HCoop | | Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | `---' pgpfTJ0CrdGvX.pgp Description: PGP signature
Bug#477067: O: emacs-wiki
Package: wnpp Severity: normal This software is no longer being maintained, and its functionality is now implemented by the muse-el package. Users of emacs-wiki are strongly encouraged to switch to muse-el. I recommend that this package be removed from future releases of Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436510: #title tag and lisp code evaluation order
Junichi Uekawa [EMAIL PROTECTED] writes: My suggestion is to do something like this: i.e. do not use variables within #title. 1. The #title line isn't long. 2. The order of operation when evaluating lisp tags is clear. 3. You don't have to insert a standard template in each file. The content of meetings can be only that which actually changes between meetings. 4. If you decide you want the meeting boilerplate to look different, you only have to change one file rather than many. For now, I've addressed the problem upstream by making Muse not interpret lisp tags in #title lines or comments when coloring the buffer. The reason for this is that the alternative -- modifying the publishing process to support evaluating lisp tags in #title lines -- would be time-consuming when publishing, because Muse would have to examine every directive for lisp tags. What do you think? I don't quite understand what you are trying to say. Are you trying to tell me do not use lisp values within #title? The change sounds quite drastic and provides no win from the end-user POV. The fix required is: for publishing (to html): current behavior of evaluating #title after everything else is acceptable Oh. I didn't realize that before. Since the behavior you want is already happening at publish time, it is OK to implement it this way when editing the buffer as well. for the buffer editing (font-lock): re-evaluate #title after everything else is evaluated. (this is what's broken in the recent release) (current workaround, run C-cC-l twice when visiting the buffer) Thanks for the concise summary. I've now fixed this upstream, and the fix will be present in the next release (which ought to happen later this week). -- Michael Olson -- FSF Associate Member #652 | http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | | Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | pgpRYM1lusaCZ.pgp Description: PGP signature
Bug#436510: #title tag and lisp code evaluation order
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, When title contains some lisp code, it is evaluated after the content is evaluated. However, when editing the file (C-cC-l), the title will initially show 'Invalid Lisp Code' error. Hmm, I hadn't considered this use case before. Do you use the lisp tag for #title on every page, or just some of them? Do you expect the lisp tag to be evaluated when publishing, or left verbatim (but with the angle brackets escaped)? I expect lisp tag to be evaluated. I use it so that it is possible to configure the values for the page in one place. '#title' seems to be evaluated last, and thus putting the setq in the #title has never worked. This is why lisp to do the setq is on the second line. Try the following for a more lively example: --- #title Meeting number lispnumber/lisp: lispyear/lisp-lispmonth/lisp-lispday/lisp lisp(progn (setq year 2007 month 12 date 15 number 10) )/lisp This is meeting number lispnumber/lisp You are expected to turn in your entry form by lisp(- date 2)/lisp My suggestion is to do something like this: - Make a header file that looks like this (call it meeting-header.html): _ !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.0 Transitional//EN\ html head titlelisp (format Meeting number %s: %s-%s-%s (muse-publishing-directive number) (muse-publishing-directive month) (muse-publishing-directive year) (muse-publishing-directive day)) /lisp/title [...other header stuff...] /head body h1lisp (format Meeting number %s: %s-%s-%s (muse-publishing-directive number) (muse-publishing-directive month) (muse-publishing-directive year) (muse-publishing-directive day)) /lisp/h1 pThis is meeting number lisp(muse-publishing-directive number)/lisp /p pYou are expected to turn in your entry form by lisp(- (string-to-number (muse-publishing-directive date)) 2)/lisp /p _ - Make meeting files that look like this: _ #year 2007 #month 12 #date 15 #number 10 [contents of meeting] _ - Derive a meeting style like this in your Muse configuration: (muse-derive-style meeting xhtml :header /path/to/meeting-header.html) - Use this style when publishing meetings. (setq muse-project-alist '((Meetings (/path/to/meetings) (:base meeting :path /path/to/meeting-output-dir This has several advantages. 1. The #title line isn't long. 2. The order of operation when evaluating lisp tags is clear. 3. You don't have to insert a standard template in each file. The content of meetings can be only that which actually changes between meetings. 4. If you decide you want the meeting boilerplate to look different, you only have to change one file rather than many. For now, I've addressed the problem upstream by making Muse not interpret lisp tags in #title lines or comments when coloring the buffer. The reason for this is that the alternative -- modifying the publishing process to support evaluating lisp tags in #title lines -- would be time-consuming when publishing, because Muse would have to examine every directive for lisp tags. What do you think? -- Michael Olson -- FSF Associate Member #652 | http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | | Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | pgp89uv9lu970.pgp Description: PGP signature
Bug#436510: #title tag and lisp code evaluation order
Junichi Uekawa [EMAIL PROTECTED] writes: When title contains some lisp code, it is evaluated after the content is evaluated. However, when editing the file (C-cC-l), the title will initially show 'Invalid Lisp Code' error. testcase: --- #title lispvalue/lisp lisp(progn (setq value 10) )/lisp hello world lispvalue/lisp Hmm, I hadn't considered this use case before. Do you use the lisp tag for #title on every page, or just some of them? Do you expect the lisp tag to be evaluated when publishing, or left verbatim (but with the angle brackets escaped)? -- Michael Olson -- FSF Associate Member #652 | http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | | Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | pgpy1cDOjUYQc.pgp Description: PGP signature
Bug#434516: emacs-wiki: emacs22 already includes wiki-mode
Rebecca Breu [EMAIL PROTECTED] (24/07/2007) wrote: Package: emacs-wiki Version: 2.72-1 Severity: grave Justification: renders package unusable Emacs 22 already includes wiki-mode. If emacs 22 is installed, emacs-wiki breaks usage of wiki-mode. On starting wiki-mode, you then get eval: Recursive `require' for feature `sb-info' Purging emacs-wiki fixes this. sb-info.el is a file in the speedbar package. Can you please tell me which version of the speedbar package you are using? There was an error to this effect that was fixed in the speedbar 1.0pre4-1 upload. I very highly doubt that this is a problem in emacs-wiki. -- Michael Olson -- FSF Associate Member #652 | http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | | Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | pgpJDlih7uvcd.pgp Description: PGP signature
Bug#414329: This was a speedbar bug, not an ecb bug
reassign 414329 speedbar close 414329 thanks This bug is fixed in cedet-1.0pre4-1. -- Michael Olson -- FSF Associate Member #652 | http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | | Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431649: marked as done ([PATCH] dictionary-el post-install fails when /bin/sh is dash)
[EMAIL PROTECTED] (Aaron M. Ucko) writes: Apologies for accidentally misspelling your name in the changelog entry for -6; I've already uploaded a -7 release with the correct spelling. No worries. Thanks for the quick response to the bug report. -- Michael Olson -- FSF Associate Member #652 | http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | | Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner | pgpd8u3WBAjPs.pgp Description: PGP signature
Bug#431649: [PATCH] dictionary-el post-install fails when /bin/sh is dash
[EMAIL PROTECTED] (Aaron M. Ucko) writes:
Michael Olson [EMAIL PROTECTED] writes:
I notice that when I install dictionary-el 1.8.7-5 on a sustem that
has dash as /bin/sh, post-install fails with the following error.
I cannot reproduce this misbehavior with any shell; do you perhaps
have an unusual filesystem layout, in which parts of /usr/share are
symlinks to other places?
Ah, good catch. I do in fact have /usr/share/emacs-snapshot -
/usr/local/share/emacs/22.1.50. So it wasn't a shell issue after all.
Also, do you actually need the full
subshell/loop setup, or does it suffice to run
ln -s ${ELDIR}/emacs/site-lisp/${PACKAGE}/*.el .
That doesn't quite work. But it does turn out that the subshell and
loop aren't really needed. I've attached a more minimalistic patch that
does work for me, with xemacs21, emacs-snapshot, and emacs21.
diff -ur dictionary-el-1.8.7/debian/changelog dictionary-el-1.8.7.new/debian/changelog
--- dictionary-el-1.8.7/debian/changelog 2007-07-04 00:12:39.0 -0400
+++ dictionary-el-1.8.7.new/debian/changelog 2007-07-04 12:14:13.0 -0400
@@ -1,3 +1,12 @@
+dictionary-el (1.8.7-6) UNRELEASED; urgency=low
+
+ [ Michael Olson ]
+ * debian/emacsen-install: Symlink files correctly. This fixes a bug
+where the post-install process would error out if /usr/share/${FLAVOR}
+was a symlink.
+
+ --
+
dictionary-el (1.8.7-5) unstable; urgency=low
* dictionary.el: per Kevin Ryde, mark the connection as safe to kill
diff -ur dictionary-el-1.8.7/debian/emacsen-install dictionary-el-1.8.7.new/debian/emacsen-install
--- dictionary-el-1.8.7/debian/emacsen-install 2007-07-04 00:12:39.0 -0400
+++ dictionary-el-1.8.7.new/debian/emacsen-install 2007-07-04 12:15:23.0 -0400
@@ -33,7 +33,7 @@
install -m 755 -d ${ELCDIR}
cd ${ELCDIR}
rm -f *.el
-ln -s ../../../emacs/site-lisp/${PACKAGE}/*.el .
+ln -s ${ELDIR}/*.el .
FILES=`echo *.el`
cat EOF path.el
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
Bug#431649: [PATCH] dictionary-el post-install fails when /bin/sh is dash
Package: dictionary-el
Version: 1.8.7-5ubuntu1
Severity: important
I notice that when I install dictionary-el 1.8.7-5 on a sustem that
has dash as /bin/sh, post-install fails with the following error.
Setting up dictionary-el (1.8.7-4) ...
install/dictionary-el: Handling install for emacsen flavor emacs-snapshot
Error occurred processing *.el: File error ((Opening input file no such
file or directory /usr/share/emacs-snapshot/site-lisp/dictionary-el/*.el))
I have looked into the problem and found a solution. A patch to fix
the problem will be attached to this bug. I have tested this patch
successfully, as can be seen by the version string in this report :^)
.
-- System Information:
Debian Release: lenny/sid
APT prefers gutsy-updates
APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500,
'gutsy-backports'), (500, 'gutsy')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-7-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dictionary-el depends on:
ii emacs-snapshot [emacsen 1.0 The GNU Emacs editor (development
ii emacs21 [emacsen] 21.4a+1-5ubuntu1 The GNU Emacs editor
ii xemacs21-mule [emacsen] 21.4.20-1highly customizable text editor --
Versions of packages dictionary-el recommends:
ii emacs-snapshot 1.0 The GNU Emacs editor (development
ii emacs21 21.4a+1-5ubuntu1 The GNU Emacs editor
-- no debconf information
diff -ur dictionary-el-1.8.7/debian/changelog dictionary-el-1.8.7.new/debian/changelog
--- dictionary-el-1.8.7/debian/changelog 2007-07-04 00:12:39.0 -0400
+++ dictionary-el-1.8.7.new/debian/changelog 2007-07-04 00:52:13.0 -0400
@@ -1,3 +1,11 @@
+dictionary-el (1.8.7-6) UNRELEASED; urgency=low
+
+ [ Michael Olson ]
+ * debian/emacsen-install: Symlink files correctly. This fixes a bug
+where the post-install process would error out if /bin/sh is dash.
+
+ --
+
dictionary-el (1.8.7-5) unstable; urgency=low
* dictionary.el: per Kevin Ryde, mark the connection as safe to kill
Only in dictionary-el-1.8.7/debian: dictionary-el
Only in dictionary-el-1.8.7/debian: dictionary-el.postinst.debhelper
Only in dictionary-el-1.8.7/debian: dictionary-el.prerm.debhelper
diff -ur dictionary-el-1.8.7/debian/emacsen-install dictionary-el-1.8.7.new/debian/emacsen-install
--- dictionary-el-1.8.7/debian/emacsen-install 2007-07-04 00:12:39.0 -0400
+++ dictionary-el-1.8.7.new/debian/emacsen-install 2007-07-04 00:49:50.0 -0400
@@ -33,7 +33,11 @@
install -m 755 -d ${ELCDIR}
cd ${ELCDIR}
rm -f *.el
-ln -s ../../../emacs/site-lisp/${PACKAGE}/*.el .
+( cd ${ELDIR}
+for f in *.el; do
+ln -sf ${ELDIR}/${f} ${ELCDIR}/${f}
+done
+)
FILES=`echo *.el`
cat EOF path.el
Only in dictionary-el-1.8.7/debian: files
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop| |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
Bug#409714: pathconfig file is not sufficient to build many SML/NJ programs
Package: smlnj Version: 110.60-1 I noticed that the version of /usr/lib/smlnj/lib/pathconfig included with the 110.60-1 package is missing several entries that are needed by many SML/NJ programs, including the examples that come with the smlnj package. One way of getting around this would be to modify the postinst for each library (libsmlnj-smlnj, ml-yacc, etc.) to add the entries. Alternatively, an easier way of dealing with this is to ship a base version of the file in smlnj-runtime. I've attached a patch against 110.60-1 which does the latter. Packages built using this patch may be found at http://kilobyte.rcac.purdue.edu/ubuntu. An additional problem fixed in this patch was the removal of the debian/rules entry that created symlinks with invalid destinations (at least, once they were installed, they became invalid). Here are a few sample changelog entries. * debian/rules: Remove rule that litters the library path with broken symlinks. Install a pathconfig file to use as a template so that directives commonly used in sources.cm files are resolved properly. * debian/smlnj-runtime.postrm: Only remove /usr/lib/smlnj/lib/ pathconfig if it hasn't been removed already. This fixes an error in postinstall. fix-smlnj-pathconfig.patch Description: Binary data
Bug#323741: Please don't allow 'emacsen' as build-dependency
Sven Joachim [EMAIL PROTECTED] writes: I think it is not correct to use emacs21 | emacsen in the Build-Depends-Indep field, since, AFIK, the xemacs packages provide emacsen but not the /usr/bin/emacs alternative. It would be better to use emacs21 | emacs22 | emacs-snapshot instead (the latter works, I just verified it). The package will still FTBFS if the system administrator has manually set the emacs alternative to some not-really-Emacs-editor as zile or e3, but that's probably too weird to bother about. Yuck. Still, I guess the only real alternative would be to use some sort of automake script to figure out where a suitable Emacs (or XEmacs) binary is, and I don't really want to complicate my build system. I'll have to give it some thought. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC |_] | \| |_| Reclaim your digital rights by eliminating DRM. See http://www.defectivebydesign.org/what_is_drm for details. pgplNMvzOjbFy.pgp Description: PGP signature
Bug#391525: emacs-wiki: can not enter emacs-wiki-mode on Emacs 22
intrigeri wrote: Same problem when trying to enter emacs-wiki-mode (package 2.71-1) in emacs-snapshot-gtk (package 1:20061003-1). I fixed it the same way as muse-el author fixed it upstream (#391186), and the same way I fixed #391408 on my local planner-el. Patch for emacs-wiki follows: Good catch! I had forgotten about this possibility. I've sent a reminder to myself to fix this on Monday. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391186: planner-el: Can not activate planner-mode on Emacs 22 (emacs-snapshot)
intrigeri wrote: I get the same error. After : - applying your upstream fix to my installed planner-el 3.41-2 package (i.e. unquoting beginning-of-line in planner.el's planner-setup-highlighting function definition) - obviously deleting planner.elc so that my changes are useful... I still get the same error. A bit of debugging shows me that the muse-use-font-lock function, defined in muse-colors.el, is somehow called when entering planner-mode, and... it has the same quoting beginning-of-line bug. I fixed it the same way as you fixed planner.el and it now works as it should. Patch for muse-el follows: Yes, I forgot to mention that the bug also exists in muse-el, and that I've also fixed that in muse-el upstream. Both muse-el and planner-el will get new debian packages, possibly on Monday. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391186: planner-el: Can not activate planner-mode on Emacs 22 (emacs-snapshot)
Kaloian Doganov wrote: Package: planner-el Version: 3.41-2 Severity: important Visiting file in planner-mode raises an error with the following backtrace: Debugger entered--Lisp error: (wrong-type-argument symbolp (quote beginning-of-line)) [snip] This happened after the last update of emacs-snapshot package. Thanks for the report. I fixed this in the development version upstream, and I;ll provide a fixed debian package shortly, once my machine is back to normal. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382695: erc: bbdb module not loading
close #382695 thanks [EMAIL PROTECTED] (Sebastian P. Luque) writes: Package: erc Version: 5.1.3-2 Severity: normal The bbdb module cannot be loaded when doing (require 'erc-bbdb), or when trying to add it through the customize interface. This is the trace obtained when doing the former: Debugger entered--Lisp error: (void-variable erc-bbdb) (require erc-bbdb) eval((require erc-bbdb)) eval-expression((require erc-bbdb) nil) call-interactively(eval-expression) This has been fixed in the 5.1.4-3 package. The problem was that the erc-bbdb.el file was not being installed properly to /usr/share/emacs-package/site-lisp. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350515: I guess this bug is not fixed.
reassign #350515 muse-el thanks [EMAIL PROTECTED] (Emilio Jesús Gallego Arias) writes: This bug keeps happening, but I actually have found its root. The problem is present when the user hasn't loaded the planner 'planner-publish file and has a setup as suggested in the docs: [snip] This is actually a bug in Muse. It has been fixed in the development version of Muse, and the fix will be included in the next Muse release. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | IRC: freenode.net/mwolson: #emacs, #hcoop, #muse, #PurdueLUG |_] | \| |_| Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
Bug#357949: muse-el: muse-http.el is not functional
Junichi Uekawa [EMAIL PROTECTED] writes: That might be a reason to separate the directory in the source tarball, but splitting it in the binary distribution in Debian package is making it harder for users to use the tool. The files in contrib/ aren't byte-compiled, and not assigning the copyright to FSF is not really a reason to not byte-compile the code (in terms of Debian integration, and from the perspective of Debian user). I've made an updated muse-el Debian package available at http://www.mwolson.org/debian that should address these concerns. I think I'll wait to have it uploaded to Debian until I can get the NEWS updated (which will probably happen just before the next release). -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Muse, Planner, ERC, EMMS /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net pgpj0DX6yGaF3.pgp Description: PGP signature
Bug#357949: muse-el: muse-http.el is not functional
Junichi Uekawa [EMAIL PROTECTED] writes: Okay, consider it a bugreport requesting improvement in your packaing of muse-http.el. First: (load-library muse-http) Debugger entered--Lisp error: (file-error Cannot open load file httpd) require(httpd) fails due to the fact that load-path does not include contrib/ directory, nor is it byte-compiled. Personally I don't think there is much point in splitting it up into contrib/ directory, so merging them into the one directory proper, might be a way to go. The reason for putting those files in the contrib/ directory is that their copyright has not yet been assigned to the Free Software Foundation, while everything in lisp/ has been assigned. I might eventually contact the original author once more pressing things are taken care of. I'm not sure what the best practice is concerning the inclusion of the contrib directory in load-path. Second, trying to work around the first problem: (load-file /usr/share/emacs/site-lisp/muse-el/contrib/httpd.el) t (load-file /usr/share/emacs/site-lisp/muse-el/contrib/cgi.el) t (load-library muse-http) t (httpd-start) Debugger entered--Lisp error: (void-function open-network-stream-server) (open-network-stream-server httpd (generate-new-buffer httpd) port nil (quote httpd-serve)) (setq httpd-process (open-network-stream-server httpd (generate-new-buffer httpd) port nil (quote httpd-serve))) httpd-start() eval((httpd-start)) This should be fixed in development versions of Muse (not in the Debian package yet). -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Muse, Planner, ERC, EMMS /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net pgp2rGdcaVW3t.pgp Description: PGP signature
Bug#354116: emacs-wiki NEWS not too useful without guidance on how to migrate
Junichi Uekawa [EMAIL PROTECTED] writes: I'm now checking out muse and what it can do for me; however I found that muse is not a full-fledged wiki editing engine like elserv-wiki. elserv-wiki handles HTTP requests and allows editing of the wiki page over http, convenient for when slapping up some page in a local workgroup. Check out httpd.el and cgi.el in the contrib/ directory. Together with muse-http.el, they should provide this functionality. I'm interested in hearing whether this works or not, since I've never used it before. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, IRC, EMMS, anime, manga, Debian /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net pgpqDZIMa8TaV.pgp Description: PGP signature
Bug#354116: emacs-wiki NEWS not too useful without guidance on how to migrate
Junichi Uekawa [EMAIL PROTECTED] writes: 1. the package name is muse-el, which is not mentioned anywhere. Good point. 2. there isn't any documentation on compatiblity. It's hard to know exactly what sorts of compatibility issues need to be mentioned. Can you please provide some additional examples of information on this topic that you would like to see? Do I have a compatible command for emacs-wiki-find-file muse-project-find-file 3. is there a elserv-wiki replacement for muse-el? I'm not sure in what ways elserv interacted with emacs-wiki, so it's hard to answer that. Muse comes with a muse-http.el file that can turn Emacs into a webserver, much like the emacs-wiki-httpd.el module, except that it doesn't need an external Python script. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, manga, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net pgpvCtBdhPRoU.pgp Description: PGP signature
Bug#322484: Bugs to be fixed in coming planner-el_3.40-1 package
close 322484 close 337002 close 337812 thanks These bugs will be fixed with the upload of the planner-el_3.40-1 Debian package. I just received the notice of its successful upload, so it should be available shortly. If there are any further concerns with these items, feel free to re-open. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: manga, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327812: Bugs to be fixed in coming planner-el_3.40-1 package
close 327812 thanks This should be addressed by the new 3.40-1 planner-el package, which has been uploaded. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: manga, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337812: Accidental bug closure
reopen 337812 thanks Terribly sorry about that! I typed in the wrong bug number when closing a few planner-el bugs. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: manga, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340620: muse-el: Doesn't escape specials when publish using the latex style
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Hankins [EMAIL PROTECTED] writes: When publishing from muse to latex files specials like '\' and '' aren't escaped. I'm not enough of an elisp hacker to know what's wrong, but '\', at least, is in the muse-latex-markup-specials table, and putting '' in as well doesn't cause it to be handled either. Thanks for the report. The reason for this behavior is that '\' and '' are used by some of the LaTeX markup functions, like in tables, so I can't just escape them throughout the entire document. This is a limitation that I am working to overcome in Muse 3.03, but I haven't perfected it yet. - -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: manga, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDiQJ0+1Ho2POo0xkRApoFAJsHSIZC5r4W7CofFCOTKepQd5onbQCfbWzR O57FPF6LwOpP5qiC3baNCto= =C2HD -END PGP SIGNATURE-
Bug#339920: emacs-snapshot: font color problems with gnus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm noticing this problem as well. My Message buffers are being colorized, but my Group buffer is not being colorized. Bold text is shown, but no colors. Setting jit-lock-stealth-time has no effect. This problem also affects ERC buffers -- no colors are shown there, either. Muse and Planner buffers still show colors, though. Wonder what could be causing this. - -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgC2P+1Ho2POo0xkRAoefAJ4mIhVxOVCIuKOakdGWpUYu3dg5IACfe+Wz ygcjVU9ZTS8gzNZVszenrCE= =C8K8 -END PGP SIGNATURE-
Bug#339920: emacs-snapshot: font color problems with gnus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Romain Francoise [EMAIL PROTECTED] writes: Oh, I think I managed to reproduce this: browsing Michael's config (yay for .emacs sharing) I noticed that he uses hi-lock-mode. And indeed, enabling hi-lock-mode makes fontification disappear from some buffers in Gnus. Indeed, getting rid of hi-lock-mode makes ERC and Gnus colorize buffers normally. Thanks! - -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: manga, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgL6E+1Ho2POo0xkRAjAnAJ9iByxy7+NiLbIe9oGPmHaClA5qqACgiaby q1IRn0edtCVqMAzrkPTI1Do= =dSce -END PGP SIGNATURE-
Bug#337224: emacs-wiki: enumerated list when a number ends a sentence.
tags 337224 wontfix thanks Matt Hodges [EMAIL PROTECTED] writes: Paragraphs that contain a number at the end of a sentence like this 2005. Apparently look like a list has started? [snip] Can this situation be protected against somehow? To fix this would be non-trivial. Emacs Muse (muse-el) only marks up lists as such if they begin with one or more spaces, which solves the problem. emacs-wiki will be considered deprecated by the end of the year -- I am porting its remaining functionality to Emacs Muse. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net pgpCoM0xqU2VB.pgp Description: PGP signature
Bug#330880: [Ludovic Courtes] Bug#330880: xtla: `tla-edit-log' triggers a bug in Emacs or Xt
Milan Zamazal [EMAIL PROTECTED] writes: The `tla-edit-log' command, on my machine, sometimes hangs GNU Emacs under X11 (I'd say it hangs once every 10 `tla-edit-log' calls or so). More precisely, Emacs hangs while typing text into the syntax-highlighted buffer provided by `tla-edit-log'. This is something I've only experienced while typing text in `tla-edit-log''s buffer. [snip] Aditionally, in case it matters, my log buffer has `flyspell-mode' enabled. One source of mysterious crashes that I've encountered while working on the Emacs Muse is the interaction between flyspell and text with the intangible property. Try doing (setq inhibit-point-motion-hooks t) and see if that makes the problem go away. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Jabber: mwolson_at_hcoop.net pgpcJwzlSWPaF.pgp Description: PGP signature
Bug#323741: FTBFS: Cannot find emacs
Matt Kraai [EMAIL PROTECTED] writes: Package: muse-el Version: 3.01.arch.201-2 Severity: serious Tags: patch muse-el fails to build because it cannot find emacs: EMACS=emacs SITEFLAG=--no-site-file ../scripts/publish html QuickStart ../scripts/publish: line 4: emacs: command not found Adding a build-dependency on emacs21-nox fixes this problem. Thanks for letting me know! I've got a 3.01.arch.201-4 ready that should hopefully fix this problem. I've chosen to add emacs21 | emacsen to Build-Depends-Indep. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #pulug |_] | \| |_| Jabber: mwolson_at_hcoop.net pgptX51GDxx5N.pgp Description: PGP signature
Bug#323020: ITP: muse-el -- Author and publish projects using Wiki-like markup
Package: wnpp Severity: wishlist * Package name: muse-el Version : 3.01.91 Upstream Author : Michael Olson [EMAIL PROTECTED] * URL or Web page : http://www.emacswiki.org/cgi-bin/wiki/MuseMode * License : GPL Description : Author and publish projects using Wiki-like markup Emacs Muse is an authoring and publishing environment for Emacs. It simplifies the process of writings documents and publishing them to various output formats, such as DocBook, LaTeX, (X)HTML, TexInfo, and PDF. It can even produce content suitable for blogging, such as Blosxom-style .txt files and RDF or RSS 2.0 feeds, using the muse-blosxom and muse-journal modules. Muse consists of two main parts: an enhanced text-mode for authoring documents and navigating within Muse projects, and a set of publishing styles for generating different kinds of output. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #pulug |_] | \| |_| Jabber: mwolson_at_hcoop.net pgp9HvIcmbEW4.pgp Description: PGP signature
Bug#321616: emacs-wiki: Add dependency on emacsen
Daniel 'NebuchadnezzaR' Dehennin [EMAIL PROTECTED] writes: I'm using emacs-multi-tty and see that emacs-wiki only depend on emacs21 | xemacs21. Is it possible to add a dependency on emacsen ? Definitely. The next upload of emacs-wiki (2.70-2) should fix this. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: anime, Debian, XHTML, wiki, Emacs Lisp /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #pulug |_] | \| |_| Jabber: mwolson_at_hcoop.net pgpmpwGp8TfSC.pgp Description: PGP signature
Bug#312195: erc: README file missing
Milan Zamazal [EMAIL PROTECTED] writes: The README file, which contains short but very important information about documentation and usage, is not present in the binary package. Thanks for the report! I've fixed this upstream (as of 2005-06-06), so once the Debian package maintainer uploads the 5.0.3 debian package, this will be marked as fixed. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /` |\ | | | |_] | \| |_| Interests: anime, Debian GNU/Linux, XHTML, wiki, Emacs Lisp pgpwO8hXufl0M.pgp Description: PGP signature
Bug#306179: erc: fails to load when using erc-autoaway [PATCH]
Daniel Brockman [EMAIL PROTECTED] writes: Steps to reproduce: 1. emacs21 -q 2. (custom-set-variables '(erc-autoaway-mode t nil (erc-autoaway)) '(erc-autoaway-use-emacs-idle t)) 3. C-x C-e This patch fixes the problem: Thanks for the patch! I've included these changes in CVS, and the next (5.0.3) release will have it. I'll close the bug when I release next, since that's the bug-closing method that I am the most familiar with :^) . By the way, Bug #301952 (erc 5.0 is out) can probably be considered fixed. Yeah, it was filed just after I put together the package. I'll close it. -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug /` |\ | | | |_] | \| |_| Interests: anime, Debian GNU/Linux, XHTML, wiki, Emacs Lisp pgpLGxdpH4dw3.pgp Description: PGP signature
Bug#290091: emacs-wiki: problem editing links.
Matt Hodges [EMAIL PROTECTED] writes:
Suppose I write a link [[foo][bar]] and move to it with
emacs-wiki-next-reference. When I try and edit it with
emacs-wiki-edit-link-at-point, in the edit process the link is
presented as [[foo][bar]], and the text as [bar], rather than
foo and bar, respectively.
Thanks for the report! I think I've fixed this in the development
version. A release should be on the way next week. In the meantime,
can you copy the following two functions to the *scratch* buffer, hit
M-C-x on each one, and see if the problem goes away for the current
Emacs session?
(defun emacs-wiki-link-at-point (optional pos)
Return non-nil if a URL or Wiki link name is at point.
(if (or (null pos)
(and (char-after pos)
(not (eq (char-syntax (char-after pos)) ?
(let ((case-fold-search nil)
(here (or pos (point)))
there)
(save-excursion
(goto-char here)
(skip-chars-backward (concat ^['\{}(
emacs-wiki-regexp-space))
(setq there (point))
(search-backward [[ (line-beginning-position) t)
(or (and (looking-at emacs-wiki-name-regexp)
(= here (match-end 0)))
(and (goto-char there)
(looking-at emacs-wiki-url-or-name-regexp)))
(defun emacs-wiki-edit-link-at-point ()
Edit the current link.
Do not rename the wiki page originally referred to.
(interactive *)
(if (emacs-wiki-link-at-point)
(let* ((old-link (match-string-no-properties 1))
(old-text (match-string-no-properties 3))
(match-start (match-beginning 0))
(match-end (match-end 0))
(link (emacs-wiki-make-link
(read-string Link:
(emacs-wiki-link-unescape old-link))
(when old-text
(read-string
Text:
(emacs-wiki-link-unescape old-text t))
(delete-region match-start match-end)
(insert link))
(error There is no valid link at point)))
--
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Jabber: mwolson_at_hcoop.net -- IRC: mwolson on freenode.net: #muse, #pulug
/~ |\ | | | Interests: anim, Debian GNU/Linux, XHTML, wiki, Lisp
|_] | \| |_| Fun quotes: http://www.mwolson.org/plans/QuoteList.html
pgpvKsM1tBhrK.pgp
Description: PGP signature
