~pkal/public-inbox

11 2

Emacs Config Generator

Details
Message ID
<843591a9-5f65-0423-00c8-852822a913e5@mgmarlow.com>
DKIM signature
missing
Download raw message
Hey Philip,

I recently ran across your Emacs Config Generator blog post/project and 
wanted to drop you a line that I'm a big fan of the idea. I ended up 
making my own variation that is more catered to newbies like myself, 
particularly for those coming from VS Code. It implements some of the 
suggestions you had in your post, relying on use-package and avoiding 
options for Emacs-y ideas (like minibuffer completion) that new users 
probably don't know too much about. Most of the commentary detail is 
moved into code comments.

Let me know what you think: https://emacs-config-generator.fly.dev/

Best,

Graham
Details
Message ID
<87pm6bob92.fsf@posteo.net>
In-Reply-To
<843591a9-5f65-0423-00c8-852822a913e5@mgmarlow.com> (view parent)
DKIM signature
missing
Download raw message
Graham Marlow <graham@mgmarlow.com> writes:

> Hey Philip,

Hi,

> I recently ran across your Emacs Config Generator blog post/project
> and wanted to drop you a line that I'm a big fan of the idea. 

Thank you!

>                                                               I ended
> up making my own variation that is more catered to newbies like
> myself, particularly for those coming from VS Code. 

I haven't ever really used the program, so I don't know what people
coming from VS Code expect in particular.  Could you explain what you
think that means?

>                                                     It implements some
> of the suggestions you had in your post, relying on use-package and
> avoiding options for Emacs-y ideas (like minibuffer completion) that
> new users probably don't know too much about. Most of the commentary
> detail is moved into code comments.

Adding more commentary to the init.el file is probably a good idea, but
I feel like it is always difficult for someone who uses Emacs to explain
notions like minibuffer completion or the help system.  To a certain
degree I don't know if this is even a realistic goal (e.g. in your case
"Add a lightweight notetaking system that supports backlinks" adds
denote, but I don't how helpful this description or the package is for a
beginner).

> Let me know what you think: https://emacs-config-generator.fly.dev/

As a contrarian Emacs user, there are obviously some design decision I
would disagree with ;^)

That being said, I think it is a good alternative approach, and I find
it interesting that you generate both website and configuration using a
templating language.  Do you think this will scale well?

> Best,
>
> Graham
Details
Message ID
<877csjxkfj.fsf@posteo.net>
In-Reply-To
<87pm6bob92.fsf@posteo.net> (view parent)
DKIM signature
missing
Download raw message
Philip Kaludercic <philipk@posteo.net> writes:

> Graham Marlow <graham@mgmarlow.com> writes:

[...]

>> Let me know what you think: https://emacs-config-generator.fly.dev/
>
> As a contrarian Emacs user, there are obviously some design decision I
> would disagree with ;^)
>
> That being said, I think it is a good alternative approach, and I find
> it interesting that you generate both website and configuration using a
> templating language.  Do you think this will scale well?

Oh, and a few more things.  Why did you decide to use Emacs 29 as the
baseline?  And since you /are/ using Emacs 29, why not recommend the
usage of .config/emacs/init.el.

Another point I wanted to ask you about is the selection of a font.  You
default to a Font called "Monaco", which is not available on my system
and raises an error when I try to evaluate the expression.  As you seem
to know more about proper web development than I do, do you have any
idea how the browser can query the operating system for available fonts,
or at least from a fixed subset of well-known fonts?

-- 
Philip Kaludercic
Details
Message ID
<1d22fd56-aa2d-b35f-c5d7-a012dd6360cf@mgmarlow.com>
In-Reply-To
<87pm6bob92.fsf@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> I haven't ever really used the program, so I don't know what people
> coming from VS Code expect in particular.  Could you explain what you
> think that means?

I think there are some ergonomic differences (vertical completions, code 
completion by default, backups and temp files) and some paradigm 
differences (project-based navigation, file explorer):

