p...@informatimago.com (Pascal J. Bourguignon) writes:
> Before that, we need an essential tool for emacs videos: we need > something that displays on the screen the keychords used.
Simply set `echo-keystrokes' to a sufficiently low value. Hm, ok, after finishing the keystroke you'd normally want to keep it displayed a second or so, even if the invoked command uses the minibuffer...
On Nov 9, 5:05 pm, Tassilo Horn <tass...@member.fsf.org> wrote:
> Hm, ok, after > finishing the keystroke you'd normally want to keep it displayed a > second or so, even if the invoked command uses the minibuffer...
p...@informatimago.com (Pascal J. Bourguignon) writes:
> Read again my first two paragraphs. About the only other program I have > to use (because of lack of javascript in w3m), is firefox. You never > leave emacs! Heresy! And of course, there's a configuration of firefox > giving you emacs key bindings. Which is not the case of Safari or IE > (AFAIK).
Do you know Conkeror ? It's a good alternative to Firefox :
On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) wrote:
> What you don't understand, is that emacs is not a mere application > running on MacOSX or on MS-Windows or on Linux.
> emacs is actually an operating system, with its own window manager, and > it's own consistent user interface.
> It just happens that nobody makes the hardware to run the emacs OS > anymore. It was the LispMachines. So it has to run as a virtual > machine (ever since it was conceived, admitedly and regretably).
Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp interpreter, no more than that. I see your point though.
> When you run MS-Windows in a virtual machine on MacOSX, you don't > complain that it doesn't respect the MacOSX User Interface Guidelines!
> And when you run MS-Windows in a virtual machine on Linux, you don't > complain that it doesn't do things like normal unix applications!
If I were to use an application on a virtual machine heavily, I would look for ways to shape the hosted environment like the hosting one. I run Windows at work, Linux at home, and I strive to get a consistent environment. Luckily, Gnome shares the same idea about CUA.
I like the idea of Eshell as shell. I'll give it a spin.
> Now, for example, I don't like the MS-Windows system, so I don't use it. > If you don't like the emacs system, you can just forget it and don't use > it ever.
No, Pascal. Real world is different. I don't like the MS-Windows system, but I make a living out of it, thus I'm using it. I think Emacs has warts, but there's nothing better out there, therefore I work around them.
> > I think an easy solution exists. First, here is a one liner for each > > binding:
> This is something for you to do, not for the reference distribution of > emacs.
Why? Novices are more likely to flock to the reference distribution, thus it would be better if helpful directions were given there.
> And as I mentionned, it's free software, you are even free to make your > own distribution of emacs.
That's never going to happen. I dislike distributions. IMO, they either show a weakness into the extendibility of a system or a weakness into the supporting community.
> > I've answered already I agree on this. I think the only fix to this > > is a preamble to Emacs' manual.
> What could be added in the preamble if it's not already there, is what > all emacser knows very well even if it's not often mentionned in public, > is that emacs is an OS running on a VM, and it would be nice if Intel, > AMD, or some other founder woud make a LispMachine processor again. > With some microprogramming, it could even be made to run as well > LispMachine microcode as JVM as a few others similar 'V'Ms.
If Lispers teamed up to make Lisp Machines a worthwhile platform, manufacturers would resurrect Lisp machines, no doubt. This is never going to happen, however, since Lispers seem more worried about their keybindings than about - God forbid! - Lisp becoming mainstream. Nothing wrong with that, mind you. Just let's not kid ourselves things are different.
> > What about having different starting points users can improve on? At > > least for keybindings, we are already there: there are vanilla Emacs, > > vanilla Emacs + CUA, Viper + Vimpulse, ErgoEmacs...
Elena <egarr...@gmail.com> writes: > On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) > wrote: >> What you don't understand, is that emacs is not a mere application >> running on MacOSX or on MS-Windows or on Linux.
>> emacs is actually an operating system, with its own window manager, and >> it's own consistent user interface.
>> It just happens that nobody makes the hardware to run the emacs OS >> anymore. It was the LispMachines. So it has to run as a virtual >> machine (ever since it was conceived, admitedly and regretably).
> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp > interpreter, no more than that. I see your point though.
Study the history!
>> When you run MS-Windows in a virtual machine on MacOSX, you don't >> complain that it doesn't respect the MacOSX User Interface Guidelines!
>> And when you run MS-Windows in a virtual machine on Linux, you don't >> complain that it doesn't do things like normal unix applications!
> If I were to use an application on a virtual machine heavily, I would > look for ways to shape the hosted environment like the hosting one. I > run Windows at work, Linux at home, and I strive to get a consistent > environment. Luckily, Gnome shares the same idea about CUA.
You should strive to make MS-Windows more like emacs.
> Why? Novices are more likely to flock to the reference distribution, > thus it would be better if helpful directions were given there.
Depend on the novice. I would have been the kind of novice who would have used the reference distribution, to be sure to be learning the true emacs way, as a long-term investment. I would hate to learn emacs with some massacred keybinding, that I would have to relearn once I switch to the real thing.
>> Why don't you try Emacs.app or Aquamacs.app?
> Because they are not GNU Emacs.
Yes, they are. Emacs.app compiles directly from gnu sources. And aquamacs is basically gnu emacs, with a custom site-start.el
> > If I were to use an application on a virtual machine heavily, I would > > look for ways to shape the hosted environment like the hosting one. I > > run Windows at work, Linux at home, and I strive to get a consistent > > environment. Luckily, Gnome shares the same idea about CUA.
> You should strive to make MS-Windows more like emacs.
Indeed I could. However, the other way around is easier. If I were to make MSW behave like some editor, I would prefer it Vi-like.
> > Why? Novices are more likely to flock to the reference distribution, > > thus it would be better if helpful directions were given there.
> Depend on the novice. I would have been the kind of novice who would > have used the reference distribution, to be sure to be learning the true > emacs way, as a long-term investment. I would hate to learn emacs with > some massacred keybinding, that I would have to relearn once I switch to > the real thing.
You would not: "GNU Emacs is an extensible, ***customizable*** text editor...". Once you have learned it, customizing it is a breeze. The hurdle is learning it, that's why novices should have it easier (without hurting power users).
> >> Why don't you try Emacs.app or Aquamacs.app?
> > Because they are not GNU Emacs.
> Yes, they are. Emacs.app compiles directly from gnu sources. > And aquamacs is basically gnu emacs, with a custom site-start.el
Elena <egarr...@gmail.com> writes: > On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) > > It just happens that nobody makes the hardware to run the emacs OS > > anymore. It was the LispMachines. So it has to run as a virtual > > machine (ever since it was conceived, admitedly and regretably).
> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp > interpreter, no more than that. I see your point though.
It a slight stretch because Emacs predated the Lisp machines: it ran first on ITS, and next (I think) on Multics. But the Lisp machine versions, EINE and ZWEI were highly influential.
> > When you run MS-Windows in a virtual machine on MacOSX, you don't > > complain that it doesn't respect the MacOSX User Interface Guidelines!
> > And when you run MS-Windows in a virtual machine on Linux, you don't > > complain that it doesn't do things like normal unix applications!
> If I were to use an application on a virtual machine heavily, I would > look for ways to shape the hosted environment like the hosting one.
I think that's a serious mistake. Firstly, tools inevitably come with a preconceived notion about how they're meant to be used: trying to use them otherwise is often difficult, requiring more skill and knowledge than you'd need if you conformed to the tools' worldview; and more likely than not prevents you from using the tools to their fullest potential. Secondly, it blurs the boundaries between things which are best kept separate: a virtual machine is distinct from its host, and if you don't keep that in mind, you will get a nasty surprise when you come across one of the essential differences.
> I run Windows at work, Linux at home, and I strive to get a consistent > environment. Luckily, Gnome shares the same idea about CUA.
I always thought that adopting conventions from Windows was a mistake in Gnome. In particular, they missed an opportunity to popularize Emacs keybindings and conventions. (Why should we have a clipboard when we could have a kill ring?)
> > Now, for example, I don't like the MS-Windows system, so I don't use > > it. If you don't like the emacs system, you can just forget it and > > don't use it ever.
> No, Pascal. Real world is different. I don't like the MS-Windows > system, but I make a living out of it, thus I'm using it.
You get to choose how you make a living. Besides, if you dislike it so much, why are you trying to make Emacs mould itself to the Windows way of working rather than the other way around? ;-)
> Why? Novices are more likely to flock to the reference distribution, > thus it would be better if helpful directions were given there.
Why is it good that novices flock to anything? Popularity and quality aren't well correlated. Windows is awful: much of the awfulness is actually because it's trying to meet the requirements of an enormous number of unskilled users.
> If Lispers teamed up to make Lisp Machines a worthwhile platform, > manufacturers would resurrect Lisp machines, no doubt. This is never > going to happen, however, since Lispers seem more worried about their > keybindings than about - God forbid! - Lisp becoming mainstream.
I think becoming mainstream would be one of the worst things that could possibly happen to Lisp! All the people who currently can only write Java because they're copying `design patterns' out of a book, trying to use Lisp? Ugh.
m...@distorted.org.uk (Mark Wooding) writes: > Elena <egarr...@gmail.com> writes:
>> On Nov 8, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) >> > It just happens that nobody makes the hardware to run the emacs OS >> > anymore. It was the LispMachines. So it has to run as a virtual >> > machine (ever since it was conceived, admitedly and regretably).
>> Come on, Pascal, this is a bit of a stretch. Emacs is an Emacs Lisp >> interpreter, no more than that. I see your point though.
> It a slight stretch because Emacs predated the Lisp machines: it ran > first on ITS, and next (I think) on Multics. But the Lisp machine > versions, EINE and ZWEI were highly influential.
AN emacs predated the Lisp machines.
But GNU emacs was started after the experience RMS had with Lisp machines.
>> If I were to use an application on a virtual machine heavily, I would >> look for ways to shape the hosted environment like the hosting one.
> I think that's a serious mistake. Firstly, tools inevitably come with a > preconceived notion about how they're meant to be used: trying to use > them otherwise is often difficult, requiring more skill and knowledge > than you'd need if you conformed to the tools' worldview; and more > likely than not prevents you from using the tools to their fullest > potential. Secondly, it blurs the boundaries between things which are > best kept separate: a virtual machine is distinct from its host, and if > you don't keep that in mind, you will get a nasty surprise when you come > across one of the essential differences.
Indeed.
>> I run Windows at work, Linux at home, and I strive to get a consistent >> environment. Luckily, Gnome shares the same idea about CUA.
> I always thought that adopting conventions from Windows was a mistake in > Gnome. In particular, they missed an opportunity to popularize Emacs > keybindings and conventions. (Why should we have a clipboard when we > could have a kill ring?)
And as an alternative, you can run X on all these systems, and use emacs X11 on all of them, with exactly the same user interface, down to the key bindings.
Or, you could run a MS-Windows in a VM and with vnc have the MS-Windows experience on either Linux or MacOSX.
Unfortunately, for the MacOSX experience, you will have to buy a Macintosh, but otherwise, you can do similarly.
>> No, Pascal. Real world is different. I don't like the MS-Windows >> system, but I make a living out of it, thus I'm using it.
> You get to choose how you make a living. Besides, if you dislike it so > much, why are you trying to make Emacs mould itself to the Windows way > of working rather than the other way around? ;-)
>> Why? Novices are more likely to flock to the reference distribution, >> thus it would be better if helpful directions were given there.
> Why is it good that novices flock to anything? Popularity and quality > aren't well correlated. Windows is awful: much of the awfulness is > actually because it's trying to meet the requirements of an enormous > number of unskilled users.
This must be repeated.
"Much of the awfulness is actually because it's trying to meet the requirements of an enormous number of unskilled users."
>> If Lispers teamed up to make Lisp Machines a worthwhile platform, >> manufacturers would resurrect Lisp machines, no doubt. This is never >> going to happen, however, since Lispers seem more worried about their >> keybindings than about - God forbid! - Lisp becoming mainstream.
> I think becoming mainstream would be one of the worst things that could > possibly happen to Lisp! All the people who currently can only write > Java because they're copying `design patterns' out of a book, trying to > use Lisp? Ugh.
Elena <egarr...@gmail.com> writes: > Pascal J. Bourguignon wrote: >> Why don't you try Emacs.app or Aquamacs.app? > Because they are not GNU Emacs.
The Emacs.app project was merged into GNU Emacs some time ago.
Consequently the Emacs.app application now builds directly from unmodified GNU sources. (There are binary downloads available too.) If it's not GNU Emacs then I 'm not sure what is.
On Nov 11, 11:14 am, m...@distorted.org.uk (Mark Wooding) wrote:
> > If I were to use an application on a virtual machine heavily, I would > > look for ways to shape the hosted environment like the hosting one.
> I think that's a serious mistake. Firstly, tools inevitably come with a > preconceived notion about how they're meant to be used: trying to use > them otherwise is often difficult, requiring more skill and knowledge > than you'd need if you conformed to the tools' worldview; and more > likely than not prevents you from using the tools to their fullest > potential.
I don't understand how this relates to keybindings. Binding "C-c" for yanking and remapping "C-c" prefix to something else, in my opinion doesn't make Emacs any less powerful. It seems I'm the only Emacs user here which doesn't bind Emacs' power to its keybindings.
> Secondly, it blurs the boundaries between things which are > best kept separate: a virtual machine is distinct from its host, and if > you don't keep that in mind, you will get a nasty surprise when you come > across one of the essential differences.
Yeah, I know the Law of Leaky abstractions. I got such a nasty surprise when I tried SSHing from Emacs on Windows.
> > I run Windows at work, Linux at home, and I strive to get a consistent > > environment. Luckily, Gnome shares the same idea about CUA.
> I always thought that adopting conventions from Windows was a mistake in > Gnome. In particular, they missed an opportunity to popularize Emacs > keybindings and conventions. (Why should we have a clipboard when we > could have a kill ring?)
And why should we have a kill ring when we could have both? I think the real mistake is not giving users choice. Do they like Emacs' bindings? Let them have their way. Do they like CUA? Let them have their way.
> > > Now, for example, I don't like the MS-Windows system, so I don't use > > > it. If you don't like the emacs system, you can just forget it and > > > don't use it ever.
> > No, Pascal. Real world is different. I don't like the MS-Windows > > system, but I make a living out of it, thus I'm using it.
> You get to choose how you make a living.
Where there's muck there's brass, they say.
> Besides, if you dislike it so > much, why are you trying to make Emacs mould itself to the Windows way > of working rather than the other way around? ;-)
Because it's more practical to mold a single application than a ton of applications on two operating systems, you know. Moreover, as I've stated already, I'm not fussy about keybindings, provided they stay the same across applications. Have I told enough times that I prefer modal over modeless editing? Yeah, it has its learning curve, but it's totally worth the effort. I fail to be mesmerized by the empowerment of using "C-y" instead of "C-c", though.
> > Why? Novices are more likely to flock to the reference distribution, > > thus it would be better if helpful directions were given there.
> Why is it good that novices flock to anything? Popularity and quality > aren't well correlated.
They aren't always uncorrelated, either.
> Windows is awful: much of the awfulness is > actually because it's trying to meet the requirements of an enormous > number of unskilled users.
Windows has more merits than you think. You have to see through the skin.
> > If Lispers teamed up to make Lisp Machines a worthwhile platform, > > manufacturers would resurrect Lisp machines, no doubt. This is never > > going to happen, however, since Lispers seem more worried about their > > keybindings than about - God forbid! - Lisp becoming mainstream.
> I think becoming mainstream would be one of the worst things that could > possibly happen to Lisp!
Yeah, maybe because then all of its shortcomings would become blindingly clear ^_^
Moreover, companies could jump at the opportunity of building Lisp machines again, and that would be awful indeed, wouldn't it? We love the Intel platform so much, don't we?
> All the people who currently can only write > Java because they're copying `design patterns' out of a book, trying to > use Lisp? Ugh.
We can bitch about Java how much we want, but being mainstream has made the JVM the most stable and performant VM out there.
On Nov 11, 12:55 pm, Elena <egarr...@gmail.com> wrote:
> We can bitch about Java how much we want, but being mainstream has > made the JVM the most stable and performant VM out there.
Not to mention how rich the Java SDK API is and how much battle-tested the Java platform as a whole is. But we would hate having these features into our Lisp systems, wouldn't we? Much more fun hunting for libraries and scavenging for scraps of code.
Elena <egarr...@gmail.com> writes: > We can bitch about Java how much we want, but being mainstream has > made the JVM the most stable and performant VM out there.
On Nov 6, 8:29 pm, p...@informatimago.com (Pascal J. Bourguignon) wrote:
> m...@distorted.org.uk (Mark Wooding) writes: [...] > > You forget: Emacs was designed /long/ before the C-z/x/c/v convention > > was dreamt up. > Moreover, the convention is NOT C-z C-x C-c C-v, but Command-z > Command-x Command-c Command-v, as you can check on any Macintosh, and > from which Microsoft copied. > emacs is totally justified in keeping its Control- bindings
Indeed, modern Mac programs almost always support a subset of the Emacs keybindings, which makes using Windows all the more perilous. I've hit C-a and started typing before realizing that I wiped out my whole document instead of adding some text to the beginning of the line many, many times. Well, at least C-z is almost always "Undo" on Windows.... :-/
Elena <egarr...@gmail.com> writes: > Pascal, maybe we are after something now. Could it be that what is > needed more in the Emacs community is knowing *how* Emacs power users > use Emacs? It's not that we need more Emacs Lisp tutorials, it's not > that we need more .emacs files.
You are exactly right. I am new to emacs, but i think i know enough to get my daily work done with it (mostly programming stuff). What i miss are new ideas how i can improve my work with emacs. Lets take gnus for example. I like reading news with it because i like the power of emacs integrated in my newsreader. But i still don't have the right "workflow". Should i catch up all articles after reading the interesting post in a newsgroup? Then the next time i visit the group all threads are incomplete. At the moment, i use "A T" to complete threads i find interesting and start reading from the completed tree. How do full-fledged user handle the way they reading news? Use scoring to mark interesting articles? The same with the org-mode. How users really use it to improve their daily work.
> Elena <egarr...@gmail.com> writes: > > On 7 Nov, 21:24, Tim X <t...@nospam.dev.null> wrote: > >> Define those basic expectations. So far, you have mentioned lack of > >> support for the common cut/copy/paste commands on the CUA > >> bindings, but that is available with one click in the options menu.
> > A basic expectation is that CUA does not require you to hunt for an > > option to enable it. It just works out of the box.
> >> You > >> mention lack of a file browser, yetemacshas two in its vanilla > >> configuration.
> > Oh, no, this was an unrelated observation. I was saying that all > > editors I've tried which target programmers have a project file tree > > on the left and output windows on the bottom. OTOH, Emacs is known to > > being used by programmers, still setting up such a configuration is > > awkward, then popups are disrupting your windows layout all the time, > > ecc. Confusing, confusing.
> > Currently my preferred file browser is that offered by IDO, but I > > depended for a long time on the basic GUI one.
> Perhaps the problem here is that you're trying to organize the windows > yourself. Let emacs pop the windows for your, and organize them for > you. You'll spend less time moving windows around, and more time > programming or debugging. Hence emacs will increase your productivity.
I'd very like to. However - unless I'm doing something wrong - Emacs keeps displaying windows in objectively wrong places. For instance, `compilation-start' opens a window on the right, where there is not enough room for file paths in errors. And so on.
Elena <egarr...@gmail.com> writes: > On 8 Nov, 12:30, p...@informatimago.com (Pascal J. Bourguignon) wrote: >> Elena <egarr...@gmail.com> writes: >> > On 7 Nov, 21:24, Tim X <t...@nospam.dev.null> wrote: >> >> Define those basic expectations. So far, you have mentioned lack of >> >> support for the common cut/copy/paste commands on the CUA >> >> bindings, but that is available with one click in the options menu.
>> > A basic expectation is that CUA does not require you to hunt for an >> > option to enable it. It just works out of the box.
>> >> You >> >> mention lack of a file browser, yetemacshas two in its vanilla >> >> configuration.
>> > Oh, no, this was an unrelated observation. I was saying that all >> > editors I've tried which target programmers have a project file tree >> > on the left and output windows on the bottom. OTOH, Emacs is known to >> > being used by programmers, still setting up such a configuration is >> > awkward, then popups are disrupting your windows layout all the time, >> > ecc. Confusing, confusing.
>> > Currently my preferred file browser is that offered by IDO, but I >> > depended for a long time on the basic GUI one.
>> Perhaps the problem here is that you're trying to organize the windows >> yourself. Let emacs pop the windows for your, and organize them for >> you. You'll spend less time moving windows around, and more time >> programming or debugging. Hence emacs will increase your productivity.
> I'd very like to. However - unless I'm doing something wrong - Emacs > keeps displaying windows in objectively wrong places. For instance, > `compilation-start' opens a window on the right, where there is not > enough room for file paths in errors. And so on.
Are you saying that it is creating a new window by splitting the existing window vertically and putting the compilation output on the right and your source on the left or are you saying that it creates a new frame, which is put on the right and which is too narrow to display the full error message?
In either case, this is not normal emacs behavior. Either you have customized things or you are using a package that has. Normal behavior is to split the source code window horizontally and usually evenly, with the source in the top window and the compilation output in the bottom window.
Try running with emacs -Q and then compiling and see what you get. If it behaves in a more sensible manner, then it is something in your .emacs, one of the libs you load or your local site init/config.
As Pascal has mentioned, generally it is better to let emacs manage this and not mess with it.One of the reasons for this is that it can be quite complicated and minor changes can have unexpected side-effects. However, we are talking about emacs, so you can mess with it if you want. Just remember that when things begin to do unexpected things or emacs seems to be doing stupid things, more often than not, this is because of the changes you have made. While you may think your changes are unrelated or would not have had any impact, it is easy to be mistaken.
To values which may be worth looking at are split-height-threshold and split-width-threshold. These variables affect when demacs decides to split a window vertically or horizontally.
If this still doesn't give you what you want, there is split-window-preferred-function, which can be used to change the function emacs uses to determine how to split a window, though you really need to be aware that changing this function can result in some weird behavior. A far better approach is to come up a level of abstraction and use things like special-display-buffer-names and friends rather than low level functions that deal directly with window/frame generation and splitting. Also, don't overlook the importance/influence that your window manager can have. I've seen quite dramatic differences on the same platform simply due to a change in window manager or window manager configuration. this is particularly relevant when it comes to frames and placement. You can even configure emacs to always use frames and not split windows if you prefer. This may, depending on platform and expectations, give an interface experience that is more in-line with what the user is accustomed to.
Elena <egarr...@gmail.com> writes: > And why should we have a kill ring when we could have both? I think > the real mistake is not giving users choice. Do they like Emacs' > bindings? Let them have their way. Do they like CUA? Let them have > their way.
I don't understand, isn't this exactly what Emacs do ?
On Nov 17, 2:22 am, Tim X <t...@nospam.dev.null> wrote:
> Are you saying that it is creating a new window by splitting the > existing window vertically and putting the compilation output on the > right and your source on the left or are you saying that it creates a > new frame, which is put on the right and which is too narrow to display > the full error message?
The former.
> In either case, this is not normal emacs behavior. Either you have > customized things or you are using a package that has. Normal behavior > is to split the source code window horizontally and usually evenly, with > the source in the top window and the compilation output in the bottom > window.
> Try running with emacs -Q and then compiling and see what you get. If it > behaves in a more sensible manner, then it is something in your .emacs, > one of the libs you load or your local site init/config.
Yes, indeed "emacs -Q" behaves like that. However, there is a lot of code between "emacs -Q" and my current Emacs configuration, so adding one package at a time is not an option.
> To values which may be worth looking at are split-height-threshold and > split-width-threshold. These variables affect when demacs decides to > split a window vertically or horizontally.
I've checked both such variables and `split-window-preferred- function', but neither are referenced by the packages I'm using.
> If this still doesn't give you what you want, there is > split-window-preferred-function, which can be used to change the > function emacs uses to determine how to split a window, though you > really need to be aware that changing this function can result in some > weird behavior. A far better approach is to come up a level of > abstraction and use things like special-display-buffer-names and friends > rather than low level functions that deal directly with window/frame > generation and splitting. Also, don't overlook the importance/influence > that your window manager can have. I've seen quite dramatic differences > on the same platform simply due to a change in window manager or window > manager configuration. this is particularly relevant when it comes to > frames and placement. You can even configure emacs to always use frames > and not split windows if you prefer. This may, depending on platform and > expectations, give an interface experience that is more in-line with > what the user is accustomed to.
Well, I guess some more hack could achieve the vanilla Emacs behavior. I'll look into that.
Elena <egarr...@gmail.com> writes: > On Nov 17, 2:22 am, Tim X <t...@nospam.dev.null> wrote: >> Are you saying that it is creating a new window by splitting the >> existing window vertically and putting the compilation output on the >> right and your source on the left or are you saying that it creates a >> new frame, which is put on the right and which is too narrow to display >> the full error message?
> The former.
>> In either case, this is not normal emacs behavior. Either you have >> customized things or you are using a package that has. Normal behavior >> is to split the source code window horizontally and usually evenly, with >> the source in the top window and the compilation output in the bottom >> window.
>> Try running with emacs -Q and then compiling and see what you get. If it >> behaves in a more sensible manner, then it is something in your .emacs, >> one of the libs you load or your local site init/config.
> Yes, indeed "emacs -Q" behaves like that. However, there is a lot of > code between "emacs -Q" and my current Emacs configuration, so adding > one package at a time is not an option.
>> To values which may be worth looking at are split-height-threshold and >> split-width-threshold. These variables affect when demacs decides to >> split a window vertically or horizontally.
> I've checked both such variables and `split-window-preferred- > function', but neither are referenced by the packages I'm using.
>> If this still doesn't give you what you want, there is >> split-window-preferred-function, which can be used to change the >> function emacs uses to determine how to split a window, though you >> really need to be aware that changing this function can result in some >> weird behavior. A far better approach is to come up a level of >> abstraction and use things like special-display-buffer-names and friends >> rather than low level functions that deal directly with window/frame >> generation and splitting. Also, don't overlook the importance/influence >> that your window manager can have. I've seen quite dramatic differences >> on the same platform simply due to a change in window manager or window >> manager configuration. this is particularly relevant when it comes to >> frames and placement. You can even configure emacs to always use frames >> and not split windows if you prefer. This may, depending on platform and >> expectations, give an interface experience that is more in-line with >> what the user is accustomed to.
> Well, I guess some more hack could achieve the vanilla Emacs > behavior. I'll look into that.
Emacs configuration is similar to programming and you need to structure it with the same principals i.e. organise it so that it is manageable and facilitates debugging. One approach, which I find really helps is to not have it all in one file. My .emacs file contains nothing other than a couple of add-path statements, a block of require statements and the customize section that is managed by emacs' customize feature.
I break all my hand crafted customizations into small distinct files in a separate config directory. Each file ends with a (provide 'some-name). I then just have (require 'some-name) in my .emacs.
The advantage with doing this is that when I have a problem, I can just comment out the require lines and run emacs to see if the problem still exists. I then start adding back the require lines until the problem appears. Once I see the problem, I know which of the small config files is the culprit and can then look more closely at that file. You can even use a binary search approach - comment out the last half, see if the problem occurs. If it does, comment out half what remains and test again. If it still occurs, you know its in the remaining quarter, comment half that and continue. . . .
> Elena <egarr...@gmail.com> writes: > > On Nov 17, 2:22 am, Tim X <t...@nospam.dev.null> wrote: > >> Are you saying that it is creating a new window by splitting the > >> existing window vertically and putting the compilation output on the > >> right and your source on the left or are you saying that it creates a > >> new frame, which is put on the right and which is too narrow to display > >> the full error message?
> > The former.
> >> In either case, this is not normal emacs behavior. Either you have > >> customized things or you are using a package that has. Normal behavior > >> is to split the source code window horizontally and usually evenly, with > >> the source in the top window and the compilation output in the bottom > >> window.
> >> Try running with emacs -Q and then compiling and see what you get. If it > >> behaves in a more sensible manner, then it is something in your .emacs, > >> one of the libs you load or your local site init/config.
> > Yes, indeed "emacs -Q" behaves like that. However, there is a lot of > > code between "emacs -Q" and my current Emacs configuration, so adding > > one package at a time is not an option.
> >> To values which may be worth looking at are split-height-threshold and > >> split-width-threshold. These variables affect when demacs decides to > >> split a window vertically or horizontally.
> > I've checked both such variables and `split-window-preferred- > > function', but neither are referenced by the packages I'm using.
> >> If this still doesn't give you what you want, there is > >> split-window-preferred-function, which can be used to change the > >> function emacs uses to determine how to split a window, though you > >> really need to be aware that changing this function can result in some > >> weird behavior. A far better approach is to come up a level of > >> abstraction and use things like special-display-buffer-names and friends > >> rather than low level functions that deal directly with window/frame > >> generation and splitting. Also, don't overlook the importance/influence > >> that your window manager can have. I've seen quite dramatic differences > >> on the same platform simply due to a change in window manager or window > >> manager configuration. this is particularly relevant when it comes to > >> frames and placement. You can even configure emacs to always use frames > >> and not split windows if you prefer. This may, depending on platform and > >> expectations, give an interface experience that is more in-line with > >> what the user is accustomed to.
> > Well, I guess some more hack could achieve the vanilla Emacs > > behavior. I'll look into that.
> Emacs configuration is similar to programming and you need to structure > it with the same principals i.e. organise it so that it is manageable > and facilitates debugging. One approach, which I find really helps is to > not have it all in one file. My .emacs file contains nothing other than > a couple of add-path statements, a block of require statements and the > customize section that is managed by emacs' customize feature.
> I break all my hand crafted customizations into small distinct files in > a separate config directory. Each file ends with a (provide 'some-name). > I then just have (require 'some-name) in my .emacs.
> The advantage with doing this is that when I have a problem, I can just > comment out the require lines and run emacs to see if the problem still > exists. I then start adding back the require lines until the problem > appears. Once I see the problem, I know which of the small config files > is the culprit and can then look more closely at that file. You can even > use a binary search approach - comment out the last half, see if the > problem occurs. If it does, comment out half what remains and test > again. If it still occurs, you know its in the remaining quarter, > comment half that and continue. . . .
Thank you for your detailed directions, Tim.
Amusingly, I'm refactoring my .emacs in the opposite direction: I'm merging all my configuration files into one, and conditionally running code based on some flags and/or available features. I got sick of grepping and opening different files all the time. Separate files are good when you are going to reuse your code, but Emacs Lisp configuration is only being run by Emacs at startup, so what? The principle is the same, however.
