August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [bug] window-end breakage 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > (window-end) returns the location of C, and that's IMO exactly right. > It's only that when you are at the end of the buffer that (window-end) > returns (1+ (point-max)), which is IMO wrong. OK, I agree on both points. I think it a time for an "allow_in_clip" argument to end_of_last line. Jan

1 participants
0 comments

Re: USER-INIT-DIRECTORY and all that jazz 24 years, 8 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: Jan> I know for a fact that users are using that feature. >> >> What for? Jan> Three reasons Jan> 1. To use an XEmacs setup maintained by another user. This could be Jan> solved by a buch of symlinks. Note however that a lot users have Jan> forgotten that they use XEmacs in this way, i.e. they have an alias Jan> xemacs -u other-user (This is a PITA if you are trying to help Jan> them). That seems to be one reason to zap it so they notice. Jan> 2. A lot our shared working directories have a user associated with Jan> them. Some people use -u gruppe3 as substitute of 'themes' when Jan> working with files contained therein. Jan> 3. It nice to be able to try somebody else's setup when helping them Jan> with a problem without touching them. Well, these are reasonable. I still think that this is not worth the complexity, especially as 3. requires that the access permissions work out which, in PC secury networked setup, they don't. >> I *did* try to fix it. I gave up after three hours. The whole logic >> behind this is fundamentally flawed with respect to the staging. Jan> You mean with respect to the eary, late, last stuff? No, I mean the loadup staging. Parts of the code actually require to location of ~/.xemacs *before* even the command-line parsing has run which groks -u. Jan> P.S. You gain one point for the fact that gnus gets this wrong too. :-) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: USER-INIT-DIRECTORY and all that jazz 24 years, 8 months

Jan Vroonhof

sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: > Jan> I know for a fact that users are using that feature. > > What for? Three reasons 1. To use an XEmacs setup maintained by another user. This could be solved by a buch of symlinks. Note however that a lot users have forgotten that they use XEmacs in this way, i.e. they have an alias xemacs -u other-user (This is a PITA if you are trying to help them). 2. A lot our shared working directories have a user associated with them. Some people use -u gruppe3 as substitute of 'themes' when working with files contained therein. 3. It nice to be able to try somebody else's setup when helping them with a problem without touching them. > I *did* try to fix it. I gave up after three hours. The whole logic > behind this is fundamentally flawed with respect to the staging. You mean with respect to the eary, late, last stuff? Jan P.S. You gain one point for the fact that gnus gets this wrong too.

1 participants
0 comments

Re: USER-INIT-DIRECTORY and all that jazz 24 years, 8 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: >> Well, the thing is, this currently doesn't work because quite a few >> places that should really use "~joe" just use "~" (packages and info, >> to name just two). My knee-jerk reaction was to fix it, but the >> staging makes that so difficult I got a headache, and things still >> didn't work. Since nobody ever noticed the problem, Jan> But when did it break, in 21.1.x? Looking at the code, it's been broken forever, even though the degree to which it varied has probably changed over time. Jan> I know for a fact that users are using that feature. What for? Jan> Personally I think a fix should be attempted first. I *did* try to fix it. I gave up after three hours. The whole logic behind this is fundamentally flawed with respect to the staging. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: HTML Documentation Available [comments, please] 24 years, 8 months

john s jacobs anderson

Matt Curtin <cmcurtin(a)interhack.net> writes: > I think I'm finished with the HTML conversions of the documentation. > > http://www.cis.ohio-state.edu/~cmcurtin/xemacs-doc/ Thanks Matt! I'll try to give these the once-over in the near future. Do you want to leave them on your server, or would you prefer if they lived on www.xemacs.org? (They should probably at least be mirrored on xemacs.org, I think). john. -- ------------------------------------------------------------------------ John S Jacobs Anderson Apprentice Geek jacobs(a)azstarnet.com Journeyman Molecular Biologist <URL:http://www.treefort.org/~jacobs/> <- GeneHack:bioinfo*linux*opinion

2 participants
1 comments

Re: USER-INIT-DIRECTORY and all that jazz 24 years, 8 months

Jan Vroonhof

sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: > Well, the thing is, this currently doesn't work because quite a few > places that should really use "~joe" just use "~" (packages and info, > to name just two). My knee-jerk reaction was to fix it, but the > staging makes that so difficult I got a headache, and things still > didn't work. Since nobody ever noticed the problem, But when did it break, in 21.1.x? I presume the package code only breaks when you have installed your own packages? How old is 21.1.x really? If it were broken in all versions starting with 19.15, this argument would make sense. I know for a fact that users are using that feature. Personally I think a fix should be attempted first. Starting with eliminating the fact that user-init-file is a full path but user-init-directory isn't. Jan