- Default Intellisense behavior: code completion is on by default, even 
if you don't have a language's extension or LSP server running.
- File explorer: Dired is a big change from VS Code's drag-and-drop file 
explorer.
- Vertical fuzzy completions for commands: the default Emacs completion 
felt really weird coming from VS Code, I actually thought there wasn't 
minibuffer completion until I read Mastering Emacs and learned about the 
default tab-tab style completion. `fido-vertical-mode' is probably the 
closest built-in.
- Git integration: I don't use it personally but I know a lot of new 
developers who are accustomed to the built-in VS Code git client.
- Backup and temp files: all of the special ~/#-named files that are 
generated alongside the ones you're editing are unexpected, VS Code 
handles backups opaquely.
- Project-based navigation: VS Code offers file search across the 
currently-opened project, which is a bit of a different paradigm from 
Emacs. I use project.el but it doesn't exactly map 1-1, as you might 
expect since Emacs is multi-project by default.

There's quite a few things on this list that I didn't implement myself 
either, I didn't really think of them until I started typing it out
> That being said, I think it is a good alternative approach, and I find
> it interesting that you generate both website and configuration using a
> templating language.  Do you think this will scale well?

It works great when things are simple and independent, but falls apart 
if you want to interact with multiple form values in the same Emacs Lisp 
code chunk. I actually moved languages out of the template since it was 
a bit annoying tailoring the template syntax to the output.

 > Oh, and a few more things. Why did you decide to use Emacs 29 as the
 > baseline?

Good question. I was trying to piggy-back on some of the recent Emacs 29 
interest that has been developing around LSP and tree-sitter, and Emacs 
29 simplifies some of the assumptions made towards use-package.

 > And since you /are/ using Emacs 29, why not recommend the
 > usage of .config/emacs/init.el.

I actually didn't know there were changes or preferences around this for 
Emacs 29, so pure ignorance haha.

 > As you seem to know more about proper web development than I do, do
 > you have any idea how the browser can query the operating system for
 > available fonts, or at least from a fixed subset of well-known fonts?

Here I was thinking Monaco was a safe choice! That's a good 
question--the browser actually handles this with 
https://www.w3.org/TR/CSS2/fonts.html#value-def-generic-family so maybe 
there's a better way of handling it.
Details
Message ID
<87pm6brql5.fsf@posteo.net>
In-Reply-To
<1d22fd56-aa2d-b35f-c5d7-a012dd6360cf@mgmarlow.com> (view parent)
DKIM signature
missing
Download raw message
Graham Marlow <graham@mgmarlow.com> writes:

>> I haven't ever really used the program, so I don't know what people
>> coming from VS Code expect in particular.  Could you explain what you
>> think that means?
>
> I think there are some ergonomic differences (vertical completions,
> code completion by default, backups and temp files) and some paradigm
> differences (project-based navigation, file explorer):
>
> - Default Intellisense behavior: code completion is on by default,
>   even if you don't have a language's extension or LSP server running.

So "Intellisense" is just a marketing term for completion?

> - File explorer: Dired is a big change from VS Code's drag-and-drop
>   file explorer.

That is true.  But Dired also has drag-and-drop capabilities.  I can
drag a file from my file manager into a Dired buffer and it will be
copied over?

That being said, from what I have seen people using VSCode I am not a
fan of the side-bar with the file hierarchy and I think it is not
something that should be encouraged among Emacs users.

> - Vertical fuzzy completions for commands: the default Emacs
>   completion felt really weird coming from VS Code, I actually thought
>   there wasn't minibuffer completion until I read Mastering Emacs and
>   learned about the default tab-tab style
>   completion. `fido-vertical-mode' is probably the closest built-in.

That is why I added the sentence:

  Emacs default completion behaves similar to Bash, in that it first
  attempts to expand a string up until an unambiguous point, then pops
  up a list of possible completions.

The default completion system is actually perfectly usable, and while
Vertico, Fido, etc. have their interesting use-cases, I have previously
argued that the implementation is based on the wrong abstractions:

  https://amodernist.com/texts/emacs-hopes.html#persistent-and-caducous-selection-interface

The default completion is more honest to this system, because it is
actually expanding partial input, instead of prompting the user to
select an option, and using input as a means of narrowing these down.

> - Git integration: I don't use it personally but I know a lot of new
>   developers who are accustomed to the built-in VS Code git client.

Does it do anything special, or is this just being used to a particular
implementation of a Git UI.

> - Backup and temp files: all of the special ~/#-named files that are
>   generated alongside the ones you're editing are unexpected, VS Code
>   handles backups opaquely.

