December 2011 - XEmacs-Beta - XEmacs Mailing List Archives

symbol's value as variable is void: allow-remote-paths 12 years, 11 months

Richard Cook

Hi, I compiled xemacs myself and installed into $HOME/xemacs-without-ipv6-cname I then made a symlink of $HOME/xemacs-without-ipv6-cname/bin/xemacs to $HOME/bin/xemacs I untarred the sumo tarball from http://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo-2009-02-17.tar.gz and untarred it into $HOME/xemacs-without-ipv6-cname/lib/xemacs, which made a directory called xemacs-packages there. When I run xemacs, I am not able to update my packages. I go to Tools -> Packages -> Set Download Site -> Official Releases -> US and choose US Main. I then go "update package index" or any other command in the Tools menu about Packages and it complains: "symbol's value as variable is void: allow-remote-paths" Can anyone help me with this? Thanks. -- ✐Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4024, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (office) (925) 423-9605 ☎ (fax) (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/mailman/listinfo/xemacs-beta

12 participants
51 comments

Re: [Success] The Package Smoketest 12 years, 11 months

The XEmacs Package Smoketest

>>>>> The XEmacs Package Smoketest <matsl(a)xemacs.org> writes: > These are the results from the XEmacs Package Smoketest: > 21.5-tip-mule -- ok > 21.5-tip-nomule-- ok > 21.4-nomule -- ok > 21.5-nomule -- ok > 21.4-mule -- ok > 21.5-mule -- ok This is something rarely seen All the builds have turned to green! <... Darn. I'll complete this poem next year ;-) ...> Happy New Year! Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Ben=?utf-8?B?4oCZ?=s unicode internal work. 12 years, 12 months

Aidan Kehoe

Hi, I’ve just created a repository on bitbucket with Ben’s unicode-internal work, formerly hosted here: http://anonscm.debian.org/hg/xemacs/ben-unicode-internal/ My repository includes work to merge in trunk changes, and it also abandons named branches; everything is in the default branch, there’s no need to do hg update ben-unicode-internal anymore. See http://mid.gmane.org/20145.34135.176918.710942＠parhasard.net for some motivation for this. The bitbucket repository is https://bitbucket.org/kehoea/unicode-internal/ ; I’ve given the xemacs:xemacs group write access. Best, Aidan -- ‘Iodine deficiency was endemic in parts of the UK until, through what has been described as “an unplanned and accidental public health triumph”, iodine was added to cattle feed to improve milk production in the 1930s.’ (EN Pearce, Lancet, June 2011) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: [COMMIT] Re: [Q] New "flush" face property 12 years, 12 months

Jerry James

On Mon, Dec 26, 2011 at 7:04 AM, Didier Verna <didier(a)xemacs.org> wrote: > Done, with a small difference. If we're to flush by default, then it's > better to have a face property for /not/ flushing. I've called it > 'shrink but other propositions are welcome. 'ragged ? -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

3 participants
4 comments

Summary of XEmacs Issue Tracking System Issues 12 years, 12 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2011-12-20 - 2011-12-27) XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 541 open ( +1) / 276 closed ( +0) / 817 total ( +1) Open issues with patches: 11 Average duration of open issues: 991 days. Median duration of open issues: 1048 days. Open Issues Breakdown new 215 ( +0) deferred 6 ( +0) napping 4 ( +0) verified 55 ( +0) assigned 150 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 17 ( +0) Issues Created Or Reopened (1) ______________________________ [Bug: 21.5-b31] Byte Compiler Failure with semantic-ede-gramma 2011-12-27 http://tracker.xemacs.org/XEmacs/its/issue819 created malcolmp _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: [Q] New "flush" face property 12 years, 12 months

Stephen J. Turnbull

Didier Verna writes: > OK, so here's what I'm gonna do: turn the flush behavior on by default > but keep it a face property so that it can still be turned off > explicitely. Then we'll see... +1 _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

Re: hg diff --subrepos 12 years, 12 months

Stephen J. Turnbull

