I am using emacs-28.2 on macOS.
I am using wezterm as my terminal emulator,
which is a “xterm-256color” terminal emulator,
and $COLORTERM is “truecolor”.
I find that the background in terminal mode
is significantly lighter than that in GUI mode.
Starting with “emacs -Q” for GUI mode,
and “emacs -Q -nw” for terminal mode,
and “M-x load-theme modus-vivendi”,
“M-x hl-line-mode”.
The attachments are two mimes for the screenshots.
It is also worthy to note that
“highlighted line” in terminal mode is darker than
lines in normal background,
while in GUI mode the “highlighted line” is lighter
than lines in normal background.
Hello there!
> From: North Year <ny-ml@outlook.com>> Date: Mon, 5 Dec 2022 01:20:00 -0500>> I am using emacs-28.2 on macOS.>> I am using wezterm as my terminal emulator,> which is a “xterm-256color” terminal emulator,> and $COLORTERM is “truecolor”.>> I find that the background in terminal mode> is significantly lighter than that in GUI mode.>> Starting with “emacs -Q” for GUI mode,> and “emacs -Q -nw” for terminal mode,> and “M-x load-theme modus-vivendi”,> “M-x hl-line-mode”.> The attachments are two mimes for the screenshots.>> It is also worthy to note that> “highlighted line” in terminal mode is darker than> lines in normal background,> while in GUI mode the “highlighted line” is lighter> than lines in normal background.
While there are some inherent limitations in how terminal emulators
reproduce colour accurately, your description here suggests that the
problem is with your terminal's default colour scheme. I am not
familiar with wezterm: does it have a way to change the first 16 colours
in the palette?
Emacs in a terminal cannot produce colours outside the range specified
by those first 16 values. So if your default "black" is something like
"#1a1a1a" then 'modus-vivendi' will default to that instead of what
should be "#000000".
Relevant entry in the modus-themes manual:
https://protesilaos.com/emacs/modus-themes#h:6b8211b0-d11b-4c00-9543-4685ec3b742f
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
> Emacs in a terminal cannot produce colours outside the range specified> by those first 16 values. So if your default “black” is something like> “#1a1a1a” then ’modus-vivendi’ will default to that instead of what> should be “#000000”.
Thanks for your quick response! This is indeed the reason!
Changing the colorscheme of my terminal emulator solve the issue.
This is indeed something unexpecteed.
I never expect that emacs cannot generate colors outside the first 16 colors.
I was thought that an “xterm-256color” terminal with “$COLORTERM=truecolor” would be sufficient enough for accurate color dispaly.
> From: North Year <ny-ml@outlook.com>> Date: Mon, 5 Dec 2022 02:27:08 -0500>> Protesilaos Stavrou <info@protesilaos.com> writes:>>> Emacs in a terminal cannot produce colours outside the range specified>> by those first 16 values. So if your default “black” is something like>> “#1a1a1a” then ’modus-vivendi’ will default to that instead of what>> should be “#000000”.>> Thanks for your quick response!
You are welcome!
> This is indeed the reason! Changing the colorscheme of my terminal> emulator solve the issue.
Very well!
> This is indeed something unexpecteed.> I never expect that emacs cannot generate colors outside the first 16 colors.> I was thought that an “xterm-256color” terminal with “$COLORTERM=truecolor” would be sufficient enough for accurate color dispaly.
It is unexpected, indeed. I do not have a technical understanding as to
why this happens. I have just observed it with all terminal emulators I
tried. Perhaps this is something the Emacs maintainers know more about,
though I never found the chance to research the issue and report it as a
bug.
--
Protesilaos Stavrou
https://protesilaos.com
On 22/12/05 09:52AM, Protesilaos Stavrou wrote:
>> From: North Year <ny-ml@outlook.com> Date: Mon, 5 Dec 2022 02:27:08>> -0500>>>> Protesilaos Stavrou <info@protesilaos.com> writes:>>>>> Emacs in a terminal cannot produce colours outside the range>>> specified by those first 16 values. So if your default “black” is>>> something like “#1a1a1a” then ’modus-vivendi’ will default to that>>> instead of what should be “#000000”.>>> This is indeed the reason! Changing the colorscheme of my terminal>> emulator solve the issue.>>> This is indeed something unexpecteed. I never expect that emacs>> cannot generate colors outside the first 16 colors. I was thought>> that an “xterm-256color” terminal with “$COLORTERM=truecolor” would>> be sufficient enough for accurate color dispaly.>>It is unexpected, indeed. I do not have a technical understanding as>to why this happens. I have just observed it with all terminal>emulators I tried. Perhaps this is something the Emacs maintainers>know more about, though I never found the chance to research the issue>and report it as a bug.
Interestingly, I find that evaluating the following code:
(set-background-color "#000000")
will let emacs uses the ansi "black" color
from your terminal's colorsheme (which is just the backround for
modus-vivendi). However, if I change the code to:
(set-background-color "#0F0000")
i.e. some color that is very close to the "pure black", then all of
sudden the magic happens, emacs now picks up the correct color, i.e.
#0F0000 that is very close to the "pure black".
This can be considered as a workaround for me since my preferred
color schemes for terminal emulator usually use a much lighter color
than pure black as the background.
However sad story is, I am using doomemacs as my configuration which
prevents me from such simple code to work:
(load-theme 'modus-vivendi)
(set-background-color "#000F00")
"emacs -Q -nw -l minimal-config.el" will simply work though. Such kind
of problems happen time to time if you are using a configuration
framework not written by yourself from scratch...
:(
> From: North Year <ny-ml@outlook.com>> Date: Mon, 12 Dec 2022 03:48:23 -0500>> On 22/12/05 09:52AM, Protesilaos Stavrou wrote:>>> From: North Year <ny-ml@outlook.com> Date: Mon, 5 Dec 2022 02:27:08>>> -0500>>>>>> Protesilaos Stavrou <info@protesilaos.com> writes:>>>>>>> Emacs in a terminal cannot produce colours outside the range>>>> specified by those first 16 values. So if your default “black” is>>>> something like “#1a1a1a” then ’modus-vivendi’ will default to that>>>> instead of what should be “#000000”.>>>>> This is indeed the reason! Changing the colorscheme of my terminal>>> emulator solve the issue.>>>>> This is indeed something unexpecteed. I never expect that emacs>>> cannot generate colors outside the first 16 colors. I was thought>>> that an “xterm-256color” terminal with “$COLORTERM=truecolor” would>>> be sufficient enough for accurate color dispaly.>>>>It is unexpected, indeed. I do not have a technical understanding as>>to why this happens. I have just observed it with all terminal>>emulators I tried. Perhaps this is something the Emacs maintainers>>know more about, though I never found the chance to research the issue>>and report it as a bug.>> Interestingly, I find that evaluating the following code:>> (set-background-color "#000000")>> will let emacs uses the ansi "black" color> from your terminal's colorsheme (which is just the backround for> modus-vivendi). However, if I change the code to:>> (set-background-color "#0F0000")>> i.e. some color that is very close to the "pure black", then all of> sudden the magic happens, emacs now picks up the correct color, i.e.> #0F0000 that is very close to the "pure black".
Interesting find! It goes to show that the intersection between Emacs
and the terminal emulator creates some unexpected results.
> This can be considered as a workaround for me since my preferred> color schemes for terminal emulator usually use a much lighter color> than pure black as the background.
Yes, this is helpful.
As an aside, is there a specific reason you use Emacs in the terminal?
I know this is useful when, for example, you connect via SSH to a remote
machine and run Emacs there. But for local usage, I find the GUI to be
better overall. All Meta keys work, it has no issues with colours, and
can also mix different font families/heights.
For my needs, I don't even use a terminal emulator. I only rely on M-x
shell. I read that Emacs' vterm package is very good if you need to run
something in the terminal that uses "graphics", such as the htop
command. Though I don't use vterm either.
> However sad story is, I am using doomemacs as my configuration which> prevents me from such simple code to work:>> (load-theme 'modus-vivendi)> (set-background-color "#000F00")>> "emacs -Q -nw -l minimal-config.el" will simply work though. Such kind> of problems happen time to time if you are using a configuration> framework not written by yourself from scratch...
Oh that is unfortunate. Depending on your needs, it may be possible to
create your own Emacs configuration without much trouble. Doom has
already exposed you to what Emacs can do, so now you can figure out what
packages you need or what to search for.
Maintaining your own setup lets you know how everything is pieced
together. It is easier to expand, tweak, troubleshoot.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>>>> Interestingly, I find that evaluating the following code:>>>> (set-background-color "#000000")>>>> will let emacs uses the ansi "black" color>> from your terminal's colorsheme (which is just the backround >> for>> modus-vivendi). However, if I change the code to:>>>> (set-background-color "#0F0000")>>>> i.e. some color that is very close to the "pure black", then >> all of>> sudden the magic happens, emacs now picks up the correct color, >> i.e.>> #0F0000 that is very close to the "pure black".>> Interesting find! It goes to show that the intersection between > Emacs> and the terminal emulator creates some unexpected results.>>> This can be considered as a workaround for me since my >> preferred>> color schemes for terminal emulator usually use a much lighter >> color>> than pure black as the background.>> Yes, this is helpful.
Would you consider to record this as a workaround to your official
manual for modus-theme hosted at
https://protesilaos.com/emacs/modus-themes section 6.1?
> As an aside, is there a specific reason you use Emacs in the > terminal?> I know this is useful when, for example, you connect via SSH to > a remote> machine and run Emacs there. But for local usage, I find the > GUI to be> better overall. All Meta keys work, it has no issues with > colours, and> can also mix different font families/heights.>> For my needs, I don't even use a terminal emulator. I only rely > on M-x> shell. I read that Emacs' vterm package is very good if you > need to run> something in the terminal that uses "graphics", such as the htop> command. Though I don't use vterm either.
Several reasons.
Firstly, I use emacs on my smart phone by remoting ssh to a remote
server. Prot I know you don't use smartphone, but for any other
who read
this mailist, I highly recommend Termius app. It is an awesome
mobile
SSH app. You can emulate the arrow keys by scrolling the screen,
emulate
the mouse click by touching screen. It's even xterm-256color.
I mainly use emacs on my smartphone for org-mode, I find if I
can't use
the true orgmode for my agenda, I am gonna mad. No org-based
mobile app
can be rival with true emacs.
Secondly, I am still in the early age of learning to use emacs (I
use
emacs for about 8 months). I tweak my configs quiet often,
restarting
emacs in terminal is much faster than GUI. The doom starter says
that it
launches in roughly 0.7-1.0s in GUI (but my own perception would
by
roughly 2s), while terminal based emacs starts in 0.5-0.7s.
I do use GUI emacs for multi media support (for example writing
code to
plotting, writing prose, and reading RSS then occasionally opening
the
source with xwidget, and reading pdf with writing notes).
The last reason is the "project/working directory" stuffs. I am
more get
used to how vim/neovim handles project. vim/neovim has a concept
of
"working directory" and there are plugins which allows to
automatically
switch the working directory to your project root. As my
understanding,
emacs handles project usually with projectile.el or project.el. So
commands like "eshell/shell/vterm/term" don't start at the project
root,
instead they launches in your current buffer's directory, which is
quite
annoying. There are "project-eshell" stuffs which will open the
shell in
your project root. But by default project-eshell (and other
project-xxx)
directly occupieis the window of your current buffer, which is an
annoying result... Doom configures eshell/vterm/term stuffs pretty
well,
they all open as a decently sized popup instead of occupying your
current window. But doom does not configure project-xxx stuffs to
do
so... Maybe configuring the rules for those apps would not be
difficult,
but I haven't figured it out yet... To be honest I even has some
ugly
code to handle such kind of situation (like the attached code). So
I
find that using emacs in tmux and running shell in a separate pane
is
much out of box and without too much mental overhead.
>> However sad story is, I am using doomemacs as my configuration >> which>> prevents me from such simple code to work:>>>> (load-theme 'modus-vivendi)>> (set-background-color "#000F00")>>>> "emacs -Q -nw -l minimal-config.el" will simply work though. >> Such kind>> of problems happen time to time if you are using a >> configuration>> framework not written by yourself from scratch...>> Oh that is unfortunate. Depending on your needs, it may be > possible to> create your own Emacs configuration without much trouble. Doom > has> already exposed you to what Emacs can do, so now you can figure > out what> packages you need or what to search for.>> Maintaining your own setup lets you know how everything is > pieced> together. It is easier to expand, tweak, troubleshoot.
Definitely, I have to write up my own config. This is just on my
agenda.
But I don't have enough time to do this. I am satisfied with a lot
of
functionalities / configurations doom provide me. Rewriting my own
config to replicate most of them would take too much of time. I
have
other higher priorities, so I just put this later.
I have this ugly code to handle annoying window rules in my
config, do
you have any recommendation on how to improve it?
> From: North Year <ny-ml@outlook.com>> Date: Mon, 12 Dec 2022 22:58:24 -0500> [... 24 lines elided]>>> This can be considered as a workaround for me since my preferred>>> color schemes for terminal emulator usually use a much lighter color>>> than pure black as the background.>>>> Yes, this is helpful.>> Would you consider to record this as a workaround to your official> manual for modus-theme hosted at> https://protesilaos.com/emacs/modus-themes section 6.1?
Yes, though please wait until I merge the 'version-4' branch into
'main'. There are about 200 commits between the two right now and I
still have a lot of work to do.
Then we can revise the manual on this point. Is that okay with you?
>> As an aside, is there a specific reason you use Emacs in the>> terminal? I know this is useful when, for example, you connect via>> SSH to a remote machine and run Emacs there. But for local usage, I>> find the GUI to be better overall. All Meta keys work, it has no>> issues with colours, and can also mix different font>> families/heights.>>>> For my needs, I don't even use a terminal emulator. I only rely on>> M-x shell. I read that Emacs' vterm package is very good if you need>> to run something in the terminal that uses "graphics", such as the>> htop command. Though I don't use vterm either.>> Several reasons.>> Firstly, I use emacs on my smart phone by remoting ssh to a remote> server. Prot I know you don't use smartphone, but for any other who> read this mailist, I highly recommend Termius app. It is an awesome> mobile SSH app. You can emulate the arrow keys by scrolling the> screen, emulate the mouse click by touching screen. It's even> xterm-256color.
Sounds useful, though I just wonder how usable the small form factor of
the phone is. In general, it is nice to have Emacs everywhere.
> I mainly use emacs on my smartphone for org-mode, I find if I can't> use the true orgmode for my agenda, I am gonna mad. No org-based> mobile app can be rival with true emacs.
Ah yes, the ones I have read about are not providing the Org+Emacs
experience.
> Secondly, I am still in the early age of learning to use emacs (I use> emacs for about 8 months). I tweak my configs quiet often, restarting> emacs in terminal is much faster than GUI. The doom starter says that> it launches in roughly 0.7-1.0s in GUI (but my own perception would by> roughly 2s), while terminal based emacs starts in 0.5-0.7s.
I see. Depending on what you are testing, there is no real need to
restart Emacs: you can just evaluate the new Elisp code and it will take
effect right away. Though it is sometimes better to start from a clean
slate, in which case a restart is preferable.
> I do use GUI emacs for multi media support (for example writing code> to plotting, writing prose, and reading RSS then occasionally opening> the source with xwidget, and reading pdf with writing notes).
I have not tried the xwidget yet, though those are nice features.
> The last reason is the "project/working directory" stuffs. I am more> get used to how vim/neovim handles project. vim/neovim has a concept> of "working directory" and there are plugins which allows to> automatically switch the working directory to your project root. As my> understanding, emacs handles project usually with projectile.el or> project.el. So commands like "eshell/shell/vterm/term" don't start at> the project root, instead they launches in your current buffer's> directory, which is quite annoying. There are "project-eshell" stuffs> which will open the shell in your project root. But by default> project-eshell (and other project-xxx) directly occupieis the window> of your current buffer, which is an annoying result... Doom configures> eshell/vterm/term stuffs pretty well, they all open as a decently> sized popup instead of occupying your current window. But doom does> not configure project-xxx stuffs to do so... Maybe configuring the> rules for those apps would not be difficult, but I haven't figured it> out yet... To be honest I even has some ugly code to handle such kind> of situation (like the attached code). So I find that using emacs in> tmux and running shell in a separate pane is much out of box and> without too much mental overhead.
You can customise the behaviour of all new windows/buffers with the
'display-buffer-alist'. I can show you more, though can also check my
dotfiles: <https://git.sr.ht/~protesilaos/dotfiles>.
> [... 15 lines elided]>> Maintaining your own setup lets you know how everything is pieced>> together. It is easier to expand, tweak, troubleshoot.>> Definitely, I have to write up my own config. This is just on my> agenda. But I don't have enough time to do this. I am satisfied with> a lot of functionalities / configurations doom provide me. Rewriting> my own config to replicate most of them would take too much of time. I> have other higher priorities, so I just put this later.>> I have this ugly code to handle annoying window rules in my config, do> you have any recommendation on how to improve it?> [... 35 lines elided]
With the 'display-buffer-alist' you get fine control over the window
rules. Check it out and I can help you with the technicalities.
--
Protesilaos Stavrou
https://protesilaos.com
On 12/15/22 14:40, Protesilaos Stavrou wrote:
>> Would you consider to record this as a workaround to your official>> manual for modus-theme hosted at>> https://protesilaos.com/emacs/modus-themes section 6.1?>>Yes, though please wait until I merge the 'version-4' branch into>'main'. There are about 200 commits between the two right now and I>still have a lot of work to do.
Awesome! I will wait until then.
>Sounds useful, though I just wonder how usable the small form factor of>the phone is. In general, it is nice to have Emacs everywhere.
You don't want to write code in smartphone definitely. You can't use
autocompletion too, since the screen is too small. Writing and reading
org prose is okay, but I think you *must* use evil bindings in
smartphone, since keychords in smartphone are emulated in a silly way
(additional virtual "ctrl" "alt" keys appeared at the top of your
regular querty virtual keyboard, you firstly touch "ctrl" to "hold" it
then touch "x" to emulate "ctrl-x" and then touch "ctrl" again to
"release" "ctrl"). You have to rely on pressing single key.
I mainly use org-capture and read org-agenda in my smartphone. I also
use it to read RSS.
>> I do use GUI emacs for multi media support (for example writing code>> to plotting, writing prose, and reading RSS then occasionally opening>> the source with xwidget, and reading pdf with writing notes).>>I have not tried the xwidget yet, though those are nice features.
Xwidget is nice. I don't expect xwidget to replace my GUI browser, but
it is nice to browse the contents that uses web stuffs. Like websites
not deployed yet, interactiven plotting...
>You can customise the behaviour of all new windows/buffers with the>'display-buffer-alist'. I can show you more, though can also check my>dotfiles: <https://git.sr.ht/~protesilaos/dotfiles>.
Thanks for your information! I will look at that!
>With the 'display-buffer-alist' you get fine control over the window>rules. Check it out and I can help you with the technicalities.
That's cool! It is my pleasure to talk with you! I enjoy this kind of
communication.
> From: North Year <ny-ml@outlook.com>> Date: Sat, 17 Dec 2022 19:39:43 -0500>> On 12/15/22 14:40, Protesilaos Stavrou wrote:>>> Would you consider to record this as a workaround to your official>>> manual for modus-theme hosted at>>> https://protesilaos.com/emacs/modus-themes section 6.1?>>>>Yes, though please wait until I merge the 'version-4' branch into>>'main'. There are about 200 commits between the two right now and I>>still have a lot of work to do.>> Awesome! I will wait until then.
Only a few days left!
>>Sounds useful, though I just wonder how usable the small form factor of>>the phone is. In general, it is nice to have Emacs everywhere.>> You don't want to write code in smartphone definitely. You can't use> autocompletion too, since the screen is too small. Writing and reading> org prose is okay, but I think you *must* use evil bindings in> smartphone, since keychords in smartphone are emulated in a silly way> (additional virtual "ctrl" "alt" keys appeared at the top of your> regular querty virtual keyboard, you firstly touch "ctrl" to "hold" it> then touch "x" to emulate "ctrl-x" and then touch "ctrl" again to> "release" "ctrl"). You have to rely on pressing single key.
Yes, this makes perfect sense. Trying to type C-x the whole time will
be unwieldy without a dedicated keyboard.
> I mainly use org-capture and read org-agenda in my smartphone. I also> use it to read RSS.
That is useful and where one would normally use some smartphone app.
>>> I do use GUI emacs for multi media support (for example writing code>>> to plotting, writing prose, and reading RSS then occasionally opening>>> the source with xwidget, and reading pdf with writing notes).>>>>I have not tried the xwidget yet, though those are nice features.>> Xwidget is nice. I don't expect xwidget to replace my GUI browser, but> it is nice to browse the contents that uses web stuffs. Like websites> not deployed yet, interactiven plotting...
Interesting! I want to try it at some point.
>>You can customise the behaviour of all new windows/buffers with the>>'display-buffer-alist'. I can show you more, though can also check my>>dotfiles: <https://git.sr.ht/~protesilaos/dotfiles>.>> Thanks for your information! I will look at that!
You are welcome! I have been using it for a long time now and am happy
with the results.
>>With the 'display-buffer-alist' you get fine control over the window>>rules. Check it out and I can help you with the technicalities.>> That's cool! It is my pleasure to talk with you! I enjoy this kind of> communication.
I am happy to be of help!
--
Protesilaos Stavrou
https://protesilaos.com