So that is comparable to a customisation along the lines of

  (setopt backup-directory-alist '((".*" . "~/.local/share/backup")))

?

> - Project-based navigation: VS Code offers file search across the
>   currently-opened project, which is a bit of a different paradigm
>   from Emacs. I use project.el but it doesn't exactly map 1-1, as you
>   might expect since Emacs is multi-project by default.

True, I just had a discussion in this topic recently, and was surprised
to find out that VSCode restricts the user to the notion of a workspace.

> There's quite a few things on this list that I didn't implement myself
> either, I didn't really think of them until I started typing it out

I think it is productive to spell these out, to understand what issues
and confusions VSCode users might be having initially.  One you get the
basics of Emacs, it is surprisingly easy to forget what was confusing
(probably because it is a higher-order of misunderstanding).

>> That being said, I think it is a good alternative approach, and I find
>> it interesting that you generate both website and configuration using a
>> templating language.  Do you think this will scale well?
>
> It works great when things are simple and independent, but falls apart
> if you want to interact with multiple form values in the same Emacs
> Lisp code chunk. I actually moved languages out of the template since
> it was a bit annoying tailoring the template syntax to the output.

How come?

>> Oh, and a few more things. Why did you decide to use Emacs 29 as the
>> baseline?
>
> Good question. I was trying to piggy-back on some of the recent Emacs
> 29 interest that has been developing around LSP and tree-sitter, and
> Emacs 29 simplifies some of the assumptions made towards use-package.

Ah OK, that is understandable.  But one should keep in mind that most
users, especially newcomers don't think about Emacs in terms of versions
(ask a random VSCode user what version they are running), and requiring
them to fetch and build a development version -- regardless of it being
in a pre-release stage or not -- is a heavy burden for someone on the
edge, with little to know preconception of what they are getting
themselves into.

>> And since you /are/ using Emacs 29, why not recommend the
>> usage of .config/emacs/init.el.
>
> I actually didn't know there were changes or preferences around this
> for Emacs 29, so pure ignorance haha.

IIRC this has been around since Emacs 26 or 27.

>> As you seem to know more about proper web development than I do, do
>> you have any idea how the browser can query the operating system for
>> available fonts, or at least from a fixed subset of well-known fonts?
>
> Here I was thinking Monaco was a safe choice! That's a good
> question--the browser actually handles this with
> https://www.w3.org/TR/CSS2/fonts.html#value-def-generic-family so
> maybe there's a better way of handling it.

I think that is a styling matter, that is only meaningful inside of the
browser context.  It maps a generic name to a concrete, available font.
I need the inverse function, that would give me the set of fonts that
could be applicable for the generic font-name "monospace".

-- 
Philip Kaludercic
Details
Message ID
<f2097289-129d-ef06-b2ae-93f57a5291d4@mgmarlow.com>
In-Reply-To
<87pm6brql5.fsf@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> So "Intellisense" is just a marketing term for completion
Yep, basically. Mostly emphasizing that it's on by default.

> That is true.  But Dired also has drag-and-drop capabilities.  I can
> drag a file from my file manager into a Dired buffer and it will be
> copied over?
> 
> That being said, from what I have seen people using VSCode I am not a
> fan of the side-bar with the file hierarchy and I think it is not
> something that should be encouraged among Emacs users.

Yeah I tend to agree here. It doesn't really feel like the "Emacs way", 
though of course people are welcome to bring their own package.

>> - Vertical fuzzy completions for commands: the default Emacs
>>    completion felt really weird coming from VS Code, I actually thought
>>    there wasn't minibuffer completion until I read Mastering Emacs and
>>    learned about the default tab-tab style
>>    completion. `fido-vertical-mode' is probably the closest built-in.
> 
> That is why I added the sentence:
> 
>    Emacs default completion behaves similar to Bash, in that it first
>    attempts to expand a string up until an unambiguous point, then pops
>    up a list of possible completions.
> 
> The default completion system is actually perfectly usable, and while
> Vertico, Fido, etc. have their interesting use-cases, I have previously
> argued that the implementation is based on the wrong abstractions:
> 
>    https://amodernist.com/texts/emacs-hopes.html#persistent-and-caducous-selection-interface
> 
> The default completion is more honest to this system, because it is
> actually expanding partial input, instead of prompting the user to
> select an option, and using input as a means of narrowing these down.

I appreciate your take. For me the big advantage of fido-vertical is 
being able to M-x "something along these lines" and discover a new 
function by quickly experimenting with the minibuffer results.

>> - Git integration: I don't use it personally but I know a lot of new
>>    developers who are accustomed to the built-in VS Code git client.
> 
> Does it do anything special, or is this just being used to a particular
> implementation of a Git UI.

It's basically just a combo of that diff-hl package (BTW thanks for the 
tip, never thought to find this one myself) and magit.

>> - Backup and temp files: all of the special ~/#-named files that are
>>    generated alongside the ones you're editing are unexpected, VS Code
>>    handles backups opaquely.
> 
> So that is comparable to a customisation along the lines of
> 
>    (setopt backup-directory-alist '((".*" . "~/.local/share/backup")))
> 
> ?
> 

> True, I just had a discussion in this topic recently, and was surprised
> to find out that VSCode restricts the user to the notion of a workspace.

VSCode does support workspaces, though they have to be configured with 
an extra step or two. But yeah when I was a VSCode user I always opened 
multiple windows via the terminal to swap between projects. One of my 
favorite things since swapping over to Emacs is how trivial it is to 
open separate projects side-by-side w/ project.el.

>>> That being said, I think it is a good alternative approach, and I find
>>> it interesting that you generate both website and configuration using a
>>> templating language.  Do you think this will scale well?
>>
>> It works great when things are simple and independent, but falls apart
>> if you want to interact with multiple form values in the same Emacs
>> Lisp code chunk. I actually moved languages out of the template since
>> it was a bit annoying tailoring the template syntax to the output.
> 
> How come?

It mostly comes down to the idiosyncrasies of the template language and 
figuring out where it will insert extra whitespace.

For a contrived example,

(use-package ef-themes
   :ensure t
   :config
   (ef-themes-select
{%- if theme == "light" -%}
  'ef-duo-light
{%- else -%}
  'autumn
{%- endif -%}))

Note the use of hyphens in the template syntax, those are meant to 
suppress the newline characters between the template expression. It 
becomes very awkward very fast to put complicated expressions in the 
Emacs Lisp itself since you still want the result to be nicely rendered 
with idiomatic formatting.

Perhaps other templating languages would work better here but I'm 
finding Askama (which uses Jinja syntax) to be a bit fiddly.

>>> Oh, and a few more things. Why did you decide to use Emacs 29 as the
>>> baseline?
>>
>> Good question. I was trying to piggy-back on some of the recent Emacs
>> 29 interest that has been developing around LSP and tree-sitter, and
>> Emacs 29 simplifies some of the assumptions made towards use-package.
> 
> Ah OK, that is understandable.  But one should keep in mind that most
> users, especially newcomers don't think about Emacs in terms of versions
> (ask a random VSCode user what version they are running), and requiring
> them to fetch and build a development version -- regardless of it being
> in a pre-release stage or not -- is a heavy burden for someone on the
> edge, with little to know preconception of what they are getting
> themselves into.

Totally fair. I also don't know a whole lot about version compatibility 
for Emacs Lisp, so I didn't want to bite off more than I could chew by 
checking against different versions of Emacs to make sure it worked.

>>> As you seem to know more about proper web development than I do, do
>>> you have any idea how the browser can query the operating system for
>>> available fonts, or at least from a fixed subset of well-known fonts?
>>
>> Here I was thinking Monaco was a safe choice! That's a good
>> question--the browser actually handles this with
>> https://www.w3.org/TR/CSS2/fonts.html#value-def-generic-family so
>> maybe there's a better way of handling it.
> 
> I think that is a styling matter, that is only meaningful inside of the
> browser context.  It maps a generic name to a concrete, available font.
> I need the inverse function, that would give me the set of fonts that
> could be applicable for the generic font-name "monospace".

I did a bit of googling around this one but I don't think there's a 
perfect fit. However, this SO post seems promising: 
https://stackoverflow.com/a/62755574. Unfortunate that it requires JS 
but that's more-or-less a given when you're interacting with the 
client's host environment.

The approach I'm thinking of using is maintaining a sizeable list of 
monospace fonts and using that checking function to filter it down, then 
simply taking the top for the pre-filled input.
Details
Message ID
<87pm6ab9sr.fsf@posteo.net>
In-Reply-To
<f2097289-129d-ef06-b2ae-93f57a5291d4@mgmarlow.com> (view parent)
DKIM signature
missing
Download raw message
Graham Marlow <graham@mgmarlow.com> writes:

>> So "Intellisense" is just a marketing term for completion
>
> Yep, basically. Mostly emphasizing that it's on by default.

OK, thanks for the clarification.

>> That is true.  But Dired also has drag-and-drop capabilities.  I can
>> drag a file from my file manager into a Dired buffer and it will be
>> copied over?  That being said, from what I have seen people using
>> VSCode I am not a fan of the side-bar with the file hierarchy and I
>> think it is not something that should be encouraged among Emacs
>> users.
>
> Yeah I tend to agree here. It doesn't really feel like the "Emacs
> way", though of course people are welcome to bring their own package.

Of course, the issue I think is to avoid appealing to short-term
sensibilities of new-comers that would stand in the way of "properly and
practically" using Emacs in the long-term.  Configuration generators,
"so-called" distributions and templates should all avoid this mistake, IMO.

>>> - Vertical fuzzy completions for commands: the default Emacs
>>>    completion felt really weird coming from VS Code, I actually thought
>>>    there wasn't minibuffer completion until I read Mastering Emacs and
>>>    learned about the default tab-tab style
>>>    completion. `fido-vertical-mode' is probably the closest built-in.
>> That is why I added the sentence:
>>    Emacs default completion behaves similar to Bash, in that it
>> first
>>    attempts to expand a string up until an unambiguous point, then pops
>>    up a list of possible completions.
>> The default completion system is actually perfectly usable, and
>> while
>> Vertico, Fido, etc. have their interesting use-cases, I have previously
>> argued that the implementation is based on the wrong abstractions:
>>    https://amodernist.com/texts/emacs-hopes.html#persistent-and-caducous-selection-interface
>> The default completion is more honest to this system, because it is
>> actually expanding partial input, instead of prompting the user to
>> select an option, and using input as a means of narrowing these down.
>
> I appreciate your take. For me the big advantage of fido-vertical is
> being able to M-x "something along these lines" and discover a new
> function by quickly experimenting with the minibuffer results.

Out of curiosity, do you ever use `apropos-command' (C-h a) or related
commands?  If these commands could be interactively narrowed, would that
make them more appealing?

>>> - Git integration: I don't use it personally but I know a lot of new
>>>    developers who are accustomed to the built-in VS Code git client.
>> Does it do anything special, or is this just being used to a
>> particular
>> implementation of a Git UI.
>
> It's basically just a combo of that diff-hl package (BTW thanks for
> the tip, never thought to find this one myself) and magit.

OK.  And another point, is this VC generic (like vc and diff-hl), or
does it just provide Git support OOTB?

>>> - Backup and temp files: all of the special ~/#-named files that are
>>>    generated alongside the ones you're editing are unexpected, VS Code
>>>    handles backups opaquely.
>> So that is comparable to a customisation along the lines of
>>    (setopt backup-directory-alist '((".*"
>> . "~/.local/share/backup")))
>> ?
>> 

?

>> True, I just had a discussion in this topic recently, and was surprised
>> to find out that VSCode restricts the user to the notion of a workspace.
>
> VSCode does support workspaces, though they have to be configured with
> an extra step or two. But yeah when I was a VSCode user I always
> opened multiple windows via the terminal to swap between projects. One
> of my favorite things since swapping over to Emacs is how trivial it
> is to open separate projects side-by-side w/ project.el.

I might be confusing terminology here, but what is the difference
between a workspace, a window and a project in the VSCode-mentality?
(Sorry for asking so many apparently stupid questions, but these are the
same issues that confused me whenever I tried to take a look at how it
works.)

>>>> That being said, I think it is a good alternative approach, and I find
>>>> it interesting that you generate both website and configuration using a
>>>> templating language.  Do you think this will scale well?
>>>
>>> It works great when things are simple and independent, but falls apart
>>> if you want to interact with multiple form values in the same Emacs
>>> Lisp code chunk. I actually moved languages out of the template since
>>> it was a bit annoying tailoring the template syntax to the output.
>> How come?
>
> It mostly comes down to the idiosyncrasies of the template language
> and figuring out where it will insert extra whitespace.

I don't know in what detail you read through my code, but part of my
solution to this was to have an Elisp-indenter run through the code
before it is sent out to the client.

> For a contrived example,
>
> (use-package ef-themes
>   :ensure t
>   :config
>   (ef-themes-select

On an unrelated point, why use the custom function here instead of
demonstrating to the user that themes can be generically loaded using
`load-theme' with the right argument?

> {%- if theme == "light" -%}
>  'ef-duo-light
> {%- else -%}
>  'autumn
> {%- endif -%}))
>
> Note the use of hyphens in the template syntax, those are meant to
> suppress the newline characters between the template expression. It
> becomes very awkward very fast to put complicated expressions in the
> Emacs Lisp itself since you still want the result to be nicely
> rendered with idiomatic formatting.
>
> Perhaps other templating languages would work better here but I'm
> finding Askama (which uses Jinja syntax) to be a bit fiddly.

