October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > (unless (and (interactive-p) (region-active-p)) > (push-mark)) That's what I proposed. Note that you don't need the `interactive-p' check. These functions should never be called non-interactively. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Call CIA and tell them that you have placed a bomb in a 7-11 shop! Be sure to let them trace you. Spend 10 years in jail and then regret it.

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > > That doesn't mean Emacs should be tailored to your ignorance. > > Neither to your ignorance or lack of interest in ergonomics > concerns. beginning-of-buffer and end-of-buffer are commands to move > in the buffer. The other commands like next-line previous-line and > even BEGINNING-OF-line and END-OF-line preserve the mark, but not > those 2 ones. I admit that a different behavior might be usefull in > the case of long moves, but I don't think this should be the > default. Didier, do you propose that beginning/end-of-buffer not push the mark only when the region is active, or all the time? If the former, I'm with you. If the latter, I'm not -- when the region is unactive, the mark-pushing behaviour is quite useful. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

1 participants
0 comments

Re: package-get-base.el issues (was Re: [patch] enhancements to package-ui.el) 26 years, 1 month

Adrian Aichner

>>>>> "SL" == SL Baur <steve(a)xemacs.org> writes: SL> - hack-package-index.el [2 hack-package-index.el SL> <application/octet-stream>] Hello Steven, all! I am having trouble looking at ascii attachments in (version) "XEmacs 21.0 \"Pyrenean-pre2\" [Lucid] (i386-pc-win32) of Sun Oct 11 1998 on TWILIGHT" (gnus-version) "Gnus v5.6.44" Both when typing e and v I get Wrote c:\tmp\TMDCAHZP External method is starting... Error starting: "c:\\export\\home\\tmp\\CVSroot\\xemacs-20\\lib-src\\tm-file", "Exec format error" Wrote c:\tmp\TMDCAUjV External method is starting... Error starting: "c:\\export\\home\\tmp\\CVSroot\\xemacs-20\\lib-src\\tm-file", "Exec format error" since tm-file is not available on windows-nt. How can I view these attachments within Gnus? I'd hate to bring up the issue why hack-package-index.el [2 hack-package-index.el <application/octet-stream>] is attached as application/octet-stream in the first place :-) Thanks for any suggestions. Regards, Adrian -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

2 participants
1 comments

Re: about the packages: directory names and places 26 years, 1 month

Didier Verna

Martin Buchholz <martin(a)xemacs.org> writes: > The distinction is between ${prefix} and ${exec_prefix}. > LOTS of GNU packages install arch-independent stuff into lib: > > emacs (good to be compatible here!) Huh ? emacs installs this: `$(datadir)/emacs/site-lisp' which by default goes to ${prefix}/share/emacs/site-lisp --didier

1 participants
0 comments

Re: about the packages: directory names and places 26 years, 1 month

Didier Verna

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Neither of these is that strong a reason against putting the > architecture independent stuff in .../share by default, and putting it > there certainly will make Linux distribution maintainers happy. I > don't know if GNU has adopted .../share as a standard, but I know that > several GNU packages I have built locally use it (the Linux versions > obviously aren't a fair test since they're explicitly made to be > FSSTND compliant). Using ${prefix}/share for architecture-independant stuff belongs to the GNU Coding Standards. Stallmacs uses it to put its lisp files. Here's an extract of our share directory here. I think it's rather informative: | ls /usr/local/share | Muttrc aclocal bison.hairy ghostscript libtool pixmaps yudit | WINGs autoconf bison.simple gimp locale psutils | WindowMaker automake dejagnu id-lang.map mime.types snmp | a2ps awk emacs less.hlp mysql tabset -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Didier Verna

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > The long moves thus must set/push the mark, so that the region can be > adjusted, and region-oriented commands can be used. Pushing mark with the > region active just seems consistent to me. But if you already have set the mark yourself, do you still expect those functions to change it ? I surely don't. So, what about something like this ? (unless (and (interactive-p) (region-active-p)) (push-mark))

1 participants
0 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Yeah, what he said. I've always intuitively divided the motion > (including search) commands into "short" moves, which have > associated delete/kill commands, and "long" moves which don't, > because they're inaccurate. Agreed so far. > The long moves thus must set/push the mark, Yes, but not if the mark is already active. > For my usage patterns the example sequence C-SPC C-F C-F M-< most > likely means that the C-SPC was pilot error (I set the mark in the > wrong place), and so M-< "Does What I Mean, Not What I Said" when it > pushes a new mark. Hmph. I'd definitely say XEmacs does what I said, not what I meant in that example -- but we obviously differ on that. But I kind of see what you mean with "pilot errors". For example, most Windows users would be appalled to find that DEL doesn't delete region by default -- and yet I often press DEL to delete a character no matter whether the region is active or not. If the region gets deactivated in the process, then that's what I wanted to do. :-) However, the problem with M-</M-> is that they are much more subtle than that, and there is no package to "fix" them like there is for pending-delete. > That said, I don't think it would be hard for me to adapt to the > proposed behavior. Yup. We adapted to the current behaviour, too. :-) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

1 participants
0 comments

XEmacs 21.0-pre15-pre4/21.2-beta3-pre2 26 years, 1 month

SL Baur

I've committed new versions of XEmacs to both release trees. There are patches for virgin XEmacs 21.0-pre14 in ftp://ftp.xemacs.org/pub/xemacs/beta/testing/ Get the latest package-get-base.el from ftp://ftp.xemacs.og/pub/xemacs/packages/package-index-1998-10-12-2 There are no 21.2-specific changes, only 21.0 syncs. The cumulative changes to 21.0 are: to 21.0 "Pyrenean" -- Package Tool Finishing Touches from Jan Vroonhof -- package-get-base.el removed from the core -- BS/DEL fix from Glynn Clements -- Tty vertical divider width now defaults to 1 instead of 0 -- MS Windows toolbar fixes from Jonathan Harris -- Fix for XtDisplay being called with stale widget from Takeshi Hagiwara -- Fixes for Cygwin b20 from Andy Piper -- Package UI fetching improvements from Greg Klanderman -- isearch regexp pruning bugfix from Hrvoje Niksic -- package deletion fixes from Jan Vroonhof -- gnuclient fix from Jan Vroonhof Please test this and report on remaining major problems. It has gotten more than ridiculous to keep holding this release back. Altrasoft has been shipping InfoDock releases based on XEmacs 21 since early July. Ben Wing, can we please release soon?

2 participants
1 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > Because, if you don't, the current behaviour is far from logical. > > Press C-SPC, then C-f a few times, then M-<. I bet 90% of XEmacs > > users would expect the mark to remain at the point before > > C-f-ing. > > The behavior is still logical. What you are describing is user > ignorance. Ascribing unintuitive behaviour to "user ignorance" is the path of least resistance. The fact is that I had to bend backwards to understand why the C-SPC example above gave the wrong results. When you run without zmacs-regions, or when you are a long-time Emacs user, you get used to it, but otherwise it's totally weird. I think the only reason that we don't get more complaints in c.x.e. is that people don't *notice* this thing. > Using the mark system requires that you learn a bit about it. > transient-mark-mode/zmacs-region, with its Benny Stulwicz[1] > interface, makes you think you understand, when you know nothing of > the mark ring or how to use it. I have no idea what you mean by this. Except for this visual problem with M-< and M->, I've found no evidence that zmacs-regions are in any way misleading to beginners, even back when I was still learning about them. Having said all this, note that I'm still not convinced we should actually make the change. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Old numerical analysts never die, they just get disarrayed.

3 participants
2 comments

Re: efs-load/require sllloooooowwww 26 years, 1 month

Andy Piper

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Actually, the xemacs-nt folks have been very secretive about what the > actual problems with EFS on NT are. However, I've received some mails > about this, and I absolutely intend to do what I can to fix the > problems once I understand them and their proposed solutions. This > will have to wait until after the 21.0 release, though, I'm afraid. Err, I think you are wrong about this Michael. I have seen several posts to xemacs-review and xemacs-beta and you relating the problem and providing patches over an extended period of time. I think it is a fundamental mistake for EFS not to work with NT on 21.0. Please reconsider. I personally think this should be on Ben's showstopper list since we can fix it right now. andy

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 October 1998