Mats Lidell writes: > >>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes: > > > While this can't corrupt released packages, note that you may get > > "unpublished" changes in the smoke test. > > That is IMO just what the smoketest is there for. Testing the latest > released consistent version is not a big favor for developers nor the > release manager. You're assuming a workflow where all pushed versions are buildable/ testable. But that's not necessarily going to be the case, eg, in a "bug day" or "sprint" context (not that we've had any of those since the big party in 1998, but one can hope!) Or, before the smoke test, in packages I "owned" I often used the CVS repository to communicate between the several machines I worked on. There would often be intervals of hours, sometimes days, when one of those packages would not be in what I considered testable state. You can say "with the smoke test that's not a very good idea", and I'd agree. All I'm trying to do is document limitations of our current infrastructure and suggest good workflows to deal with them. I would like our workflow to produce consistent, expected results. Right now it doesn't, and this thread is the right place to try to figure out why not, and how to improve it. Sometimes that's going to involve developer adjustments, and we should make those explicit. > > Probably most people are happy to push only testable commits. > > I hope so. With mercurial you are even better of than with CVS. You > can commit your work without pushing until you are really done. My point is that this *is* a restriction on collaboration and we should say so. That gives potential contributors a chance to say "Hey that's a PITA!" and we can document good ways to accomplish their goals with a minimum of changes from what the contributors expect. > Anyway. This worked rather well with CVS so I think with Mercurial > it should only be better. "More is not just more, it's *different*." People don't like changes when they can be avoided, and I'd like to be prepared to help contributors develop workflows that are comfortable for them in the context of the overall XEmacs infrastructure. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

Re: [Q] New "flush" face property 13 years

Didier Verna

[ Redirecting to xemacs-beta＠ ] Stephen J. Turnbull wrote: > Didier Verna writes: > > > I'm certainly open to alternatives. I'm not very satisfied with > > "flush" either. "justify" doesn't sound quite right though because it > > means both sides and also suggests that the actual text layout is > > involved, which is not the case. > > Ah, I see now, having taken time to actually look at the blog :-P. > You're right, it's not "justify" since text layout isn't involved. > > Actually, I think any time the background of a face is different from > default, 'flush should be on by default. Yeah, the idea crossed my mind, but I was hesitating because it would be a somewhat radical change to the way things look right now. Also, maybe there are still some situations in which flushing would be undesirable. For instance, imagine just one line of text, with the right part (including the newline) using a different background. I think it would look strange to have this background extend to the right end of the window, on this single line only. > How hard would it be to implement a dimension? I can see applications > for (say) a flush-to-column-65 face, which I'd apply to a whole > paragraph, and anything hanging into the margin would end up in the > default face (or more precisely, the face of a containing region). That's an interesting idea. I don't think this would be very hard to implement with one problem though: what about variable width fonts (the notion of column number doesn't always make sense visually)? Which brings the question of unit of measure: columns, pixels, percentage of the window's width? > Flushright doesn't work for me, it refers to the text layout and > implies ragged left. Why not just "block"? Other not very satisfactory > terms that come to mind are "brick" (as in "bricktext"), "div" (from > HTML but not terribly evocative), "spill" or "flood" or the more > explicit "spill-to-margin" or "flood-to-margin". Something that refers > to "lines" or "rows", maybe. "band-oriented" or "band-fill" or > "full-band" maybe? > > I guess it can stay "flush" for now, since I don't have a good > alternative suggestion, all the above are pretty awkward. I'm pretty > sure something will occur to me someday soon, but it's just not coming > now. :-/ OK so let's wait until tomorrow morning :-) > Doesn't GNU have something like this by now? We should steal their > name. I've just downloaded 23.3 for Mac, and from what I can see, all faces behave like this (I don't see any face property that would allow one to turn the "flush" effect off). In that case, maybe we don't even need a specific property for this... -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
2 comments

Cannot commit to packages 13 years

Vin Shelton

I do not seem to be able to commit to the edit-utils package: cd scmroot/xemacs-packages/xemacs-packages/edit-utils hg commit hg push pushing to https://bitbucket.org/xemacs/edit-utils searching for changes http authorization required realm: Bitbucket.org HTTP user: acs(a)xemacs.org password: abort: authorization failed I think that is the procedure I use for committing to 21.4 and 21.5 or am I missing something? - Vin _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
2 comments