I can't help you there, neither of these names mean anything to me ^^.

But what I actually had in mind when asking the question was whether or
not you think that maintaining two separate templates could become
confusing over time?  My approach, which also has its own difficulties
is to use the Common Lisp Object System to define generic objects that
can either be mapped to a HTML form or an Emacs configuration.  In
retrospect I wonder if the complexity was warranted or not.

>>>> Oh, and a few more things. Why did you decide to use Emacs 29 as the
>>>> baseline?
>>>
>>> Good question. I was trying to piggy-back on some of the recent Emacs
>>> 29 interest that has been developing around LSP and tree-sitter, and
>>> Emacs 29 simplifies some of the assumptions made towards use-package.
>> Ah OK, that is understandable.  But one should keep in mind that
>> most
>> users, especially newcomers don't think about Emacs in terms of versions
>> (ask a random VSCode user what version they are running), and requiring
>> them to fetch and build a development version -- regardless of it being
>> in a pre-release stage or not -- is a heavy burden for someone on the
>> edge, with little to know preconception of what they are getting
>> themselves into.
>
> Totally fair. I also don't know a whole lot about version
> compatibility for Emacs Lisp, so I didn't want to bite off more than I
> could chew by checking against different versions of Emacs to make
> sure it worked.

If you are interested in playing around with that field, and have access
to a machine with GNU Guix installed, these package definitions could be
of use: https://git.sr.ht/~pkal/guix-emacs-historical.

