April 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: change \C-m binding to newline-and-indent 25 years

Jason R Mastaler

SL Baur <steve(a)xemacs.org> writes: > > But even on other days, I'd prefer the default configuration of Emacs > > to be as CUA compliant as possible, and then some. > ... > > What does CUA stand for? Common User Application.

1 participants
0 comments

Re: Patches to split the Options/Font menu based on the first char 25 years

Didier Verna

Tudor Hulubei writes: Tudor> The code that generates the Options menu is part of the XEmacs core Tudor> lisp packages. `func-menu.el' is not, and using it in generating the Tudor> Options menu will unconditionally require it. Is that acceptable? No it is not, but I beleive it should be good to have a generic implementation of this feature, because it's potentially useful for all menus that may appear in a XEmacs menubar. -- / / _ _ 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

2 participants
1 comments

Patches to split the Options/Font menu based on the first char 25 years

Giacomo Boffi

Tudor Hulubei writes: > This is an ugly hack, but it makes life a lot easier. The correct > solution would be to use a toolkit that splits long menus > automatically Tudor, may i suggest you to look at the code of func-menu, that automatically splits long lists of functions, putting them on submenus?

2 participants
1 comments

Patches to split the Options/Font menu based on the first char 25 years

Giacomo Boffi

Tudor Hulubei writes: > This is an ugly hack, but it makes life a lot easier. The correct > solution would be to use a toolkit that splits long menus > automatically Tudor, may i suggest you to look at the code of func-menu, that automatically splits long lists of functions, putting them on submenus?

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

SL Baur

Per Abrahamsen <abraham(a)dina.kvl.dk> writes in xemacs-beta(a)xemacs.org: > But even on other days, I'd prefer the default configuration of Emacs > to be as CUA compliant as possible, and then some. ... What does CUA stand for? > Having thus lost all credibility, I can comment on CR's proposal, > which apparently isn't specific for this day. I believe it is a bad > idea, even though it is what 99% of the users will want. I think > programs should be stupid, until the user explicitly tells them to be > smart. In a text editor, something as basic as the carriage return > key should only insert a new line, not try to be smart. Not by > default. Once the user has discovered what the `C' or `TeX' in the > second line from the bottom means, he can start change the defaults. > Maybe it should be easier to enable `smart return' though. I agree with not changing the default. I prefer C-j to get automatic indentation. On the other hand, cc-mode has gotten so `smart' lately that I tend to edit C code in fundamental-mode now. I think changing the [(control m)] binding sucks, but I don't intend to fight against a strong consensus. I despise rebinding [(control c)], [(control x)], and [(control v)] with a passion, however if someone can make Kim Storm's code work with XEmacs, I am not opposed to making it a default if it is installed (ie. by having it autoload initialization).

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

SL Baur

Per Abrahamsen <abraham(a)dina.kvl.dk> writes in xemacs-beta(a)xemacs.org: > Colin Rafferty <craffert(a)ms.com> writes: >> Does anyone disagree? > Not today, there aren't. But maybe we should rebind `C-x', `C-c', and > `C-v' to `cut', `copy', and `paste' at the same time? Somebody hack on the attachment and make it not suck. > That is what most new users expect. This port is courtesy of Altrasoft and I didn't have a chance to get it integrated before I left for Japan in January.

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

Hrvoje Niksic

Colin Rafferty <craffert(a)ms.com> writes: > This is a major change, so I thought it would be better to throw > this out to the list, rather than just submitting a patch. [...] Colin, you're out of luck. I asked the _exactly_ same question about a year ago, and it turned out that many people never saw the light regarding this, and they actively opposed the change of the defaults.

1 participants
0 comments

XEmacs crashes on empty menus 25 years

Tudor Hulubei

Add this to menubar-items.el: ("Crash" :filter '()) under the line reading: ["Edit Faces..." (customize-face nil)] Then recompile and run XEmacs. Click on Options, then on Crash. You will get an item saying "No menu". Try going to that item with the keyboard (type right-arrow) instead of the mouse. XEmacs will crash. I didn't had time to investigate it too much, all I saw was that Fcharacter_to_event gets called with ch=0 (in events.c) which causes a crash at the time CONSP(ch) is called. Hope this helps, Tudor

1 participants
0 comments

Re: change \C-m binding to newline-and-indent 25 years

Didier Verna

[ Sorry, accident post ] Didier Verna writes: Colin> I see it the other way around. 99% of the time that you hit <return> Colin> when writing code, the next key that you type is <tab>. me> Right. The real question behind this has actually been underlying in me> several other threads: assuming that 99% of the population does THIS, me> should the default be THIS and not THAT? Or the other way around, if we me> have 1% doing THAT (which is the default), do we have the right to fuck me> them up? ... Personaly, I'm usually pissed off by all the backward compatibility that we're trying to maintain, so doing a radical change wouldn't bother me that much. However, there are cases (like this one) where I think it is a bad idea. Here we're not talking of rewriting a better API for such or such feature of XEmacs, we're talking of changing one of the _most basic_ thing that an editor is supposed to do, namely inserting a character from the keyboard, to something fancy. In that particular case, I don't think that 99% of the people doing something is a valid argument to change the default. What if the other 1% someday fall on a case where the fancy binding leads to an undesirable behavior? That's something that I don't think we can afford. IMHO, and this is valid for all the threads we've had on similar questions, the majority should _not_ win, if a _single_ person has to customize an option to actually make it simpler. Customize things to make them more clever, never simpler. -- / / _ _ 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: change \C-m binding to newline-and-indent 25 years

Didier Verna

Colin Rafferty writes: Colin> The first line in `newline-and-indent': Colin> (delete-region (point) (progn (skip-chars-backward " \t") (point))) Colin> So when you just hit return to move through the lines, only the last Colin> line is indented (the one that you end up on). Hmph! Then I think I'll immediately bind return to newline-and-indent :-) Colin> I see it the other way around. 99% of the time that you hit <return> Colin> when writing code, the next key that you type is <tab>. Right. The real question behind this has actually been underlying in several other threads: assuming that 99% of the population does THIS, should the default be THIS and not THAT? Or the other way around, if we have 1% doing THAT (which is the default), do we have the right to fuck them up? -- / / _ _ 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

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