Patcher 4.0 is on the way 13 years

Didier Verna

Hi again, and here's another Christmas present. I have a new major version of Patcher on the way. It's an extensive rewrite with lotsa nu features (see NEWS excerpt below). One side effect of this is that Patcher will now be distributed as a standalone package. There's already a Mercurial repository at https://bitbucket.org/xemacs/patcher/ (thanks Mike). This repo is not completely integrated with the XEmacs Packages umbrella repo yet. It's already referenced as a subrepo but Norbert will have to remove the old Patcher from xemacs-devel. Patcher is currently at 4.0 pre 1. Tests and feedback welcome. Here's what's new at user-level in this version: Backward incompatible changes ============================= * ChangeLogs insertion in mail buffers rebound to C-c C-p l * Compressed ChangeLogs insertion in logmsg buffers rebound to C-c C-p L * Removed directory-sep-char hacks until the need for it raises again. Probably better implemented via project options anyway. * Diff commands can no longer be changed from patcher-mail-[adapt] but instead, the prefix argument allows for temporary subproject specification. * patcher-*-subproject entry points removed since they are no longer needed (see above). * Removed :kill-source-file-after-diffing option *:kill-source-files-after-sending renamed to :kill-sources-after-sending * patcher-mail-check-change-logs-insertion is now a project option named:check-change-logs-insertion. * patcher-mail-check-commit-action is now a project option named:check-commit. *:change-logs-diff-command option now understands nil instead of 'diff * The 'packed ChangeLogs appearance has been renamed to 'pack New features ============ * Support floating projects and temporary relocation[1] allowing to use the same project descriptor for various directories. * Support for automatic detection of submodules via the :submodule-detection-function project option and the patcher-detect-submodules function. Currently supported RCS submodules are Mercurial and Git via the functions 'patcher-[hg|git]-detect-submodules. * Support ephemeral ChangeLogs thanks to a new :change-logs-status project option. Ephemeral ChangeLogs are not stored in ChangeLog files, but exist only temporarily for mail or log message insertion (See ChangeLogs Status in the documentation). * ChangeLog minor mode providing easy navigation through the mail/ChangeLog buffers cycle via C-c C-p n, C-c C-p p, C-c C-p N, C-c C-p P and C-c C-p m (See ChangeLogs Navigation in the documentation). * Support for switching to mail buffer and inserting ChangeLogs at once via C-c C-p l from ChangeLog buffers. * patcher-mail-insert-change-logs gets a prefix argument allowing to temporarily change the ChangeLogs appearance. It also supports inserting ChangeLogs even when the project is set not to. * Additional binding for patcher-logmsg-commit: C-c C-p c * Commit command buffer is now editable Commit is done via C-c C-p c or C-c C-c (patcher-cmtcmd-commit). * Fontification of commit command and log message buffers with comment syntax and initial informative help. See new Patcher faces. * Support for commit or log message canceling via C-c C-z. * Support for project abortion via C-c C-p k or C-c C-k in all relevant buffers, including ChangeLogs. * Support Subject: header modification in mail adaptation routines via a new project option :subject-rewrite-format. * Support project-wide dynamic subject modification via C-c C-p S in both mail and log message buffers. * Implement :kill-source-files-after-sending project option * Support for source file saving * Support for CVS diff's broken exit code policy via a new project option: :ignore-diff-status. Fixes and improvements ====================== * Improved support for temporary subprojects making them behave like permanent ones (with a specific subdirectory and set of files). * Much better error handling including exit code checking for external processes. * Improved support for overlapping Patcher instances through buffer and file referencing for both ChangeLog and source files. * Documentation rewrite and sections organization cleanup * More checks for project consistency including missing or spurious ChangeLog entries, source diffs, undiffable and uncommittable projects etc. * Improved project rediffing including support for partially generated ChangeLog skeletons, and interactive prompting for skeleton un/re-generation. Footnotes: [1] this one's for Mats ;-) -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta December 2011