August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Layout support + widget fixes 25 years, 3 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > This allows you to layout glyphs according to some predefined strategy > within a predefined area, e.g. right justified. You can optionally draw a > border round the layout area which can be etched in/out or bevelled in/out. > Layouts can be organised within layouts allowing for arbitrarily complex > structures. My calculations tell me that if you put a border round > sub-layouts you can get a nice table effect (which might interest BillP). Can you layout non-glyph buffer content, for instance to produce a nice Gnus summary listing with a proportional font? The reason I want this to be no be the glyph is data is because I want it to still to be locatable using isearch. What would be nice if that wherever there is a glyph that has text data you could say "Use the text under extent so-and-so as data". Jan

2 participants
1 comments

Re: trouble getting started with binary distribution 25 years, 3 months

Andy Piper

At 12:14 PM 8/23/99 -0500, Steve Grout wrote: >The FAQ said to post this to xemacs-beta-request, but that alias >does not seem to exist. I apologize for posting the list directly. Someone else has reported this which makes me think I have done something wrong. If you move xemacs-*.exe up a level - does that help? andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: [SITE] make over finished(?) 25 years, 3 months

SL Baur

john s jacobs anderson <jacobs(a)azstarnet.com> writes in xemacs-beta(a)xemacs.org: > Greetings. > The initial make over work on www.xemacs.org is complete, I think. Oooh. Very nice. Good job. > There are still a couple of holes, particularly in the links sections, > and most notably the installation instructions, but everything else is > done. I've a couple of minor comments. Please add ETL/Electrotechnical Laboratory (http://www.etl.go.jp/) to the list of sponsors (after BeOpen.com) on the home page. Thanks. We should probably also put an acknowledgement and link to the good folks of www.tux.org for graciously hosting our main web and ftp sites. We need a link to the CVS sources at cvs.xemacs.org somewhere. It really looks good, John. Thank you so much for your efforts.

3 participants
3 comments

Gutter, add-tab-to-gutter and extent-info 25 years, 3 months

Olivier Galibert

The extent_info structure is a particularily nasty one to dump portably. Actually, this one is so nasty that I'd rather have none to dump. Interestingly enough, there is only one reachable instance of such a lrecord at dump time : the one in the 'global scope on the default-gutter specifier. It comes from add-tab-to-gutter which creates a zero-length gutter-string with an extend on it, and adds it with a value corresponding to the different image-able console types. So my question is, is it possible to move the add-tab-to-gutter to somewhere after dump time ? Incidentally, how can one get rid of this tab thingy? I already have the toolbar removed, it's not in order to add that :/ OG. PS: Current status : Undumpable types list : - lcrecord-list (15) - opaque_ptr (1) - color-instance (1) - font-instance (1) - range-table (2) - buffer (7) - extent-info (1) - console (5) - stream (1) - device (2) - frame (1) - window (1) Most of these don't have to be dumped anyway.

2 participants
3 comments

RE: Layout support + widget fixes 25 years, 3 months

Andy Piper

At 12:03 PM 8/23/99 -0700, you wrote: >Under WinNT, using MSVC, the link fails with: > >glyphs-widget.obj : error LNK2005: _Qlayout already defined in general.obj >..\src\temacs.exe : fatal error LNK1169: one or more multiply defined >symbols found Fixed, thanks. >Under Solaris 2.5.1, using GCC 2.95.1, compilation fails with: > >toolbar-x.c: In function `x_draw_blank_toolbar_button': >toolbar-x.c:81: too many arguments to function `x_output_shadows' >toolbar-x.c: In function `x_output_toolbar_button': >toolbar-x.c:163: too many arguments to function `x_output_shadows' >toolbar-x.c:217: warning: passing arg 11 of `x_output_x_pixmap' makes >integer from pointer without a cast >toolbar-x.c:217: too few arguments to function `x_output_x_pixmap' Oops, cvs didn't pick up that I had touched the file. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Suggested addition to README.packages 25 years, 3 months

Robert Pluim

