* bug#32950: 27.0.50; Strange display bug in *Help* buffer @ 2018-10-05 18:52 Filipp Gunbin 2018-10-05 19:54 ` Eli Zaretskii 2021-11-06 0:28 ` Stefan Kangas 0 siblings, 2 replies; 28+ messages in thread From: Filipp Gunbin @ 2018-10-05 18:52 UTC (permalink / raw) To: 32950 [-- Attachment #1: Type: text/plain, Size: 758 bytes --] emacs -Q C-h f proced-sort RET C-x o (go to newly created *Help* buffer) TAB TAB (to move to `proced-sort' link) RET (to go to that link) Now the screen looks like in the screenshot attached. It's Terminal app on macOS 10.13.6, if that matters. It looks like a new window is created, with that black line instead of a usual separator. But it's still the same window. Maybe it has to do with the fact that help buffer for `proced-sort' contains link to the same function (or similarly name variable). In GNU Emacs 27.0.50 (build 2, x86_64-apple-darwin17.7.0, NS appkit-1561.60 Version 10.13.6 (Build 17G65)) of 2018-10-04 built on fgunbin.playteam.ru Repository revision: 44bf4a6b012f65327718b8c8334bfac1aee26370 System Description: Mac OS X 10.13.6 [-- Attachment #2: Screen Shot 2018-10-05 at 21.41.28.png --] [-- Type: image/png, Size: 160171 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-05 18:52 bug#32950: 27.0.50; Strange display bug in *Help* buffer Filipp Gunbin @ 2018-10-05 19:54 ` Eli Zaretskii 2018-10-08 15:28 ` Filipp Gunbin 2021-11-06 0:28 ` Stefan Kangas 1 sibling, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2018-10-05 19:54 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 32950 tags 32950 notabug thanks > From: Filipp Gunbin <fgunbin@fastmail.fm> > Date: Fri, 05 Oct 2018 21:52:15 +0300 > > emacs -Q > C-h f proced-sort RET > C-x o (go to newly created *Help* buffer) > TAB TAB (to move to `proced-sort' link) > RET (to go to that link) > > Now the screen looks like in the screenshot attached. It's Terminal app > on macOS 10.13.6, if that matters. > > It looks like a new window is created, with that black line instead of a > usual separator. But it's still the same window. > > Maybe it has to do with the fact that help buffer for `proced-sort' > contains link to the same function (or similarly name variable). Yes. This is the intended behavior. Go to that black line and type "M-x describe-text-properties RET": you will see what it tries to do. Also try the same on a GUI frame. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-05 19:54 ` Eli Zaretskii @ 2018-10-08 15:28 ` Filipp Gunbin 2018-10-08 20:00 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Filipp Gunbin @ 2018-10-08 15:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 32950 Thanks Eli, On 05/10/2018 22:54 +0300, Eli Zaretskii wrote: >> Maybe it has to do with the fact that help buffer for `proced-sort' >> contains link to the same function (or similarly name variable). > > Yes. This is the intended behavior. Go to that black line and type > "M-x describe-text-properties RET": you will see what it tries to do. > Also try the same on a GUI frame. I see these text props there: face (:height 0.1 :inverse-video t) Yes, it's inverse-video, but it does not provide an explanation. Anyway, it looks somewhat scary for an unprepared user. Why don't we just show usual help for variable/function separately, and make this "list"? If this "list" was displayed right after help for either var/fun was requested, then it's understandable. But this scenario of "open help for one of them, follow the link to another, and see it added" is non-obvious and confusing. To me, at least. I doubt that even experienced users know about this feature. Filipp ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-08 15:28 ` Filipp Gunbin @ 2018-10-08 20:00 ` Eli Zaretskii 2018-10-08 23:11 ` Filipp Gunbin 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2018-10-08 20:00 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 32950 > From: Filipp Gunbin <fgunbin@fastmail.fm> > Cc: 32950@debbugs.gnu.org > Date: Mon, 08 Oct 2018 18:28:55 +0300 > > > Yes. This is the intended behavior. Go to that black line and type > > "M-x describe-text-properties RET": you will see what it tries to do. > > Also try the same on a GUI frame. > > I see these text props there: > > face (:height 0.1 :inverse-video t) > > Yes, it's inverse-video, but it does not provide an explanation. I'm not sure I follow: explanation for what? The ":height 0.1" part is supposed to explain that the intent is to display a thin horizontal line, except that TTY frames don't support variable-height lines, so you see a normal-height line there in inverse video. > Anyway, it looks somewhat scary for an unprepared user. Why don't we > just show usual help for variable/function separately, and make this > "list"? I'm sure that whoever coded this thought it to be a very coll feature, so all I can advise is to get used to it. > I doubt that even experienced users know about this feature. Well, I, for one, do. Not every surprising feature should be an immediate candidate for removal. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-08 20:00 ` Eli Zaretskii @ 2018-10-08 23:11 ` Filipp Gunbin 2018-10-09 7:44 ` martin rudalics 0 siblings, 1 reply; 28+ messages in thread From: Filipp Gunbin @ 2018-10-08 23:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 32950 Hi, On 08/10/2018 23:00 +0300, Eli Zaretskii wrote: >> From: Filipp Gunbin <fgunbin@fastmail.fm> >> Cc: 32950@debbugs.gnu.org >> Date: Mon, 08 Oct 2018 18:28:55 +0300 >> >> > Yes. This is the intended behavior. Go to that black line and type >> > "M-x describe-text-properties RET": you will see what it tries to do. >> > Also try the same on a GUI frame. >> >> I see these text props there: >> >> face (:height 0.1 :inverse-video t) >> >> Yes, it's inverse-video, but it does not provide an explanation. > > I'm not sure I follow: explanation for what? The ":height 0.1" part > is supposed to explain that the intent is to display a thin horizontal > line, except that TTY frames don't support variable-height lines, so > you see a normal-height line there in inverse video. Explanation for why it's there, in the first place. Ok, it's thin in GUI, but it's very prominent on TTY. >> Anyway, it looks somewhat scary for an unprepared user. Why don't we >> just show usual help for variable/function separately, and make this >> "list"? > > I'm sure that whoever coded this thought it to be a very coll feature, > so all I can advise is to get used to it. > >> I doubt that even experienced users know about this feature. > > Well, I, for one, do. > > Not every surprising feature should be an immediate candidate for > removal. I'm sure on GUI it serves its purpose well, when it's really thin line. But on TTY, as I already wrote, nothing except "what happened?" comes to (my) mind. When you are accustomed to the usual behavior of Help buffers to replace contents when following a link, this special-case adding is really confusing. Well, now I know about it too, so it's not a problem for me. I was thinking of others, who may as well file a bug about it, and maintainers will spend time responding to it. Yes, this seems to be a rare case - for example, the reverse reference (from variable proced-sort to function) is not there, but still. Thanks. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-08 23:11 ` Filipp Gunbin @ 2018-10-09 7:44 ` martin rudalics 2018-10-09 14:59 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: martin rudalics @ 2018-10-09 7:44 UTC (permalink / raw) To: Filipp Gunbin, Eli Zaretskii; +Cc: 32950 > I'm sure on GUI it serves its purpose well, when it's really thin line. > But on TTY, as I already wrote, nothing except "what happened?" comes to > (my) mind. When you are accustomed to the usual behavior of Help > buffers to replace contents when following a link, this special-case > adding is really confusing. Would it be difficult to replace it with a line of dashes on TTYs? martin ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-09 7:44 ` martin rudalics @ 2018-10-09 14:59 ` Eli Zaretskii 0 siblings, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2018-10-09 14:59 UTC (permalink / raw) To: martin rudalics; +Cc: 32950, fgunbin > Date: Tue, 09 Oct 2018 09:44:39 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: 32950@debbugs.gnu.org > > > I'm sure on GUI it serves its purpose well, when it's really thin line. > > But on TTY, as I already wrote, nothing except "what happened?" comes to > > (my) mind. When you are accustomed to the usual behavior of Help > > buffers to replace contents when following a link, this special-case > > adding is really confusing. > > Would it be difficult to replace it with a line of dashes on TTYs? You mean, apart of adding some code to make that happen? No, I don't think so. But don't be surprised if someone then comes up crying that their favorite feature was removed. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2018-10-05 18:52 bug#32950: 27.0.50; Strange display bug in *Help* buffer Filipp Gunbin 2018-10-05 19:54 ` Eli Zaretskii @ 2021-11-06 0:28 ` Stefan Kangas 2021-11-06 0:34 ` Lars Ingebrigtsen 1 sibling, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 0:28 UTC (permalink / raw) To: Filipp Gunbin; +Cc: 32950 Filipp Gunbin <fgunbin@fastmail.fm> writes: > emacs -Q > C-h f proced-sort RET > C-x o (go to newly created *Help* buffer) > TAB TAB (to move to `proced-sort' link) > RET (to go to that link) > > Now the screen looks like in the screenshot attached. It's Terminal app > on macOS 10.13.6, if that matters. > > It looks like a new window is created, with that black line instead of a > usual separator. But it's still the same window. > > Maybe it has to do with the fact that help buffer for `proced-sort' > contains link to the same function (or similarly name variable). This is about how a horizontal line is displayed in the terminal. We now have at least three different ways to display horizontal lines: 1. The above recipe 2. M-x customize-group RET emacs RET 3. C-h b [which seems buggy?] I think we should decide which of the three are best, and replace the others with that. Aesthetically, I very much prefer the one in customize-group, but point jumps to the right when you move over it, which is slightly jarring. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 0:28 ` Stefan Kangas @ 2021-11-06 0:34 ` Lars Ingebrigtsen 2021-11-06 0:37 ` Lars Ingebrigtsen 2021-11-06 1:05 ` Stefan Kangas 0 siblings, 2 replies; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 0:34 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Stefan Kangas <stefan@marxist.se> writes: > This is about how a horizontal line is displayed in the terminal. > We now have at least three different ways to display horizontal lines: > > 1. The above recipe > 2. M-x customize-group RET emacs RET > 3. C-h b [which seems buggy?] Buggy in what way? Seems to be working for me both in GUI and TUI Emacs in `C-h b'? > I think we should decide which of the three are best, and replace the > others with that. > > Aesthetically, I very much prefer the one in customize-group, but point > jumps to the right when you move over it, which is slightly jarring. Yes, it looks better in TUI Emacs (but I prefer the 'C-h b' one in GUI Emacs). But the point movement is really jarring (in both GUI and TUI), so overall I think the 'C-h b' one wins. 😀 -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 0:34 ` Lars Ingebrigtsen @ 2021-11-06 0:37 ` Lars Ingebrigtsen 2021-11-06 1:05 ` Stefan Kangas 2021-11-06 1:05 ` Stefan Kangas 1 sibling, 1 reply; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 0:37 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Lars Ingebrigtsen <larsi@gnus.org> writes: >> This is about how a horizontal line is displayed in the terminal. >> We now have at least three different ways to display horizontal lines: >> >> 1. The above recipe >> 2. M-x customize-group RET emacs RET >> 3. C-h b [which seems buggy?] > > Buggy in what way? Seems to be working for me both in GUI and TUI Emacs > in `C-h b'? 1. and 3. are the same, I think? (At least now.) It's a newline with `separator-face' on it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 0:37 ` Lars Ingebrigtsen @ 2021-11-06 1:05 ` Stefan Kangas 2021-11-06 1:13 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 1:05 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, Filipp Gunbin Lars Ingebrigtsen <larsi@gnus.org> writes: >>> We now have at least three different ways to display horizontal lines: >>> >>> 1. The above recipe >>> 2. M-x customize-group RET emacs RET >>> 3. C-h b [which seems buggy?] [snip] > 1. and 3. are the same, I think? (At least now.) It's a newline with > `separator-face' on it. I thought it was different as I didn't see this behavior in `C-h f proced-sort RET' for some reason. I guess the call happens later in `C-h f', or something. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 1:05 ` Stefan Kangas @ 2021-11-06 1:13 ` Lars Ingebrigtsen 0 siblings, 0 replies; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 1:13 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Stefan Kangas <stefan@marxist.se> writes: > I thought it was different as I didn't see this behavior in `C-h f > proced-sort RET' for some reason. > > I guess the call happens later in `C-h f', or something. It happens when the buffer displays both the function and the variable, which happens when hitting RET on the variable in the function *Help* buffer. :-) But I think this means that the reported display bug is gone, so I'm closing this bug report. There's a question of whether we should use `make-separator-line' more throughout Emacs (like in Customize), and I think we should, probably? But gingerly. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 0:34 ` Lars Ingebrigtsen 2021-11-06 0:37 ` Lars Ingebrigtsen @ 2021-11-06 1:05 ` Stefan Kangas 2021-11-06 1:16 ` Lars Ingebrigtsen 1 sibling, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 1:05 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, Filipp Gunbin [-- Attachment #1: Type: text/plain, Size: 468 bytes --] Lars Ingebrigtsen <larsi@gnus.org> writes: > Stefan Kangas <stefan@marxist.se> writes: > >> This is about how a horizontal line is displayed in the terminal. >> We now have at least three different ways to display horizontal lines: >> >> 1. The above recipe >> 2. M-x customize-group RET emacs RET >> 3. C-h b [which seems buggy?] > > Buggy in what way? Seems to be working for me both in GUI and TUI Emacs > in `C-h b'? See the attached screenshot. [-- Attachment #2: Type: text/plain, Size: 317 bytes --] > Yes, it looks better in TUI Emacs (but I prefer the 'C-h b' one in GUI > Emacs). But the point movement is really jarring (in both GUI and TUI), > so overall I think the 'C-h b' one wins. 😀 Hmm, the `C-h b' one looks better here in both GUI and terminal. Are you sure you used the same set of eyes as I did? [-- Attachment #3: buggy-line.png --] [-- Type: image/png, Size: 4310 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 1:05 ` Stefan Kangas @ 2021-11-06 1:16 ` Lars Ingebrigtsen 2021-11-06 1:36 ` Stefan Kangas 0 siblings, 1 reply; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 1:16 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Stefan Kangas <stefan@marxist.se> writes: > See the attached screenshot. Hm, very odd. It's supposed to use a `window-width's worth of dashes on TUI, and it seems to be overshooting that significantly? Do you have a recipe to reproduce the bug (starting from emacs -Q)? >> Yes, it looks better in TUI Emacs (but I prefer the 'C-h b' one in GUI >> Emacs). But the point movement is really jarring (in both GUI and TUI), >> so overall I think the 'C-h b' one wins. 😀 > > Hmm, the `C-h b' one looks better here in both GUI and terminal. > Are you sure you used the same set of eyes as I did? It's possible not. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 1:16 ` Lars Ingebrigtsen @ 2021-11-06 1:36 ` Stefan Kangas 2021-11-06 1:48 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 1:36 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, Filipp Gunbin Lars Ingebrigtsen <larsi@gnus.org> writes: > Hm, very odd. It's supposed to use a `window-width's worth of dashes on > TUI, and it seems to be overshooting that significantly? Do you have a > recipe to reproduce the bug (starting from emacs -Q)? Sure, it's a short one: "emacs -Q -nw" and then `C-h b'. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 1:36 ` Stefan Kangas @ 2021-11-06 1:48 ` Lars Ingebrigtsen 2021-11-06 2:24 ` Stefan Kangas 0 siblings, 1 reply; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 1:48 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin [-- Attachment #1: Type: text/plain, Size: 125 bytes --] Stefan Kangas <stefan@marxist.se> writes: > Sure, it's a short one: "emacs -Q -nw" and then `C-h b'. Huh. That gives me: [-- Attachment #2: Type: image/png, Size: 60163 bytes --] [-- Attachment #3: Type: text/plain, Size: 176 bytes --] What does (window-width) evaluate to for you here? (It's 80 for me.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 1:48 ` Lars Ingebrigtsen @ 2021-11-06 2:24 ` Stefan Kangas 2021-11-06 2:31 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 2:24 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, Filipp Gunbin Lars Ingebrigtsen <larsi@gnus.org> writes: > Stefan Kangas <stefan@marxist.se> writes: > >> Sure, it's a short one: "emacs -Q -nw" and then `C-h b'. > > Huh. That gives me: Try with a very wide terminal window. > What does (window-width) evaluate to for you here? (It's 80 for me.) 255 before running `C-h b', 128 after. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 2:24 ` Stefan Kangas @ 2021-11-06 2:31 ` Lars Ingebrigtsen 2021-11-06 3:11 ` Stefan Kangas 2021-11-06 8:00 ` Eli Zaretskii 0 siblings, 2 replies; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 2:31 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Stefan Kangas <stefan@marxist.se> writes: >> What does (window-width) evaluate to for you here? (It's 80 for me.) > > 255 before running `C-h b', 128 after. Oh, you resized the terminal? Well, then that's expected. Hm... hang on a minute. Can't we just use an underline on TUI? Or was that what Customize did? Hm... OK, tried it now, and it seems to work without the odd point motion? So I've now pushed it to Emacs 29. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 2:31 ` Lars Ingebrigtsen @ 2021-11-06 3:11 ` Stefan Kangas 2021-11-06 4:01 ` Lars Ingebrigtsen 2021-11-06 8:00 ` Eli Zaretskii 1 sibling, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 3:11 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, Filipp Gunbin Lars Ingebrigtsen <larsi@gnus.org> writes: > Stefan Kangas <stefan@marxist.se> writes: > >>> What does (window-width) evaluate to for you here? (It's 80 for me.) >> >> 255 before running `C-h b', 128 after. > > Oh, you resized the terminal? Well, then that's expected. No, I didn't resize it. (I wrote up a detailed explanation, but the bug was fixed by your below commit, so it's not relevant now I think.) > Hm... hang on a minute. Can't we just use an underline on TUI? Or was > that what Customize did? Hm... OK, tried it now, and it seems to work > without the odd point motion? So I've now pushed it to Emacs 29. With that change, the above bug is gone. And it looks much better! I think we should change customize to use that, too. However, especially on a graphical display, it would be nice if you couldn't place point on the actual divider. It looks almost as jarring as the weird point movement to me. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 3:11 ` Stefan Kangas @ 2021-11-06 4:01 ` Lars Ingebrigtsen 2021-11-06 6:12 ` Stefan Kangas 0 siblings, 1 reply; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 4:01 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Stefan Kangas <stefan@marxist.se> writes: > With that change, the above bug is gone. And it looks much better! > I think we should change customize to use that, too. Yes, probably. > However, especially on a graphical display, it would be nice if you > couldn't place point on the actual divider. It looks almost as jarring > as the weird point movement to me. You mean the teensy tiny cursor? Yes, that's odd, but... Perhaps we should experiment with making it intangible? I've had really bad experiences with that before, but perhaps it could work here. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 4:01 ` Lars Ingebrigtsen @ 2021-11-06 6:12 ` Stefan Kangas 2021-11-06 18:00 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 6:12 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, Filipp Gunbin Lars Ingebrigtsen <larsi@gnus.org> writes: > You mean the teensy tiny cursor? Yes, that's odd, but... Perhaps we > should experiment with making it intangible? I've had really bad > experiences with that before, but perhaps it could work here. Yes, I'm thinking of the small cursor there. I'm aware of the existence of intangible, but I've never actually tried to use it. From its description in the manual, it does sound like it could be a good solution here. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 6:12 ` Stefan Kangas @ 2021-11-06 18:00 ` Lars Ingebrigtsen 0 siblings, 0 replies; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 18:00 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, Filipp Gunbin Stefan Kangas <stefan@marxist.se> writes: > I'm aware of the existence of intangible, but I've never actually tried > to use it. From its description in the manual, it does sound like it > could be a good solution here. Hm... It doesn't seem like that does what we want here, because it's really just a newline character with a face with :extend there. `intangible' is: --- If a group of consecutive characters have equal and non-@code{nil} @code{intangible} properties, then you cannot place point between them. --- Which I'd forgotten. So we'd have to put intangible on the ... preceding newline, too? And that just sounds too hacky. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 2:31 ` Lars Ingebrigtsen 2021-11-06 3:11 ` Stefan Kangas @ 2021-11-06 8:00 ` Eli Zaretskii 2021-11-06 9:34 ` Eli Zaretskii 1 sibling, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2021-11-06 8:00 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, stefan, fgunbin > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Sat, 06 Nov 2021 03:31:15 +0100 > Cc: 32950@debbugs.gnu.org, Filipp Gunbin <fgunbin@fastmail.fm> > > Hm... hang on a minute. Can't we just use an underline on TUI? Or was > that what Customize did? Hm... OK, tried it now, and it seems to work > without the odd point motion? So I've now pushed it to Emacs 29. Not all terminals support underline. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 8:00 ` Eli Zaretskii @ 2021-11-06 9:34 ` Eli Zaretskii 2021-11-06 11:09 ` Stefan Kangas 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2021-11-06 9:34 UTC (permalink / raw) To: larsi; +Cc: 32950, stefan, fgunbin > Date: Sat, 06 Nov 2021 10:00:28 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 32950@debbugs.gnu.org, stefan@marxist.se, fgunbin@fastmail.fm > > > From: Lars Ingebrigtsen <larsi@gnus.org> > > Date: Sat, 06 Nov 2021 03:31:15 +0100 > > Cc: 32950@debbugs.gnu.org, Filipp Gunbin <fgunbin@fastmail.fm> > > > > Hm... hang on a minute. Can't we just use an underline on TUI? Or was > > that what Customize did? Hm... OK, tried it now, and it seems to work > > without the odd point motion? So I've now pushed it to Emacs 29. > > Not all terminals support underline. And, as I suspected, we now show no separator at all on those text terminals which don't support the underline attribute. This is a regression, I think. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 9:34 ` Eli Zaretskii @ 2021-11-06 11:09 ` Stefan Kangas 2021-11-06 11:39 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Stefan Kangas @ 2021-11-06 11:09 UTC (permalink / raw) To: Eli Zaretskii, larsi; +Cc: 32950, fgunbin Eli Zaretskii <eliz@gnu.org> writes: > And, as I suspected, we now show no separator at all on those text > terminals which don't support the underline attribute. This is a > regression, I think. Can we detect those terminals that doesn't support underline and fall back to the old method for them? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 11:09 ` Stefan Kangas @ 2021-11-06 11:39 ` Eli Zaretskii 2021-11-06 17:57 ` Lars Ingebrigtsen 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2021-11-06 11:39 UTC (permalink / raw) To: Stefan Kangas; +Cc: 32950, larsi, fgunbin > From: Stefan Kangas <stefan@marxist.se> > Date: Sat, 6 Nov 2021 04:09:01 -0700 > Cc: 32950@debbugs.gnu.org, fgunbin@fastmail.fm > > Eli Zaretskii <eliz@gnu.org> writes: > > > And, as I suspected, we now show no separator at all on those text > > terminals which don't support the underline attribute. This is a > > regression, I think. > > Can we detect those terminals that doesn't support underline and fall > back to the old method for them? Yes, of course. See display-supports-face-attributes-p. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 11:39 ` Eli Zaretskii @ 2021-11-06 17:57 ` Lars Ingebrigtsen 2021-11-06 18:27 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Lars Ingebrigtsen @ 2021-11-06 17:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 32950, Stefan Kangas, fgunbin Eli Zaretskii <eliz@gnu.org> writes: > Yes, of course. See display-supports-face-attributes-p. Thanks; this should now be fixed on the trunk. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#32950: 27.0.50; Strange display bug in *Help* buffer 2021-11-06 17:57 ` Lars Ingebrigtsen @ 2021-11-06 18:27 ` Eli Zaretskii 0 siblings, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2021-11-06 18:27 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 32950, stefan, fgunbin > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: Stefan Kangas <stefan@marxist.se>, 32950@debbugs.gnu.org, > fgunbin@fastmail.fm > Date: Sat, 06 Nov 2021 18:57:00 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Yes, of course. See display-supports-face-attributes-p. > > Thanks; this should now be fixed on the trunk. It is indeed. Thanks. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2021-11-06 18:27 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-05 18:52 bug#32950: 27.0.50; Strange display bug in *Help* buffer Filipp Gunbin 2018-10-05 19:54 ` Eli Zaretskii 2018-10-08 15:28 ` Filipp Gunbin 2018-10-08 20:00 ` Eli Zaretskii 2018-10-08 23:11 ` Filipp Gunbin 2018-10-09 7:44 ` martin rudalics 2018-10-09 14:59 ` Eli Zaretskii 2021-11-06 0:28 ` Stefan Kangas 2021-11-06 0:34 ` Lars Ingebrigtsen 2021-11-06 0:37 ` Lars Ingebrigtsen 2021-11-06 1:05 ` Stefan Kangas 2021-11-06 1:13 ` Lars Ingebrigtsen 2021-11-06 1:05 ` Stefan Kangas 2021-11-06 1:16 ` Lars Ingebrigtsen 2021-11-06 1:36 ` Stefan Kangas 2021-11-06 1:48 ` Lars Ingebrigtsen 2021-11-06 2:24 ` Stefan Kangas 2021-11-06 2:31 ` Lars Ingebrigtsen 2021-11-06 3:11 ` Stefan Kangas 2021-11-06 4:01 ` Lars Ingebrigtsen 2021-11-06 6:12 ` Stefan Kangas 2021-11-06 18:00 ` Lars Ingebrigtsen 2021-11-06 8:00 ` Eli Zaretskii 2021-11-06 9:34 ` Eli Zaretskii 2021-11-06 11:09 ` Stefan Kangas 2021-11-06 11:39 ` Eli Zaretskii 2021-11-06 17:57 ` Lars Ingebrigtsen 2021-11-06 18:27 ` Eli Zaretskii
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).
![[-- Attachment #3: buggy-line.png --] [-- Type: image/png, Size: 4310 bytes --]](../../CADwFkm=c6MPDQ+kKY5t=Q_w8gDcT639xGh6LY10O0jr8wz4LUA@mail.gmail.com/3-buggy-line.png){kind=link}