>>>> As you seem to know more about proper web development than I do, do
>>>> you have any idea how the browser can query the operating system for
>>>> available fonts, or at least from a fixed subset of well-known fonts?
>>>
>>> Here I was thinking Monaco was a safe choice! That's a good
>>> question--the browser actually handles this with
>>> https://www.w3.org/TR/CSS2/fonts.html#value-def-generic-family so
>>> maybe there's a better way of handling it.
>> I think that is a styling matter, that is only meaningful inside of
>> the
>> browser context.  It maps a generic name to a concrete, available font.
>> I need the inverse function, that would give me the set of fonts that
>> could be applicable for the generic font-name "monospace".
>
> I did a bit of googling around this one but I don't think there's a
> perfect fit. However, this SO post seems promising:
> https://stackoverflow.com/a/62755574. Unfortunate that it requires JS
> but that's more-or-less a given when you're interacting with the
> client's host environment.

I expected that much, and as long as this is an enhancement and not a
critical feature, then something along these lines could be legitimate.
Thanks!

> The approach I'm thinking of using is maintaining a sizeable list of
> monospace fonts and using that checking function to filter it down,

Right.

> then simply taking the top for the pre-filled input.

What does this mean?
Details
Message ID
<349f99d2-41a0-3724-df8e-614329be41a7@mgmarlow.com>
In-Reply-To
<87pm6ab9sr.fsf@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> Out of curiosity, do you ever use `apropos-command' (C-h a) or related
> commands?  If these commands could be interactively narrowed, would that
> make them more appealing?

I haven't actually used that much at all--my usual is `M-x` or `C-h f` 
when I'm searching for a command/function and I rely on descriptive 
function names and Marginalia for the details. Though now that you 
mention it I probably should, in particular `apropos-function' could've 
saved me some trouble in the past.

If it were interactively narrowed that would be helpful, I find it a 
better interface than scrolling or searching the buffer. It would also 
be cool if the return values were more obviously stated.

>>>> - Git integration: I don't use it personally but I know a lot of new
>>>>     developers who are accustomed to the built-in VS Code git client.
>>> Does it do anything special, or is this just being used to a
>>> particular
>>> implementation of a Git UI.
>>
>> It's basically just a combo of that diff-hl package (BTW thanks for
>> the tip, never thought to find this one myself) and magit.
> 
> OK.  And another point, is this VC generic (like vc and diff-hl), or
> does it just provide Git support OOTB?

Nope, just git! If you want another VC provider you have to download a 
community extension.

>>>> - Backup and temp files: all of the special ~/#-named files that are
>>>>     generated alongside the ones you're editing are unexpected, VS Code
>>>>     handles backups opaquely.
>>> So that is comparable to a customisation along the lines of
>>>     (setopt backup-directory-alist '((".*"
>>> . "~/.local/share/backup")))
>>> ?
>>>

Ah, sorry missed one. I think so? Although maybe I'd say a combo of 
`backup-directory-alist' and `global-auto-revert-mode', and probably 
some other variables like `load-prefer-newer' and `backup-by-copying'.

>>> True, I just had a discussion in this topic recently, and was surprised
>>> to find out that VSCode restricts the user to the notion of a workspace.
>>
>> VSCode does support workspaces, though they have to be configured with
>> an extra step or two. But yeah when I was a VSCode user I always
>> opened multiple windows via the terminal to swap between projects. One
>> of my favorite things since swapping over to Emacs is how trivial it
>> is to open separate projects side-by-side w/ project.el.
> 
> I might be confusing terminology here, but what is the difference
> between a workspace, a window and a project in the VSCode-mentality?
> (Sorry for asking so many apparently stupid questions, but these are the
> same issues that confused me whenever I tried to take a look at how it
> works.)

Generally speaking in VS Code a project is just the thing you're working 
on, not an actual feature/term of the editor.

The equivalent to a project.el project is a workspace. That is, a single 
folder that is the root of your file explorer and for your file 
searches, search and replace, etc.

my-project/
   foo.el
   README.md

You can configure a "Multi-root workspace" with JSON, which will allow 
you to have multiple workspaces open in your file explorer:

mutli-root-workspace/
   my-project/
     foo.el
     README.md

   my-project2/
     stuff.txt

You actually have to open a JSON file instead of a folder to use a 
multi-root workspace (since the workspaces that you add to the root can 
be anywhere on your file system) 
https://code.visualstudio.com/docs/editor/workspaces#_multiroot-workspaces.

Workspaces can also contain a .vscode/ folder that's equivalent to a 
dir-locals.el (though in JSON instead of an actual programming language).

By window I mean a running instance of the program. e.g. I would use the 
vscode command in my terminal to launch multiple VS Code instances, one 
for each project (directory) I was working in.

>>>>> That being said, I think it is a good alternative approach, and I find
>>>>> it interesting that you generate both website and configuration using a
>>>>> templating language.  Do you think this will scale well?
>>>>
>>>> It works great when things are simple and independent, but falls apart
>>>> if you want to interact with multiple form values in the same Emacs
>>>> Lisp code chunk. I actually moved languages out of the template since
>>>> it was a bit annoying tailoring the template syntax to the output.
>>> How come?
>>
>> It mostly comes down to the idiosyncrasies of the template language
>> and figuring out where it will insert extra whitespace.
> 
> I don't know in what detail you read through my code, but part of my
> solution to this was to have an Elisp-indenter run through the code
> before it is sent out to the client.

Smart!

>> Perhaps other templating languages would work better here but I'm
>> finding Askama (which uses Jinja syntax) to be a bit fiddly.
> 
> I can't help you there, neither of these names mean anything to me ^^.
> 
> But what I actually had in mind when asking the question was whether or
> not you think that maintaining two separate templates could become
> confusing over time?  My approach, which also has its own difficulties
> is to use the Common Lisp Object System to define generic objects that
> can either be mapped to a HTML form or an Emacs configuration.  In
> retrospect I wonder if the complexity was warranted or not.

Oh in terms of the HTML and init.el template I think it's worth keeping 
them separate. I think of the GET request that generates the Emacs Lisp 
code as its own API, it just happens to take its arguments in the form 
of query parameters submitted via an HTML form. Past web experience has 
me recollecting too many times where accessible form controls make for 
awkward APIs, it's tough to tie the two together if you want to tweak 
your presentation a lot.

I see lots of value in having the entire Emacs Lisp generation 
controlled by a programming language though, for those cases where 
there's an intersection of different API arguments that interact with 
the same snippet of Emacs Lisp. That's actually why I avoid adding 
`eglot-ensure` blocks for languages picked by the user in my 
implementation--I'll likely move the Eglot snippet to Rust so I can more 
easily tweak it based on a bunch of form values.

> If you are interested in playing around with that field, and have access
> to a machine with GNU Guix installed, these package definitions could be
> of use: https://git.sr.ht/~pkal/guix-emacs-historical.

I've been wanting to check out Guix but I'm currently on Mac OS. Thanks 
for the tip!

>> The approach I'm thinking of using is maintaining a sizeable list of
>> monospace fonts and using that checking function to filter it down,
> 
> Right.
> 
>> then simply taking the top for the pre-filled input.
> 
> What does this mean?

Something like,

document.getElementById("font_family").value =
   availableMonospaceFonts[0];
Details
Message ID
<87edmmlan9.fsf@posteo.net>
In-Reply-To
<349f99d2-41a0-3724-df8e-614329be41a7@mgmarlow.com> (view parent)
DKIM signature
missing
Download raw message
Graham Marlow <graham@mgmarlow.com> writes:

>> Out of curiosity, do you ever use `apropos-command' (C-h a) or related
>> commands?  If these commands could be interactively narrowed, would that
>> make them more appealing?
>
> I haven't actually used that much at all--my usual is `M-x` or `C-h f`
> when I'm searching for a command/function and I rely on descriptive
> function names and Marginalia for the details. Though now that you
> mention it I probably should, in particular `apropos-function'
> could've saved me some trouble in the past.

That is why I think that investing energy into the completing-read
interface is a mistake, despite the short-term convenience/comfort that
it might provide.

> If it were interactively narrowed that would be helpful, I find it a
> better interface than scrolling or searching the buffer. It would also
> be cool if the return values were more obviously stated.

Return values?  Commands don't have return values, that might be
relevant for the other apropos commands.

>>>>> - Git integration: I don't use it personally but I know a lot of new
>>>>>     developers who are accustomed to the built-in VS Code git client.
>>>> Does it do anything special, or is this just being used to a
>>>> particular
>>>> implementation of a Git UI.
>>>
>>> It's basically just a combo of that diff-hl package (BTW thanks for
>>> the tip, never thought to find this one myself) and magit.
>> OK.  And another point, is this VC generic (like vc and diff-hl), or
>> does it just provide Git support OOTB?
>
> Nope, just git! If you want another VC provider you have to download a
> community extension.

Interesting, but I guess they know their audience.

>>>>> - Backup and temp files: all of the special ~/#-named files that are
>>>>>     generated alongside the ones you're editing are unexpected, VS Code
>>>>>     handles backups opaquely.
>>>> So that is comparable to a customisation along the lines of
>>>>     (setopt backup-directory-alist '((".*"
>>>> . "~/.local/share/backup")))
>>>> ?
>>>>
>
> Ah, sorry missed one. I think so? Although maybe I'd say a combo of
> `backup-directory-alist' and `global-auto-revert-mode', and probably
> some other variables like `load-prefer-newer' and `backup-by-copying'.

Ok, thanks.

>>>> True, I just had a discussion in this topic recently, and was surprised
>>>> to find out that VSCode restricts the user to the notion of a workspace.
>>>
>>> VSCode does support workspaces, though they have to be configured with
>>> an extra step or two. But yeah when I was a VSCode user I always
>>> opened multiple windows via the terminal to swap between projects. One
>>> of my favorite things since swapping over to Emacs is how trivial it
>>> is to open separate projects side-by-side w/ project.el.
>> I might be confusing terminology here, but what is the difference
>> between a workspace, a window and a project in the VSCode-mentality?
>> (Sorry for asking so many apparently stupid questions, but these are the
>> same issues that confused me whenever I tried to take a look at how it
>> works.)
>
> Generally speaking in VS Code a project is just the thing you're
> working on, not an actual feature/term of the editor.
>
> The equivalent to a project.el project is a workspace. That is, a
> single folder that is the root of your file explorer and for your file
> searches, search and replace, etc.
>
> my-project/
>   foo.el
>   README.md
>
> You can configure a "Multi-root workspace" with JSON, which will allow
> you to have multiple workspaces open in your file explorer:
>
> mutli-root-workspace/
>   my-project/
>     foo.el
>     README.md
>
>   my-project2/
>     stuff.txt

I guess this would be comparable to `project-external-roots'?

> You actually have to open a JSON file instead of a folder to use a
> multi-root workspace (since the workspaces that you add to the root
> can be anywhere on your file system)
> https://code.visualstudio.com/docs/editor/workspaces#_multiroot-workspaces.
>
> Workspaces can also contain a .vscode/ folder that's equivalent to a
> dir-locals.el (though in JSON instead of an actual programming
> language).

To be fair, .dir-locals.el is just an s-expression and cannot be evaluated.

> By window I mean a running instance of the program. e.g. I would use
> the vscode command in my terminal to launch multiple VS Code
> instances, one for each project (directory) I was working in.
>
>>> The approach I'm thinking of using is maintaining a sizeable list of
>>> monospace fonts and using that checking function to filter it down,
>> Right.
>> 
>>> then simply taking the top for the pre-filled input.
>> What does this mean?
>
> Something like,
>
> document.getElementById("font_family").value =
>   availableMonospaceFonts[0];

I don't get what this is supposed to do.
Details
Message ID
<1bc48d71-54d4-82d0-9049-8d4026768d48@mgmarlow.com>
In-Reply-To
<87edmmlan9.fsf@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> Return values?  Commands don't have return values, that might be
> relevant for the other apropos commands.

Referring to `apropos-function'.

>> Generally speaking in VS Code a project is just the thing you're
>> working on, not an actual feature/term of the editor.
>>
>> The equivalent to a project.el project is a workspace. That is, a
>> single folder that is the root of your file explorer and for your file
>> searches, search and replace, etc.
>>
>> my-project/
>>    foo.el
>>    README.md
>>
>> You can configure a "Multi-root workspace" with JSON, which will allow
>> you to have multiple workspaces open in your file explorer:
>>
>> mutli-root-workspace/
>>    my-project/
>>      foo.el
>>      README.md
>>
>>    my-project2/
>>      stuff.txt
> 
> I guess this would be comparable to `project-external-roots'?

Whoa, had no idea that existed. Very interesting!

>> Something like,
>>
>> document.getElementById("font_family").value =
>>    availableMonospaceFonts[0];
> 
> I don't get what this is supposed to do.

It actually ended up being more complicated than what was originally 
proposed by that SO post, I noticed the font check API didn't work 
properly with Firefox. The full solution I ended up going with involves 
some copy-paste from that same thread: 
https://github.com/mgmarlow/emacs-config-generator/blob/main/static/fontselector.js. 
I would love for an easier way to get a valid font but I guess it's an 
uncommon use-case since it's usually handled by the browser engine.

The original code snippet from the email thread (a) grabs the input 
element for font family in the form by its ID (e.g. <input 
id="font_family" />, (b) sets its value to the first element from the 
list availableMonospaceFonts. That effectively sets the default value in 
the form, assuming the JS script is placed at the bottom of the page and 
loads after the HTML does.
Details
Message ID
<871qii2rhj.fsf@posteo.net>
In-Reply-To
<1bc48d71-54d4-82d0-9049-8d4026768d48@mgmarlow.com> (view parent)
DKIM signature
missing
Download raw message
Graham Marlow <graham@mgmarlow.com> writes:

>> Return values?  Commands don't have return values, that might be
>> relevant for the other apropos commands.
>
> Referring to `apropos-function'.

There has recently been some development for compiled functions:

https://yhetil.org/emacs-devel/xjfzg5v0zhj.fsf@ma.sdf.org/

But generally speaking, it wouldn't be possible to type ever function,
as this is not statically annotated and can not be computed.

>>> Generally speaking in VS Code a project is just the thing you're
>>> working on, not an actual feature/term of the editor.
>>>
>>> The equivalent to a project.el project is a workspace. That is, a
>>> single folder that is the root of your file explorer and for your file
>>> searches, search and replace, etc.
>>>
>>> my-project/
>>>    foo.el
>>>    README.md
>>>
>>> You can configure a "Multi-root workspace" with JSON, which will allow
>>> you to have multiple workspaces open in your file explorer:
>>>
>>> mutli-root-workspace/
>>>    my-project/
>>>      foo.el
>>>      README.md
>>>
>>>    my-project2/
>>>      stuff.txt
>> I guess this would be comparable to `project-external-roots'?
>
> Whoa, had no idea that existed. Very interesting!

You are probably surprised, because this functionality is not that
widely used.

>>> Something like,
>>>
>>> document.getElementById("font_family").value =
>>>    availableMonospaceFonts[0];
>> I don't get what this is supposed to do.
>
> It actually ended up being more complicated than what was originally
> proposed by that SO post, I noticed the font check API didn't work
> properly with Firefox. The full solution I ended up going with
> involves some copy-paste from that same thread:
> https://github.com/mgmarlow/emacs-config-generator/blob/main/static/fontselector.js. I
> would love for an easier way to get a valid font but I guess it's an
> uncommon use-case since it's usually handled by the browser engine.

That was also my intuition.

> The original code snippet from the email thread (a) grabs the input
> element for font family in the form by its ID (e.g. <input
> id="font_family" />, 

That much Javascript even I know ;)

>                      (b ) sets its value to the first element from the
> list availableMonospaceFonts. That effectively sets the default value
> in the form, assuming the JS script is placed at the bottom of the
> page and loads after the HTML does.

This was the part that confused me.  Unless `availableMonospaceFonts'
was some kind of special variable, which to my understanding it is not,
then this just defers the issue to the definition of that variable.

I'll take a look at your code, and with your permission perhaps adapt it
at some point to work with my configurator?

~

Another thing I just noticed, as you are assuming Emacs 29, you can use
C-h o to combine C-h f and C-h v into a single command.  And if I may
make a suggestion, I'd like to mentioned C-h C-q as a worthy candidate
of also being mentioned.

-- 
Philip Kaludercic
Details
Message ID
<5d1ed2c7-8aa4-f452-99d4-214497acbba4@mgmarlow.com>
In-Reply-To
<871qii2rhj.fsf@posteo.net> (view parent)
DKIM signature
missing
Download raw message
> This was the part that confused me.  Unless `availableMonospaceFonts'
> was some kind of special variable, which to my understanding it is not,
> then this just defers the issue to the definition of that variable.

Hah, yes sorry. That variable is just a hard-coded list of monospace 
fonts, filtered by the technique in the aforementioned SO post to only 
include the ones available on the client's OS.

> I'll take a look at your code, and with your permission perhaps adapt it
> at some point to work with my configurator?

Absolutely, please do.

> Another thing I just noticed, as you are assuming Emacs 29, you can use
> C-h o to combine C-h f and C-h v into a single command.  And if I may
> make a suggestion, I'd like to mentioned C-h C-q as a worthy candidate
> of also being mentioned.

Great suggestions, thanks!
Reply to thread Export thread (mbox)