On Thu, Jul 1, 2021 at 7:35 PM Zhiwei Chen wrote: > > On Jul 1, 2021, at 7:26 PM, Lars Ingebrigtsen wrote: > > Zhiwei Chen writes: > > Personally, hl-line-mode is used to show the approximate position of > my point so the face defined in doom-one is fine to me. It needn’t to > be too contrast as it hurts my eyes in daily use. > > But when debugging, I need to know where the line as if I step over the > interesting line I will blame myself. Debugging is more serious than > coding/writing, so I would like to > make the line highlighted/contrast. > > > So, Doom has customised the hi-line face to be less perceptible, so you > want to introduce a new highlighting mechanism to make it more > perceptible again, but only in gud buffers? > > This can be done with `face-remapping-alist' -- it's a buffer-local > variable that's used to display a different face in certain buffers. > Would using that variable in gud buffers solve your problems? > > > Another problem it can’t solve is the debugging line will be lost if I > select the source buffer and move the point since the highlighted line uses > hl-line-mode. > And I think the new mechanism can supersede the use of hl-line-mode almost. > > Why do I introduce a new overlay in gud buffer? Because it's used to show the line where the debugger stops at. The position of the gud overlay is controlled by the debugger, not by users. So using hl-line-mode in such a situation is not the proper way. See the pic below. [image: image.png] gdb stops at line 4 (see the arrow in left fringe). But after I select the source buffer and move 3 lines down, the line 7 is highlighted. Does it mean that gdb stops at line 7? It's too confusing to users.