1 participants
0 comments

Re: [bug] window-end breakage 24 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > Because it covers the whole window, including the clipped line. With > > the GUARANTEE value, I need to apply (forward-line) twice to the value > > I get. > > Aha.. I understand now I was not reading correctly. Then the > GUARANTEE is also wrong, IMHO it should return the position of the > last visible char including that one on the clipped line. That would be unlike anything else in Emacs. I can certainly imagine (point-max) returning the location of the last char in the buffer, but that's not how Emacs works. > This is the last line you can reach with the cursor.A > This is the clipped line, which is infact also brok\B > Cen because it is too long. > DThis is is the first line in the buffer that is not visible. > > so (window-end) gives D, (window-end nil t) gives A, and I think the > correct answer is B. (window-end) returns the location of C, and that's IMO exactly right. It's only that when you are at the end of the buffer that (window-end) returns (1+ (point-max)), which is IMO wrong.

1 participants
0 comments

Re: [bug] window-end breakage 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Because it covers the whole window, including the clipped line. With > the GUARANTEE value, I need to apply (forward-line) twice to the value > I get. Aha.. I understand now I was not reading correctly. Then the GUARANTEE is also wrong, IMHO it should return the position of the last visible char including that one on the clipped line. i.e. This is the last line you can reach with the cursor.A This is the clipped line, which is infact also brok\B Cen because it is too long. DThis is is the first line in the buffer that is not visible. so (window-end) gives D, (window-end nil t) gives A, and I think the correct answer is B. The problem with all this of course that some of these functions are intentionally broken, for instance to accommodate old FSF code that makes assumptions about being able to move the cursor up to that point. > I have no idea if it is feasible to use the line-start cache for the > purposes of window-start. It may be hard or impossible. It is the right thing, it is feasible, it laid out for such uses (this is why there are actually 3 line start caches). It however also hard, because the line start cache stuff is hard in general. Personally I think this the most dense part of the XEmacs C code. Jan P.S. Another redisplay problem. Open a large frame. Start C-u 6 M-x hanoi RET. Now resize the frame so that the towers _just_ fit. I see enormous redisplay speedup in that case. Why do the additional empty lines in the large display matter that much?

1 participants
0 comments

Re: USER-INIT-DIRECTORY and all that jazz 24 years, 8 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> - zap `init-file-user' Jan> Do you mean zap "-u" or not? "-u" should stay , it is being used. Yes. (I.e., I do want to zap it.) Jan> The problem is that things like gnus should be able to locate Jan> ~joe/.gnus if -u joe is used. It currently uses init-file-user for Jan> that. Well, the thing is, this currently doesn't work because quite a few places that should really use "~joe" just use "~" (packages and info, to name just two). My knee-jerk reaction was to fix it, but the staging makes that so difficult I got a headache, and things still didn't work. Since nobody ever noticed the problem, I suspect few people will notice that the "feature" is gone. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

USER-INIT-DIRECTORY and all that jazz 24 years, 8 months

Michael Sperber

OK, I've now waded through the morass associated with locating and actually using ~/.xemacs. I now know why I didn't try to touch this mess before, but now it's time to clean up. The problem: `user-init-directory' (for startup staging reasons) is relative to (concat "~" init-file-user). Here's its docstring: > Identity of user whose `.emacs' file is or was read. > The value is nil if no init file is being used; otherwise, it may be either > the null string, meaning that the init file was taken from the user that > originally logged in, or it may be a string containing a user's name. > > In either of the latter cases, `(concat \"~\" init-file-user \"/\")' > evaluates to the name of the directory in which the `.emacs' file was > searched for. > > Setting `init-file-user' does not prevent Emacs from loading > `site-start.el'. The only way to do that is to use `--no-site-file'. Some clients of `user-init-directory' (including code I wrote) just use (paths-construct-path "~" user-init-directory) to do the trick, but there are some other variants in core Lisp and the packages. This leads to different parts of XEmacs having a potentially different idea of where ~/.xemacs really is. BUT NOONE EVER NOTICED! I conclude from this that `init-file-user' is really too arcane to matter. The logic behind it is too twisted for me to really grok, and therefore probably to most users and many developers. Here's what I want to do: - zap `init-file-user' - set user-init-directory (effectively) to "~/.xemacs" - fix the two packages that need adjustment Any objections? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 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 August 1999