Re: FYI: "Emacs and XEmacs" on the Emacs Wiki
15 years, 9 months
Stephen J. Turnbull
David Kastrup writes:
> I was talking of control. Code which can only be understood and
> managed by an inner kabaal or single persons because of its
> inherent design decisions and resulting complexity is a much more
> absolute lock-in than even copyright.
I'm not going to argue that Richard's decision was insane on technical
grounds; it was not.
But the claim that letting Lucid go ahead with the merger unmolested
was risking "absolute lock-in" is nonsense on the face of it. "rm -rf
emacs; tar xzf emacs-18.59.tar.gz" cures any such lock-in in theory,
and in practice, Richard had already done something far more dramatic:
"rm -rf emacs; mkdir emacs". Richard is a hard man to lock in! At
worst, if the product of a Lucid merge had to be abandoned completely,
with no code surviving into GNU Emacs 19, the cost would only be a few
months. And the upside was *huge*.
> And the Lucid programmers basically said that: we want this in now, in
> the shape we consider fit, and under our control. You don't get to
> criticize or cherry-pick, you don't get to voice wishes, you don't get
> to review.
No, AFAIK they never said "we want this in" at all. Feel free to
point it out if they did. What they said was: "if *you* want *us* to
do the merge work *now* ...". The rest of your paragraph is accurate
enough, except that it ignores the fact that the merge would take
maybe a couple of months, and after that RMS could do all the
reviewing he wanted, and throw out any rotten cherries.
Sure, this does risk some extra, annoying work, and for that reason
your opinion that:
> From a point of sane software and project engineering, I consider
> Richard's choice given the options wise.
is plausible, although I disagree.
> Emacs does not have stasis areas where people are waiting for
> Richard Stallman, or Gerd Möllmann, or even Kenichi Handa to keep
> maintaining stuff they created and nobody else understands.
Neither did Lucid Emacs 19.6 have "stasis areas". You can't compare
to XEmacs today, which is much more bloated, with much code written by
far less professional programmers, than the code that Richard wanted
Lucid to merge.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
triage on issue # 411
15 years, 9 months
Ram Bhamidipaty
Hi,
I am trying to do triage on the xemacs tracker. I picked issue #411
as that was the oldest. I believe the module for this one should be
custom - but that choice is not available.
Is there a way for me to create a module? Or should I use something
else?
Thanks for any help.
-Ram
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Problems building packages (semantic), package-future.el?
15 years, 9 months
Ville Skyttä
Hi,
I'm trying to build packages from CVS with XEmacs 21.5.28 (patched with the
autoload changes for defclass and friends from hg), starting with "make
distclean autoloads". When plain "make" after those reaches semantic, I'm
first getting "Symbol's function definition is void: defclass", then after
doing "make" in eieio and ede and retrying "make" in semantic, I get "Given
parent class eieio-persistent is not a class".
By the way, I see some PACKAGE_FUTURE stuff in ede/Makefile and
semantic/Makefile, but there's nothing matching *package-future* in my CVS
checkout, but on the other hand nothing seems to be using PACKAGE_FUTURE for
anything.
Thoughts?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
enable-local-variables (was: Parsing standard C++ includes)
15 years, 9 months
Marcus Harnisch
"Eric M. Ludlam" <eric(a)siege-engine.com> writes:
> I checked the doc, and Emacs 21, and XEmacs 21.4 don't have the nifty
>:safe feature. For them :safe means to ask the user. At the same
> time, only Emacs 23 seems to indicate that this variable controls
> looking up modes in a -*- line. Perhaps that is an oversight in older
> version of the doc?
>
> It would be handy if an XEmacs user could look up any options on newer
> versions of XEmacs.
XEmacs 21.5.28 doesn't have it and neither does Emacs 22.2.1 (the
latter from Ubuntu 8.10).
Regards
Marcus
--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]
(seen on http://www.veripool.com/verilog-mode_news.html)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [CEDET-devel] enable-local-variables
15 years, 9 months
Alastair Rankine
On 23/02/2009, at 7:15 AM, DaveS wrote:
>>
> Obviously the number one priority is ensuring that parsing works
> correctly
> on all platforms. Could we do a bit of inspection and do a best
> choice
> based on the user's platform. Barring that, how about exposing this
> so a
> knowledgeable user can specify a value if they choose.
Another idea occurred to me. The mode of the new file is almost
certainly going to match that of the parsed parent file. In other
words, if we are parsing a c++ file, then all of the #included files
can be parsed as c++ as well. Hence as a fallback, if after loading
the file with find-file-noselect we find that there is no mode set, we
can attempt to parse it using whatever the parent (not sure if that's
the right terminology here) file's mode is.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: assigning bug 443 failed
15 years, 9 months
Aidan Kehoe
Ar an dara lá is fiche de mí Feabhra, scríobh Andreas Roehler:
> Hi Aidan,
>
> tried to assign bug 443 to me,
>
> editing is refused with comment:
>
> "Required issue property module not supplied"
>
> "Module" is highlighted red, so it seems some
> specifying needed here.
Right, you need to specify that it’s in the PSGML package. I’ve done that,
but not assigned the issue to you, your name doesn’t show up in the list of
people.
> BTW bug shows up too at
>
> XEmacs 21.5 (beta28) "fuki" (+CVS-20070806) [Lucid] (i386-suse-linux, Mule) of Sun Sep 23 2007 on verdi
>
> Got some ideas how to fix it.
Good good!
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Non-urgent Tracker blatherings
15 years, 9 months
Vladimir G. Ivanovic
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Back when I did some bug triage in Oct'08, I drew up this list of
requests, rants and questions (I haven't checked recently to see if
any are now no longer relevant) that made my workflow slower.
I'd like to have these addressed, in some fashion, either by modifying
Tracker, or by denying the request.
- --- Vladimir
1. If a submission fails, please do not clear any fields, in
particular "Module" and "Platform".
2. Please add "x86_64" to the list of platforms.
3. If it is not the case that Linux is assumed, please add "Linux" to
the list of platforms.
4. It would be nice if there were a "Next" button (like in Bugzilla)
to go to the next issue in the current list. (I happen to be working
off the Open issues list, so "Show Open" works for me.)
5. Shouldn't every issue have a status of at least "New"? If so,
please make it the default when submitting or modifying an existing
issue which does not have a status set.
6. If an issue is the result of the interaction between two modules,
then the "Module" field will not capture essential information since
only one module can be specified. The "Module" field should be a list.
7. There is no way to save the current issue list or to re-load a
previously created issue list.
8. Comment text should be forcibly wrapped (or should be an option).
See Issue 150 for an example of an issue that's hard to read.
9. "core code other" should be broken up[sic] into "core code other"
and "core code lisp", with "core code other" covering lib-src and
lwlib and "core code lisp" covering (obviously) the core lisp code.
10. "Make a copy" doesn't work and returns errors.
11. The Comment field seems to start up with a number of spaces and/or
tabs. So, when clicking anywhere except at the very beginning, the
cursor is misplaced. The spaces & tabs should be removed.
12. The automated transition to "deferred" after one month of
inactivity doesn't seem to work. I've opened 8 month old issues that
are still "chatting".
13. When I forgot to fill in "Module", "Submit Changes" reported
something like "Required issue property platform not supplied." This
should refer to "module" not "platform". (But, next time it worked, so
maybe I'm hallucinating.)
14. There should be an "N/A" in the module list, for use when the
issues is not a bug. Same comment for "Type".
15. The elements in the platform list seem to be missing some entries:
Linux, Solaris, lwlib, motif, SPARC, but nt is mentioned even though
mswindows is in the list. And what is "stream"?
- --- Vladimir
- --
Vladimir G. Ivanovic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmflZEACgkQtoykdjDhdFugMgCggd0S1QAVz3t1ZDBd9Mm7npEK
MPsAoJU0Na8tpHRnSqikEYODI5oUmfgJ
=G4ed
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
thing-at-point-utils.el, char-classes
15 years, 9 months
Andreas Röhler
Hi,
I'm not happy with compatiblity-definitions of char
classes as its solved for example with [[:alnum:]]
(when (featurep 'xemacs)
(defcustom alnum "[a-zA-ZäöüßÄÖÜ0-9]"
"Rexexp to specify the character class
Change it, if you want to pick strings differently.
XEmacs-users: `unibyte' and `multibyte' class is unused i.e. set to \".\""
:type 'regexp
:group 'convenience))
It should be possible to detect the range from the
buffer-coding-system instead customizing in manually.
Any ideas how to perform this?
Hi Steve,
changing it at the bottom of things would take a lot of
effort. Should solve some other tasks first, as
beginning-of-defun-function, further enhancements to
python-mode.el etc.
Given there is no answer how to do it at lisp-level,
please take `thing-at-point-utils.el',
`thingatpt-utils-base.el' as is for the moment.
It will provide a lot of useful functions IMHO.
Cheers
Andreas Röhler
--
https://code.launchpad.net/s-x-emacs-werkstatt/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [Bug: 21.5-b28] C-x C-s immediately after C-x C-f does the wrong thing, I think
15 years, 9 months
robert delius royar
Fri, 20 Feb 2009 (17:01 +0900 UTC) Mats Lidell wrote:
>>>>>> Stephen wrote:
>
> Aidan Kehoe writes:
>>> I think that’s wrong, I think it should create the file; C-x C-f is what I
>>> think to do when I want to create a file
>
> Stephen> But I don't much care the other way, either. Just make sure
> Stephen> that this only happens on an explicit, interactive find-file.
>
> I guess the implementation would be that the buffer would be marked as
> changed after a find file on a file that can't be found. In that case
> the only thing, objection, that pops to my mind is that a later
> save-some-buffers would semi silently create the file.
>
> But I guess that is what the proposal is all about. If you create a
> buffer using find-file you also really want to create the file. Go for
> it!
If I were to mistype a directory name within the path to the file, what
would the action be? Now, I am asked if I wish to create the directory.
If I answer "no," then I get a buffer with that filename. It is not
modified, so I can delete the buffer without answering another question.
I would want similar action in a revised C-x-C-f.
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta