June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: column number starts at 1 or 0? 26 years, 5 months

Hrvoje Niksic

Andy Piper <andyp(a)parallax.co.uk> writes: > At 03:05 PM 6/11/98 +0200, Hrvoje Niksic wrote: > >Andy Piper <andyp(a)parallax.co.uk> writes: > > > >> I'm with Kyle on this. But then I'm a hacker and my brain is wired > >> up to start at 0 rather than 1. > > > >Then you surely mind the line numbers starting at 1? > > The cursor is never between lines only characters, thus the argument > for lines starting at 0 is less strong - but a case could be made, > yes ;) What I mean is: if, as a hacker, you like numbers starting from 0, you should probably require the first line to numbered as "0 line", too. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Oh lord won't you buy me a color TV...

2 participants
1 comments

Re: column number starts at 1 or 0? 26 years, 5 months

Hrvoje Niksic

Andy Piper <andyp(a)parallax.co.uk> writes: > I'm with Kyle on this. But then I'm a hacker and my brain is wired > up to start at 0 rather than 1. Then you surely mind the line numbers starting at 1? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!!

2 participants
1 comments

Re: Bug when selecting TTY frames 26 years, 5 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > (select-frame (next-frame)) is working as (I) intended. The tty > frame you see is controlled by raise-frame/lower-frame. Keyboard > focus is controlled by select-frame. If you want to be sure that > the user can see the frame that they are typing in, you need to call > raise-frame. That is true for X as well as tty frames. The manual says otherwise, so this should be documented. The offending paragraph follows: When using a text-only terminal, there is no window manager; therefore, `select-frame' is the only way to switch frames, and the effect lasts until overridden by a subsequent call to `select-frame'. Only the selected terminal frame is actually displayed on the terminal. (...) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity!

1 participants
0 comments

Re: Bug when selecting TTY frames 26 years, 5 months

Colin Rafferty

Greg Klanderman writes: >>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Hrvoje> The selection of TTY frames has broken somewhere along the lines. To Hrvoje> repeat: Hrvoje> Hrvoje> $ xemacs -nw -q Hrvoje> C-x 5 2 ; to create and select a new frame Hrvoje> M-: (select-frame (next-frame)) ; select the original frame Hrvoje> Hrvoje> For me, this creates a strange effect where keyboard "focus" goes to Hrvoje> the other frame, but it is not redisplayed. > yup :-( > Do you know for sure that this used to work? I can tell you right now that it has the same (incorrect?) effect under 20.4. Unless this was fixed, and then broken, it has always been this way (as far as I can tell). -- Colin

2 participants
1 comments

Re: Bug when selecting TTY frames 26 years, 5 months

Hrvoje Niksic

greg(a)alphatech.com (Greg Klanderman) writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > Hrvoje> > Hrvoje> The selection of TTY frames has broken somewhere along the lines. To > Hrvoje> repeat: > Hrvoje> > Hrvoje> $ xemacs -nw -q > Hrvoje> C-x 5 2 ; to create and select a new frame > Hrvoje> M-: (select-frame (next-frame)) ; select the original frame > Hrvoje> > Hrvoje> For me, this creates a strange effect where keyboard "focus" goes to > Hrvoje> the other frame, but it is not redisplayed. > > yup :-( > > Do you know for sure that this used to work? I don't. I've checked now, and it didn't. Sorry for the implication that you broke it. > Hrvoje> When using a text-only terminal, there is no window manager; > Hrvoje> therefore, `select-frame' is the only way to switch frames, and the > Hrvoje> effect lasts until overridden by a subsequent call to `select-frame'. > Hrvoje> Only the selected terminal frame is actually displayed on the terminal. > Hrvoje> Each terminal screen except for the initial one has a number, and the > Hrvoje> number of the selected frame appears in the mode line after the word > Hrvoje> `XEmacs' (*note Modeline Variables::.). > > Is this second paragraph what you'd want? I would think you should > have to use focus-frame/other-frame to permanently change the frame, > and that select-frame should revert to the original frame as under > X? I don't know. > Or should focus-follows-mouse apply only to X consoles? Well, it would be logical. :-) In fact, focus-follows-mouse should be a console-local flag. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Manic depression is cool... your body can make its own drugs.

1 participants
0 comments

Re: Projects ideas 26 years, 5 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > > > > Module support is **dangerous**. Beware! > > > > > > So is executing elisp. :) > > > > That's not what I meant. I'm not a security freak. > > > > What I meant was that announcing module support has potentially > > far-reaching ramifications that we don't really appreciate at this time. > > Oh, you mean including it in the 21.0 release announcement? Yeah, > that would be bad, considering the doc strings get lost, there is no > support for autoloading them, etc, etc. That's the stuff I want to > hack on for 21.1 as soon as we fork the tree. Close, but no cigar! :-) What I meant was that our abstraction layer line between "interface" and "implementation" is currently drawn somewhere around C<->elisp distinction (with the exception of some code in lisp/ that can also be consider "implementation"). Specifically, this means that we can play around with the C code as much as we like, and noone will get burnt. Now, if we announce the modules support for 21.1, we'll have to make it damn sure that we know *exactly* what we're doing. Suddenly, when making changes to XEmacs, we'll have to consider not only the compatibility with old Lisp code, but the compatibility with old C code. We'll also have to make the same interface<->implementation distinction within the C code, and somehow announce which parts of the interface are cast in stone, and which are liable to change. I don't think XEmacs C code is ready for this sort of thing. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Try to use "ad nauseam" at least once per flame. It doesn't mean anything; but it gives that polished feel to your postings.

1 participants
0 comments

Re: package version dependence [ was Re: Binary distributions ] 26 years, 5 months

Jens-Ulrik Petersen

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Darryl Okahata <darrylo(a)sr.hp.com> writes: >> Jonathan Harris <jhar(a)tardis.ed.ac.uk> wrote: >> >> > A sensible install tree for XEmacs on mswindows might look >> > like: >> > >> > PROGS\XEmacs\ >> > packages\ XEmacs-21.0\ >> > bin info lisp >> > >> > where PROGS should default to "C:\Program Files". >> >> What's the philosophy for packages? A scheme such as the above >> works only if packages are independent of XEmacs versions. >> However, in practice, I have not found this to be true; >> packages tend to depend on a particular XEmacs version or >> vice-versa. Actually I think this is a seriously problem. For example recently I modified a function called by a macro in "derived.el". To rebuild XEmacs then requires recompiling "help", "list-mode", and a number of package files including a couple of "psgml" and others (any library using `define-derived-mode' to be precise). The recompiled libraries now no longer work with any previous XEmacsen. -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

1 participants
0 comments

Re: Binary distributions [ was Re: [PROPOSAL] fix for bad Xrefs . .. ] 26 years, 5 months

Hrvoje Niksic

Jeff Paulsen <jeff.paulsen(a)poorman-douglas.com> writes: > My thought is this: creating an install set using InstallShield does > not create a "modified work", but rather creates a "mere > aggregation". My point exactly. Apologies for muddling the waters with the bogus "but it's impossible!" argument. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- aibohphobia (ay' bo fo beeya): n. The fear of palindromes.

2 participants
1 comments

[need help] minor mode buffer local keymap question 26 years, 5 months

Greg Klanderman

OK, I'm trying to have a buffer-local keymap variable which is used by add-minor-mode. I tried passing the symbol as the keymap argument, but this does not seem to work. Looking at keymap.c, get_relevant_minor_maps calls minor_mode_keymap_predicate which calls get_keymap. Get_keymap seems to indicate that it will dereference through any symbols, but I don't see how this works... it seems to be looking through function slots. Can anyone clue me in as to the right way to do this? The prize is that ediff-minor-mode (which came to me in a dream this weekend and will allow one to ignore the control frame and work from the ediff buffers themselves) should work once this is resolved. thanks greg

2 participants
1 comments

Re: Bug when selecting TTY frames 26 years, 5 months

Greg Klanderman

>>>>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Hrvoje> The selection of TTY frames has broken somewhere along the lines. To Hrvoje> repeat: Hrvoje> Hrvoje> $ xemacs -nw -q Hrvoje> C-x 5 2 ; to create and select a new frame Hrvoje> M-: (select-frame (next-frame)) ; select the original frame Hrvoje> Hrvoje> For me, this creates a strange effect where keyboard "focus" goes to Hrvoje> the other frame, but it is not redisplayed. Somehow, DEVICE_FRAME_THAT_OUGHT_TO_HAVE_FOCUS (d) and DEVICE_FRAME_WITH_FOCUS_FOR_HOOKS (d) aren't getting set like they do under X. I'm not even sure how those get set under X - will have to probe deeper. I wonder if someone could test how broken it is under mswindows, with and without focus-follows-mouse set? greg

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