* Reopen bug 535: Problem with highlit regions on Linux virtual terminal @ 2009-04-05 23:05 Alan Mackenzie 2009-04-06 1:12 ` Miles Bader 2009-04-06 3:03 ` Chong Yidong 0 siblings, 2 replies; 17+ messages in thread From: Alan Mackenzie @ 2009-04-05 23:05 UTC (permalink / raw) To: emacs-devel Hi, Yidong, Hi Emacs! I submitted the bug report (below) ~9 months ago. In August, it got tagged with "won't fix". I seem to have missed the discussion on this decision. This problem makes the default setup barely usable on a Linux virtual terminal; it surely must be fixed before release. I have removed the "won't fix" tag and increased its severity to "serious". -- Alan Mackenzie (Nuremberg, Germany). ----- Forwarded message from Alan Mackenzie <acm@muc.de> ----- Date: Fri, 4 Jul 2008 21:17:01 +0000 From: Alan Mackenzie <acm@muc.de> To: emacs-pretest-bug@gnu.org Subject: Problem with highlit regions on Linux virtual terminal In a GNU/Linux system, log on to a virtual terminal. (If already in X, do, e.g., Ctrl-Alt-F1 to get there). With an up to date CVS version, emacs -Q C-x C-f .../path/to/emacs/lisp/files.el C-s find-alternate-file <CR> Note the general quality of the display (high :-), including the font locking. Now do C-M-h to mark the function. Note again the quality of the display (low :-(). We have uniform pale grey text on a bright blue background, and the sole remaining vestige of the font locking is that font-lock-keyword-face (and one or two others) are in bold white rather than pale grey. This is unacceptable for our release. It has been a particular problem since transient-mark-mode became switched on by default. -- Alan Mackenzie (Nuremberg, Germany). ----- End forwarded message ----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-05 23:05 Reopen bug 535: Problem with highlit regions on Linux virtual terminal Alan Mackenzie @ 2009-04-06 1:12 ` Miles Bader 2009-04-06 3:10 ` Chong Yidong 2009-04-06 9:03 ` Alan Mackenzie 2009-04-06 3:03 ` Chong Yidong 1 sibling, 2 replies; 17+ messages in thread From: Miles Bader @ 2009-04-06 1:12 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: > C-M-h > > to mark the function. Note again the quality of the display (low :-(). > We have uniform pale grey text on a bright blue background, and the sole > remaining vestige of the font locking is that font-lock-keyword-face > (and one or two others) are in bold white rather than pale grey. I beg to differ -- it looks great to me (high-contrast, readable, usable). [not just on the linux console, either, but in every environment I tried it in -- X, xterm, gnome-terminal, light-background, black-background] You seem to be right that it's suppressing most of the font-locking in the highlighted area. I don't know exactly why it does so (whether this is intentional behavior or an artifact of the implementation), but it's not at all clear to me that this behavior is a bad thing -- region highlighting is generally temporary, and the text would very likely be _less_ readable if the font-locking was preserved (because the font-lock colors are designed to be readable with the standard background, and would in many cases be quite awful against the highlighted background). -Miles -- Conservative, n. A statesman enamored of existing evils, as opposed to a Liberal, who wants to replace them with new ones. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 1:12 ` Miles Bader @ 2009-04-06 3:10 ` Chong Yidong 2009-04-06 9:36 ` Alan Mackenzie 2009-04-06 9:03 ` Alan Mackenzie 1 sibling, 1 reply; 17+ messages in thread From: Chong Yidong @ 2009-04-06 3:10 UTC (permalink / raw) To: Miles Bader; +Cc: Alan Mackenzie, emacs-devel Miles Bader <miles@gnu.org> writes: > You seem to be right that it's suppressing most of the font-locking in > the highlighted area. I don't know exactly why it does so (whether this > is intentional behavior or an artifact of the implementation) See the definition of the `region' face in faces.el. On displays with sufficient colors, the face definition sets just :background, leaving the remaining face attributes unspecified; those will generally be set from the font-lock face. On 8-color displays, both :background and :foreground is set. This is quite reasonable, because of the paucity of colors on such displays. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 3:10 ` Chong Yidong @ 2009-04-06 9:36 ` Alan Mackenzie 0 siblings, 0 replies; 17+ messages in thread From: Alan Mackenzie @ 2009-04-06 9:36 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel, Miles Bader HI, Yidong! On Sun, Apr 05, 2009 at 11:10:06PM -0400, Chong Yidong wrote: > Miles Bader <miles@gnu.org> writes: > > You seem to be right that it's suppressing most of the font-locking > > in the highlighted area. I don't know exactly why it does so > > (whether this is intentional behavior or an artifact of the > > implementation) > See the definition of the `region' face in faces.el. On displays with > sufficient colors, the face definition sets just :background, leaving > the remaining face attributes unspecified; those will generally be set > from the font-lock face. > On 8-color displays, both :background and :foreground is set. This is > quite reasonable, because of the paucity of colors on such displays. I disagree - precisely because of this paucity of colours, it is unreasonable to override both. Font locking is important. The contrast between a highlit region and a font locked region (the current setup excludes a combination of both) is too violent. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 1:12 ` Miles Bader 2009-04-06 3:10 ` Chong Yidong @ 2009-04-06 9:03 ` Alan Mackenzie 2009-04-06 9:30 ` Miles Bader 1 sibling, 1 reply; 17+ messages in thread From: Alan Mackenzie @ 2009-04-06 9:03 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Hi, Miles! On Mon, Apr 06, 2009 at 10:12:54AM +0900, Miles Bader wrote: > Alan Mackenzie <acm@muc.de> writes: > > C-M-h > > to mark the function. Note again the quality of the display (low :-(). > > We have uniform pale grey text on a bright blue background, and the sole > > remaining vestige of the font locking is that font-lock-keyword-face > > (and one or two others) are in bold white rather than pale grey. > I beg to differ -- it looks great to me (high-contrast, readable, usable). > [not just on the linux console, either, but in every environment I tried > it in -- X, xterm, gnome-terminal, light-background, black-background] Yes, it is high-contrast and so on, in the same way that a foghorn at 200m is highly audible when you're trying to have a quiet conversation. > You seem to be right that it's suppressing most of the font-locking in > the highlighted area. It all but obliterates it. It obliterates hi-lock mode entirely. I think it does this in GUI environments too. > I don't know exactly why it does so (whether this is intentional > behavior or an artifact of the implementation), but it's not at all > clear to me that this behavior is a bad thing -- region highlighting > is generally temporary, A blaring foghorn is temporary too. When I start Emacs 23 -Q, all of my buffers (loaded by desktop) are foghorned - I find Emacs in this state unusable. > and the text would very likely be _less_ readable if the font-locking > was preserved (because the font-lock colors are designed to be > readable with the standard background, and would in many cases be > quite awful against the highlighted background). I agree with the logic here. Region highlighting is incompatible with font lock and hi-lock. Do you think that turning off font lock by default might be a good solution? > -Miles -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 9:03 ` Alan Mackenzie @ 2009-04-06 9:30 ` Miles Bader 2009-04-06 12:52 ` Alan Mackenzie 2009-04-07 20:55 ` Alan Mackenzie 0 siblings, 2 replies; 17+ messages in thread From: Miles Bader @ 2009-04-06 9:30 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: > Yes, it is high-contrast and so on, in the same way that a foghorn at > 200m is highly audible when you're trying to have a quiet conversation. This a silly analogy, and bears no resemblance to the actual appearance, which is quite nice in my opinion. >> You seem to be right that it's suppressing most of the font-locking in >> the highlighted area. > > It all but obliterates it. ... and yet, it simply _doesn't matter_, because highlighted regions are _temporary_. I use Emacs too, and I find the behavior very reasonable. Font-Locking is nice, but it's very much secondary information, and suppressing some of it when selecting a region (when your attention is focused on the region), is just not a big deal -- indeed, I didn't even _notice_ that font-locking colors were suppressed by the region on a tty until you mentioned it! >It obliterates hi-lock mode entirely. I > think it does this in GUI environments too. Yes, because hi-lock uses the background. This is probably not particularly important. > A blaring foghorn is temporary too. ... which is quite irrelevant, since your "foghorn" analogy is not accurate; arguing by means of poor analogies is not useful. > When I start Emacs 23 -Q, all of my buffers (loaded by desktop) are > foghorned - I find Emacs in this state unusable. All of your buffers have activated regions when Emacs starts? If so, _that_ sounds like a bug (so please try to send a test case); needless to say, I think, I do not see this behavior. > I agree with the logic here. Region highlighting is incompatible with > font lock and hi-lock. Do you think that turning off font lock by > default might be a good solution? Of course not, since as far as I can see, there isn't actually any problem. It seems pretty obvious to me that all of this is much more a matter of taste than anything else. You have made your opinion on the matter very clear, repeatedly. The Emacs maintainers have made their best judgement as to what the majority of Emacs users will prefer. You know how to turn off the highlighting. -Miles -- "Whatever you do will be insignificant, but it is very important that you do it." Mahatma Gandhi ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 9:30 ` Miles Bader @ 2009-04-06 12:52 ` Alan Mackenzie 2009-04-06 15:35 ` David De La Harpe Golden 2009-04-07 20:55 ` Alan Mackenzie 1 sibling, 1 reply; 17+ messages in thread From: Alan Mackenzie @ 2009-04-06 12:52 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel On Mon, Apr 06, 2009 at 06:30:28PM +0900, Miles Bader wrote: > Alan Mackenzie <acm@muc.de> writes: > >> You seem to be right that it's suppressing most of the font-locking > >> in the highlighted area. > > It all but obliterates it. > ... and yet, it simply _doesn't matter_, because highlighted regions > are _temporary_. I use Emacs too, and I find the behavior very > reasonable. Why does the temporariness make something not important? Temporary things are very important. I'm sensitive to things which flash and bang, which is one of the main reasons I've loved Emacs so much - up till now, it has never flashed and banged by default. > Font-Locking is nice, but it's very much secondary information, and > suppressing some of it when selecting a region (when your attention is > focused on the region), is just not a big deal -- indeed, I didn't > even _notice_ that font-locking colors were suppressed by the region > on a tty until you mentioned it! It's a big deal for me. Probably for lots of other TTY users, too. And if font-locking is secondary, surely region highlighting is tertiary? The normal Emacs default for such personal preferences has always been to be restrained - surely lots of people like angry fruit salad font lock faces, but we don't make them the default. > >It obliterates hi-lock mode entirely. I think it does this in GUI > >environments too. > Yes, because hi-lock uses the background. This is probably not > particularly important. Again, I think it is. I don't think it's been discussed here at all. > All of your buffers have activated regions when Emacs starts? They all have hilit regions when Emacs starts. > If so, _that_ sounds like a bug (so please try to send a test case); Ah, OK. I don't have the background to judge. ;-) > needless to say, I think, I do not see this behavior. No, you do in fact need to say this. You're saying that when you start Emacs with a desktop, your buffers don't have highlit regions, yes? Mine do. My .emacs.desktop was first created by Emacs 21 in ~4004 BC, and currently gets renewed in Emacs 22, and occasionally loaded into Emacs 23. Maybe that has something to do with it. I'll have a look sometime. > > I agree with the logic here. Region highlighting is incompatible > > with font lock and hi-lock. Do you think that turning off font lock > > by default might be a good solution? > Of course not, since as far as I can see, there isn't actually any > problem. > It seems pretty obvious to me that all of this is much more a matter of > taste than anything else. Yes. Normally, in matters of taste, Emacs's defaults incline towards the restrained, conservative. Here we have a glaring exception. > You have made your opinion on the matter very clear, repeatedly. The > Emacs maintainers have made their best judgement as to what the > majority of Emacs users will prefer. No, not at all. On the specific matter of the interaction between region hilighting and font-locking/hi-locking, I raised a bug report last summer, as requested by Stefan. Until yesterday there had been no discussion of it at all, as far as I am aware. > You know how to turn off the highlighting. Yes of course. But for a "mere" user, it's very difficult to find this out. > -Miles -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 12:52 ` Alan Mackenzie @ 2009-04-06 15:35 ` David De La Harpe Golden 2009-04-07 21:46 ` Alan Mackenzie 0 siblings, 1 reply; 17+ messages in thread From: David De La Harpe Golden @ 2009-04-06 15:35 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Miles Bader Alan Mackenzie wrote: > > It's a big deal for me. Probably for lots of other TTY users, too. These days, a lot text terminal emulators support 256 color mode. Unfortunately, the linux kernel console in particular doesn't seem to, but framebuffer (rather than hardware text mode) consoles on PC SVGA and similar hardware certianly *should* be able to in principle, it's possible just no-one's bothered writing the support. Hmm. > And > if font-locking is secondary, surely region highlighting is tertiary? ? Stuff is still legible without font locking, you can't even see the region without region highlighting... > No, not at all. On the specific matter of the interaction between region > hilighting and font-locking/hi-locking, I raised a bug report last > summer, as requested by Stefan. Until yesterday there had been no > discussion of it at all, as far as I am aware. > I thought I posted something about the IMO nicest solution being to allow alphablending computation to mix the various foreground and background colors coming in from the overlaid faces somewhere around face realization time rather than just having higher priority override lower priority, but maybe I hallucinated actually saying that publically or thought I'd wait till I had a patch to do it. Such a solution still wouldn't work exactly amazingly on an 8-color terminal to solve your "hi-lock background popping" problem, but would on 256 color text terminal or bitmap gui emacs - i.e. the region face could supply a translucent-looking tint instead of nuking the background (and maybe foreground). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 15:35 ` David De La Harpe Golden @ 2009-04-07 21:46 ` Alan Mackenzie 0 siblings, 0 replies; 17+ messages in thread From: Alan Mackenzie @ 2009-04-07 21:46 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Miles Bader, emacs-devel Hi, David, On Mon, Apr 06, 2009 at 04:35:59PM +0100, David De La Harpe Golden wrote: > Alan Mackenzie wrote: > These days, a lot text terminal emulators support 256 color mode. > Unfortunately, the linux kernel console in particular doesn't seem to, > but framebuffer (rather than hardware text mode) consoles on PC SVGA > and similar hardware certianly *should* be able to in principle, it's > possible just no-one's bothered writing the support. Hmm. > > And if font-locking is secondary, surely region highlighting is > > tertiary? > ? Stuff is still legible without font locking, you can't even > see the region without region highlighting... I've never had a problem seeing a region, and I've never used region highlighting. (OK, I know what you meant.). > >No, not at all. On the specific matter of the interaction between > >region hilighting and font-locking/hi-locking, I raised a bug report > >last summer, as requested by Stefan. Until yesterday there had been > >no discussion of it at all, as far as I am aware. > I thought I posted something about the IMO nicest solution being to > allow alphablending computation to mix the various foreground and > background colors coming in from the overlaid faces somewhere around > face realization time rather than just having higher priority override > lower priority, but maybe I hallucinated actually saying that > publically or thought I'd wait till I had a patch to do it. No, I must just have forgotten about it, or missed it. That sounds like an excellent solution, so that you could make region highlighting do some de-saturization, and adjust the degree of it to an optimum where the colour change is slight enough not to be disturbing, yet firm enough to be clearly seen. > Such a solution still wouldn't work exactly amazingly on an 8-color > terminal to solve your "hi-lock background popping" problem, but would > on 256 color text terminal or bitmap gui emacs - i.e. the region face > could supply a translucent-looking tint instead of nuking the background > (and maybe foreground). Yes. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-06 9:30 ` Miles Bader 2009-04-06 12:52 ` Alan Mackenzie @ 2009-04-07 20:55 ` Alan Mackenzie 2009-04-08 5:35 ` Stephen J. Turnbull 1 sibling, 1 reply; 17+ messages in thread From: Alan Mackenzie @ 2009-04-07 20:55 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Hi, Miles! On Mon, Apr 06, 2009 at 06:30:28PM +0900, Miles Bader wrote: > Alan Mackenzie <acm@muc.de> writes: > > When I start Emacs 23 -Q, all of my buffers (loaded by desktop) are > > foghorned - I find Emacs in this state unusable. > All of your buffers have activated regions when Emacs starts? > If so, _that_ sounds like a bug (so please try to send a test case); > needless to say, I think, I do not see this behavior. In Emacs-22 -Q, enable desktop-save-mode, load some files, create a region in each file. DO NOT enable transient-mark-mode (or anything similar). Exit Emacs, creating .emacs.desktop. Have a look at this .emacs.desktop. It will contain buffer entries like this: (desktop-create-buffer 206 "/home/acm/emacs/emacs.cvs/src/callint.c" "callint.c" 'c-mode '(abbrev-mode hi-lock-mode) 1 '(8314 t) ; <============================================== nil nil '((buffer-file-coding-system . undecided-unix))) The cons in the marked line is of the mark and the variable `mark-active'. This variable doesn't have a coherent definition, but it causes the region to be highlit. It is "defined" as Non-nil means the mark and region are currently active in this buffer. As I have pointed out before, this is Humpty Dumpty language, liable to cause bugs. The mark and the region are never "active" and cannot be active - so to assert is a category error; they don't do anything, they are never agents. I don't know what it means for a mark to be "active" and for a region to be "active" - I don't think it's defined anywhere, and there is certainly no entry in the Concept Index for "active". It seems that the hacker who created `mark-active' had a different understanding from the hacker who wrote desktop.el, hence this bug. As it is, `mark-active' is meaningless unless transient-mark-mode is enabled. Hence the arbitrariness of the `t' in (8314 t). My suggestion for a fix: (i) The variable `mark-active' should be renamed to what it actually means, together with an alias. Other similarly named variables should also be renamed as needed to make their names meaningful; all uses of these variables should be checked. (ii) The concept "active" should be defined in the Emacs manual. (ii) desktop-mode.el should be enhanced to record the state of `transient-mark-mode' in .emacs.desktop. (iii) On loading the desktop, buffers' regions should not be highlit unless `transient-mark-mode' is recorded with a non-nil state. > -Miles -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-07 20:55 ` Alan Mackenzie @ 2009-04-08 5:35 ` Stephen J. Turnbull 2009-04-08 8:13 ` Alan Mackenzie 0 siblings, 1 reply; 17+ messages in thread From: Stephen J. Turnbull @ 2009-04-08 5:35 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Miles Bader Alan Mackenzie writes: > The cons in the marked line is of the mark and the variable > `mark-active'. This variable doesn't have a coherent definition, > but it causes the region to be highlit. It is "defined" as > > Non-nil means the mark and region are currently active in this > buffer. > > As I have pointed out before, this is Humpty Dumpty language, Not at all. Active regions and the terminology go back twenty years or more. If the mark is non-nil, then the region exists. The region may be active, in which case operations on the region will succeed, or inactive, when such operations will fail.[1] In transient-mark-mode, it is possible for the region to be inactive. Outside of transient- mark-mode, the region is always active. (Or something like that, that's how zmacs-regions works in XEmacs, transient-mark-mode has some tiny differences that I never understood very well.) It sounds to me like there's a bug in desktop.el[2], and maybe a lack of documentation of active regions. But the term is well-defined. Footnotes: [1] This is the same terminology used for GUI elements. But I guess you would say that the whole concept of "GUI" is a "category error".<wink> [2] I guess, as you say, it should record and check for transient-mark-mode before going ahead and highlighting regions. Personally, I would prefer desktop to have an option such that mark status is always reset across sessions. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-08 5:35 ` Stephen J. Turnbull @ 2009-04-08 8:13 ` Alan Mackenzie 2009-04-08 9:16 ` Eli Zaretskii 2009-04-08 9:26 ` Stephen J. Turnbull 0 siblings, 2 replies; 17+ messages in thread From: Alan Mackenzie @ 2009-04-08 8:13 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Miles Bader, emacs-devel Hi, Stephen! On Wed, Apr 08, 2009 at 02:35:16PM +0900, Stephen J. Turnbull wrote: > Alan Mackenzie writes: > > The cons in the marked line is of the mark and the variable > > `mark-active'. This variable doesn't have a coherent definition, > > but it causes the region to be highlit. It is "defined" as > > Non-nil means the mark and region are currently active in this > > buffer. > > As I have pointed out before, this is Humpty Dumpty language, > Not at all. Active regions and the terminology go back twenty years > or more. I don't doubt this, but it has no bearing on the matter. > If the mark is non-nil, then the region exists. The region may be > active, .... What is the activity that this region does? Does the region delete a block of characters? Does the region jump to the start of the next defun? Supposing you have a geologist inside a dead volcano, examining it, measuring it, chipping bits out of it. You would call this an "active volcano", would you? > ...., in which case operations on the region will succeed, or inactive, > when such operations will fail.[1] This is a misuse of the word "active", just as confusing as talking about "protecting" a copyright work rather than "restricting" it. In any sentence with a verb of activity, "the region" is always in the object position, never the subject position. "Active" is the wrong word. Possibly "Reactive" would be a suitable one - a "reactive region" being one which reacts to commands directed at it. > In transient-mark-mode, it is possible for the region to be inactive. > Outside of transient- mark-mode, the region is always active. (Or > something like that, that's how zmacs-regions works in XEmacs, > transient-mark-mode has some tiny differences that I never understood > very well.) > It sounds to me like there's a bug in desktop.el[2], and maybe a lack of > documentation of active regions. But the term is well-defined. "Active region" is not well defined, which is what caused the bug in desktop. In particular, it is ill defined whilst transient-mark-mode is not enabled. Because "active" is here a purely conventional label, disconnected from its normal semantics, hackers get confused as to what they really mean by it. Two competing definitions here are "highlit" and "reacts to region commands"; one hacker understood the former meaning, the other the latter. I think that desktop needs to record whether a region is highlit. Or something like that. Do you have definitions of (as contrasted to a discussion around) "active region" and "active mark" that you could contribute to the Emacs manual? > Footnotes: > [2] I guess, as you say, it should record and check for > transient-mark-mode before going ahead and highlighting regions. > Personally, I would prefer desktop to have an option such that mark > status is always reset across sessions. Yes. Maybe. Perhaps.... transient-mark-mode is not simple. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-08 8:13 ` Alan Mackenzie @ 2009-04-08 9:16 ` Eli Zaretskii 2009-04-08 9:26 ` Stephen J. Turnbull 1 sibling, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2009-04-08 9:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: stephen, emacs-devel, miles > Date: Wed, 8 Apr 2009 08:13:42 +0000 > From: Alan Mackenzie <acm@muc.de> > Cc: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org > > > If the mark is non-nil, then the region exists. The region may be > > active, .... > > What is the activity that this region does? Does the region delete a > block of characters? Does the region jump to the start of the next > defun? > > Supposing you have a geologist inside a dead volcano, examining it, > measuring it, chipping bits out of it. You would call this an "active > volcano", would you? Sorry, Alan, but this goes waaaay beyond the limits of courtesy and civilized discussion. Stephen tried to explain the terminology to you, and you are mocking him? why does he deserve that? > This is a misuse of the word "active" Any terminology misuses words to some extent. "Active region" is a well established terminology in Emacs, as Stephen points out, and it will not change just because you happen to have difficulties with agreeing with it. You should simply get used to it. > Do you have definitions of (as contrasted to a discussion around) "active > region" and "active mark" that you could contribute to the Emacs manual? That would be good, indeed. The current Emacs manual begins talking about these (in the "Mark" node) without defining them first. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-08 8:13 ` Alan Mackenzie 2009-04-08 9:16 ` Eli Zaretskii @ 2009-04-08 9:26 ` Stephen J. Turnbull 2009-04-08 13:05 ` Alan Mackenzie 1 sibling, 1 reply; 17+ messages in thread From: Stephen J. Turnbull @ 2009-04-08 9:26 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Miles Bader Alan Mackenzie writes: > This is a misuse of the word "active", Any dictionary will quickly show that this usage of "active" is well-known. From dictionary.reference.com: 2. being in a state of existence, progress, or motion: active hostilities. 5. characterized by action, motion, volume, use, participation, etc.: an active market in wheat; an active list of subscribers. reference.com doesn't mention it, but biology and biochemistry have a very similar usage, viz. "active receptors", "active sites". > "Active" is the wrong word. Possibly "Reactive" would be a > suitable one - a "reactive region" being one which reacts to > commands directed at it. I don't think that's as good a term as "active". The region is not an object with methods it uses to "react" to commands. It is an object to which things may be done, unless it is inactive. "Receptive region" might be more accurate, but unfortunately there is no verb "to receptivate". I think documenters would mutiny if they had to write "to activate the receptivity of the region". > Do you have definitions of (as contrasted to a discussion around) > "active region" and "active mark" that you could contribute to the > Emacs manual? Not really. As you say, transient-mark-mode is complex. And we've been through this discussion before, IIRC, and the XEmacs terminology was considered inappropriate for Emacs. To recap, XEmacs does not have a concept of "active mark" (or if that term is used, I guess it is identical to "the mark", ie, the mark on the top of the mark stack). It does have two concepts of active region, the more often used of which is `region-exists-p' (for compatibility with code written for Emacs): Return t if the region exists. If active regions are in use (i.e. `zmacs-regions' is true), this means that the region is active. Otherwise, this means that the user has pushed a mark in this buffer at some point in the past. the other being `region-active-p': (defun region-active-p () (and zmacs-regions (region-exists-p))) where zmacs-regions is the XEmacs equivalent to transient-mark-mode. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-08 9:26 ` Stephen J. Turnbull @ 2009-04-08 13:05 ` Alan Mackenzie 2009-04-08 14:44 ` Stephen J. Turnbull 0 siblings, 1 reply; 17+ messages in thread From: Alan Mackenzie @ 2009-04-08 13:05 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Miles Bader, emacs-devel Hi, Stephen! On Wed, Apr 08, 2009 at 06:26:13PM +0900, Stephen J. Turnbull wrote: > Alan Mackenzie writes: > > This is a misuse of the word "active", > Any dictionary will quickly show that this usage of "active" is > well-known. From dictionary.reference.com: > 2. being in a state of existence, progress, or motion: > active hostilities. > 5. characterized by action, motion, volume, use, participation, > etc.: an active market in wheat; an active list of > subscribers. Well, hostilities kill people, and markets shift wheat around, at least when they're of sufficient granularity. _Processes_ can clearly be active merely by "existing". An active list? OK, point to you. ;-) > > "Active" is the wrong word. Possibly "Reactive" would be a suitable > > one - a "reactive region" being one which reacts to commands > > directed at it. > I don't think that's as good a term as "active". The region is not an > object with methods it uses to "react" to commands. It is an object > to which things may be done, unless it is inactive. "Receptive > region" might be more accurate, but unfortunately there is no verb "to > receptivate". I think documenters would mutiny if they had to write > "to activate the receptivity of the region". :-) There seems to be a hole in the English language here; there doesn't seem to be an adjective meaning "in a state in which things can be done to it". Maybe in Japanese? > > Do you have definitions of (as contrasted to a discussion around) > > "active region" and "active mark" that you could contribute to the > > Emacs manual? > Not really. As you say, transient-mark-mode is complex. And we've > been through this discussion before, IIRC, and the XEmacs terminology > was considered inappropriate for Emacs. Pity. `zmacs-regions' is much less confusing than `transient-mark-mode'; the mark isn't transient, and neither is the mode. Well, Germany was in transient-mark-mode from 1989 to 2001, but that's something different. > To recap, XEmacs does not have a concept of "active mark" (or if that > term is used, I guess it is identical to "the mark", ie, the mark on > the top of the mark stack). It does have two concepts of active > region, the more often used of which is `region-exists-p' (for > compatibility with code written for Emacs): > Return t if the region exists. > If active regions are in use (i.e. `zmacs-regions' is true), this > means that the region is active. Otherwise, this means that the > user has pushed a mark in this buffer at some point in the past. This seems to be the interpretation intended for `mark-active' by the hacker who created it. > the other being `region-active-p': > (defun region-active-p () (and zmacs-regions (region-exists-p))) This seems to be the interpretation of `mark-active' understood in desktop.el. > where zmacs-regions is the XEmacs equivalent to transient-mark-mode. Yes. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-08 13:05 ` Alan Mackenzie @ 2009-04-08 14:44 ` Stephen J. Turnbull 0 siblings, 0 replies; 17+ messages in thread From: Stephen J. Turnbull @ 2009-04-08 14:44 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Miles Bader Alan Mackenzie writes: > Well, [...]. I didn't claim your usage is *wrong*, just that correct usage is not limited to the ones you admit. > > [XEmacs] does have two concepts of active region, the more often > > used of which is `region-exists-p' > > This seems to be the interpretation intended for `mark-active' by the > hacker who created it. > > > the other being `region-active-p': > > This seems to be the interpretation of `mark-active' understood in > desktop.el. Well, that's the bug, then. Oh, and I guess the documentation. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal 2009-04-05 23:05 Reopen bug 535: Problem with highlit regions on Linux virtual terminal Alan Mackenzie 2009-04-06 1:12 ` Miles Bader @ 2009-04-06 3:03 ` Chong Yidong 1 sibling, 0 replies; 17+ messages in thread From: Chong Yidong @ 2009-04-06 3:03 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: > This problem makes the default setup barely usable on a Linux virtual > terminal; it surely must be fixed before release. Like Miles, I find the color scheme highly usable. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2009-04-08 14:44 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-05 23:05 Reopen bug 535: Problem with highlit regions on Linux virtual terminal Alan Mackenzie 2009-04-06 1:12 ` Miles Bader 2009-04-06 3:10 ` Chong Yidong 2009-04-06 9:36 ` Alan Mackenzie 2009-04-06 9:03 ` Alan Mackenzie 2009-04-06 9:30 ` Miles Bader 2009-04-06 12:52 ` Alan Mackenzie 2009-04-06 15:35 ` David De La Harpe Golden 2009-04-07 21:46 ` Alan Mackenzie 2009-04-07 20:55 ` Alan Mackenzie 2009-04-08 5:35 ` Stephen J. Turnbull 2009-04-08 8:13 ` Alan Mackenzie 2009-04-08 9:16 ` Eli Zaretskii 2009-04-08 9:26 ` Stephen J. Turnbull 2009-04-08 13:05 ` Alan Mackenzie 2009-04-08 14:44 ` Stephen J. Turnbull 2009-04-06 3:03 ` Chong Yidong
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).