Could we add something like the following? It was not at all obvious to me how to do this until I read package-get.el. Finding the right packages -------------------------- If you want to find out which package contains the functionality you are looking for, use M-x package-get-package-provider, and give it a symbol that is likely to be in that package. eg, if some code you want to use has a (require 'thingatpt) in it, try doing M-x package-get-package-provider RET thingatpt , which will return something like: (fsf-compat "1.06"). Robert -- The above are my opinions, and my opinions only.

1 participants
0 comments

Re: package-get.el : package-get-user-package-location 25 years, 3 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: >> Is no more in 21.2. >> >> >> >> The general concept of having a single package hierarchy >> >> >> into which user packages go is broken by now. >> Jan> Huh? Why? >> >> There are *two* now under ~/.xemacs: xemacs-packages and >> mule-packages. Jan> Yes. And this one is a definite candidate for ~/.xemacs/site-packages .... No, this one should not go into a package hierarchy at all. The package index transcends package hierarchies, doesn't it? Jan> Ok, the problem here is that the directories in data-directory-list Jan> can magically appear. I don't understand this. `data-directory-list' is set at startup. Nobody is supposed to mess with it afterwards. Jan> Yes, but it is necessary because of the "magic" creation problem and Jan> the fact that we really want to stick in the top level /etc directory Jan> of a package hierarchy, not the "etc/" of some package. It is only currently "necessary" because there's no clear organizational coherence between search paths and installation directories. I tried to clean up the pre-21 mess as best as I could without breaking backwards compatibility. This problem really needs a general solution sufficiently factored to package-get can simply *use* it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: package-get.el : package-get-user-package-location 25 years, 3 months

Jan Vroonhof

sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: > Is no more in 21.2. > > >> >> The general concept of having a single package hierarchy > >> >> into which user packages go is broken by now. > > Jan> Huh? Why? > > There are *two* now under ~/.xemacs: xemacs-packages and > mule-packages. Yes. And this one is a definite candidate for ~/.xemacs/site-packages .... > >> Especially the latter is totally sloppy and should be rewritten. > > Jan> Please define 'sloppy'. > > There's no clear concept of where the package index is really supposed > to go. `package-get-locate-index-file' calls `locate-data-file', but > the location where the package index is *stored* is not inferred from > `data-directory-list' at all. Ok, the problem here is that the directories in data-directory-list can magically appear. There maybe no ~/.xemacs/etc/ directory now but (in 21.1) it will magically appear if we create it and restart XEmacs. > Moreover, `package-get-locate-index-file', as a last resort, just > returns `package-get-base-filename' without checking for its > existence. Ok, granted. I think this cruft left from earlier versions. > Jan> Please define broken? It al does what it is supposed to (modulo "~") > Jan> 4. If we cannot write to it, offer to write it to a location where the > Jan> user is likely to be able to write and where XEmacs will find it > Jan> again (i.e. the etc directory of the users package hierarchy). > > But there's a strange mixture of genericity (`locate-data-file') and > hard-wired path construction (like (expand-file-name "etc/" > package-get-user-package-location) ) going on. Yes, but it is necessary because of the "magic" creation problem and the fact that we really want to stick in the top level /etc directory of a package hierarchy, not the "etc/" of some package. Jan

1 participants
0 comments

Re: package-get.el : package-get-user-package-location 25 years, 3 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> >> This looks wrong. Packages go into a package hierarchy, and ~/.xemacs >> >> isn't one. Jan> It is/was in 21.1. Is no more in 21.2. >> >> The general concept of having a single package hierarchy >> >> into which user packages go is broken by now. Jan> Huh? Why? There are *two* now under ~/.xemacs: xemacs-packages and mule-packages. >> >> Actually, looking at >> >> package-get.el (for the first time), the entire logic associated with >> >> `package-get-user-package-location' is complete bogus. >> Especially the latter is totally sloppy and should be rewritten. Jan> Please define 'sloppy'. There's no clear concept of where the package index is really supposed to go. `package-get-locate-index-file' calls `locate-data-file', but the location where the package index is *stored* is not inferred from `data-directory-list' at all. Moreover, `package-get-locate-index-file', as a last resort, just returns `package-get-base-filename' without checking for its existence. >> There's clearly a blatant bug here, but I'd rather leave this eyesore >> in to remind people things are really broken here, rather than going >> for the quick fix. Jan> Please define broken? It al does what it is supposed to (modulo "~") Jan> 1. Get the package index from the best location possible. Jan> 2. Get the file locally using the standard XEmacs data file Jan> algorithms. Jan> 3. If the two don't match offer to update the local file if we can Jan> write to it. This is all cool. Jan> 4. If we cannot write to it, offer to write it to a location where the Jan> user is likely to be able to write and where XEmacs will find it Jan> again (i.e. the etc directory of the users package hierarchy). But there's a strange mixture of genericity (`locate-data-file') and hard-wired path construction (like (expand-file-name "etc/" package-get-user-package-location) ) going on. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: trouble getting started with binary distribution 25 years, 3 months

Michael Sperber

>>>>> "Steve" == Steve Grout <grouts(a)bootskut.eng.sematech.org> writes: Steve> [1 <text/plain>] Steve> The FAQ said to post this to xemacs-beta-request, but that alias Steve> does not seem to exist. I apologize for posting the list directly. Steve> ... Steve> Can you please direct me to the appropriate INSTALL or README.INSTALL? Steve> I downloaded Xemacs 20 from the ftp site and WinZip7.0 extracted it Steve> into c:\bin\Xemacs. I can't get it to start. I've been thru the FAQ. Steve> The backgraound of this is that I am a long time emacs and gnuemacs user Steve> and am wanting to try out Xemacs to see which I like best. I currently Steve> have NtEmacs installed and running (I have clipped in the 'set' output Steve> following the command line output. Steve> --Steve Grout Steve> Sematech Steve> ------------------------------ Steve> C:\bin\Xemacs\bin\i686-pc-cygwin32>xemacs -q -no-site-file > startup-ab Steve> WARNING: Steve> Couldn't find an obvious default for the root of the Steve> XEmacs hierarchy. Steve> WARNING: Steve> Couldn't find obvious defaults for: Steve> doc-directory Steve> data-directory Steve> exec-directory Steve> Perhaps some directories don't exist, or the XEmacs executable, Steve> /bin/Xemacs/bin/i686-pc-cygwin32/xemacs.exe Steve> is in a strange place? Steve> C:\bin\Xemacs\bin\i686-pc-cygwin32>dir Steve> Volume in drive C has no label. Steve> Volume Serial Number is C047-32FA Could you post the output of xemacs -debug-paths ? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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 August 1999